Le DNS cache poisoning ou empoisonnement de cache DNS est une pratique vieille de plus de 10 ans, visant à usurper un nom de domaine. Cette pratique revient aujourd’hui sur le devant de la scène grâce à la découverte d’une nouvelle vulnérabilité provoquée par l’exploitation de canaux auxiliaires. Il a été constaté au fil des années que le détournement de DNS est une attaque courante dont les enjeux sont critiques.
L’aspect stratégique de l’attaque par DNS cache poisoning
L’essence de l’attaque par DNS cache poisoning se trouve dans l’obsolescence du système de nom de domaine que nous connaissons actuellement. Au début d’internet, dans les années 1980, les enjeux n’étaient pas les mêmes qu’aujourd’hui. À l’origine, internet a été conçu pour faire communiquer ensemble quelques grandes universités américaines, à l’aide de protocoles se basant sur la confiance. Aujourd’hui, le réseau est devenu mondial et les protocoles, même s’ils ont évolué, souffrent de vulnérabilités fondamentales. DNS fait partie de ces services dont la conception n’a pas été pensée de manière sécurisée.
L’empoisonnement de cache DNS a pour objectif de diriger un utilisateur vers un contenu qu’il n’a pas demandé pour lui subtiliser des données et cela de manière totalement transparente. Cette pratique et celle du phishing sont semblables dans l’idée, mais n’ont finalement rien en commun. Le DNS cache poisoning possède l’avantage stratégique de ne nécessiter aucune ingénierie sociale et d’être indétectable, car aucune information visible ne permet de se rendre compte de la supercherie. Par cette attaque, un hacker peut rendre inaccessible un site, porter atteinte à l’image d’une entreprise, diffuser des malwares ou encore subtiliser tout type de données à un utilisateur.
Cette attaque se base sur des facteurs relativement complexes et n’est pas à la portée du premier venu. Celle-ci nécessite une bonne compréhension du système de nom de domaines et des réseaux en général. Le résultat de l’exploitation de cette faille est critique, mais la difficulté d’exploitation rend sa criticité relative. Toutefois, de nombreuses attaques de la sorte ont été constatées durant la dernière décennie. En 2009, pendant plusieurs heures le trafic de twitter.com a été redirigé vers une page web revendiquant la supériorité de l’Iran. En 2010, le trafic vers la plus grande banque en ligne russe (chronopay.com) a été détourné. L’attaque a duré plusieurs heures durant lesquels plus de 800 cartes de crédit ont été volées. À plus grande échelle, une attaque ayant eu lieu en 2011 redirigeait tous les internautes brésiliens utilisant Google, Gmail et Hotmail sur un site malveillant. Cette attaque aurait exposé des millions d’utilisateurs à un malware.
Plus récemment, les sites malaysiaairlines.com en 2015 et amazon.com en 2018 ont également été victimes de détournement de trafic par empoisonnement de cache DNS. Ces quelques exemples mettent en évidence qu’aucun site web n’est à l’abri et que la portée de ce type d’attaque peut être considérable.
Cette pratique pourrait représenter un outil d’espionnage et de déstabilisation de plus en plus puissant dans un monde de plus en plus connecté. Apporter des correctifs de sécurité ou fermer les canaux auxiliaires faillibles peut apporter une solution temporaire à ce type de vulnérabilité, mais ne représente en aucun cas une solution efficace pour mettre fin à ce problème. L’arrivée de DNSSEC semble être la réponse au problème. Il apporte une importante couche de sécurité, notamment sur l’authentification des communications entre les serveurs DNS. Cependant, la démocratisation de cette évolution prendra encore du temps étant donné la frilosité des acteurs lorsqu’il s’agit de toucher aux fondements d’internet.
Qu’est ce qu’un système de nom de domaine ?
Un Domaine Name System (DNS) ou système de nom de domaine est un service informatique permettant de faire la traduction d’un nom de domaine vers une adresse IP. Il faut savoir que les navigateurs internet ne communiquent que par le biais d’adresses IP. Un nom de domaine est une chaine de caractère intelligible par l’homme, comme « google.com » par exemple, et associée à une adresse IP. Un serveur DNS est en quelque sorte l’équivalent d’un répertoire téléphonique, mais pour internet. Il associe les noms de domaines aux adresses IP.
Crédits : icones8.fr
Figure 1 : processus de récupération de l’adresse IP liée à un nom de domaine
Le navigateur a besoin d’échanger avec un DNS spécifique, le DNS Resolver (ou résolveur). Cela afin de récupérer l’adresse IP associée au nom de domaine présent dans l’URL, comme l’expose la figure 1. Ce processus permet au navigateur de se connecter au serveur attaché à cette adresse IP et de lui demander d’afficher la page voulue par l’utilisateur. Il est important de préciser que le DNS Resolver n’est pas l’unique acteur dans ce processus de résolution. En effet, il communique lui-même des serveurs DNS de référence (Authoritative nameservers), pour pouvoir décoder le nom de domaine et adresser le bon chemin au client final. Toutefois, c’est le DNS Resolver qui joue le rôle le plus important, car finalement c’est lui qui transmet au navigateur la route à suivre pour afficher la page demandée sur l’écran de l’utilisateur. Pour un hacker, le résolveur est la cible idéale, car c’est le premier, mais également le dernier maillon de la chaine. Compromettre ce serveur de nom donnerait au pirate un contrôle total sur les IP transmises aux navigateurs et par conséquent sur le contenu envoyé aux clients.
Le principe de l’attaque par empoisonnement de cache DNS
Afin de diminuer le temps d’attente pour l’utilisateur, le DNS Resolver dispose d’un espace de stockage dédié à la sauvegarde des résolutions précédemment effectuées. C’est une sorte de feuille de note sur laquelle le serveur inscrit chaque résolution qu’il a dû réaliser. Cet espace de stockage s’appelle le cache DNS. Ainsi, le résolveur n’a pas constamment besoin de redécoder les noms de domaines qui lui sont transmis. Si un client lui demande une résolution et que celle-ci a déjà été exigée récemment par un autre utilisateur, il peut regarder dans son cache et renvoyer sans délai l’adresse IP correspondante. Ce mécanisme permet de décharger le réseau de requêtes, d’économiser des ressources et d’améliorer le confort pour l’ensemble des usagers d’internet. Cependant, cette fonctionnalité représente aussi bien une force qu’une faiblesse pour le réseau internet. Imaginons qu’un hacker parvienne à accéder au cache, il pourrait y modifier lui-même son contenu. Il y écrirait de fausses sauvegardes avec les IP de ses propres serveurs malveillants qu’il associerait à des noms de domaines légitimes. Il piègerait alors tout utilisateur voulant accéder au site web. Il pourrait par exemple associer au nom de domaine « google.com » l’IP de son serveur malveillant. Ce serveur contiendrait un site web parfaitement semblable à celui de Google, pour n’éveiller aucun soupçon chez les individus naviguant sur le site. Le hacker se retrouverait alors en position de Man In The Middle (MITM). C’est ce que le chercheur Dan Kaminsky a démontré en 2008.
Avant 2008, lors d’un processus de résolution de nom de domaine, le DNS Resolver communiquait avec les Authoritative nameservers par le port 53 par défaut. Le seul dispositif de sécurité implémenté était la génération d’un identifiant (ID) de 16 bits (compris entre 0 et 65 536) inclus dans l’échange entre le DNS Resolver et le DNS de référence. De cette manière, si la réponse reçue comprend un ID différent de celui qui a été envoyé, DNS Resolver ignore cette réponse car considérée comme illégitime. La figure 2 démontre l’inefficacité de cette fonctionnalité du fait du faible nombre de possibilités pour cet identifiant. Dan Kaminsky a prouvé qu’il était possible d’insérer dans le cache DNS, l’IP de son propre serveur pour n’importe quel nom de domaine, en envoyant au résolveur toutes les combinaisons possibles d’identifiants dans un très court laps de temps. Sa réponse malveillante est alors inscrite dans le cache, car reçue avant celle l’Authoritative, qui elle, est ignorée.
Crédits : icones8.fr
Figure 2 : principe du DNS cache poisoning démontré par Dan Kaminsky
La nouvelle attaque par exploitation de canaux auxiliaires
Depuis cette publication faite en 2008, des mesures de sécurité supplémentaires ont été déployées pour rendre l’attaque infaisable. Aujourd’hui, la communication ne se fait plus par défaut sur le port 53. Il est choisi aléatoirement parmi toute la gamme de ports UDP disponibles. En combinant le nombre d’identifiants possibles sur 16 bits avec le nombre de ports disponibles également sur 16 bits, nous nous retrouvons avec plus de 134 millions de combinaisons possibles. En novembre 2021, une équipe de chercheurs de l’université de Californie à Riverside a publié un papier se basant sur un travail fait en 2020 (SADDNS), exploitant des canaux auxiliaires pour parvenir à un empoisonnement de cache DNS. Lorsqu’un algorithme ou une méthode est fortement sécurisé, il est souvent plus facile pour un attaquant de passer par un moyen détourné pour parvenir à ses fins. Une attaque par canal auxiliaire vise à extraire des informations par l’interprétation de signaux émis involontairement par un système. Des signaux qui trahiraient indirectement la sécurité de l’algorithme visé. De façon imagée, lire sur les lèvres de quelqu’un qui dicte à voix basse son mot de passe résulte de l’exploitation d’un canal auxiliaire. Cette nouvelle version de l’attaque a révélé que 38 % des résolveurs DNS étaient vulnérables.
Dans le cadre de notre attaque, c’est le protocole Internet Control Message Protocol (ICMP) qui a été utilisé pour trahir l’algorithme de communication du DNS Resolver. ICMP est un protocole de diagnostic réseau qui génère des messages relatifs à des erreurs de transmission. Par exemple, si l’on tente de joindre un serveur inaccessible, ICMP renverra un message d’erreur l’indiquant. Pour cette attaque, les chercheurs ont découvert deux messages d’erreur du protocole permettant d’apprendre quel port aléatoire secret a été utilisé pour le dialogue entre DNS Resolver et Authoritative nameserver. Les deux messages utilisés sont Frag-Needed et Redirect. Le principe est d’envoyer un de ces deux messages au DNS Resolver pour qu’il adapte son comportement après réception, afin de ne plus reproduire cette erreur. Pour que cette requête ICMP soit prise en compte par DNS Resolver, elle doit lui être envoyée sur le fameux port aléatoire secret.
Crédits : icones8.fr
Figure 3 : identification du port ouvert par bombardement de sondes ICMP
Comme cela est visible sur la figure 3, l’objectif est de bombarder le DNS Resolver de sondes ICMP sur tous les ports possibles. Dans notre exemple, le port ouvert secret que le hacker doit deviner est le n°12345. Le message ICMP est alors accepté et interprété par le résolveur. Cela a pour effet de faire changer son fonctionnement, ce qui pourra être constaté ultérieurement en observant le comportement de DNS Resolver. Pour résumer, si le comportement du serveur change après une sonde ICMP, c’est que l’attaquant a deviné le bon numéro de port de communication entre DNS Resolver et Authoritative nameserver. Ce canal auxiliaire lui a permis de réduire à néant l’efficacité de l’algorithme de sécurité visant à sélectionner aléatoirement le port UDP. Cela réduit considérablement le nombre de combinaisons port/IP possibles, celui-ci passe de 134 millions à 65 536. Comme le port est maintenant connu, il ne reste plus qu’à trouver l’identifiant aléatoire en utilisant la même méthode exposée par Dan Kaminsky en 2008.
Crédits : icones8.fr
Figure 4 : exemple de l’envoi de sondes ICMP Frag-Needed sur port ouvert et port fermé
Prenons l’exemple du message ICMP Frag-Needed pour illustrer ces deux mécanismes, c’est-à-dire la sonde sur port ouvert et sur port fermé. Le message d’erreur ICMP Frag-Needed indique à la source (ici DNS Resolver) que le paquet qu’il a essayé d’envoyer à un destinataire (ici Authoritative nameserver) n’a pas été accepté, car sa taille est supérieure à la taille maximale de paquet tolérée par le destinataire. En réaction à la réception de ce message d’erreur, la source va désormais découper ses messages pour les envoyer en plusieurs paquets de plus petites tailles. Sur la figure 4, le hacker envoie un message demandant la fragmentation des paquets. Puis il envoie une requête de type « Ping » pour vérifier si la réponse du serveur est bien fragmentée. Si la réponse qu’il reçoit est fragmentée, alors il a deviné le port ouvert.
Il est nécessaire d’aborder un dernier point pour comprendre la réelle plus-value apportée par le travail des chercheurs de l’université de Californie. La figure 4 expose un cas de figure où le DNS Resolver communique par port public. C’est-à-dire qu’il accepte des réponses provenant de n’importe quelle IP, sans vérifier si celle-ci provient bien de l’Authoritative nameserver à qui il a posé sa question. Or dans la pratique, la plupart des serveurs DNS communiquent par port privé. Par conséquent, si le paquet reçu par DNS Resolver ne contient pas l’IP d’Authoritative nameserver, il ne l’acceptera pas. Il est alors impossible de deviner quel port est ouvert sans spoofer l’IP d’Authoritative nameserver. L’inconvénient de spoofer une IP est que tout changement de comportement lié à ce paquet ne concernera que l’IP spoofé. Le hacker ne peut donc pas interpréter les canaux auxiliaires. Pour illustrer, si Eve souhaite envoyer une lettre postale à Bob en se faisant passer pour Alice, Eve va renseigner dans la case « expéditeur » l’adresse d’Alice. Lorsque Bob répondra à cette lettre, il inscrira dans la case « destinataire » l’adresse de l’expéditeur de la lettre reçue, donc Alice. Eve n’est pas dans la boucle, elle ne recevra rien. Les chercheurs ont trouvé un moyen de contourner ce problème complexe.
Lorsqu’un serveur Linux reçoit une erreur ICMP, celle-ci est enregistrée dans une table de hachage de 2048 emplacements avec l’adresse IP de destination comme clé. Chacun de ces emplacements est lié à une liste de 5 (6 pour IPV6) autres emplacements pour pallier le problème de collision. La vulnérabilité se trouve dans le fait que le nombre d’emplacements disponibles dans cette table est très faible. Il est alors très facile de provoquer des collisions. L’objectif pour le hacker est de trouver 5 (6 pour IPV6) IP différentes provoquant une collision avec l’IP du destinataire réel (Authoritative nameserver). Une fois ces IP trouvées, l’attaquant doit envoyer 5 (6 pour IPV6) sondes ICMP Frag-Needed successives au DNS Resolver pour remplir tous les emplacements anticollisions existants. Il ne lui reste plus qu’à bombarder de sondes la totalité des ports de DNS Resolver, comme dans la figure 4, avec l’IP spoofée d’Authoritative nameserver. Si la sonde touche le port secret ouvert, DNS Resolver enregistrera l’erreur ICMP dans la table de hachage. Sauf que la liste anticollision est déjà pleine… Le plus ancien enregistrement sera alors remplacé par celui-ci. Le plus ancien enregistrement étant une adresse IP contrôlée par l’attaquant, il va pouvoir tester la réaction du serveur à un paquet envoyé par cette IP. Par conséquent, si l’attaquant envoie un « PING » depuis l’adresse IP qui a été écrasée dans la table de hachage, il recevra une réponse de DNS Resolver qui n’est pas fragmentée. Il peut donc en déduire que son IP personnelle a été éjectée de la table de hachage à cause de la collision, il a donc deviné le numéro de port ouvert. Il ne lui reste plus qu’à reproduire l’attaque de Dan Kaminsky, avec le port qu’il connaît désormais.
Raphaël Barrasset, pour le club Cyber AEGE
Pour aller plus loin :