O mito do cadeado de segurança

Desde a divulgação, em 2011, de uma vulnerabilidade que permite a captura de informações devido a falhas noprotocolo SSL/TLS – conhecida como BEAST [1] (Browser Exploit Against SSL/TLS), descoberta pelos pesquisadores Thai Duong e Juliano Rizzo –, a segurança proporcionada pelo protocolo HTTPS foi colocada em questão.

Empresas como Mozilla e Microsoft anunciaram correções em suas implementações do protocolo SSL… Mas um novo ataque denominado CRIME [2](Compression Ratio Info-leak Made Easy) foi anunciado em 2012 pelos mesmos pesquisadores do BEAST. O CRIME possibilitava a recuperação de dados dos cookies de autenticação, permitindo que um atacante roubasse a sessão de um usuário autenticado.

Na época, o procedimento recomendado para mitigar essas falhas foi o uso do algoritmo RC4[3]. Porém, em março de 2013, os pesquisadores AlFardan, Bernstein, Paterson, Poettering e Schuldt demonstraram uma falha na cifra RC4, que permitia que se recuperasse parte dos dados de uma conexão TLS, em texto plano.

Para piorar ainda mais a situação, no final do mês passado (julho de 2013), durante a conferência BlackHat, mais um ataque contra o protocolo HTTPS foi divulgado: o BREACH[4] (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), apresentado pelos pesquisadores Angelo Prado, Neal Harris e Yoel Gluck. Bastante parecido com o CRIME, exceto pelo fato de que o ataque BREACH é feito usando técnicas de MITM (Man in the Middle) para capturar tokens CSRF[5]. Afinal, sem a compressão do TLS, forma de mitigar o ataque CRIME, é muito comum o uso da biblioteca gzip para fazer a compressão dos dados. Durante a apresentação no evento, o BREACH possibilitou a captura de um token criptografado de 30 caracteres, em 30 segundos.

Por meio de um teste simples, identificamos falhas no protocolo HTTPS usado por algumas instituições financeiras, como mostra a imagem abaixo:

Na imagem, os resultados de um teste no protocolo HTTPS de uma grande instituição financeira brasileira provam que servidores de bancos aceitam conexões com cifras fracas.

Ataques como BEAST, CRIME e BREACH demonstram a fragilidade no uso do protocolo TLS e mostram a necessidade de atualização das especificações técnicas voltadas para segurança tanto do protocolo TLS quanto do protocolo HTTP.

Para mitigar estas vulnerabilidades, recomendamos as seguintes ações:

1. Desabilitar a compressão TLS
2. Ativar o suporte dos protocolos TLS 1.2 e AES-GCM
3. Usar técnica de XORing com um segredo randômico por requisição, a fim de dificultar a previsibilidade na geração de números
4. Ofuscar o tamanho de respostas web adicionando bytes arbitrários randomicamente
5. Fazer uso do Foward Secrecy[6] no servidor web
6. Criar proteções nas páginas contra ataques de CSRF[7]

Saiba mais sobre o BREACH: http://nakedsecurity.sophos.com/2013/08/06/anatomy-of-a-cryptographic-oracle-understanding-and-mitigating-the-breach-attack/

Descubra se seus usuários estão correndo riscos por conta dos ataques BEAST, CRIME e BREACH.

Referências:

[1] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
[1] http://thehackernews.com/2012/04/90-ssl-sites-vulnerable-to-beast-ssl.html
[2] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4929
[3] http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html
[4] http://www.isg.rhul.ac.uk/tls/http://www.kb.cert.org/vuls/id/987798
[4] http://threatpost.com/breach-compression-attack-steals-https-secrets-in-under-30-seconds/101579
[5]https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
[6]http://blog.ivanristic.com/2013/06/ssl-labs-deploying-forward-secrecy.html
[6]http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
[7]https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Fonte:  | iBLISS Segurança e Inteligência
O mito do cadeado de segurança | iBLISS Segurança e Inteligência