Um grupo de pesquisadores da Universidade de Tel Aviv e do Centro Interdisciplinar de Herzliya (Israel) um novo método de ataque (), permitindo o uso de qualquer resolvedor DNS como amplificadores de tráfego, proporcionando um nível de amplificação de até 1621 vezes no número de pacotes (para cada consulta enviada ao resolvedor, é possível gerar até 1621 consultas para o servidor da vítima) e até 163 vezes no tráfego.
O problema está relacionado às características do funcionamento do protocolo e afeta todos os servidores DNS que suportam o processamento recursivo de consultas, incluindo (CVE-2020-8616), (CVE-2020-12667), (CVE-2020-10995), e (CVE-2020-12662), bem como os serviços DNS públicos do Google, Cloudflare, Amazon, Quad9, ICANN e outras empresas. A correção do problema foi coordenada com os desenvolvedores dos servidores DNS, que ao mesmo tempo lançaram atualizações para corrigir a vulnerabilidade em seus produtos. A proteção contra o ataque foi implementada nas versões
, , , .
O ataque baseia-se na utilização de consultas pelo atacante que referenciam um grande número de registros NS fictícios que nunca foram encontrados anteriormente, os quais são delegados para resolver um nome, mas sem a inclusão de registros glue na resposta com informações sobre os endereços IP dos servidores NS. Por exemplo, o atacante envia uma consulta para resolver o nome sd1.attacker.com, controlando o servidor DNS responsável pelo domínio attacker.com. Em resposta à consulta do resolvedor ao servidor DNS do atacante, é dada uma resposta que delega a resolução do endereço sd1.attacker.com ao servidor DNS da vítima, através da inclusão de registros NS na resposta sem detalhamento dos IPs dos servidores NS. Como o servidor NS mencionado não foi encontrado anteriormente e seu endereço IP não está especificado, o resolvedor tenta determinar o endereço IP do servidor NS, enviando uma consulta ao servidor DNS da vítima que gerencia o domínio alvo (victim.com).
O problema é que o atacante pode retornar uma enorme lista de servidores NS não repetidos com nomes de subdomínios fictícios que não existem da vítima (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.com). O resolvedor tentará enviar uma solicitação ao servidor DNS da vítima, mas receberá uma resposta dizendo que o domínio não foi encontrado, e então tentará determinar o próximo servidor NS na lista, e assim por diante, até que tenha passado por todas as entradas de NS fornecidas pelo atacante. Assim, para uma única solicitação do atacante, o resolvedor enviará um número enorme de solicitações para determinar os hosts NS. Como os nomes dos servidores NS são formados aleatoriamente e referem-se a subdomínios inexistentes, eles não são extraídos do cache, e cada solicitação do atacante leva a uma enxurrada de solicitações ao servidor DNS que atende ao domínio da vítima.
Pesquisadores estudaram a vulnerabilidade dos resolvedores DNS públicos e determinaram que, ao enviar solicitações ao resolvedor CloudFlare (1.1.1.1), pode-se alcançar um aumento no número de pacotes (PAF, Fator de Amplificação de Pacote) de 48 vezes, Google (8.8.8.8) — 30 vezes, FreeDNS (37.235.1.174) — 50 vezes, OpenDNS (208.67.222.222) — 32 vezes. Os valores mais notáveis são observados para
Level3 (209.244.0.3) — 273 vezes, Quad9 (9.9.9.9) — 415 vezes
SafeDNS (195.46.39.39) — 274 vezes, Verisign (64.6.64.6) — 202 vezes,
Ultra (156.154.71.1) — 405 vezes, Comodo Secure (8.26.56.26) — 435 vezes, DNS.Watch (84.200.69.80) — 486 vezes, e Norton ConnectSafe (199.85.126.10) — 569 vezes. Para servidores baseados no BIND 9.12.3, devido à paralelização de solicitações, o nível de amplificação pode chegar a 1000. No Knot Resolver 5.1.0, o nível de amplificação é de aproximadamente algumas dezenas de vezes (24-48), pois a determinação dos nomes NS é realizada sequencialmente e está sujeita a uma limitação interna no número de etapas de resolução de nomes permitidas para uma única solicitação.
Duas estratégias principais de proteção são destacadas. Para sistemas com DNSSEC utilizados para evitar a contornada do cache DNS, já que as solicitações são enviadas com nomes aleatórios. A essência do método é gerar respostas negativas sem recorrer a servidores DNS autoritativos, utilizando verificação de intervalos através do DNSSEC. Um método mais simples é limitar o número de nomes que podem ser determinados durante o processamento de uma única solicitação delegada, mas esse método pode levar a problemas com algumas configurações existentes, pois os limites não são definidos no protocolo.
Fonte: opennet.ru
