Empoisonnement du cache DNS

L'empoisonnement du cache DNS, l’usurpation de DNS, ou la pollution de cache DNS (DNS cache poisoning, DNS spoofing, ou DNS cache pollution en anglais) est une technique permettant de leurrer les serveurs DNS afin de leur faire croire qu'ils reçoivent une réponse valide à une requête qu'ils effectuent, alors qu'elle est frauduleuse. Une fois que le serveur DNS a été empoisonné, l'information est mise dans un cache, rendant ainsi vulnérables tous les utilisateurs de ce serveur. Ce type d'attaque permet, par exemple, d'envoyer un utilisateur vers un faux site dont le contenu peut servir à de l'hameçonnage (dans le cas du DNS, on parle de pharming) ou comme vecteur de virus et autres applications malveillantes.

Un ordinateur présent sur Internet utilise normalement un serveur DNS géré par le fournisseur d'accès. Ce serveur DNS est la plupart du temps limité aux seuls utilisateurs du réseau du fournisseur d'accès et son cache contient une partie des informations rapatriées par le passé. Une attaque par empoisonnement sur un seul serveur DNS du fournisseur d'accès peut affecter l'ensemble de ses utilisateurs, soit directement ou indirectement si des serveurs esclaves s'occupent de propager l'information.

La vulnérabilité des systèmes à l'empoisonnement du cache DNS va au-delà de ses effets immédiats, les rendant potentiellement exposés à des risques supplémentaires tels que l'hameçonnage, les injections de logiciels malveillants, les dénis de service et le piratage de sites en raison des vulnérabilités du système.

Principe

Pour mener à bien une attaque par empoisonnement de cache, l'attaquant exploite une vulnérabilité du serveur DNS qui accepte alors des informations incorrectes. Si le serveur ne valide pas les informations reçues et qu'il ne vérifie pas qu'elles proviennent d'une source fiable, alors il stockera dans son cache ces informations erronées. Il les transmettra par la suite aux utilisateurs qui effectuent la requête visée par l'attaque.

Cette technique peut être employée pour substituer un contenu, que les victimes s'attendent à obtenir, par un autre contenu. L'attaquant peut par exemple rediriger un utilisateur d'un site web vers un autre site dont le serveur est compromis ou maintenu par l'attaquant. Selon le type d'attaque menée et afin de ne pas éveiller les soupçons, le nouveau contenu doit ressembler le plus possible au contenu original.

Cette manipulation peut avoir plusieurs buts :

• propagation de virus ou de vers en faisant croire à l'utilisateur qu'il télécharge des fichiers sains
• hameçonnage (pharming) afin de collecter des informations personnelles, récupérer des mots de passe ou effectuer une fraude
• usurpation d'identité (on renvoie le site d'une personne vers un autre site)
• attaque de l'homme du milieu (l'attaquant fait en sorte de se trouver au milieu de transactions afin de les intercepter, les déchiffrer et les rediriger de manière transparente)
• propagande, contestation (par exemple en renvoyant un site d'un parti politique vers un autre parti)
• guerre électronique (perturbation du réseau en renvoyant les utilisateurs vers d'autres sites qui ne leur permettent pas d'effectuer leur travail)
• déni de service (renvoi vers un site n'existant pas, faisant croire à l'utilisateur que le serveur n'est plus disponible) ou guerre commerciale (voir l'affaire AlterNIC plus loin)

Aspects techniques

Un serveur DNS permet d'obtenir l'adresse IP d'une cible à partir de son nom (par exemple l'entrée pour fr.wiki.x.io retourne 145.97.39.155). Afin d'obtenir cette adresse IP, le serveur peut soit consulter son cache si l'information s'y trouve ou alors propager la requête plus loin, vers d'autres serveurs de manière récursive. L'ensemble du réseau est organisé selon un arbre subdivisé en domaines. Dans le cas de fr.wiki.x.io, le serveur DNS chargé du domaine .org va être interrogé, il va indiquer quel serveur peut donner des informations au sujet du domaine wikipedia.org. Finalement, ce dernier serveur indiquera l'IP complète pour fr.wiki.x.io. La validité des messages repose sur un identifiant de 16 bits qui doit être le même durant une transaction. Par ailleurs, le port et l'adresse utilisée pour la réponse doivent correspondre aux paramètres utilisés lors de l'envoi de la requête.

Attaque basée sur le paradoxe des anniversaires

Cette attaque part du principe qu'un identifiant de 16 bits ne garantit pas une sécurité suffisante. Grâce au paradoxe des anniversaires, il est en effet possible de générer un grand nombre de messages de manière à tomber sur un identifiant valide. L'attaque se déroule comme suit et s'apparente à du spoofing :

1. Alice envoie un grand nombre de requêtes au serveur cible A, en spécifiant le nom de domaine (fr.oui biensur) dont elle voudrait obtenir l'IP
2. en même temps, elle se fait passer pour un autre serveur de nom B en préparant des réponses qui y ressemblent, mais avec des identifiants de transaction aléatoires (en vertu du paradoxe des anniversaires) de manière à produire un paquet comme celui attendu par le serveur cible. Elle spécifie par ailleurs une nouvelle IP w.x.y.z
3. si le paquet correspond à ce qui était attendu par le serveur cible, alors celui-ci, en l'absence d'une protection particulière, insère l'information malveillante dans le cache où elle reste durant un certain temps (défini par le TTL, time to live)
4. Bob demande à accéder à Wikipédia, l'IP qu'il reçoit n'est plus celle de fr.wiki.x.io mais w.x.y.z

La difficulté de cette attaque consiste à déterminer le port sur lequel le serveur B va répondre et à empêcher le vrai serveur de nom de répondre dans les temps. Si les ports sont aléatoires alors l'attaque sera beaucoup plus difficile, car elle nécessite plus de messages. Certaines attaques reposaient sur le fait que les générateurs de nombres pseudo-aléatoires des serveurs n'offraient pas un aléa suffisant. Des identifiants de transaction avaient ainsi plus de chance d'apparaître que d'autres, offrant à l'attaque une probabilité de réussite accrue.

La solution à ce problème fut d'empêcher les demandes multiples émanant de la même source pour un même nom de domaine (c'est-à-dire qu'une seule requête d'Alice concernant fr.wiki.x.io est traitée à la fois).

Variante

Pour contourner le problème lié au TTL, au lieu de susciter une requête pour fr.wiki.x.io, le pirate génère une série de requêtes pour des hôtes du même sous-domaine, par exemple xx.wiki.x.io, et tente à chaque fois un empoisonnement en tentant de deviner le numéro de transaction. La réponse consiste non pas en un enregistrement A vers un serveur pirate (dont l'IP est 6.6.6.6) mais un NS :

xx.wiki.x.io     IN NS    fr.wiki.x.io
fr.wiki.x.io     IN A     6.6.6.6

Le second enregistrement est alors mis en cache, ce qui assure le succès de l'attaque. Le hacker peut envoyer de très nombreuses réponses (seule celle avec le numéro de transaction correct sera pris en compte), et le temps dont il dispose dépend de la rapidité de la réponse du serveur DNS légitime. Si cette tentative échoue, il peut recommencer immédiatement avec un autre hôte du sous-domaine, ce qui augmente de façon importante ses chances de succès. Les serveurs récursifs n'étant généralement accessibles qu'à certaines plages d'adresses IP (les clients), le hacker peut utiliser une fausse adresse IP source ou bien générer un trafic qui résultera probablement en une requête DNS (SMTP HELO, scanning, etc).

Attaque par l'ajout de plusieurs résolutions

L'attaquant dispose d'un serveur de nom pour un domaine (par exemple empoisonnement-dns.com). Le but est de polluer le cache du serveur cible A en se basant sur une vulnérabilité et en procédant comme suit :

1. Alice demande l'IP de empoisonnement-dns.com au serveur cible A
2. le serveur A ne dispose pas de cette information dans son cache, il contacte alors le serveur de nom pour le domaine
3. le serveur de nom, sous le contrôle de l'attaquant, renvoie les informations concernant empoisonnement-dns.com, mais ajoute des informations concernant d'autres sites dans sa réponse, par exemple l'adresse de fr.wiki.x.io qu'il fait pointer vers un autre site dont l'IP est w.x.y.z
4. le serveur insère l'information malveillante dans le cache où elle reste durant un certain temps (défini par le TTL, time to live)
5. Bob demande à accéder à Wikipédia, l'IP qu'il reçoit n'est plus celle de fr.wiki.x.io, mais w.x.y.z

Cette attaque a été utilisée en juin 1997 par Eugene Kashpureff qui gérait un serveur DNS alternatif à la racine du système (nommé AlterNIC). Kashpureff redirigea le trafic d'Internic (son concurrent direct) vers le site d'AlterNIC . Nommée Operation DNS Storm, son action lui valut d'être arrêté quelques mois plus tard.

Prévention et défense

La plupart des attaques peuvent être évitées en ajoutant des vérifications supplémentaires. Dans le cas d'une attaque comme celle d'Eugene Kashpureff, la parade consiste à vérifier que la réponse correspond à ce qui était attendu (l'IP du nom de domaine demandé et rien d'autre) et à l'ignorer dans le cas contraire. L'amélioration des générateurs de nombres pseudo-aléatoires en utilisant des générateurs cryptographiques pour l'identifiant de 16 bits et les ports ont permis de limiter les problèmes dans les serveurs les plus utilisés (dont BIND). La limitation des demandes multiples pour un même nom à partir d'une même source a partiellement réduit l'attaque par le paradoxe des anniversaires, mais elle pourrait être menée à partir d'un botnet, ce qui nécessite d'autres moyens de défense pour détecter les tentatives de ce type.

Une version sécurisée du DNS existe, DNSSEC, qui se base sur des signatures électroniques avec un certificat qui permet de vérifier l'authenticité des données. Même s'il reste toutefois peu répandu, son usage doit être encouragé. L'empoisonnement peut être limité au niveau des couches transport ou application grâce à une authentification des intervenants, via par exemple TLS. Un serveur DNS pourrait ainsi s'assurer qu'il reçoit bien les informations depuis un serveur de confiance. Il en va de même pour les autres applications comme les navigateurs qui peuvent vérifier l'authenticité d'une page grâce aux certificats.

En juillet 2008, des mises à jour de sécurité concernant les serveurs DNS ont été effectuées par un grand nombre d'acteurs du logiciel libre et propriétaire. Ces mises à jour ont été effectuées de façon synchronisée pour remédier à une faille découverte plusieurs mois avant par Dan Kaminsky (de la société IOActive) qui s'avérait critique. Cette faille a été jugée suffisamment sérieuse pour que le secret soit conservé le temps de mettre en place des solutions de protection.

Liens externes

• (en) Test le DNS de votre ISP
• « Qu’est ce que l’empoisonnement de cache DNS ? », sur cloudflare.com (consulté le 15 septembre 2022)