Usurpation DNS et empoisonnement de cache : vue d'ensemble

Le DNS a été conçu à l'origine sans aucun moyen de vérifier qu'une réponse provient bien du serveur de noms dont elle prétend émaner. Cette lacune rend possible l'usurpation : un attaquant en position d'intercepter une requête DNS, ou de la devancer, peut renvoyer une réponse falsifiée qui oriente la victime vers l'adresse de son choix, souvent pour rediriger le trafic vers un serveur malveillant qui se fait passer pour un site légitime.

Empoisonnement de cache : la même idée, à grande échelle

L'empoisonnement de cache reprend la même idée de réponse falsifiée, mais vise un résolveur partagé plutôt qu'une seule victime. Si un attaquant parvient à glisser une réponse forgée dans le cache d'un résolveur récursif très utilisé, chaque utilisateur suivant de ce résolveur reçoit la réponse empoisonnée jusqu'à son expiration : une seule falsification réussie devient ainsi une attaque contre tous ceux qui partagent ce résolveur, sans qu'il soit nécessaire d'intercepter chacune de leurs requêtes.

Comment le DNS moderne s'en défend

Aucune de ces défenses n'est déployée partout : l'adoption de DNSSEC en particulier reste partielle parmi les domaines qui composent l'internet. Utiliser un résolveur public bien exploité et soucieux de sécurité, et considérer qu'un résultat de résolution inattendu ou suspect mérite d'être revérifié auprès d'un second résolveur indépendant, reste une précaution pratique raisonnable, même là où DNSSEC n'est pas en jeu.

La faille qui a changé le sérieux accordé au sujet

L'empoisonnement de cache a cessé d'être une préoccupation théorique en 2008, lorsque le chercheur en sécurité Dan Kaminsky a divulgué une faille fondamentale touchant presque tous les résolveurs DNS alors en service : l'espace des identifiants de transaction et des ports sources qu'un attaquant devait deviner était assez petit pour être exploré par force brute en quelques secondes sur une connexion rapide, ce qui lui permettait d'empoisonner le cache d'un résolveur pour tout un domaine, et pas seulement pour un enregistrement. Cette divulgation a conduit à une publication de correctifs inhabituellement coordonnée et simultanée chez tous les grands éditeurs de logiciels DNS : la randomisation du port source est devenue la norme presque du jour au lendemain, et c'est en grande partie la raison pour laquelle les défenses citées plus haut existent sous leur forme actuelle.

Pourquoi l'adoption de DNSSEC traîne alors que le correctif date de vingt ans

DNSSEC résout le problème de confiance sous-jacent bien plus complètement que la seule randomisation des ports : c'est une preuve cryptographique, pas simplement un jeu de devinettes plus difficile. Son déploiement lent tient davantage à sa complexité opérationnelle qu'à un doute sur son intérêt : signer correctement une zone, faire tourner les clés dans les délais sans casser la validation et maintenir intacte toute la chaîne de confiance depuis la racine jusqu'à un domaine donné est nettement plus difficile à réussir que d'ajouter un enregistrement A non signé. Une seule erreur dans ce processus produit exactement le mode de défaillance SERVFAIL traité ailleurs dans cette série, ce qui constitue en soi un frein pour les petits exploitants de domaines qui n'ont pas d'expertise DNS dédiée en interne. L'écart entre « résolu en théorie » et « déployé partout en pratique » est courant dans l'infrastructure de sécurité, et DNSSEC en est un exemple frappant.