Falsificação de DNS e envenenamento de cache

Falsificação de DNS é o ato de fornecer uma resposta DNS forjada para que a vítima resolva um nome para um IP controlado pelo invasor. Envenenamento de cache é uma forma específica em que a resposta forjada é aceita e armazenada por um resolvedor recursivo, infectando todos os clientes que o utilizam.

O objetivo geralmente é redirecionar o tráfego: enviar usuários para páginas fraudulentas, downloads de software malicioso ou proxies de interceptação.

Quando um resolvedor envia uma consulta, um invasor tenta injetar uma resposta forjada antes que o servidor autoritativo legítimo responda. Se a falsificação chegar primeiro e corresponder aos campos esperados, ela vence a corrida e é armazenada no cache.

É por isso que a latência, a ordenação dos pacotes e a porta de saída do resolvedor são tão importantes nos ataques e na defesa.

Para que uma resposta UDP forjada seja aceita, o invasor precisa corresponder a:

• O IP de origem (o servidor autoritativo).
• A porta de destino (a porta de saída do resolvedor).
• O nome e o tipo da consulta.
• O ID de transação (TXID) de 16 bits.

Sem proteções, o único segredo real é o TXID, o que dá uma probabilidade de aproximadamente 1 em 65.536 por pacote.

A divulgação de Dan Kaminsky em 2008 mostrou que o envenenamento era muito mais fácil do que se imaginava. Em vez de uma corrida por registro, o invasor consulta muitos subdomínios inexistentes (aaa.bank.com, aab.bank.com...) e inunda o sistema com respostas forjadas que contêm um registro NS malicioso ou um registro de cola para todo o domínio.

Cada tentativa é uma nova corrida, sem penalidade de cache por uma consulta sem resultado, então o invasor pode repetir as tentativas até acertar e envenenar toda a zona.

A principal mitigação após Kaminsky foi a randomização da porta de origem. Em vez de uma porta de saída fixa, o resolvedor escolhe uma porta efêmera aleatória para cada consulta.

Agora o invasor precisa adivinhar tanto o TXID (16 bits) quanto a porta de origem (~16 bits), ampliando o espaço de busca para aproximadamente 2^32. Isso torna impraticável o envenenamento cego fora do caminho, embora não impossível em implementações com entropia fraca.

Um invasor fora do caminho não consegue ver a consulta e precisa adivinhar às cegas o TXID e a porta. Um invasor no caminho (Wi-Fi não autorizado, roteador comprometido, ISP) pode ler a consulta diretamente e elaborar facilmente uma resposta correspondente.

A falsificação no caminho derrota completamente a randomização da porta, por isso o transporte criptografado e a validação DNSSEC são necessários para uma garantia forte, e não apenas entropia.

Os invasores nem sempre forjam pacotes. Um servidor DHCP malicioso pode fornecer aos clientes o endereço de um resolvedor DNS malicioso, fazendo com que cada consulta seja respondida pelo invasor. De modo semelhante, um software malicioso reescreve /etc/resolv.conf ou as configurações do roteador.

Ameaças históricas, como o software malicioso DNSChanger, redirecionaram silenciosamente o DNS das vítimas para servidores fraudulentos durante anos. Valide quais resolvedores sua frota realmente usa.

Os resolvedores aplicam regras de autoridade da zona: uma resposta só pode fornecer registros para nomes dentro da zona sobre a qual tem autoridade. Uma resposta para bank.com não pode inserir secretamente um registro para unrelated.com.

Isso limita as injeções no estilo Kaminsky ao domínio consultado e impede que uma resposta envenenada contamine zonas não relacionadas. Verifique se seu resolvedor aplica uma filtragem rigorosa dos limites de autoridade.

Indícios de um envenenamento em andamento ou bem-sucedido:

• Um pico de consultas a subdomínios aleatórios e inexistentes.
• Respostas DNS duplicadas ou fora de ordem para o mesmo TXID.
• Endereços IP resolvidos que repentinamente apontam para sistemas autônomos ou regiões geográficas que não eram esperados.
• Incompatibilidade entre as respostas do resolvedor e uma consulta confiável feita por outro canal.

Nenhum controle isolado é suficiente. Combine:

• Randomização da porta de origem + TXID para aumentar o custo para um invasor fora do caminho.
• Validação do DNSSEC para que respostas forjadas falhem nas verificações de assinatura.
• DNS sobre TLS/DNS sobre HTTPS para negar visibilidade e adulteração aos invasores no caminho.
• Codificação 0x20 (maiúsculas e minúsculas aleatórias nos nomes das consultas) para obter entropia adicional.
• Monitoramento de inundações de NXDOMAIN e de anomalias nas respostas.

Na prática, hoje o envenenamento cego de cache fora do caminho é raro em resolvedores atualizados, mas reaparece por meio de canais laterais (por exemplo, fragmentação de UDP e ataques de inferência de porta baseados em ICMP, como o SAD DNS). Mantenha os resolvedores atualizados e prefira resolvedores que validem respostas e usem criptografia.

Lembre-se: o comprometimento de maior impacto do DNS costuma não ser uma engenhosa corrida de envenenamento, mas uma conta roubada do registrador. Proteja ambas as pontas.

A falsificação de DNS forja respostas; o envenenamento de cache faz com que elas persistam em um resolvedor. A aceitação depende da correspondência entre o IP de origem, a porta, o nome da consulta e o TXID. A randomização da porta de origem e as verificações de autoridade elevaram a dificuldade para os atacantes fora do caminho, mas os atacantes no caminho e os canais laterais continuam sendo uma ameaça.

A defesa em profundidade — entropia, validação de DNSSEC, transporte criptografado e monitoramento — é essencial. Em seguida, veremos como os atacantes abusam do DNS para mover dados: tunelamento e exfiltração.