Le Domain Name System (DNS en abrégé) nous permet de déchiffrer le nom d’une page web grâce à son adresse IP. De cette manière, en tant qu’utilisateurs, nous n’avons pas besoin de nous remémorer les séquences de chiffres qui constituent une adresse IP (ou les numéros et lettres dans IPV6) et nous pouvons par exemple, accéder à la page de “www.facebook.com” juste en l’écrivant ainsi plutôt que d’indiquer “31.13.92.36”.
Le travail qu’effectuent les serveurs DNS est donc de retranscrire ces noms plus faciles à comprendre pour les utilisateurs en adresses IP. Cela est rendu possible grâce à une base de données hiérarchique distribuée qui stocke des informations (entre autres) comme quelle adresse IP est rattachée à quel nom de domaine, etc. Ce système permet de rendre plus facile la mémorisation des adresses Web et cela signifie que l’adresse IP peut être changée si besoin.
En clair, le DNS fournit une adresse IP pour chaque nom de domaine. Ce processus est appelé « résolution de nom ». Pour que la résolution de nom puisse fonctionner, l’adresse IP d’un serveur DNS doit être enregistrée sur chaque terminal. Le terminal adresse ses requêtes DNS à ce serveur qui procède à la résolution de nom et renvoie une réponse. Si aucun serveur DNS n’est paramétré sur un terminal, le serveur du routeur local est automatiquement utilisé.
Cependant, en 2008, un chercheur en sécurité du nom de Dan Kaminsky a présenté une technique permettant à des attaquants de modifier la réponse des serveurs DNS, afin d’orienter les internautes vers de faux sites, même après avoir tapé une adresse aussi connue que « google.com ». Cette attaque est connue sous le nom d’usurpation du DNS.
Pour être plus précis, l’usurpation de DNS représente le but ultime de l’attaque (en vue de changer les enregistrements stockés sur le serveur DNS selon les souhaits de l’attaquant) et plusieurs techniques existent. Elles peuvent se présenter sous la forme d’un empoisonnement du cache DNS, d’une attaque de type homme du milieu, d’une utilisation de stations de base factices et peut même compromettre la sécurité du serveur DNS.
L’empoisonnement de cache
Lorsque les architectes Internet ont conçu le DNS pour la première fois, ils ont reconnu qu’il était possible pour quelqu’un d’usurper l’identité d’un serveur faisant autorité et d’utiliser le DNS pour renvoyer des résultats malveillants aux résolveurs. Pour endiguer ce scénario, ils ont donc inclus un ID de 16 bits, afin qu’un résolveur n’accepte en réponse à ses requêtes que celles incluant le même identifiant.
Mais Kaminsky en a vite perçu la limite : un identifiant codé sur 16 bits ne laisse que 65 536 possibilités. Un attaquant pourrait exploiter cette limitation en inondant un résolveur DNS d’adresses IP pointant vers des domaines présentant de faibles variations avec celui que l’on voulait détourner (par exemple « 1.facebook.com », « 2.facebook.com », « 3.facebook.com », etc.) et en incluant un ID de transaction différent pour chacune des réponses. De cette façon, le hacker pourrait finir par obtenir le bon ID, le serveur réorientant alors les requêtes vers la nouvelle adresse et mettant à jour son cache, d’où cette appellation « d’empoisonnement ».
En fait, les serveurs du DNS sont organisés de façon hiérarchique et communiquent entre eux. Un hacker peut utiliser l’usurpation d’adresse IP pour se faire passer pour l’un de ces serveurs. Le hacker convainc un serveur d’accepter une adresse IP erronée pour un domaine. Le serveur enregistre l’entrée malveillante dans le cache qui est alors « empoisonné ». À chaque fois qu’une requête est adressée au serveur après l’empoisonnement du cache, l’entrée malveillante est transmise aux victimes. La menace reste active jusqu’à ce que l’entrée ait été retirée du cache.
L’écosystème DNS a résolu le problème en augmentant de façon exponentielle la quantité d’entropie requise pour qu’une réponse soit acceptée. Alors qu’avant, les requêtes et les réponses ne voyageaient que sur le port 53, le nouveau système procédait à l’utilisation d’un port aléatoire en combinaison de l’identifiant. Pour qu’un résolveur DNS accepte l’adresse IP, la réponse devait également inclure ce même numéro de port. Combinée à un numéro de transaction, l’entropie a été mesurée en milliards, ce qui rend mathématiquement impossible pour les attaquants de trouver la bonne combinaison.
Le retour de l’empoisonnement de cache
Mercredi, des chercheurs de l’Université Tsinghua et de l’Université de Californie à Riverside ont présenté une technique qui, une fois de plus, rend possible l’empoisonnement du cache. Leur méthode exploite un canal auxiliaire (side channel) leur permettant d’identifier le numéro de port. Une fois que les attaquants connaissent le numéro de port, nous nous retrouvons dans la situation de départ puisqu’ils ont de nouveau des chances de deviner l’ID de transaction.
Le canal auxiliaire dans ce cas est la limite de débit pour ICMP, l’abréviation de Internet Control Message Protocol, un protocole utilisé pour véhiculer des messages de contrôle et d’erreur, par exemple lorsqu’un service ou un hôte est inaccessible. Pour économiser la bande passante et les ressources informatiques, les serveurs ne répondront qu’à un nombre défini de requêtes provenant d’autres serveurs. Après cela, les serveurs ne fourniront aucune réponse. Jusqu’à récemment, Linux fixait toujours cette limite à 1 000 par seconde.
Pour exploiter ce canal auxiliaire, la nouvelle technique d’usurpation d’identité inonde un résolveur DNS avec un nombre élevé de requêtes conçues pour ressembler à celles émises par le serveur de nom du domaine qu’ils cherchent à imiter. Chaque requête est envoyée sur un port différent.
Lorsqu’un attaquant envoie une requête sur le mauvais port, le serveur envoie une réponse indiquant que le port est inaccessible, ce qui permet de faire baisser la liste d’un élément. Lorsque l’attaquant envoie une requête sur le bon port, le serveur ne donnera aucune réponse, ce qui ne permet pas de modifier la liste.
Quand le serveur reçoit une requête comportant un port qu’il ne peut pas contacter, la limite ICMP baisse de 1. Si les mille numéros de port sont tous erronés, les chercheurs testent un nouveau lot, la limite étant tombée à 0. Mais si elle est de 1 après coup, c’est que parmi les 1 000 ports testés, l’un était bon. La procédure recommence avec des échantillons de plus en plus petits, jusqu’à mettre la main sur le port gagnant.
Le commentaire des chercheurs
« Nous essayons de déduire indirectement que le résolveur a envoyé un message ICMP inaccessible au serveur faisant autorité », a expliqué le professeur Zhiyun Qian de l’UC Riverside. « Comment le savons-nous ? Parce que le résolveur ne peut envoyer qu’un nombre fixe de tels messages ICMP en une seconde, ce qui signifie que l’attaquant peut également essayer de solliciter de tels paquets ICMP pour lui-même »
L’article des chercheurs, DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels, fournit une description beaucoup plus détaillée et technique de l’attaque. Ils appellent l’attaque SAD DNS l’abréviation de Side channel AttackeD DNS.
Les chercheurs ont confié en privé leurs résultats aux fournisseurs DNS et aux développeurs de logiciels. En réponse, les développeurs du noyau Linux ont introduit un changement qui fait que la limite de débit fluctue de manière aléatoire entre 500 et 2000 par seconde. Le professeur Qian a déclaré que le correctif empêche cette technique de fonctionner. Cloudflare a introduit son propre correctif. Dans certains cas, son service DNS reviendra à TCP, beaucoup plus difficile à usurper.
La recherche a été présentée lors de la conférence 2020 ACM sur la sécurité informatique et des communications, qui se tient cette année en vidéoconférence en raison de la pandémie COVID-19.
