Webfight - Automatizando a análise passiva de aplicações web

Conforme prometido, acabo de publicar os fontes da ferramenta que eu lancei na OWASP AppSec Latam deste ano. A ferramenta chamada WebFight é Open Source e pretendo ir incrementando e lançando novas atualizações de acordo com a minha necessidade e claro, espero a contribuição da comunidade.

A idéia

A WebFight nasceu da minha necessidade de lidar com um número grande de informações que uma aplicação web pode gerar. Como eu quero continuar analisando os detalhes de cada requisição e não adotar um web security scanner, decidi criar uma ferramenta que automatizasse a análise de um log de proxy. Assim eu continuo analisando os detalhes manualmente, mas ganhando muito tempo na análise do log.

A ferramenta

A idéia foi fazer um parser do log do Burp e a partir deste parser criar módulos para realizar as análises. A estrutura da ferramenta é resumida no fluxo a seguir:

A ferramenta é facilmente estendida criando módulos e as seguintes análises já estão implementadas:

• Apresenta todas as requisições e seus parâmetros para que sejam realizados testes fuzzing e de validação de dados


• Apresenta todos os status codes, possibilitando identificar erros 500; Redirects 30x; Conteúdo estático 0


• Apresenta as requisições fora do escopo da análise para identificar integrações, ou requests a outros domínios


• Realiza um fingerprint a partir da análise de headers e informações da aplicação


• Apresenta todos os cookies de sessão e a existência de cookies de sessão passados como parâmetro em requisições GET


• Cria PoC em arquivos html de todas as requisições com parâmetros para que seja testado CSRF


• Faz grep e identifica objetos DOM (password; hidden; file upload; iframe; etc...)


• Apresenta todos os comentários em client-side (HTML e javascript)


• Identifica arquivos javascript e javascripts no corpo da página apresentando o conteúdo com syntaxhighlight e realiza análise sintática no javascript apresentando Sink e Sources potencialmente perigosos


• Identifica arquivos swf; realiza download; desassembla o swf e faz grep buscando características potencialmente vulneráveis em flash


• Apresenta todas as respostas em JSON


• Apresenta todos as diretivas de cache nos headers Pragma e Cache-Control


• Apresenta as diretivas de segurança de headers CSP; HSTS e X-Frame-Options


• Apresenta o base64 do header authorization (autenticação básica de HTTP)

A Interface

A interface também facilita bastante a análise por classificar as análises e possibilita que se pesquise e filtre os registros apresentados.

Demo

 

Aguardo feedback e requisição de outras análises. Faça um clone do Git na página do Projeto e participe da lista de discussão.

A besta assusta, mas nem tudo está perdido

Na última Ekoparty foi apresentada uma técnica de exploração de uma falha antiga na configuração do SSL/TLS 1.0 via browser. O ataque foi identificado pelos pesquisadores Juliano Rizzo e Thai Duong e foi batizado como BEAST (Browser Exploit Against SSL/TLS).

A pesquisa foi brilhante e mostrou mais uma vez a destreza dos pesquisadores, mas assim como a outra pesquisa apresentada pela mesma dupla no ano passado: Padding Oracle Attack, gerou muita confusão e FUD na mídia. A do ano passado gerou pânico nos desavisados que achavam que o ataque era uma nova aterrorizante maneira de explorar banco de dados Oracle e a deste foi um prato cheio para a mídia, pois supostamente eles iriam derrubar um gigante da web o SSL. Além das fragilidades em algumas implementações eu aprendi com estes pesquisadores o poder de um bom título para palestras. Lembram das dicas de Jeremiah Grossman para ter um paper aprovados?

O ataque

Explorado em client-side, depende de alguma ação que irá fazer a vítima carregar um conteúdo malicioso em javascript que irá utilizar características do websocket do HTML5  ou outras técnicas de bypass para realizar requisições quebrando a SOP (Same-Origin Policy). O javascript irá explorar uma falha antiga no algoritmo CBC (Cipher Block Chaining) para conseguir decifrar em client-side o conteúdo cifrado pelo SSL/TLS 1.0. No blog do Thai Duong tem alguns detalhes sobre a pesquisa e um vídeo mostrando um PoC, também recomendo a leitura dos posts falando do Chrome e o Opera frente ao BEAST.

Porque o mundo não acabou com este ataque?

Ao contrário do que muita gente achava a falha não quebra o SSL/TLS, ele consegue via browser e um ataque client-side (esta vulnerabilidade no CBC já foi explorado em VPN) explorar uma fragilidade de configuração (porque você pode usar o RC4 como workaround para mitigar isto e muitos serviços já utilizam recursos contra esta fragilidade) e conseguir tornar viável a identificação do ID de sessão. Apesar de na teoria ser possível ter o conteúdo todo em texto claro, o poder computacional necessário é alto para isto, o que inviabiliza muitos ataques. Uma outra característica importante é que o usuário que for realizar o ataque precisa estar no mesmo segmento de rede da vítima, o que restringe bastante a superfície de ataque. Ai eu pergunto: se eu preciso estar no mesmo segmento, explorar uma falha client-side, porque não fazer algo mais fácil? Existem n ataques para sequestrar uma sessão e ferramentas "dummies" como BeEF e Firesheep. A pesquisa é fantástica, mas a aplicabilidade em ataques reais é contestável.

Alguns pesquisadores estão apresentando alternativas ao SSL/TLS, como o Convergence apresentado por Moxie Marlinspike's (lembra do SSLStrip?), mas recomendo manter a tranquilidade, consultar o TLS/SSL Hardening & Compatibility Report e o Cheat Sheet da OWASP para configurar adequadamente o seu ambiente e se manter protegido. Claro, até quando ninguém pode garantir.