Ataque NXNSAttack afetando todos os resolvedores de DNS

Um grupo de pesquisadores da Universidade de Tel Aviv e do Centro Interdisciplinar de Herzliya (Israel) foi desenvolvido novo método de ataque Ataque NXNS (PDF), permitindo que você use qualquer resolvedor DNS como amplificador de tráfego, fornecendo uma taxa de amplificação de até 1621 vezes em termos de número de pacotes (para cada solicitação enviada ao resolvedor, você pode conseguir 1621 solicitações enviadas ao servidor da vítima) e até 163 vezes em termos de tráfego.

O problema está relacionado às peculiaridades do protocolo e afeta todos os servidores DNS que suportam processamento de consultas recursivas, incluindo LIGAR (CVE-2020-8616) pavio (CVE-2020-12667) PowerDNS (CVE-2020-10995) Servidor DNS do Windows и Não consolidado (CVE-2020-12662), bem como serviços DNS públicos do Google, Cloudflare, Amazon, Quad9, ICANN e outras empresas. A correção foi coordenada com desenvolvedores de servidores DNS, que lançaram simultaneamente atualizações para corrigir a vulnerabilidade em seus produtos. Proteção contra ataques implementada em versões
Não consolidado 1.10.1, Resolvedor de nós 5.1.1, Recursor PowerDNS 4.3.1, 4.2.2, 4.1.16, VINCULAR 9.11.19, 9.14.12, 9.16.3.

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).

Ataque NXNSAttack afetando todos os resolvedores de DNS

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.

Ataque NXNSAttack afetando todos os resolvedores de DNS

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 proposto por usar RFC-8198 para evitar o desvio do cache DNS porque as solicitações são enviadas com nomes aleatórios. A essência do método é gerar respostas negativas sem entrar em contato com servidores DNS autorizados, usando verificação de intervalo via DNSSEC. Uma abordagem mais simples é limitar o número de nomes que podem ser definidos ao processar uma única solicitação delegada, mas este método pode causar problemas com algumas configurações existentes porque os limites não estão definidos no protocolo.

Fonte: opennet.ru

Adicionar um comentário