# A falha de Kaminsky: o verão em que oitenta fabricantes corrigiram o mesmo defeito no mesmo dia

> Em 2008 um pesquisador percebeu que uma fraqueza conhecida do DNS era muito pior do que qualquer um calculara - não um jeito de envenenar um registro, mas um jeito de tomar um domínio inteiro em segundos, repetidamente. O que veio depois foi a maior correção coordenada que a internet já tentara, um conserto que comprou entropia e não certeza, e um lembrete de que publicar uma correção também publica a vulnerabilidade.

Source: https://ronutz.com/pt-BR/learn/the-kaminsky-dns-flaw  
Updated: 2026-09-08

---

## O que já se sabia, e o que não

Envenenamento de cache não era ideia nova em 2008. Todo mundo que trabalhava com DNS (Domain Name System) entendia o formato: um resolvedor faz uma pergunta a um servidor autoritativo e aceita a primeira resposta que casa, e casar significava uma coisa - um identificador de transação de dezesseis bits, sessenta e cinco mil quinhentas e trinta e seis possibilidades. Um atacante que adivinhasse e respondesse mais rápido que o servidor real vencia. Artigos tinham sido escritos sobre isso. Era considerado difícil, lento e em larga medida teórico.

Duas coisas o tornavam pior do que a aritmética sugeria, e ninguém as juntara. Muitas implementações mandavam suas consultas de uma **porta de origem fixa**, então a única incógnita era realmente o identificador de transação. E uma tentativa fracassada era cara: errou, a resposta verdadeira chega, o registro entra em cache, e o atacante precisa esperar o tempo de vida expirar para tentar de novo - possivelmente um dia.

Dan Kaminsky, então diretor de teste de invasão da IOActive, achou como contornar a espera.

## O truque

Em vez de atacar `www.exemplo.com`, peça ao resolvedor `aaaa1.exemplo.com` - um nome que não existe e portanto não pode estar em cache. O resolvedor não tem escolha senão ir perguntar. Agora corra com ele. E, decisivamente, ponha na resposta forjada não só uma resposta para aquele nome sem sentido, mas uma **delegação**: registros de autoridade nomeando o servidor do atacante como servidor de nomes do domínio inteiro, com os registros de cola para alcançá-lo.

Perder a corrida não custa nada, porque o nome era lixo. Tente de novo imediatamente com `aaaa2`, `aaaa3`, tão rápido quanto o enlace permitir. Vença uma vez e o resolvedor guarda em cache não um registro, mas o servidor do atacante como autoridade da zona inteira - todo nome sob ela, enquanto a delegação viver.

É essa a descoberta inteira, e ela converte um ataque lento e incerto num que funciona em segundos. Tudo o que a internet faz repousa sobre nomes resolverem corretamente: tráfego web, roteamento de correio, atualizações de software, e o e-mail de redefinição de senha que autentica a maioria das contas. Kaminsky levou aquilo a Paul Vixie, cuja avaliação relatada foi a de que tudo no universo digital ia ter de ser corrigido.

## 8 de julho de 2008

O que veio depois não tinha precedente. Kaminsky foi ao Departamento de Segurança Interna e a executivos da Cisco e da Microsoft. Uma reunião secreta foi convocada. Fabricantes que competiam entre si, e cujas implementações não compartilhavam nada além do protocolo, foram informados de uma falha que nenhum deles podia consertar sozinho - porque um resolvedor corrigido conversando com infraestrutura não corrigida continua exposto, e o ponto inteiro do DNS é que os resolvedores de todos falam com os servidores de todos.

Em 8 de julho de 2008, mais de oitenta fabricantes lançaram correções simultaneamente. O aviso trazia o CVE-2008-1447 e a nota de vulnerabilidade VU#800113 do CERT. O boletim do próprio Internet Systems Consortium para o BIND listava toda versão afetada - que era, na prática, todas - e dizia algo que vale citar pela franqueza: o DNSSEC é a única solução completa, e as versões novas oferecem maior resiliência ao ataque.

**Resiliência, não imunidade.** Essa escolha de palavra é a parte honesta do episódio inteiro.

## O que o conserto de fato comprou

A correção foi a aleatorização da porta de origem. Em vez de perguntar de uma porta previsível, um resolvedor escolhe uma aleatória para cada consulta, e o atacante agora precisa adivinhar tanto o identificador de transação quanto a porta - uns trinta e dois bits em vez de dezesseis. Isso não torna a forjadura impossível. Torna-a umas sessenta e cinco mil vezes mais difícil, o que converte um ataque de segundos num que leva tempo bastante para ser notado.

Vale ser preciso aqui, porque é um padrão que os profissionais encontram o tempo todo e frequentemente leem errado. A correção não consertou o protocolo. O DNS ainda autentica uma resposta por seus campos casarem com uma pergunta, o que não é autenticação em nenhum sentido criptográfico. O que a correção fez foi elevar o custo. O conserto de verdade é o DNSSEC, que assina os registros de modo que uma resposta forjada falha na validação por melhor que adivinhe - e a adoção do DNSSEC segue parcial quase duas décadas depois, que é por que o [artigo sobre DNSSEC](https://ronutz.com/pt-BR/learn/dnssec-records-in-dig) deste site fala em conferir e não em supor.

## O embargo, e o que embargos não resolvem

O plano era que a correção saísse em 8 de julho e Kaminsky explicasse o mecanismo na Black Hat em 7 de agosto, dando à internet um mês para atualizar antes de alguém saber contra o quê. A palestra aconteceu; a sala estava cheia até o chão.

Mas o mês não ficou quieto, e a razão é estrutural, não culpa de ninguém. **Uma correção é uma descrição da vulnerabilidade.** Qualquer pessoa competente compara o código novo com o velho e trabalha de trás para frente até o que ele impede. A [retrospectiva do Conficker](https://ronutz.com/pt-BR/learn/the-worm-era) faz o mesmo ponto pelo lado da Microsoft, e a [porta dos fundos da Juniper](https://ronutz.com/pt-BR/learn/there-is-no-perfect-code) é sua ilustração mais afiada - pesquisadores extraíram a senha embutida em seis horas depois de a correção ser pública. Um embargo protege o intervalo antes de o conserto existir. Uma vez que o conserto sai, o relógio que o defensor está correndo é acertado por quem lê diferenças de código mais rápido.

## O que um profissional deve tirar disso

**Aleatorização é custo, não fronteira.** Todo controle descrito em bits de entropia está comprando tempo. Muitas vezes é a troca certa, e deveria ser entendida como troca, especialmente quando o número de bits foi escolhido décadas atrás para uma rede de outro tamanho.

**O resolvedor que você opera é o que importa.** A falha estava nos resolvedores, não nos servidores autoritativos, e a exposição pertencia a quem operasse o serviço recursivo - que é por que a pergunta de [qual resolvedor público escolher](https://ronutz.com/pt-BR/learn/choosing-a-public-dns-resolver) é uma pergunta de segurança e não só de latência.

**Coordenação nessa escala é possível e é rara.** Oitenta fabricantes corrigindo uma falha de protocolo num único dia aconteceu porque alguém passou meses organizando aquilo em sigilo, e porque a alternativa era visivelmente catastrófica. É o modelo que a indústria cita, e não foi repetido muitas vezes nessa escala.

**E a pessoa importou.** Kaminsky achou, escolheu coordenar em vez de publicar, e passou os anos seguintes no conserto e não no achado - a ICANN o nomeou um dos representantes de confiança da comunidade para a raiz do DNSSEC em 2010. Morreu em abril de 2021, aos quarenta e dois anos. O New York Times o chamara de um Paul Revere digital, o que é floreado e, pelo registro daquele verão, não é errado.

## Fontes

- [Aviso do Internet Systems Consortium, 8 de julho de 2008: uma fraqueza no protocolo DNS pode permitir o envenenamento de resolvedores recursivos com dados forjados; o DNSSEC é a única solução completa e as versões novas do BIND oferecem maior resiliência; CVE-2008-1447, VU#800113; versões afetadas incluem BIND 8 (todas), 9.0 a 9.4.2 e as betas da 9.5.0; detalhes completos a serem explicados por Kaminsky na Black Hat em 7 de agosto](https://kb.isc.org/docs/aa-00924)
- [Dark Reading, 6 de agosto de 2008: na terça-feira 8 de julho, Kaminsky e mais de 80 fabricantes lançaram uma campanha sem precedentes para corrigir uma falha em software DNS amplamente distribuído; na Black Hat os presentes ocuparam todas as cadeiras e quase todo o chão](https://www.darkreading.com/vulnerabilities-threats/dan-kaminsky-reveals-dns-flaw-at-black-hat)
- [Notas de curso da Academia Naval dos Estados Unidos: em 2008 Kaminsky descobriu uma falha fundamental no DNS que permitia envenenamento fácil de cache na maioria dos servidores de nomes, tornando viáveis a personificação de sites, a interceptação de e-mail e o contorno de autenticação por recursos de redefinição de senha; ele contatou Paul Vixie, que descreveu a gravidade como significando que tudo no universo digital ia ter de ser corrigido, e então alertou o Departamento de Segurança Interna e executivos da Cisco e da Microsoft; antes do anúncio, a maioria das implementações DNS usava porta de origem fixa](https://www.usna.edu/Users/cs/choi/it432/lec/l07/lec.html)
- [Sobre o mecanismo: o atacante emite uma rajada de consultas por nomes aleatórios diferentes sob o domínio-alvo, driblando o cache do resolvedor e provocando consultas de saída pendentes, e então gera respostas adivinhando a porta de origem e o identificador de transação, cada uma contendo registros NS e de cola forjados como informação de delegação; o resolvedor os guarda e os usa como autoritativos nas resoluções seguintes](https://arxiv.org/pdf/1605.01394)
- [Sobre a aritmética: o campo de identificador de transação do DNS tem 16 bits, então um identificador corretamente aleatório exige em média 32.768 tentativas; algumas implementações usavam menos bits ou geravam identificadores com defeitos conhecidos de aleatoriedade](https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/7930428)
- [Sobre a resposta coordenada: os fabricantes colaboraram com Kaminsky e outros especialistas da indústria num plano para corrigir a falha e lançaram a correção simultaneamente em 8 de julho de 2008](https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/10834066)
- [Sobre o conserto e seus limites: os resolvedores foram corrigidos para suportar as boas práticas da RFC 5452 - aleatorizar campos incluindo porta de origem e identificador de transação, validá-los nas respostas e aplicar verificações de bailiwick - o que tornou o DNS resiliente ao envenenamento fora do caminho; trabalhos posteriores desenvolveram novos ataques usando canais laterais e fragmentação](https://arxiv.org/pdf/2205.05439)
- [Wikipedia, Dan Kaminsky: 7 de fevereiro de 1979 a 23 de abril de 2021; diretor de teste de invasão na IOActive; conhecido pela vulnerabilidade de envenenamento de cache DNS de 2008 e por mostrar que o rootkit da Sony infectara ao menos 568 mil computadores; nomeado pela ICANN em junho de 2010 um dos representantes de confiança da comunidade para a raiz do DNSSEC; o New York Times o rotulou de salvador da segurança da internet e Paul Revere digital](https://en.wikipedia.org/wiki/Dan_Kaminsky)