O que já se sabia e o que ainda não se sabia

Envenenamento de cache (cache poisoning) não era novidade em 2008. Quem trabalhava com DNS (Domain Name System) conhecia o mecanismo: o resolver (o servidor DNS recursivo) faz uma pergunta a um servidor autoritativo e aceita a primeira resposta que bater com ela. E o que decidia se a resposta batia era uma coisa só: o transaction ID, um identificador de transação de dezesseis bits, ou seja, sessenta e cinco mil quinhentas e trinta e seis possibilidades. Quem conseguisse adivinhar esse número e responder antes do servidor verdadeiro ganhava. Já havia artigos publicados sobre isso, e o ataque era visto como difícil, lento e, em boa parte, teórico.

Havia dois detalhes que decidiam o tamanho real do problema, e ninguém tinha ligado um ao outro. Muitas implementações mandavam as consultas de uma porta de origem fixa, e aí a única incógnita era mesmo o transaction ID. E cada tentativa errada custava caro: o atacante errava, a resposta verdadeira chegava, o registro ia para o cache, e era preciso esperar o (time-to-live) expirar para tentar de novo, o que podia levar um dia.

, na época diretor de pentest (testes de invasão) da IOActive, descobriu como escapar dessa espera.

O truque

Em vez de atacar www.exemplo.com, peça ao resolver aaaa1.exemplo.com, um nome que não existe e, portanto, não pode estar no cache. O resolver não tem saída: precisa ir perguntar. Aí começa a corrida. E o ponto decisivo é este: a resposta forjada não leva só uma resposta para esse nome sem sentido, mas uma delegação, isto é, registros de autoridade que apontam o servidor do atacante como servidor de nomes do domínio inteiro, junto com os glue records (registros de cola) para chegar até ele.

Se perder a corrida, não custa nada, porque o nome era descartável. É só tentar de novo na mesma hora, com aaaa2, aaaa3, tão rápido quanto o link permitir. Basta ganhar uma vez: o resolver guarda no cache não um registro, mas o servidor do atacante como autoridade da zona inteira, com todos os nomes dentro dela, enquanto a delegação valer.

A descoberta se resume a isso, e ela transforma um ataque lento e incerto em um ataque que dá certo em segundos. Tudo o que a internet faz depende de nomes resolvidos corretamente: o tráfego web, o roteamento de e-mail, as atualizações de software e o e-mail de reset de senha, que é o que autentica a maioria das contas. Kaminsky levou o achado a , que, segundo os relatos, avaliou que tudo no universo digital ia precisar de patch.

8 de julho de 2008

O que veio depois não tinha precedente. Kaminsky procurou o Departamento de Segurança Interna dos Estados Unidos e executivos da Cisco e da Microsoft, e uma reunião secreta foi organizada. Fabricantes concorrentes, cujas implementações só tinham em comum o protocolo, foram informados de uma falha que nenhum deles conseguiria corrigir sozinho. Isso porque um resolver corrigido que conversa com uma infraestrutura sem patch continua exposto, e a razão de ser do DNS é justamente que os resolvers de todo mundo conversam com os servidores de todo mundo.

Em 8 de julho de 2008, mais de oitenta fabricantes publicaram seus patches ao mesmo tempo. O advisory (o alerta de segurança) trazia o -2008-1447 e a nota de vulnerabilidade VU#800113 do CERT. O boletim do próprio Internet Systems Consortium para o listava todas as versões afetadas (na prática, todas) e dizia uma coisa 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. A escolha dessa palavra é a parte honesta de todo o episódio.

O que o patch realmente fez

O patch foi a aleatorização da porta de origem (source port randomisation). Em vez de consultar de uma porta previsível, o resolver sorteia uma porta diferente para cada consulta, e o atacante passa a ter de adivinhar o transaction ID e também a porta: uns trinta e dois bits, em vez de dezesseis. Isso não torna a falsificação impossível, mas a deixa umas sessenta e cinco mil vezes mais difícil, e um ataque que levava segundos passa a levar tempo suficiente para alguém perceber.

Vale ser preciso aqui, porque esse é um padrão que quem trabalha na área encontra o tempo todo e muitas vezes interpreta mal. O patch não consertou o protocolo. O DNS continua aceitando uma resposta como autêntica só porque os campos dela batem com a pergunta, e isso não é autenticação em nenhum sentido criptográfico. O que o patch fez foi aumentar o custo. O conserto de verdade é o DNSSEC, que assina os registros, de modo que uma resposta forjada falha na validação por mais que o atacante acerte nos palpites. Só que a adoção do DNSSEC continua parcial quase duas décadas depois, e por isso o artigo sobre DNSSEC deste site fala em verificar, e não em supor.

O embargo, e o que nenhum embargo resolve

O plano era publicar o patch em 8 de julho e deixar para Kaminsky explicar o mecanismo na , em 7 de agosto. Assim a internet teria um mês para se atualizar antes que alguém soubesse contra o que estava se protegendo. A palestra aconteceu em 6 de agosto, um dia antes do anunciado e no primeiro dia das palestras (briefings), com a sala lotada e gente sentada até no chão.

Mas o mês não foi tranquilo, e o motivo é estrutural, não culpa de ninguém. Um patch é uma descrição da vulnerabilidade. Qualquer pessoa competente compara o código novo com o antigo e deduz, de trás para frente, o que ele impede. A retrospectiva do Conficker mostra a mesma coisa do lado da Microsoft, e o backdoor da Juniper é o exemplo mais claro: pesquisadores extraíram a senha hardcoded (gravada no próprio código) no máximo seis horas depois de o patch se tornar público. Um embargo protege o intervalo antes de a correção existir. Depois que ela sai, o defensor está numa corrida contra quem lê diffs mais rápido.

O que levar disso para o dia a dia

Aleatorização é custo, não barreira. Todo controle medido em bits de entropia só está ganhando tempo. Muitas vezes essa é a troca certa, mas ela precisa ser entendida como troca, principalmente quando o número de bits foi definido décadas atrás, para uma rede de outro tamanho.

O resolver que você opera é o que importa. A falha estava nos resolvers, não nos servidores autoritativos, e o risco era de quem operava o serviço recursivo. Por isso a escolha de um resolver público é uma questão de segurança, e não só de latência.

Coordenação nessa escala é possível, mas é rara. Oitenta fabricantes corrigiram uma falha de protocolo no mesmo dia porque alguém passou meses organizando tudo em sigilo, e porque a alternativa era claramente catastrófica. É o modelo que a indústria cita, e poucas vezes ele se repetiu nessa escala.

E a pessoa fez diferença. Kaminsky encontrou a falha, preferiu coordenar a correção a publicar a descoberta, e passou os anos seguintes dedicado à solução, e não ao achado: em 2010, a o escolheu como um dos trusted community representatives (representantes de confiança da comunidade) da raiz do DNSSEC. Ele morreu em abril de 2021, aos quarenta e dois anos. O New York Times chegou a chamá-lo de Paul Revere digital, um elogio exagerado no estilo, mas que, pelo que ele fez naquele verão, não está errado.

Fontes