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é une nouvelle méthode d'attaque NXNSAttack (PDF), qui permet d'utiliser n'importe quel résolveur DNS comme amplificateur de trafic, offrant un taux d'amplification allant jusqu'à 1621 fois en nombre de paquets (pour chaque requête envoyée au résolveur, on peut obtenir l'envoi de 1621 requêtes au serveur cible) et jusqu'à 163 fois en trafic.

Le problème est lié aux particularités du fonctionnement du protocole et affecte tous les serveurs DNS prenant en charge le traitement récursif des requêtes, y compris BIND (CVE-2020-8616), Knot (CVE-2020-12667), PowerDNS (CVE-2020-10995), Serveur DNS Windows et Unbound (CVE-2020-12662), ainsi que les services DNS publics de Google, Cloudflare, Amazon, Quad9, ICANN et d'autres entreprises. La correction du problème a été coordonnée avec les développeurs de serveurs DNS, qui ont simultanément publié des mises à jour pour corriger la vulnérabilité dans leurs produits. La protection contre l'attaque a été mise en œuvre dans les versions
Unbound 1.10.1, Knot Resolver 5.1.1, PowerDNS Recursor 4.3.1, 4.2.2, 4.1.16, BIND 9.11.19, 9.14.12, 9.16.3.

L'attaque repose sur l'utilisation, par l'attaquant, de requêtes se référant à un grand nombre d'enregistrements NS fictifs jamais rencontrés auparavant, qui se voient déléguer la définition d'un nom, mais sans fournir dans la réponse des enregistrements glue contenant des informations sur les adresses IP des serveurs NS. Par exemple, l'attaquant envoie une requête pour définir le nom sd1.attacker.com, contrôlant le serveur DNS responsable du domaine attacker.com. En réponse à la requête du résolveur au serveur DNS de l'attaquant, une réponse est fournie, déléguant la définition de l'adresse sd1.attacker.com au serveur DNS de la victime par le biais d'enregistrements NS dans la réponse sans spécifier les adresses IP des serveurs NS. Étant donné que le serveur NS mentionné n'a jamais é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, qui gère le domaine ciblé (victim.com).

Le problème est que l'attaquant peut renvoyer une énorme liste de serveurs NS uniques avec des noms de sous-domaines fictifs non existants de la victime (fake-1.victim.com, fake-2.victim.com,… fake-1000.victim.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 est introuvable, après quoi il tentera de déterminer le prochain serveur NS dans la liste et ainsi de suite, jusqu'à ce qu'il ait épuisé tous les enregistrements NS listés par l'attaquant. Par conséquent, pour une seule requête de l'attaquant, un grand nombre de requêtes sera envoyé par le résolveur pour déterminer les hôtes NS. Étant donné que les noms des serveurs NS sont générés aléatoirement et font référence à des sous-domaines inexistants, ils ne sont pas extraits du cache, ce qui conduit chaque requête de l'attaquant à une multitude de requêtes vers le serveur DNS qui gère le domaine de la victime.

Les chercheurs ont étudié la vulnérabilité des résolveurs DNS publics et ont déterminé qu'en envoyant des requêtes au résolveur CloudFlare (1.1.1.1), on pouvait multiplier le nombre de paquets (PAF, Packet Amplification Factor) par 48, Google (8.8.8.8) par 30, FreeDNS (37.235.1.174) par 50, OpenDNS (208.67.222.222) par 32. Des chiffres plus significatifs sont observés pour
Level3 (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, grâce à l'égalisation des requêtes, le niveau d'amplification peut atteindre 1000. Dans Knot Resolver 5.1.0, le niveau d'amplification est d'environ plusieurs dizaines de fois (24-48), car la détermination des noms NS est effectuée de manière séquentielle et est limitée par un plafond interne sur le nombre d'étapes de résolution des noms autorisées pour une seule requête.

Deux principales stratégies de protection se distinguent. Pour les systèmes avec DNSSEC, d'activer d'utiliser RFC-8198 pour empêcher le contournement du cache DNS, car les requêtes sont envoyées avec des noms aléatoires. Le principe de la méthode consiste à générer des réponses négatives sans interroger les serveurs DNS autoritaires, en appliquant un contrôle par plages via DNSSEC. Une méthode plus simple consiste à limiter le nombre de noms pouvant être résolus lors du traitement d'une seule requête déléguée, mais cette méthode peut poser des problèmes avec certaines configurations existantes, car les limites ne sont pas spécifiées dans le protocole.

Source : opennet.ru