Um resumo sobre a vulnerabilidade do DNS

De juliano.info

Este é um resumo dos eventos envolta da recentemente descoberta vulnerabilidade do Sistema de Nomes de Domínio (DNS). Em poucas palavras, um dos protocolos de núcleo da Internet possui uma séria falha de projeto. Esta falha compromete todo o sistema de nomes de domínio, a privacidade e a segurança de todos os usuários da Internet. Não há solução real pronta para desenrolar hoje, mas correções para mitigar o problema foram liberadas. É importante verificar seu sistema e tomar ação imediata se você descobrir que está vulnerável.

Continue lendo para mais informações.

Tabela de conteúdo

Introdução

O Sistema de Nomes de Domínio, também conhecido como DNS, é um banco-de-dados distribuído e hierárquico de nomes de domínio e endereços IP, é um dos protocolos de núcleo da Internet. Ele trabalha como uma lista telefônica, onde você pergunta por um nome (como google.com), e ele retorna o número que seu computador deve "discar" (como 64.233.167.99) de forma a contactar o destino correto. Na verdade, é um pouco mais complexo do que isso, mas isto deve ser suficiente para pessoas não familiares com os protocolos de Internet para entender a importância do DNS.

Foi criado pouco depois do desenrolar do TCP/IP, quando a ARPAnet se tornou o que hoje conhecemos como a Internet. Isso foi há vinte e cinco anos atrás, e assim como a maioria da tecnologia daquela época, sofreu alguns problemas em relação a escalabilidade e a segurança demandada pelo subestimado crescimento da Internet.

Apesar do DNS ter sido projetado para escalar bem, as preocupações com segurança eram bem diferentes há 25 anos atrás. Assim como com vários sistemas legados que conseguem sobreviver por tanto tempo, não é mais tecnicamente viável substituir o DNS por qualquer coisa diferente, sem com isso quebrar a Internet ao meio. É perfeitamente comparável com outras tecnologias com grandes problemas de escalabilidade e segurança, como o IPv4 e o SMTP. Muitas novas tecnologias foram inventadas de forma a corrigir ou mitigar este problemas, como o NAT para o IPv4 e o SPF para o SMTP. Mas estas tecnologias são, na maioria dos casos, muito difíceis de se desenrolar ou traz reluzentes novos problemas consigo mesmas. A solução preferida, quando viável, é trocar para uma nova tecnologia a par com os padrões atuais. Essa é uma tarefa inerentemente difícil, mesmo se todas as medidas necessárias forem planejadas com antecedência, como estamos observando hoje com a (muito mais lenta do que esperada) adoção e desenrolamento da próxima geração do protocolo Internet (IPv6).

O DNS também teve sua parcela de vulnerabilidades de segurança, que foram descobertas e corrigidas no passado. A maior parte dessas vulnerabilidades envolvem o envenenamento do cache DNS, onde seu resolvedor de nomes de domínio é induzido a acreditar que um servidor de nomes de domínio diferente (pertencente ao atacante) tem autoridade sobre um certo nome de domínio. Uma vez que os nomes de domínio são hierárquicos, dependendo do nível almejado pelo ataque, isso pode resultar em alguns cenários bastante assustadores, onde enormes ramificações da árvore de nomes de domínio (imagine, por exemplo, todos os domínios sob ".com") são delegados para os servidores do atacante. Isso significa que seu resolvedor estará perguntando à pessoa errada sobre qual número "discar" quando você conecta a um sítio.

Algumas tecnologias para mitigar as fraquezas do Sistema de Nomes de Domínio foram projetadas, especificamente, as extensões de segurança do DNS (DNSSEC). O DNSSEC melhora a segurança do DNS usando autenticação criptográfica. Infelizmente, as grandes mudanças na infraestrutura necessárias para o DNSSEC e alguns outros poucos mas significantes problemas não resolvidos impedem seu desenrolar.

O Sistema de Nomes de Domínio, como é hoje, é extremamente inseguro. Isso foi evidenciado com a recente descoberta por Dan Kaminsky de uma forma bem simples e fácil de envenenar o cache de qualquer resolvedor de nomes de domínio. Reparos coordenados para mitigar o problema foram liberados pelos maiores provedores de software de DNS, mas o problema é ainda de grande preocupação.

Seqüência de eventos

Em 8 de julho, 2008, vários fornecedores de software de DNS coordenadamente liberaram correções para mitigar um suposto ataque de envenenamento de cache. A revelação pública da vulnerabilidade (sem detalhes) seguiu a liberação das correções.

Notificações dos fornecedores e correções:

Alertas de segurança:

Cobertura da mídia:

As correções consistem em aleatorizar as portas de origem UDP de todas as consultas realizadas pelos resolvedores de nome de domínio. Elas não corrigem de fato o problema, elas apenas tornam mais difícil para atacantes injetarem respostas forjadas aos resolvedores de nomes de domínio. Note que o DJBDNS não precisa de correção, uma vez que este já fazia aleatorização das portas de origem desde o começo.

Uma vez que nenhuma revelação completa estava imediatamente disponível (de forma a dar algum tempo para administradores de rede corrigirem seus sistemas), todos começaram a especular sobre a vulnerabilidade.

Em 14 de julho, Paul Vixie, autor de vários RFCs da Internet, autor do software servidor de nomes de domínio BIND e fundador do Internet Software Consortium, respondeu aos céticos sobre a vulnerabilidade do DNS, e reforçou sobre a importância de corrigir teus sistemas o quanto antes possível.

Em 21 de julho, depois de muita especulação por parte de vários especialistas em segurança, alguns eventos levaram à confirmação e a revelação dos detalhes da vulnerabilidade no Matasano blog. A informação foi retirada do sítio duas horas depois, mas não sem ser espalhada para vários outros sítios.

Em 23 de julho, o código que explora a vulnerabilidade se tornou público. Quinze dias depois que as correções para mitigar o problema foram liberadas.

Teste seu sistema

Você pode verificar o seu sistema através do blog de Kaminsky. Clique no botão "Check My DNS" na coluna da direita, e você deverá ver uma análise da segurança do seu resolvedor de nomes de domínio.

O DNS-OARC também publicou um teste baseado na web para determinar se o seu resolvedor de nomes de domínio faz uma boa aleatorização de porta de origem, e portanto mais seguro contra envenenamento do cache DNS. Vá até o DNS-OARC: Web-based DNS Randomness Test e clique no grande link "Test My DNS". Ele testa tanto a aleatorização de porta de origem quanto do identificador de transação. Se você obtiver um resultado "POOR" (ruim) em qualquer teste, então você tem um sério problema.

Você pode também testar de servidores remotos fazendo uma solicitação DNS TXT para o endereço porttest.dns-oarc.net. O resultado desta consulta diz se a sua aleatorização de portas de origem é boa ou não: DNS-OARC: Check your resolver's source port behavior.

Se você obtiver qualquer resultado "POOR" (ruim) dos testes acima, você deve tomar ação imediatamente.

Tomando ação

Se você é um usuário de Internet doméstico, a primeira coisa que você deve fazer é chamar seu provedor de serviços de Internet e solicitar que eles corrijam seus resolvedores de nomes de domínio. Nesse meio tempo, você deve considerar alterar seus endereços de servidor DNS para apontarem para o OpenDNS ou qualquer outro provedor de serviços de resolução de nomes de domínio que já tenha resolvido esse problema. Usuários avançados podem querer executar seu próprio resolvedor de nomes de domínio. Se você decidir executar seu próprio resolvedor de nomes de domínio local, esteja alerta de que alguns roteadores caseiros traduzem portas de origem de uma forma previsível, significando que você acaba tendo novamente o mesmo problema.

Se você é um administrador de redes, corrija todos os seus servidores, agora! Se você executa resolvedores de nomes de domínio sem a correção, você tem a privacidade e a segurança de todos os seus usuários em risco. O ataque é muito simples e com um potencial de dano que é realmente assustador. Se você não consegue visualizar a relevância desta situação, então você possui dois problemas.

Também lembre-se de que o problema real não foi resolvido ainda. Grandes alterações à infraestrutura da Internet são necessárias para se obter um DNS mais seguro. Se você é um administrador de redes e gerencia servidores de nomes de domínio, pesquise sobre DNSSEC. Verifique se seu TLD ou ccSLD suporta.

Note que o Brasil é um dos primeiros países a adotar o DNSSEC, e a maior parte dos domínios de segundo nível brasileiros (exceto ".com.br" e ".org.br") suportam DNSSEC.

Leitura adicional

Visualizações