DNS spoofing e cache poisoning: uma visão prática

O DNS foi projetado originalmente sem nenhuma forma de verificar se uma resposta realmente veio do servidor de nomes que dizia ter enviado. Essa lacuna permite o spoofing: um atacante bem posicionado para interceptar uma consulta DNS, ou para chegar antes da resposta verdadeira, pode devolver uma resposta forjada que leva a vítima a um endereço escolhido por ele, muitas vezes para redirecionar o tráfego a um servidor malicioso que se passa por um site legítimo.

Cache poisoning: a mesma ideia, em escala

O cache poisoning (envenenamento de cache) pega a mesma ideia da resposta forjada, mas mira um resolvedor compartilhado em vez de uma única vítima. Se um atacante conseguir inserir uma resposta forjada no cache de um resolvedor recursivo muito usado, todos os usuários seguintes desse resolvedor recebem a resposta envenenada até ela expirar, o que transforma uma única falsificação bem-sucedida em um ataque contra todos que compartilham aquele resolvedor, sem a necessidade de interceptar cada uma das consultas individuais.

Como o DNS moderno se defende

Nenhuma dessas defesas é implantada universalmente, e a adoção do DNSSEC em particular continua parcial entre os domínios que compõem a internet. Usar um resolvedor público bem administrado e atento à segurança, e tratar um resultado de resolução inesperado ou suspeito como algo que vale conferir em um segundo resolvedor independente, continua sendo uma precaução prática razoável, mesmo onde o DNSSEC não está em jogo.

O bug que mudou a seriedade com que o tema é tratado

O cache poisoning deixou de ser uma preocupação teórica em 2008, quando o pesquisador de segurança Dan Kaminsky divulgou uma falha fundamental que afetava quase todos os resolvedores DNS em uso na época: o espaço de IDs de transação e de portas de origem que um atacante precisava adivinhar era pequeno o bastante para ser testado por força bruta em segundos, numa conexão rápida, permitindo envenenar o cache de um resolvedor para um domínio inteiro, e não apenas para um registro. A divulgação levou a um lançamento de correções incomumente coordenado e simultâneo por todos os grandes fornecedores de software DNS (a randomização da porta de origem virou padrão quase da noite para o dia) e é em grande parte o motivo de as defesas listadas acima existirem na forma atual.

Por que a adoção do DNSSEC ainda é lenta, mesmo com a correção tendo vinte anos

O DNSSEC resolve o problema de confiança subjacente de forma muito mais completa do que a randomização de portas por si só: é prova criptográfica, e não apenas um jogo de adivinhação mais difícil. A implantação lenta tem mais a ver com complexidade operacional do que com dúvida sobre o seu valor: assinar uma zona corretamente, trocar as chaves no prazo sem quebrar a validação e manter intacta toda a cadeia de confiança, da raiz até um domínio específico, é bem mais difícil de acertar do que adicionar um registro A sem assinatura. Um único erro nesse processo produz exatamente o modo de falha SERVFAIL tratado em outros artigos desta série, o que por si só desestimula operadores de domínio menores, sem especialistas em DNS na equipe. A distância entre “resolvido na teoria” e “implantado em toda parte na prática” é comum na infraestrutura de segurança, e o DNSSEC é um exemplo claro disso.