Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

La vulnérabilité DNS tsuNAME

Première rédaction de cet article le 6 mai 2021


L'Internet est plein de failles de sécurité donc, aujourd'hui, pas de surprise qu'une nouvelle faille soit publiée : tsuNAME est une faille DNS permettant des attaques par déni de service en exploitant un cycle dans les dépendances des noms de domaine.

Le principe est simple : l'attaquant doit contrôler deux noms de domaine, avec un parent qui est la victime visée. Mettons que le méchant veuille attaquer le TLD .example, il a deux noms, foo.example et bar.example, il crée un cycle en faisant en sorte que les serveurs de noms de foo.example soient tous dans bar.example et réciproquement. En syntaxe de fichier de zone :

foo IN NS ns.bar.example.
bar IN NS ns.foo.example.
  

(C'est une présentation simplifiée : un attaquant peut faire des cycles plus complexes.) Aucun nom en foo.example ou bar.example ne peut être résolu avec succès, en raison de ce cycle. Mais le but de l'attaquant n'est pas là : lorsqu'un résolveur veut résoudre www.foo.example, le serveur faisant autorité pour .example le renvoie à ns.bar.example. Pour résoudre ce nom, il interroge à nouveau le pauvre serveur faisant autorité pour .example, qui le renvoie à ns.foo.example et ainsi de suite. (Si vous aimez les vidéos, je vous renvoie à celle de l'Afnic sur le fonctionnement du DNS.) Et, pire, certains résolveurs ne se souviennent pas que la résolution a échoué et recommencent donc la fois suivante. Un attaquant qui a configuré le cycle (ou bien repéré un cycle existant) peut donc utiliser les résolveurs auxquels il a accès (directement, ou bien via un botnet qu'il contrôle) pour faire l'attaque à sa place.

Normalement, les résolveurs limitent le nombre de requêtes déclenchées par une requête originale. Ils le font surtout pour se protéger eux-mêmes, par exemple contre les attaques en récursion infinie. Mais la nouveauté de tsuNAME est de se servir d'un éventuel manque de limites pour attaquer les serveurs faisant autorité. En pratique, peu de résolveurs sont assez imprudents pour être vraiment intéressants pour l'attaquant. La principale exception était Google Public DNS, qui a ainsi involontairement participé à une attaque contre le .nz. (Il a été corrigé depuis.)

Une leçon pour les programmeurs de résolveurs DNS : ne vous laissez pas entrainer dans des cycles, pensez à jeter l'éponge rapidement, et à mémoriser cet échec pour la prochaine fois.

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)