tempest.blog

Semana passada, na conferência de segurança Ekoparty, foi apresentada um artigo com uma técnica e uma ferramenta associada (batizada de "BEAST") que viabiliza certos tipos de ataque mesmo em sites protegidos com HTTPS. Neste artigo, vou apenas prover algumas receitas práticas de mitigar o ataque e algumas referências externas para você se informar melhor; depois eu escrevo um outro artigo explicando como o ataque funciona, o que está sendo feito a respeito e meus comentários filosóficos usuais.

Para esse artigo sair rápido, eu deixei de lado meu processo usual de finalização e revisão – publiquei mesmo antes do artigo poder ser considerado "pronto", de forma que tem algumas coisas faltando. Vou atualizado à medida em que for confirmando tudo e terminando de escrever. Portanto, abuse do F5 nessa página. :)

Driblando o Ataque

O ataque explora uma falha (já discutida teoricamente desde 2004) no modo de encadeamento CBC dos algoritmos de cifragem simétrica. Em tese, a técnica se aplica a qualquer algoritmo de bloco encadeado em modo CBC, independente do algoritmo de cifragem principal (AES, DES, etc.)

O protocolo SSL/TLS permite que o servidor e o cliente negociem um conjunto comum de algoritmos criptográficos a serem utilizados e a maioria das implementações permite que isso seja ajustado nas configurações. Assim, uma maneira de mitigar o problema a curto prazo é reconfigurar os servidores para preferirem um algortimo de stream (tal como o ARCFOUR) ao invés de um algoritmo de bloco (tal como as diversas variantes do AES que o TLS só oferece em modo CBC).

A melhor escolha é o algoritmo ARCFOUR-128¹ (tendo o cuidado para não inadvertidamente ativar o ARCFOUR-40, que é inseguro contra busca exaustiva), pois ele é provavelmente o único que praticamente toda implementação suporta, evitando problemas de compatibilidade.

Algumas receitinhas prontas:

• Se você usa o Apache com mod_ssl (tanto o externo da série 1.3 quanto o embutido do 2.0 em diante), acrescente as seguintes linhas nas configurações dos seus virtual hosts:

SSLHonorCipherOrder on
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!AES:!DES:RC4-SHA:RC4-MD5:ALL

• Para o IIS, veja as instruções de mitigação nesta página (agradecimentos ao Fernando Cima pelo link).

Após aplicar essas mudanças, reinicie o seu servidor web e teste usando seu navegador. Ao acessar seu site, peça para o navegador mostrar as informações da conexão (CONTROL+I, no Firefox). Ele deverá informar que a cifragem utilizada é a RC4 (que, para nossos fins aqui, é a mesma coisa que ARCFOUR) com 128 bits, tal como no trecho destacado em vermelho na figura abaixo:

Se ele disser qualquer coisa com menos de 128 bits, a cifragem é fraca, suscetível a busca exaustiva, e muita gente diz que você não deveria utilizá-la (uma questão filosófica: é melhor usar uma cifra fraca mas pouco atacada do que uma cifra forte com uma vulnerabilidade recente e em uso?) Se aparecer que ele está usando AES ou DES, com qualquer tamanho de chave, ou se aparecer algo com CBC, a contramedida não está ativada – retrace seus passos e veja onde errou.

Referências

• Blog post do Duong com vídeo do ataque apresentado na Ekoparty (grato, Pimpão!)
• Post do Eric Rescola (autor deste livro, considerado um clássico) explicando os aspectos criptográficos do ataque e um pouco do contexto histórico relevante do TLS.

¹ alguns diriam "a menos ruim", pois o ARCFOUR também tem outras fraquezas; mas, como aparentemente nenhuma delas está sendo ativamente explorada, o ARCFOUR acaba sendo o "menor dentre dois males"

Victor,

1) Idealmente, sim. No mundo acadêmico, o modo CBC já é considerado inadequado há um bom tempo.

2) Não sei se entendi sua pergunta... a que algoritmos você se refere, exatamente?

3) Eu sou fã do integer counter mode. É simples, não padece dos problemas dos demais modos e oferece acesso aleatório ao keystream.

4) O problema é intrínseco ao modo de operação.

Kiko,

Gostei do artigo, bem prático e rápido. Que acho que é o que precisamos no momento... Correr pra mitigar o ataque :P

No entanto não cheguei a estudar o ataque do BEAST profundamente e me surgiram algumas dúvidas:

1) Isso quer dizer que deveríamos evitar usar algorítmos com cifra de bloco (CBC) em todas as aplicações da criptografia, incluindo o SSL/TLS?

2) Você acha que existem grandes chances de outras implementações desses algorítimos terem falhas grandes como essas do SSL/TLS?

3) E os modos de operação PCBC, CFB, OFB, CTR, xCBC e etc... Seriam possíveis substitutos para resolver esse problema do CBC?

4) Ou isso nada disso seria necessário...? O problema estaria na implementação do algorítimo ou no modo de operação em si?

Well, foram tantas perguntas que deixo você a vontade para responde-las em outro post :P

Obrigado Kiko. Na parte relativa ao uso de RC4, o link acima vale não só para o IIS mas também para clientes Windows a partir do Windows Vista. Até o momento não existem ainda paliativos para o Windows XP.

Grato pelos links, Goncales.

Eu não recomendo ativar o TLS versão >= 1.1, pelo menos por enquanto, porque muitos clientes e navegadores ainda não suportam. É a melhor solução a longo prazo, mas inviável por enquanto. Pretendo me aprofundar nisso em um artigo futuro.

Boa Iniciativa,

Lembre que para casos de ativar o TLS 1.1 ou 1.2, depende do suporte dos browsers que vários ainda não possuem.

Segue alguns links da microsoft com mais informações:

• http://technet.microsoft.com/security/advisory/2588513
• http://blogs.technet.com/b/msrc/
• http://blogs.technet.com/b/srd/

[]s