Empoisonnement de cache DNS de Kaminsky à SAD DNS et parades

Empoisonnement de cache DNS de Kaminsky à SAD DNS et parades

Le DNS (Domain Name System) répond en UDP (User Datagram Protocol), sans connexion ni authentification : un résolveur accepte la première réponse qui ressemble à celle qu’il attend, puis la sert à tous ses clients pendant la durée du TTL (Time To Live). Empoisonner un cache, c’est gagner cette course à la ressemblance. La position défendue ici : les défenses par entropie (port source, casse, cookies) sont obligatoires et insuffisantes, et seule la validation DNSSEC (DNS Security Extensions) remplace le pari par une vérification.

Explication de la marmotte

Un standardiste de quartier note dans un carnet les numéros qu’on lui demande souvent, pour répondre plus vite la fois suivante. Si un escroc réussit à lui faire noter un faux numéro pour la banque, tout le quartier appelle l’escroc en croyant appeler la banque. Cette page parle de la protection du carnet.

→ Lire l’explication complète de la marmotte

Ce qu’un résolveur vérifie avant d’accepter une réponse DNS

Tout dépend de la position de l’attaquant. Sur le chemin (il voit passer la question), il lit toutes les valeurs à deviner et n’a plus qu’à répondre avant le serveur légitime : aucune des parades par entropie décrites plus bas ne le gêne. Ce cas est traité dans la page sur l’attaquant intercepteur. Hors chemin, il ne voit rien : il envoie des réponses à l’aveugle, en usurpant l’adresse IP (Internet Protocol) du serveur faisant autorité. C’est ce second cas qui a occupé la recherche depuis vingt-cinq ans, parce qu’il ne demande aucun accès privilégié au réseau.

Un résolveur récursif accepte une réponse UDP si elle passe quatre contrôles, et seulement ceux-là :

• l’adresse source est celle du serveur interrogé, et le port de destination est le port source de la question ;
• l’identifiant de transaction, un champ de 16 bits de l’en-tête, est celui de la question ;
• la section question est recopiée à l’identique (nom, type, classe) ;
• les enregistrements des sections autorité et additionnelle respectent la règle du bailliage : ils concernent la zone pour laquelle le serveur interrogé est légitime, pas le reste du monde.

La règle du bailliage date de la fin des années 1990, quand des résolveurs gobaient n’importe quel enregistrement additionnel sans rapport avec la question. Elle borne les dégâts d’une réponse acceptée ; elle n’empêche pas d’en forger une. Toute la sécurité repose donc sur la quantité de bits que l’attaquant doit deviner avant l’arrivée de la vraie réponse. Les bases (récursif, autoritaire, TTL) sont posées dans la page DNS, DHCP, NTP.

Identifiants de transaction prévisibles et attaque des anniversaires avant 2008

Seize bits, c’est 65 536 valeurs. À condition qu’elles soient imprévisibles, ce qui n’a pas toujours été le cas : les premières implémentations incrémentaient l’identifiant d’une question à la suivante. Il suffisait d’en observer un (en faisant résoudre un nom dont on contrôle le serveur) pour connaître le prochain. Les générateurs pseudo-aléatoires qui ont suivi n’ont pas tous mieux vieilli : en 2007 encore, celui de BIND 9 (Berkeley Internet Name Domain) était montré prédictible à partir de quelques identifiants observés.

Deuxième faiblesse, l’attaque des anniversaires. Un résolveur qui émet plusieurs questions simultanées pour le même nom offre autant de cibles valables. Avec n questions ouvertes et n réponses forgées, la probabilité de collision approche 1 - exp(-n²/65 536) : un peu plus de 200 de chaque pour dépasser une chance sur deux, 700 pour la quasi-certitude. La parade est connue depuis le début des années 2000 : ne jamais avoir deux questions identiques en vol, donc dédupliquer.

Restait un frein : le cache lui-même. Tant que la bonne réponse y dort, le résolveur ne repose pas la question, et l’attaquant qui rate sa course doit attendre l’expiration du TTL. Un TTL long passait alors pour une mesure de sécurité, ce qui en dit long sur l’état de l’art.

Exemple : la course de l’attaque de Kaminsky vue du résolveur

En 2008, Dan Kaminsky supprime ce frein avec deux idées (CVE-2008-1447 ; CVE pour Common Vulnerabilities and Exposures). La première : ne pas demander www.example.com, mais un sous-domaine aléatoire qui n’existe pas. Il n’est jamais en cache, donc chaque question déclenche une nouvelle course, immédiatement, autant de fois que nécessaire. La seconde : ne pas chercher à empoisonner ce nom sans intérêt, mais glisser dans la réponse forgée une délégation. La section autorité annonce un enregistrement NS (Name Server) pour example.com, la section additionnelle fournit l’adresse de ce serveur, celle de l’attaquant. Tout est dans le bailliage, puisque la question portait sur example.com : la règle est respectée à la lettre, et la zone entière change de mains.

Le schéma suit une itération de la course ; la ligne à regarder est la comparaison faite par le résolveur, seule barrière entre le paquet forgé et le cache.

Avec un port source fixe ou prévisible, ce qui était la norme, l’attaquant n’a que 16 bits à deviner et des essais illimités : l’empoisonnement aboutit en quelques secondes à quelques minutes selon le débit. Le TTL de l’entrée forgée est choisi par l’attaquant, qui n’a aucune raison d’être modeste.

Randomisation du port source, codage 0x20 et cookies DNS : l’entropie par couches

Le correctif coordonné de 2008, formalisé ensuite par la RFC 5452 (RFC pour Request for Comments), ne répare rien : il agrandit la botte de foin. Chaque couche ajoute des bits à deviner, sous condition.

Port source aléatoire. Tirer le port de chaque question dans la plage disponible porte l’espace à environ 2^32 combinaisons. La course passe de quelques secondes à une durée qui se compte en jours de rafale soutenue, donc visible. Le piège classique : un équipement de NAT (Network Address Translation) placé devant le résolveur qui réécrit les ports sources en séquence. Le résolveur randomise consciencieusement, le boîtier remet tout dans l’ordre, et l’entropie vue d’Internet retombe à 16 bits. La topologie montre où regarder : le port qui compte est celui qui sort côté Internet, pas celui que le résolveur a choisi.

Codage 0x20. Le DNS ignore la casse à la comparaison, mais les serveurs recopient la question telle quelle. Le résolveur écrit donc eXaMpLe.CoM avec une casse tirée au hasard et exige de la retrouver dans la réponse (0x20 est le bit qui sépare majuscule et minuscule en ASCII). Gain : un bit par lettre, soit une dizaine pour un nom courant, rien pour la racine ni pour les chiffres. La proposition de Paul Vixie et David Dagon date de 2008 et n’a jamais dépassé le stade du brouillon à l’IETF (Internet Engineering Task Force). Elle est pourtant déployée : Unbound la propose (use-caps-for-id), et des résolveurs publics de grande taille l’appliquent. Vingt ans de DNS apprennent que les mécanismes non normalisés sont parfois les mieux déployés, ce qui n’arrange personne et fonctionne quand même. Le coût : quelques serveurs faisant autorité qui normalisent la casse, d’où une liste d’exceptions ou un repli à prévoir.

Cookies DNS (RFC 7873). Le client joint à sa question un cookie de 64 bits, que le serveur renvoie ; un attaquant hors chemin ne le voit pas et ne peut pas le deviner. C’est la couche la plus généreuse en bits et la plus dépendante du voisin : face à un serveur qui ne gère pas l’option, il n’y a rien à vérifier, et le résolveur ne peut pas refuser de parler à la moitié d’Internet.

Le compromis central tient là. Ces trois couches se déploient unilatéralement, côté résolveur, sans rien coûter. En échange, elles restent probabilistes et conditionnelles : chacune tient tant que personne ne trouve un moyen de lire la valeur au lieu de la deviner. C’est précisément ce que la recherche a fait ensuite.

Variantes récentes : fragmentation IP, SAD DNS et MaginotDNS

Fragmentation IP (Herzberg et Shulman, 2013). Une réponse plus grosse que la MTU (Maximum Transmission Unit) du chemin part en plusieurs fragments. L’identifiant de transaction, les ports UDP et la section question sont tous dans le premier. Le second ne porte que la fin du message, typiquement les sections autorité et additionnelle. L’attaquant forge ce second fragment et l’envoie en avance ; il lui reste à deviner le champ d’identification IPv4 (16 bits, souvent prévisible) et à conserver une somme de contrôle UDP valide. Port aléatoire et 0x20 sont contournés d’un coup, puisqu’ils vivent dans le fragment légitime. Un faux message ICMP (Internet Control Message Protocol) « fragmentation nécessaire » permet même de forcer le serveur à fragmenter. Parade : ne plus fragmenter, donc un tampon EDNS (Extension Mechanisms for DNS) plafonné à 1232 octets et un repli sur TCP (Transmission Control Protocol) au-delà.

SAD DNS (Side-channel AttackeD DNS, 2020, CVE-2020-25705). Le port source n’est plus deviné, il est mesuré. Le noyau Linux plafonnait globalement l’émission des messages d’erreur ICMP, toutes destinations confondues. L’attaquant envoie une salve de sondes UDP usurpées vers 50 ports du résolveur : chaque port fermé consomme un message d’erreur du quota. Il sonde ensuite depuis sa propre adresse : s’il reçoit encore une erreur, le quota n’est pas épuisé, donc un des ports sondés était ouvert. Le port se retrouve par balayage, et le problème retombe de 2^32 à 2^16 + 2^16. Pour avoir le temps de balayer, la fenêtre est élargie en muselant le serveur faisant autorité, par exemple en déclenchant sa limitation de débit (voir la page sur le déni de service). Le noyau a été corrigé en rendant ce plafond aléatoire. Une suite publiée en 2021 par la même équipe a rouvert le canal par d’autres messages ICMP, dont le traitement modifie un état observable du noyau. La leçon dépasse le correctif : un port éphémère est un secret que la pile réseau n’a jamais été conçue pour garder.

MaginotDNS (2023). Ici, c’est le bailliage qui cède. La cible est le résolveur qui joue deux rôles à la fois : récursif pour le cas général, redirecteur conditionnel pour quelques zones envoyées vers un serveur amont. Plusieurs implémentations appliquaient en mode redirecteur un bailliage beaucoup plus lâche (le serveur amont étant réputé parler pour tout), tout en partageant le cache entre les deux modes. Une réponse forgée sur une question redirigée pouvait donc installer une délégation pour une zone sans rapport, jusqu’à un domaine de premier niveau entier. Les éditeurs concernés ont corrigé ; la règle d’architecture reste : un cache partagé entre deux niveaux de confiance vaut le plus faible des deux.

Ce que DNSSEC change pour l’empoisonnement de cache, et ce qu’il laisse intact

DNSSEC change la nature du problème : la réponse est signée par la zone, le résolveur validant vérifie la signature, et une réponse forgée sans la clé privée est rejetée, que l’attaquant soit hors chemin, sur le chemin ou très chanceux. L’empoisonnement dégénère en déni de service (le client reçoit SERVFAIL, le code d’échec du résolveur), ce qui se voit et ne détourne personne. Le fonctionnement (clés, signatures, chaîne de confiance) est décrit dans la page DNSSEC et chaîne de confiance.

Ce que DNSSEC ne garantit pas, et qui doit venir d’ailleurs :

• Les zones non signées, soit la majorité des domaines de second niveau. Pour elles, un résolveur validant se comporte exactement comme un résolveur de 2009 : seule l’entropie protège.
• Le résolveur non validant. Une zone signée interrogée par un résolveur qui ne vérifie rien n’a aucune protection ; les signatures voyagent pour le décor.
• Le dernier tronçon, du poste au résolveur. Le poste ne valide presque jamais lui-même ; il fait confiance au bit AD (Authenticated Data) de la réponse, transmis en clair. Ce tronçon se protège par un transport chiffré et authentifié, DoT (DNS over TLS) ou DoH (DNS over HTTPS) : voir DNS et TLS et DNSSEC, DoH, ODoH et visibilité.
• Les délégations elles-mêmes. Les NS et adresses de colle dans la zone parente ne sont pas signés (seul l’enregistrement DS (Delegation Signer) l’est). Un attaquant peut encore rediriger les questions vers son serveur ; il ne pourra pas y produire de réponse valide, mais il verra les questions et pourra faire échouer la résolution.

Le prix de DNSSEC se paie en exploitation : une rotation de clé ratée ou une signature expirée ne dégrade pas la zone, elle la fait disparaître pour tous les résolveurs validants. C’est un coût réel côté zone. Côté résolveur, valider est unilatéral et gratuit. D’où la recommandation, sans nuance : validation activée sur tout résolveur, toutes les couches d’entropie en plus (pour les zones non signées), et signature des zones dont le détournement coûterait cher, à condition d’avoir une rotation automatisée et supervisée. Sans cette condition, signer revient à programmer sa propre panne.

L’arbre résume quelle parade arrête quelle variante ; à lire de gauche à droite, une ligne par scénario.

Détournement par BGP ou par compte de bureau d’enregistrement : un cas distinct

Deux attaques produisent le même symptôme (le nom mène ailleurs) sans toucher au cache. Le détournement de préfixe par BGP (Border Gateway Protocol) attire vers l’attaquant le trafic destiné aux serveurs faisant autorité : le résolveur interroge la bonne adresse, et c’est le mauvais serveur qui répond. La compromission du compte chez le bureau d’enregistrement modifie la délégation à la source, dans la zone parente. Dans les deux cas il n’y a aucune course, aucune réponse forgée au sens de cette page, et aucune des parades par entropie ne s’applique. DNSSEC arrête le premier si la zone est signée et le résolveur validant (l’attaquant n’a pas la clé de la zone), pas le second si le compte permet aussi de remplacer le DS. Les parades sont ailleurs : validation d’origine des routes par RPKI (Resource Public Key Infrastructure), authentification multifacteur et verrou de registre sur le domaine.

Exploitation d’un résolveur durci : prérequis, vérification et supervision

Prérequis côté plateforme : un résolveur maintenu (les correctifs de 2008, de MaginotDNS et les défauts de générateur aléatoire se règlent par la version, pas par la configuration), un noyau postérieur aux correctifs des canaux auxiliaires ICMP, une ancre de confiance de la racine tenue à jour automatiquement, et une horloge fiable (une signature se valide dans une fenêtre de temps). Côté réseau : aucun NAT séquentiel entre le résolveur et Internet, TCP 53 ouvert en sortie (sans lui, le plafond à 1232 octets transforme les grosses réponses en pannes), et un résolveur qui ne répond qu’à ses clients, puisque l’attaque commence toujours par lui faire poser une question.

Le bloc suivant vérifie l’essentiel sur un Unbound ; l’adresse du résolveur et le nom de l’interface sont à remplacer.

# Réglages attendus dans unbound.conf (section server:)
#   use-caps-for-id: yes            # codage 0x20
#   edns-buffer-size: 1232          # pas de fragmentation des réponses
#   harden-glue: yes                # bailliage strict sur la colle
#   harden-dnssec-stripped: yes     # refuse une zone signée sans signatures
#   unwanted-reply-threshold: 10000000   # purge du cache si rafale de réponses non sollicitées
unbound-checkconf

# Validation effective : le drapeau "ad" doit figurer dans la ligne flags
dig @192.0.2.53 ietf.org A +dnssec | grep flags

# Entropie réellement visible : capture APRÈS le NAT, côté Internet.
# Les ports sources doivent être dispersés, les noms en casse mélangée.
tcpdump -ni eth0 -c 50 'udp and dst port 53'

Supervision : le signal propre à cette attaque est la réponse qui ne correspond à aucune question en cours. Unbound l’expose (unwanted.replies dans unbound-control stats) ; une hausse brutale est une rafale de devinettes, pas du bruit de fond. Surveiller aussi le taux de SERVFAIL (échecs de validation : attaque ou zone cassée, à distinguer), la part de questions rejouées en TCP, et les échecs de comparaison de casse. Ces compteurs méritent une règle dans la chaîne de détection, avec les réserves habituelles sur la fatigue d’alerte.

Reprise : un cache empoisonné ne se répare pas, il se purge (unbound-control flush_zone pour une zone, redémarrage pour tout). Il n’y a rien à sauvegarder dans un cache ; ce qui se sauvegarde, c’est la configuration et l’ancre de confiance. Les journaux de requêtes, s’ils existent, sont la seule source pour dater l’entrée forgée lors d’une reconstruction de chronologie. Côté secrets, le résolveur n’en détient aucun de durable ; les clés de signature vivent côté zone, et leur rotation relève de la page DNSSEC.

FAQ

Un TTL court sur les enregistrements réduit-il le risque ?

Non, et c’est l’apport de Kaminsky : les sous-domaines aléatoires donnent une course par question, sans attendre aucune expiration. Le TTL de l’entrée empoisonnée est fixé par la réponse forgée, pas par la zone légitime. Un TTL court augmente même le nombre de questions émises, donc d’occasions.

DoH ou DoT entre le poste et le résolveur protègent-ils du cache empoisonné ?

Ils protègent ce tronçon, pas le cache. Si le résolveur a été empoisonné en amont, le poste reçoit la fausse réponse par un canal parfaitement chiffré. Le tronçon entre résolveur et serveurs faisant autorité reste très majoritairement en UDP clair.

Passer toutes les requêtes du résolveur en TCP règle-t-il le problème hors chemin ?

En grande partie : forger un segment dans une connexion TCP suppose de deviner des numéros de séquence, et il n’y a plus de fragment à remplacer. Le coût en latence et en charge sur les serveurs faisant autorité rend ce choix réaliste comme repli (réponses tronquées, zones sensibles), pas comme régime général.

🐝 Ce qui arrive si on s’en passe

Un résolveur laissé avec un port source figé, sans mélange de casse ni validation, accepte une délégation forgée après une brève rafale, et rien dans ses journaux ne distingue l’entrée empoisonnée d’une entrée légitime : la réponse a passé tous les contrôles prévus. La durée de vie de l’entrée étant choisie par l’attaquant, la reprise ne vient pas d’elle-même ; il faut purger, et savoir quoi purger. Entre-temps, le courrier du domaine visé part vers le serveur désigné par l’attaquant, et les contrôles de possession de domaine exigés par une autorité de certification peuvent être satisfaits par lui. La reconstruction bute ensuite sur un fait gênant : les postes n’ont rien fait d’anormal, ils ont demandé un nom et reçu une réponse.

🦫 Explication de la marmotte 🍫

Pour joindre un site, un ordinateur demande l’adresse numérique qui correspond au nom du site à un serveur appelé résolveur. Le résolveur interroge les serveurs qui détiennent l’information officielle, puis garde la réponse en mémoire un certain temps pour la resservir à tous. Ces messages circulent sans signature : le résolveur accepte le premier qui porte le bon numéro de question, le bon numéro de port (un nombre qui identifie la conversation) et qui répète la question posée. Un attaquant placé ailleurs sur Internet peut donc envoyer des milliers de fausses réponses en devinant ces valeurs. En 2008, un chercheur a montré comment recommencer la tentative à volonté et prendre la main sur un nom de domaine entier. Les parades rendent la devinette plus dure : port tiré au hasard, majuscules et minuscules mélangées dans la question, jeton secret entre les deux serveurs. D’autres chercheurs ont ensuite contourné ces parades, notamment en retrouvant le port grâce aux messages d’erreur de la machine. La seule protection qui ne dépend pas de la chance est la signature numérique des réponses : le résolveur la vérifie et jette ce qui est faux. Elle ne fonctionne que si le propriétaire du nom signe et si le résolveur vérifie. Sinon, la fausse adresse reste en mémoire et tous les utilisateurs sont envoyés chez l’attaquant.

À lire aussi

• Le DNS, le protocole qu'on ne regarde jamaisChaque connexion commence par une question posée en clair à un résolveur que l'on n'a, le plus souvent, pas choisi. DNSSEC, DoT et DoH corrigent chacun une partie du problème, et aucun ne dispense de la vraie décision : à qui confier la liste de tout ce qu'on consulte.
• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.
• GRE, IPsec ou GRE dans IPsec pour un tunnel site à siteChoisir entre GRE, IPsec et GRE dans IPsec pour relier deux sites, selon le chiffrement, le routage dynamique, le multicast et le coût en MTU.
• UDP, TCP et comportements de transportComprendre les transports classiques, leurs états, timeouts, performance et risques de sécurité.

Pages voisines

La citent

• Normaliser les logs avec OCSF, ECS ou CIM
• Chiffrer les flux est-ouest dans un data center
• Le DNS, le protocole qu'on ne regarde jamais

Empoisonnement de cache DNS de Kaminsky à SAD DNS et parades

Elle cite

• ⇄Lien dans les deux sens :Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS
• ⇄Lien dans les deux sens :DNS over TLS (DoT) : chiffrer la résolution de noms
• ⇄Lien dans les deux sens :DNS, DHCP, NTP : services d'infrastructure réseau
• ⇄Lien dans les deux sens :DNSSEC : chaîne de confiance, validation et exploitation des clés
• Défendre un DDoS volumétrique et applicatif
• Reconstruire une timeline d'attaque après incident
• Réduire la fatigue d’alerte dans un SOC
• BGP, la confiance par défaut
• DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense

⇄ : les deux pages se citent l’une l’autre.