O que é o envenenamento de cache DNS

O envenenamento de cache DNS, conhecido em ingles como DNS cache poisoning ou DNS spoofing, e um tipo de ataque em que um agente malicioso insere registros falsificados no cache de um servidor DNS recursivo. O objetivo e fazer com que consultas legítimas de domínios retornem enderecos IP controlados pelo atacante em vez dos enderecos reais, redirecionando silenciosamente o tráfego de usuários sem que eles percebam qualquer anomalia.

O Sistema de Nomes de Domínio (DNS) e frequentemente descrito como a "agenda telefonica" da internet: ele traduz nomes de domínio legivel por humanos, como exemplo.com, nos enderecos IP numericos que os roteadores usam para entregar pacotes. Quando um resolvedor recursivo consulta um servidor autoritativo e obtem a resposta, ele armazena esse mapeamento em cache pelo período definido pelo TTL (Time To Live) do registro. E exatamente nesse cache que o atacante tenta injetar informações falsas.

A consequencia prática e grave: um usuário que digita o endereco correto de seu banco, loja virtual ou serviço de email pode ser silenciosamente redirecionado para uma página identica controlada por criminosos, tendo suas credenciais capturadas sem qualquer indicativo visual de fraude, dependendo da técnica usada.

Como funciona o ataque

O mecanismo clássico de envenenamento de cache DNS explora a forma como resolvedores recursivos validam respostas. Quando um resolvedor envia uma consulta para um servidor autoritativo, ele abre uma porta UDP de origem aleatorio e inclui um identificador de transação de 16 bits na requisição. A resposta válida deve retornar pela mesma porta com o mesmo ID. Um atacante que consiga enviar uma resposta falsificada antes da resposta legítima, com o ID correto, consegue "ganhar a corrida" e ter seu registro falso aceito pelo cache.

A probabilidade de adivinhar os 16 bits do ID de transação e de 1 em 65.536. Parece alto, mas em um ataque de inundação, onde o atacante envia milhares de respostas forjadas por segundo, a janela de tempo em que o resolvedor aguarda a resposta legítima (que pode ser de varios milissegundos a centenas) e suficiente para que a colisao ocorra. Esse vetor foi explorado de forma famosa pelo pesquisador Dan Kaminski em 2008, que demonstrou como a combinação de consultas em larga escala e respostas forjadas para registros CNAME com NS autoritativo falso permitia envenenar caches rapidamente, sem esperar o TTL expirar.

Variações modernas do ataque incluem: (1) ataques fora do caminho que exploram fragmentação IP ou predição de porta; (2) ataques MITM em redes locais via ARP spoofing combinado com falsificação de resposta DNS; (3) exploração de resolvedores mal configurados que aceitam recursao de qualquer origem, tornando-se amplificadores de resposta fraudulenta. Em redes corporativas com roteadores sem filtros adequados, o vetor via rede interna e especialmente perigoso.

Quem e afetado

Qualquer ambiente que dependa de DNS sem validação criptografica e potencialmente vulnerável. Os alvos mais frequentes incluem: provedores de internet com resolvedores recursivos abertos, empresas que operam seus próprios servidores DNS sem DNSSEC, redes Wi-Fi públicas onde um atacante local pode interceptar tráfego UDP e roteadores domesticos com firmware desatualizado que não randomiza portas de origem. Usuários finais são afetados de forma indireta: eles consultam o resolvedor do provedor ou da empresa, e se esse cache estiver envenenado, qualquer dispositivo na rede recebe o registro falso.

Do ponto de vista de impacto histórico documentado, ataques de DNS poisoning foram usados em campanhas de phishing em massa no Brasil direcionadas a clientes de grandes bancos, em ataques contra infraestrutura de telecomunicações e em operações de espionagem que redirecionavam tráfego de domínios governamentais. O vetor não e apenas teorico: e um componente recorrente em operações de fraude financeira e coleta de credenciais.

Como identificar e detectar

A detecção de envenenamento de cache DNS e desafiadora porque o ataque não gera erros visíveis para o usuário final. Os principais indicadores incluem: (1) registros DNS retornando TTLs muito baixos ou valores inconsistentes com o histórico do domínio; (2) enderecos IP de resposta pertencendo a ASNs (sistemas autonomos) geograficamente distantes do servidor real do domínio; (3) certificados TLS inválidos ou autoassinados no destino, o que aciona alertas no navegador; (4) logs de NXDOMAIN em excesso seguidos de respostas repentinas para domínios que antes não resolviam.

Ferramentas úteis para auditoria incluem o dig com a flag +trace para rastrear a cadeia de resolução completa, o dnstracer e o whois para validar os ASNs dos enderecos retornados. Monitoramento continuo via plataformas como o TrustSiteMonitor pode alertar quando o IP de resolução de um domínio muda inesperadamente, indicando possível poisoning ou hijacking de DNS.

Em nível de rede, um IDS (sistema de detecção de intrusao) configurado para alertar sobre respostas DNS fora do padrão, como multiplos registros A para o mesmo domínio chegando de fontes diferentes em um curto intervalo, e um indicador valioso. Logs do resolvedor (disponível no BIND via querylog e no Unbound via verbosidade elevada) também revelam padrões anomalos de consulta e resposta.

Como se proteger e mitigar

A defesa mais eficaz contra envenenamento de cache DNS e a implantação de DNSSEC (DNS Security Extensions). O DNSSEC adiciona assinaturas criptograficas aos registros DNS, permitindo que resolvedores verifiquem a autenticidade da resposta usando uma cadeia de confianca até a zona raiz. Com DNSSEC habilitado, um registro forjado será rejeitado pelo resolvedor porque a assinatura não corresponde a chave pública publicada na zona pai.

Para operadores de resolvedores recursivos, as medidas incluem: habilitar a randomização de portas de origem (0x20 encoding ou RFC 5452), que eleva a entropia da autenticação de consultas; configurar o resolvedor para aceitar recursao somente de clientes internos (não ser um open resolver); habilitar validação DNSSEC (dnssec-validation auto no BIND); e manter o software DNS atualizado, pois versões antigas do BIND, Unbound e Microsoft DNS tiveram vulnerabilidades específicas de cache poisoning corrigidas ao longo dos anos.

Para operadores de domínios: assinar a zona com DNSSEC e publicar os registros DS no registrador; configurar TTLs razoaveis (não excessivamente baixos); usar registradores com suporte a bloqueio de transferência e autenticação de dois fatores para alterações de NS; e habilitar DNS over HTTPS (DoH) ou DNS over TLS (DoT) para clientes moveis, eliminando a exposição do tráfego DNS em redes não confiáveis.

Comparação com ataques similares e contexto histórico

O envenenamento de cache DNS e frequentemente confundido com DNS hijacking, mas são distintos. No hijacking, o atacante comprometeu diretamente o servidor autoritativo ou o painel de controle do registrador, alterando os registros NS ou A reais do domínio. No cache poisoning, os registros oficiais não são alterados: apenas o cache do resolvedor intermediario e corrompido. O impacto pode ser similar para o usuário final, mas o vetor de ataque e diferente e as defesas também.

O ataque de Kaminski em 2008 levou a uma correção emergencial coordenada pelos principais fornecedores de software DNS (Microsoft, ISC/BIND, Cisco) antes da divulgação pública, algo incomum na epoca. Essa coordenação estabeleceu um precedente para a industria de DNS e acelerou a adoção de randomização de portas como padrão. Antes disso, muitos resolvedores usavam porta de origem fixa (53/UDP), tornando o ataque trivialmente exploravel.

Mais recentemente, técnicas como SAD DNS (descrita em 2020 em pesquisa academica) demonstraram que mesmo resolvedores com randomização de porta podiam ser atacados via inferencia de porta usando mensagens ICMP, contornando parcialmente as proteções adotadas após Kaminski. O SAD DNS afetava resolvedores em sistemas Linux com certas configurações de rede. A mitigação principal e DNSSEC, que independe da entropia de porta.

Análise técnica

O ataque clássico de Kaminski tem complexidade prática de O(n * janela_de_tempo), onde n e o número de tentativas de ID aleatorio por segundo que o atacante consegue enviar. Com um RTT (round-trip time) de 10ms entre resolvedor e servidor autoritativo e capacidade de envio de 100.000 pacotes por segundo, a probabilidade de colisao e significativa em poucos segundos.

A exploração moderna usa técnicas de Side Channel para reduzir o espaco de busca. O SAD DNS, por exemplo, usa o campo de número de sequência IPID ou mensagens ICMP Port Unreachable para inferir qual porta de origem o resolvedor está usando, reduzindo o espaco de 65.536 para decenas de possibilidades. Isso foi possível porque o kernel Linux usava um contador global de IPID, vazando informação sobre a porta ativa. A correção no kernel envolveu usar contadores por fluxo e descarte seletivo de mensagens ICMP.

Para ambientes com DNSSEC, a resistencia e garantida pela estrutura criptografica: mesmo que o atacante injete um registro A falso com IP errado, o resolvedor validador rejeita a resposta porque o RRSIG (Resource Record Signature) não e válido para a chave KSK/ZSK publicada no pai da zona. O único vetor restante e comprometer a própria zona ou a cadeia de confianca, que é um ataque diferente (e muito mais difícil).

Impacto e consequencias

As consequencias de um cache DNS envenenado são multiplas. Do ponto de vista de segurança, usuários redirecionados para sites falsos estão sujeitos a phishing de credenciais, instalação de malware via drive-by download e interceptação de comunicações. Do ponto de vista financeiro, ataques contra domínios de bancos e e-commerces resultam em fraudes diretas. Do ponto de vista de reputação, uma empresa cujos clientes são redirecionados para páginas maliciosas sofre danos significativos mesmo sem ter sido diretamente comprometida.

Para infraestruturas críticas, como sistemas de saude, energia e telecomunicações, o impacto pode ser operacional: sistemas internos que dependem de DNS para localizar outros serviços podem ser redirecionados para endpoints incorretos, causando falhas em cascata. O vetor foi documentado em operações de APT (Advanced Persistent Threat) como técnica de persistência e movimentação lateral em redes corporativas.

Dicas práticas e boas práticas

Lista de verificação para proteger sua infraestrutura DNS:

  • Habilitar DNSSEC na zona e publicar DS no registrador
  • Usar resolvedores com validação DNSSEC habilitada (Unbound, BIND com dnssec-validation auto, Cloudflare 1.1.1.1, Google 8.8.8.8)
  • Desabilitar recursao aberta: o resolvedor deve atender apenas a clientes internos
  • Manter software DNS atualizado com patches de segurança
  • Configurar DNS over TLS ou DNS over HTTPS em endpoints moveis e redes não confiáveis
  • Monitorar alterações de IP nos domínios críticos da empresa com ferramentas de monitoramento externo
  • Rever TTLs: valores muito baixos aumentam o tráfego de consulta e a janela de ataque; valores muito altos atrasam propagação de mudancas legítimas. TTL de 3600s e um equilibrio razoavel para a maioria dos casos
  • Auditar os registradores de domínio: habilitar autenticação de dois fatores e registrar lock no domínio para evitar hijacking que precede o poisoning

Conclusao: o que fazer agora

O envenenamento de cache DNS e um vetor maduro, documentado e ainda presente em ataques modernos. A boa noticia e que as defesas existem, são bem compreendidas e, em muitos casos, gratuitas: DNSSEC, randomização de porta e atualização de software resolvem a maior parte da superficie de ataque sem custo de licença.

O primeiro passo prático e auditar o estado atual: verificar se os domínios da sua organização estão assinados com DNSSEC (ferramentas como o dnssec-analyzer.verisignlabs.com fazem esse diagnóstico em segundos), confirmar que os resolvedores internos validam DNSSEC e revisar se ha resolvedores abertos expostos na internet. Em paralelo, habilitar monitoramento externo de DNS para os domínios críticos garante alertas imediatos caso um IP de resolução mude inesperadamente, seja por poisoning, hijacking ou atualização legítima não documentada. Proteger o DNS e proteger a entrada principal da sua infraestrutura digital.