Resumo

  • O envenenamento no estilo Kaminsky provocava consultas por nomes inéditos e reabria a disputa fora do caminho: uma resposta forjada precisava adivinhar a consulta e derrotar o pacote autêntico no tempo.
  • Os patches coordenados de 2008 não autenticaram o DNS. Eles acrescentaram IDs e portas de origem imprevisíveis à decisão local, e essa entropia ainda precisava sobreviver ao firewall e ao NAT e ser observada no fio.

O primeiro pacote compatível ganhava

Um resolvedor recursivo costumava consultar por UDP e receber dados sem assinatura. A resposta comum não carregava prova criptográfica de origem. O resolvedor verificava se ela correspondia a um trabalho que ele realmente tinha iniciado.

O RFC 5452 consolidou os critérios: pergunta e ID deveriam coincidir; a origem aparente deveria ser o servidor consultado; o pacote deveria voltar ao endereço e à porta usados na consulta. Em geral, a primeira resposta que passasse nesses testes era aceita.

Um agressor fora do caminho não via o tráfego, mas podia falsificar o endereço de uma autoridade e disparar muitos candidatos. Um acerto na combinação, antes da resposta legítima, bastava para inserir a mentira no cache. Depois, o próprio resolvedor a repetia para os clientes.

O alcance era específico: um cache, determinados registros e um período de validade. Não era domínio universal sobre o DNS. Essa limitação mostra por que recursão, correspondência, bailiwick, aleatoriedade e assinatura precisam de controles distintos.

O ataque fabricava a próxima tentativa

Prever IDs e poluir caches não era novidade. O RFC 3833 já havia descrito essas ameaças em 2004. O ID tinha 16 bits; alguns geradores entregavam ainda menos incerteza; uma porta UDP fixa não acrescentava nenhum segredo.

Dan Kaminsky demonstrou como transformar fragilidades conhecidas em repetição prática. O atacante induzia uma consulta por um rótulo aleatório sob o domínio-alvo. Como o nome não estava no cache, o resolvedor fazia nova pergunta à autoridade. Respostas falsas corriam contra a verdadeira. Um rótulo diferente reabria a janela após cada fracasso.

O nome descartável era o gatilho, não necessariamente o prêmio. A resposta forjada podia tentar instalar informação de delegação que afetasse o domínio pai, sujeita às regras de relevância do resolvedor. Assim, não era preciso esperar o TTL de um registro valioso terminar.

O RFC 5452 modelou algumas variantes como TTL efetivamente próximo de zero. No exemplo de 7 mil pacotes falsos por segundo e uma única porta, a chance chega a 50% em cerca de sete segundos. Não é um prazo universal: é a demonstração de que uma probabilidade pequena se torna operacional quando a tentativa pode ser renovada barato.

A porta virou uma segunda identidade

A resposta emergencial aumentou o conjunto a adivinhar. Resolvedores corrigidos passaram a escolher uma porta de origem imprevisível por consulta e a usar IDs mais fortes. O número da porta funcionou como mais um identificador local.

Com aproximadamente 64 mil portas, o RFC 5452 multiplicou o espaço por esse fator. No mesmo modelo repetitivo, o ponto de 50% saiu de sete segundos para cerca de 116 horas. O CERT/CC descreveu o ganho teórico como quase 16 bits, lembrando que portas reservadas ou ocupadas reduzem a população real.

A mudança não exigiu novo formato de pacote. O servidor autoritativo já respondia à porta de origem. Fornecedores puderam alterar o código e operadores puderam instalar sem uma virada global coordenada.

Havia custo. O ISC alertou para impacto perceptível do patch inicial do BIND acima de aproximadamente 10 mil consultas por segundo e ofereceu betas otimizados. Regras que só autorizavam saída pela porta 53 precisavam mudar; equipamentos com estado consumiam mais mapeamentos.

O patch, portanto, trocou uma tupla previsível por gestão mais exigente de sockets e estado. Era uma decisão local, mensurável e reversível, não o fim da engenharia.

A rede podia desfazer o ganho do host

Uma versão corrigida no inventário não garantia variedade na Internet. NAT e PAT reescrevem portas. O CERT/CC advertiu que poderiam reduzir ou eliminar a melhoria; o RFC 5452 apontou dispositivos que serializam ou restringem o conjunto.

Nem todo NAT se comporta mal. Alguns preservam a escolha e outros mudam a variação em direções diferentes. A pergunta útil é quantas opções o agressor enxerga após sistema operacional, firewall e tradutor.

Os testes do DNS-OARC observaram portas e IDs do lado autoritativo. O operador enviava consultas especiais e recebia uma leitura dos valores que realmente chegaram. Em vez de confiar no rótulo do software, auditava o comportamento final.

Essa é a prioridade do código em execução aplicada a uma propriedade concreta. O boletim comunica intenção; o tráfego prova se o controle continuou existindo ao atravessar a arquitetura local.

Divulgação conjunta não significou adoção conjunta

O DNS-OARC registra uma reunião na Microsoft em 31 de março de 2008. Em 8 de julho, o CERT/CC publicou VU#800113 e muitos fornecedores lançaram correções. O ISC atualizou o BIND; a Microsoft alterou IDs, sockets UDP e lógica de cache.

O sigilo terminou antes da apresentação planejada. A cronologia marca o vazamento efetivo em 21 de julho, código funcional no dia 23 e novas implementações no dia 24. Em 25 de julho, a Microsoft disse que o risco crescera com o código público. Disse também não conhecer, naquele momento, ataques ativos ou impacto em clientes e verificou que o exploit testado não afetava sistemas com MS08-037.

Essas observações não provam ausência global de exploração. Código público elevou a capacidade; o campo de visão de um fornecedor era limitado; bloquear uma amostra não certificou todas as combinações de software e rede.

Kaminsky apresentou o mecanismo na Black Hat em 7 de agosto. O RFC 5452 veio em janeiro de 2009. O código implantável produziu defesa antes de o documento padronizar os critérios. A norma consolidou a experiência, mas não instalou a atualização em nenhum resolvedor.

Mais entropia não é uma assinatura

Aleatorizar portas tornou a falsificação fora do caminho muito mais cara. Não provou que o dado sem assinatura pertencia à autoridade delegada. Estado vazado, um tradutor empobrecedor, muitas tentativas ou uma posição no caminho mudavam as premissas.

Por isso o ISC chamou o DNSSEC de solução definitiva e reconheceu que sua adoção imediata não era realista. O DNSSEC verifica origem e integridade com assinaturas e cadeia de confiança. É outra propriedade, não uma versão maior da loteria.

As duas camadas se complementam. Correspondência e entropia rejeitam lixo barato; o DNSSEC julga a autoridade do conteúdo. Nenhum dos dois controles deve reivindicar a função do outro.

A Especificação Inicial Mínima de Heng Lu mantém pequeno o contrato comum: correspondência exata e imprevisibilidade suficiente. Ela não transforma o gerador, o alocador de sockets ou o cronograma de um fornecedor em comando global. Decisões posteriores ficam locais, e a adoção só se torna real em comportamento operacional verificável.

Limites da evidência

As fontes sustentam exposição multivendedor e uma técnica muito mais prática. Não mostram defeito idêntico em todo resolvedor, implantação universal em 8 de julho nem duração aplicável a qualquer rede. Portas aleatórias aumentaram o custo sob hipóteses declaradas, sem eliminar todo envenenamento. A existência do DNSSEC tampouco prova que um resolvedor o valide.

A conclusão suficiente é precisa: parte da confiança repousava em uma corrida pequena, e muitos sistemas comprimiam sua incerteza. A correção ampliou e tornou observável esse espaço, deixando a autenticação como trabalho separado.

Fontes