Un groupe de chercheurs de l’Université de Tel Aviv et du Centre Interdisciplinaire de Herzliya (Israël)
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
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
Source: opennet.ru