Cache poisoning : à nouveau possible via SAD DNS

SAD DNS revitalise l'attaque Kaminsky de 2008, où des attaquants  avaient empoisonné des caches DNS avec de fausses informations.  Le remède conçu à l'époque ne fonctionne plus : en effet, aujourd’hui, il est possible d'utiliser une méthode intelligente pour tracer le port UDP sortant du DNS resolver. Comment fonctionne SAD DNS et comment le contrer ?

DNS Cache poisoning: une histoire ancienne

Pour rappel, et comme décrit dans Cloudflare, le système et le protocole DNS garantissent une association en langage naturel entre les noms de domaine et les adresses IP correspondantes. Le protocole DNS se compose à chaque fois d'un ensemble de messages : une question (query) et une réponse (reply). Ces messages sont échangés entre machines via un réseau au moyen d'un protocole de transport. 

Le protocole de transport le plus couramment utilisé de DNS est UDP. L'UDP a le grand avantage d'être rapide et omniprésent et de ne nécessiter aucune configuration de session. Mais sans DNSSEC , il n'y a pas d'authentification.  Ce qui signifie que n'importe qui pourrait envoyer une réponse à une demande contenant de fausses informations sur l' adresse IP correspondante. Cela ne serait pas possible avec d'autres protocoles de transport DNS tels que TCP, ou même TLS ou HTTPS .

Pour éviter de devoir rechercher l'adresse correspondante dans les tables DNS à chaque nouvelle requête, les résultats des requêtes DNS sont temporairement stockés dans la mémoire cache des serveurs de noms. Si un serveur DNS de mise en cache conserve une telle fausse réponse dans sa mémoire cache, on parle d'"empoisonnement de la mémoire cache du DNS" (DNS cache poisoning): cette fausse information reste dans la mémoire cache tant que dure le TTL (Time To Live).

Ce phénomène peut conduire à de nombreux abus. Les visiteurs qui saisissent un nom de domaine dans leur navigateur par exemple peuvent être détournés vers une fausse version du site web qu'ils souhaitent visiter...  où ils peuvent alors être victimes de fraude, etc.

Ces attaques sont dirigées contre différents types de serveurs dans la hiérarchie DNS qui utilisent la mise en cache du DNS (DNS caching ) – donc, tant  au niveau des DNS resolvers publics, des fournisseurs d'accès Internet et des opérateurs télécoms, des entreprises exploitant leur propre resolver qu’au niveau de la passerelle domestique, la mémoire cache des particuliers. À tous ces niveaux, il existe un risque d'injection de faux records détournant l'utilisateur vers des sites web non sécurisés.

L’attaque Kaminsky en 2008 vite résolue

Le système DNS dispose en fait d'une tactique de protection contre la falsification des réponses : les deux premiers octets du message doivent être identiques dans la requête et dans la réponse. Lorsqu'en 2008 une méthode a été trouvée pour deviner ces identifiants, méthode qui a reçu le nom d'attaque Kaminsky, une solution a été trouvée: la randomisation du port source (source port randomization)... En utilisant un port source aléatoire, l'attaquant devait non seulement deviner les identifiants, mais aussi ce port source. Le nombre de tentatives nécessaires pour réussir une attaque est ainsi passé de quelques dizaines de milliers à plus d'un milliard. En conséquence, cette attaque est devenue moins intéressante, et cette méthode n'a plus été utilisée ces dernières années.

SAD DNS donne un nouveau souffle au cache poisoning

Récemment, des chercheurs de l'université de Riverside et de Tsinghua ont découvert une nouvelle méthode d'attaque le SAD DNS ou Side Channel AttackeD DNS. Cette méthode abuse de la limitation du débit ICMP (ICMP rate limiting), un moyen d'empêcher qu'un serveur soit abusé lors d'une attaque reflection, en limitant le nombre de réponses ICMP qu'un serveur donnera dans un certain laps de temps. 

SIDN.nl explique clairement comment le principe fonctionne. Supposons que la limite soit fixée à un maximum de 1 000 messages par seconde ; dans ce cas l'attaquant peut scanner les 65 000 ports UDP par blocs de mille, et voir dans quel bloc se trouve le port sortant du DNS resolver. Pour ce faire, il envoie d'abord 1 000 fausses réponses DNS à partir d'une fausse adresse à tous les ports de ce bloc. Il ne verra pas les messages d'erreur de l'ICMP, car ils sont dirigés vers cette fausse adresse. Mais s'il envoie ensuite un 1.001è message dans la même seconde, cette fois-ci à partir de sa propre adresse IP réelle, et qu'il reçoit toujours une réponse ICMP en retour, alors il sait que le port correct se trouve dans cette fourchette de mille ports. Car le fait qu'il ait reçu un message en retour signifie que la limite de mille messages d'erreur n'a pas été atteinte, et que le port correct se situe dans cette fourchette de mille ports.

Cela annule la protection par randomisation des ports contre une attaque Kaminsky, car l'attaquant n'a désormais plus qu'à essayer de récupérer les 65 000 ID de transaction.

Quelle mesure devez-vous prendre? 

Les responsables du noyau linux ont publié un patch qui résout le problème des limites de taux (rate limits) en les rendant aléatoires. 

Mais il ne s'agit là que d'une solution ponctuelle. Une manière plus structurelle d'éviter le cache poisoning est d'utiliser DNSSEC. Car un résolveur non sécurisé accepte les informations à condition qu'elles soient présentées au bon moment, par le bon port et avec le bon identifiant de transaction par le bon expéditeur. Mais elles peuvent être devinées ou usurpées, comme le nom de l'expéditeur. 

Cependant, un résolveur travaillant avec DNSSEC (un résolveur de validation) n'acceptera pas ces informations falsifiées, car il se basera également sur la signature numérique correcte.

Voici quelques recommandations aux administrateurs de cache DNS tels que les opérateurs télécoms, les ISP (home nat gateways), les administrateurs de réseaux d'entreprise :

• Appliquez le kernel patch dès que possible (version du noyau > 5.10)
• Si vous ne pouvez pas passer au tout dernier noyau, alors en bloquant les messages ICMP sortants (type ICMP port-unreachable), vous pouvez également empêcher l'attaque SAD DNS.
• Si vous utilisez un caching resolver derrière un dispositif NAT (Network Address Translation) tel que des routeurs, envisagez de corriger ces dispositifs NAT (ou de mettre en œuvre une solution de contournement susmentionnée). L'attaque pourra toujours être menée par le biais de ces dispositifs également comme l’ont constaté nos propres ingénieurs de DNS Belgium et comme l’ont confirmé des recherches. Il est important de savoir que ce vecteur d'attaque fonctionne via le dispositif NAT, même si le caching DNS resolver a été patché (ou si une solution de contournement a été configurée).
• Soulignez l'importance de DNSSEC pour vos clients. En savoir plus sur DNSSEC et sur la façon dont DNS Belgium met en œuvre cette sécurité supplémentaire.

Remarque : Dans certains logiciels resolver, il existe déjà un mécanisme de détection supplémentaire du cache poisoning : cela permet à la communication DNS de se rabattre sur le protocole de transport, TCP. Cela rend également impossible l'attaque SAD DNS.  

Recommandations pour les détenteurs de noms de domaine et les internautes en général :

• Demandez à votre ISF ou à votre agent d'activer DNSSEC. C'est la solution ultime pour garantir l'intégrité d’un look-up record et empêcher que les visiteurs de votre site web ne soient redirigés. Toutefois, vos visiteurs doivent toujours utiliser un résolveur de validation DNSSEC pour bénéficier efficacement de la protection offerte par DNSSEC. 
• La plupart des fournisseurs autorisent DNSSEC pour les noms de domaine, et il suffit de l'activer.