Um grupo de pesquisadores da Universidade de Tel Aviv e do Centro Interdisciplinar de Herzliya (Israel)
O problema está relacionado às peculiaridades do protocolo e afeta todos os servidores DNS que suportam processamento de consultas recursivas, incluindo
O ataque é baseado no fato de o invasor usar solicitações que se referem a um grande número de registros NS fictícios inéditos, aos quais é delegada a determinação do nome, mas sem especificar registros cola com informações sobre os endereços IP dos servidores NS na resposta. Por exemplo, um invasor envia uma consulta para resolver o nome sd1.attacker.com controlando o servidor DNS responsável pelo domínio attacker.com. Em resposta à solicitação do resolvedor ao servidor DNS do invasor, é emitida uma resposta que delega a determinação do endereço sd1.attacker.com ao servidor DNS da vítima, indicando os registros NS na resposta sem detalhar os servidores IP NS. Como o servidor NS mencionado não foi encontrado antes e seu endereço IP não foi especificado, o resolvedor tenta determinar o endereço IP do servidor NS enviando uma consulta ao servidor DNS da vítima que atende o domínio de destino (victim.com).
O problema é que o invasor pode responder com uma lista enorme de servidores NS não repetitivos com nomes de subdomínios de vítimas fictícios inexistentes (fake-1.victim.com, fake-2.victim.com,... fake-1000. vítima. com). O resolvedor tentará enviar uma solicitação ao servidor DNS da vítima, mas receberá uma resposta informando que o domínio não foi encontrado, após o que tentará determinar o próximo servidor NS da lista e assim por diante até tentar todos os Registros NS listados pelo invasor. Conseqüentemente, para a solicitação de um invasor, o resolvedor enviará um grande número de solicitações para determinar os hosts NS. Como os nomes dos servidores NS são gerados aleatoriamente e referem-se a subdomínios inexistentes, eles não são recuperados do cache e cada solicitação do invasor resulta em uma enxurrada de solicitações ao servidor DNS que atende o domínio da vítima.
Os pesquisadores estudaram o grau de vulnerabilidade dos resolvedores DNS públicos ao problema e determinaram que ao enviar consultas ao resolvedor CloudFlare (1.1.1.1), é possível aumentar o número de pacotes (PAF, Packet Amplification Factor) em 48 vezes, disse o Google. (8.8.8.8) - 30 vezes, FreeDNS (37.235.1.174) - 50 vezes, OpenDNS (208.67.222.222) - 32 vezes. Indicadores mais perceptíveis são observados para
Nível3 (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 em BIND 9.12.3, devido à paralelização de solicitações, o nível de ganho pode chegar a 1000. No Knot Resolver 5.1.0, o nível de ganho é aproximadamente várias dezenas de vezes (24-48), desde a determinação de Os nomes NS são executados sequencialmente e dependem do limite interno do número de etapas de resolução de nomes permitidas para uma solicitação.
Existem duas estratégias principais de defesa. Para sistemas com DNSSEC
Fonte: opennet.ru