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.
Um comentário:
Ótimo post.
Congrats!
Postar um comentário