Attaque NXNSAttack affectant tous les résolveurs DNS

Un groupe de chercheurs de l’Université de Tel Aviv et du Centre Interdisciplinaire de Herzliya (Israël) a développé nouvelle méthode d'attaque NXNSAttaque (PDF), vous permettant d'utiliser n'importe quel résolveur DNS comme amplificateur de trafic, fournissant un taux d'amplification allant jusqu'à 1621 fois en termes de nombre de paquets (pour chaque requête envoyée au résolveur, vous pouvez atteindre 1621 requêtes envoyées au serveur de la victime) et jusqu'à 163 fois en termes de trafic.

Le problème est lié aux particularités du protocole et affecte tous les serveurs DNS prenant en charge le traitement récursif des requêtes, notamment BIND (CVE-2020-8616), Nœud (CVE-2020-12667), PowerDNS (CVE-2020-10995), Windows serveur DNS и Non lié (CVE-2020-12662), ainsi que les services DNS publics de Google, Cloudflare, Amazon, Quad9, ICANN et d'autres sociétés. Le correctif a été coordonné avec les développeurs de serveurs DNS, qui ont simultanément publié des mises à jour pour corriger la vulnérabilité de leurs produits. Protection contre les attaques implémentée dans les versions
Non lié 1.10.1, Résolveur de nœuds 5.1.1, Récurseur PowerDNS 4.3.1, 4.2.2, 4.1.16, LIER 9.11.19, 9.14.12, 9.16.3.

L'attaque est basée sur l'utilisation par l'attaquant de requêtes faisant référence à un grand nombre d'enregistrements NS fictifs inédits, auxquels la détermination du nom est déléguée, mais sans spécifier d'enregistrements de colle contenant des informations sur les adresses IP des serveurs NS dans la réponse. Par exemple, un attaquant envoie une requête pour résoudre le nom sd1.attacker.com en contrôlant le serveur DNS responsable du domaine attaquant.com. En réponse à la requête du résolveur au serveur DNS de l'attaquant, une réponse est émise qui délègue la détermination de l'adresse sd1.attacker.com au serveur DNS de la victime en indiquant les enregistrements NS dans la réponse sans détailler les serveurs IP NS. Étant donné que le serveur NS mentionné n'a pas été rencontré auparavant et que son adresse IP n'est pas spécifiée, le résolveur tente de déterminer l'adresse IP du serveur NS en envoyant une requête au serveur DNS de la victime desservant le domaine cible (victim.com).

Le problème est que l'attaquant peut répondre avec une énorme liste de serveurs NS non répétitifs avec des noms de sous-domaines de victimes fictifs inexistants (fake-1.victim.com, fake-2.victim.com,... fake-1000. victime.com). Le résolveur tentera d'envoyer une requête au serveur DNS de la victime, mais recevra une réponse indiquant que le domaine n'a pas été trouvé, après quoi il tentera de déterminer le prochain serveur NS dans la liste, et ainsi de suite jusqu'à ce qu'il ait essayé toutes les solutions. Enregistrements NS répertoriés par l'attaquant. En conséquence, pour une requête d’un attaquant, le résolveur enverra un grand nombre de requêtes pour déterminer les hôtes NS. Étant donné que les noms de serveurs NS sont générés de manière aléatoire et font référence à des sous-domaines inexistants, ils ne sont pas récupérés du cache et chaque requête de l'attaquant entraîne une vague de requêtes adressées au serveur DNS desservant le domaine de la victime.

Les chercheurs ont étudié le degré de vulnérabilité des résolveurs DNS publics au problème et ont déterminé que lors de l'envoi de requêtes au résolveur CloudFlare (1.1.1.1), il est possible d'augmenter le nombre de paquets (PAF, Packet Amplification Factor) de 48 fois, Google (8.8.8.8) - 30 fois, FreeDNS (37.235.1.174) - 50 fois, OpenDNS (208.67.222.222) - 32 fois. Des indicateurs plus visibles sont observés pour
Niveau3 (209.244.0.3) - 273 fois, Quad9 (9.9.9.9) - 415 fois
SafeDNS (195.46.39.39) - 274 fois, Verisign (64.6.64.6) - 202 fois,
Ultra (156.154.71.1) - 405 fois, Comodo Secure (8.26.56.26) - 435 fois, DNS.Watch (84.200.69.80) - 486 fois et Norton ConnectSafe (199.85.126.10) - 569 fois. Pour les serveurs basés sur BIND 9.12.3, en raison de la parallélisation des requêtes, le niveau de gain peut atteindre jusqu'à 1000. Dans Knot Resolver 5.1.0, le niveau de gain est d'environ plusieurs dizaines de fois (24-48), puisque la détermination de Les noms NS sont exécutés séquentiellement et reposent sur la limite interne du nombre d'étapes de résolution de noms autorisées pour une requête.

Il existe deux principales stratégies de défense. Pour les systèmes avec DNSSEC Proposé par utiliser RFC-8198 pour empêcher le contournement du cache DNS car les requêtes sont envoyées avec des noms aléatoires. L'essence de la méthode est de générer des réponses négatives sans contacter des serveurs DNS faisant autorité, en utilisant la vérification de plage via DNSSEC. Une approche plus simple consiste à limiter le nombre de noms pouvant être définis lors du traitement d'une seule demande déléguée, mais cette méthode peut poser des problèmes avec certaines configurations existantes car les limites ne sont pas définies dans le protocole.

Source: opennet.ru