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.

, 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 , 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 -2008-1447 e a nota de vulnerabilidade VU#800113 do CERT. O boletim do próprio Internet Systems Consortium para o listava toda versão afetada - que era, na prática, todas - e dizia algo que vale citar pela franqueza: o é 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 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 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 faz o mesmo ponto pelo lado da Microsoft, e a porta dos fundos da Juniper é 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 é 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 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