Résumé

  • L’attaque dite de Kaminsky provoquait des requêtes nouvelles sous un même domaine et renouvelait ainsi une course hors chemin : une réponse forgée devait deviner les paramètres de la requête avant l’arrivée du serveur légitime.
  • Les correctifs coordonnés de 2008 n’ont pas authentifié les données DNS. Ils ont ajouté au contrôle local un port source imprévisible, dont l’entropie devait encore survivre au pare-feu et au NAT et être constatée sur le réseau réel.

Croire le premier paquet conforme

Un résolveur récursif interrogeait le plus souvent un serveur faisant autorité par UDP, sans signature attachée à la réponse ordinaire. Il ne tranchait donc pas entre deux récits du monde. Il vérifiait qu’un paquet ressemblait suffisamment à la réponse d’une question qu’il avait effectivement posée.

RFC 5452 a ensuite formulé ce filtre. La section question devait correspondre à une requête en attente, l’identifiant de transaction devait être le bon, l’adresse source devait être celle du serveur interrogé et le paquet devait revenir à l’adresse et au port utilisés au départ. En règle générale, la première réponse qui satisfaisait ces conditions était acceptée.

Un adversaire hors chemin ne voyait pas la requête, mais pouvait usurper l’adresse du serveur faisant autorité et envoyer une rafale de candidats. Il lui suffisait qu’un paquet devine le bon ensemble de valeurs et arrive le premier. Le cache redistribuait ensuite le mensonge à ses propres clients.

Cette autorité était réelle mais bornée. L’attaquant influençait un cache, pendant la durée et pour les noms admis par les enregistrements forgés. Il ne prenait pas possession de tout le DNS. Cette précision permet de distinguer les leviers : qui peut demander la récursion, quels paquets correspondent, quelles données sont pertinentes, combien d’incertitude protège la course et quelles données possèdent une preuve cryptographique.

Une tentative ratée n’obligeait plus à attendre

L’empoisonnement de cache était ancien. RFC 3833 décrivait déjà en 2004 la prédiction des identifiants et les chaînes de noms. Le champ d’identification ne contient que 16 bits ; des générateurs faibles ou prévisibles réduisaient parfois encore cet espace. Un port UDP fixe n’ajoutait aucune inconnue.

La découverte de Dan Kaminsky a surtout rendu l’assemblage exploitable. L’attaquant faisait demander un libellé inédit, par exemple un sous-domaine aléatoire placé sous la cible. Puisque ce nom n’était pas dans le cache, le résolveur lançait une nouvelle requête. Les fausses réponses entraient aussitôt en compétition avec la réponse authentique. Après un échec, un autre libellé ouvrait une nouvelle fenêtre.

Le sous-domaine jetable n’était pas nécessairement l’objectif. Une réponse fabriquée pouvait chercher à installer une délégation concernant le domaine parent, dans les limites des règles de pertinence et de bailiwick du résolveur. L’attaquant n’attendait donc pas l’expiration d’un enregistrement intéressant : il fabriquait une absence de cache.

RFC 5452 explique que, pour certaines variantes répétitives, la durée de vie effective devient presque nulle. Dans son modèle à 7 000 paquets forgés par seconde et un seul port, la probabilité atteint 50 % en environ sept secondes. Ce chiffre n’est ni une mesure universelle ni une promesse d’exploitation. Il révèle seulement pourquoi une petite probabilité devient dangereuse lorsque l’expérience peut être répétée à faible coût.

Un port transformé en identifiant supplémentaire

Les correctifs ont agrandi ce que le faux paquet devait deviner. Les résolveurs corrigés ont combiné un identifiant de transaction imprévisible avec un port source choisi pour chaque requête, au lieu de réutiliser un port stable. Le port est devenu un second cadran local.

Selon RFC 5452, quelque 64 000 ports utilisables multipliaient d’autant l’espace de recherche. Dans le même exemple répétitif à 7 000 paquets par seconde, le seuil de 50 % passait d’environ sept secondes à près de 116 heures. CERT/CC parlait d’environ 16 bits supplémentaires en théorie, tout en rappelant que les ports réservés ou occupés réduisent la population réelle.

Cette défense avait une vertu décisive : elle ne modifiait pas le format DNS. Un serveur faisant autorité pouvait répondre au nouveau port sans adopter un protocole inédit. Les éditeurs pouvaient livrer du code et les opérateurs le déployer sans attendre une migration mondiale.

Le coût n’était toutefois pas nul. ISC signalait un impact sensible de son premier correctif BIND au-delà d’environ 10 000 requêtes par seconde et publiait des branches bêta optimisées. Des règles de pare-feu n’autorisant que le port source 53 devaient changer. Des équipements à état pouvaient consommer davantage de traductions.

Le correctif n’a donc pas supprimé l’ingénierie : il a échangé une course trop prévisible contre une gestion plus exigeante des sockets et de l’état. Ce compromis était local, mesurable et réversible.

Le NAT pouvait rendre le paquet prévisible à nouveau

Une machine pouvait porter une version corrigée alors que les paquets visibles sur Internet continuaient d’employer une petite suite de ports. Les équipements NAT/PAT réécrivent parfois les ports source. CERT/CC prévenait qu’ils pouvaient réduire, voire annuler, le bénéfice ; RFC 5452 visait notamment les dispositifs qui sérialisent ou limitent fortement les ports.

Il ne s’ensuit pas que tout NAT affaiblit le DNS. Selon sa politique, il peut conserver, réduire ou même accroître la variation apparente. La bonne unité d’audit est le chemin complet. L’attaquant doit deviner la valeur qui sort réellement du traducteur, non celle choisie avant lui par le processus.

DNS-OARC a rendu cette frontière observable grâce à des tests de ports et d’identifiants. Un serveur contrôlé décrivait les valeurs reçues depuis le résolveur. L’opérateur pouvait ainsi examiner la distribution effective au lieu de faire confiance à l’étiquette d’un paquet logiciel.

La primauté du code en fonctionnement prend ici un sens matériel. Le bulletin décrit une intention, l’inventaire confirme une installation, mais seul le trafic montre si le correctif a survécu au système qui l’entoure.

La coordination n’a pas créé une autorité centrale

DNS-OARC situe un sommet privé chez Microsoft au 31 mars 2008. Le 8 juillet, CERT/CC publia VU#800113 tandis que de nombreux fournisseurs livraient leurs mises à jour. ISC corrigea BIND ; Microsoft renforça les identifiants, les sockets UDP et la logique de cache ; chaque fournisseur resta responsable de son implémentation.

Le secret n’a pas tenu jusqu’à l’exposé prévu. La chronologie de DNS-OARC place la fuite effective au 21 juillet, un code d’exploitation fonctionnel au 23 et d’autres réalisations au 24. Le 25 juillet, Microsoft déclara que le danger avait augmenté avec le code public. L’entreprise disait ne connaître alors ni attaque active ni impact client et constatait que l’exploit testé échouait sur les systèmes équipés de MS08-037.

Ces faits ne se fusionnent pas. L’apparition du code a accru la capacité disponible ; l’absence d’incident connu chez un fournisseur n’a pas prouvé l’absence mondiale d’usage. Le succès d’un correctif contre un exploit publié n’a pas certifié tous les résolveurs, pare-feu et traducteurs.

Kaminsky présenta le mécanisme à Black Hat le 7 août. RFC 5452 fut publié en janvier 2009. Le code déployé avait donc apporté une défense compatible avant que le document Standards Track ne consolide les règles. La norme a rendu la leçon partageable ; elle n’a pas installé les correctifs de juillet.

Rendre le mensonge coûteux n’est pas prouver la vérité

L’aléa du port diminuait la chance qu’un paquet forgé hors chemin franchisse le filtre. Il ne démontrait pas que les données non signées venaient du détenteur de la zone. Un état divulgué, une traduction appauvrie, suffisamment d’essais ou une position sur le chemin changeaient la situation.

ISC présentait donc DNSSEC comme la solution définitive, tout en reconnaissant qu’un déploiement immédiat n’était pas réaliste. Un résolveur validant peut vérifier l’origine et l’intégrité par signatures et chaîne de confiance. C’est une propriété différente d’une loterie rendue plus difficile.

Les couches se complètent. Un résolveur signé gagne encore à écarter rapidement les paquets qui ne correspondent pas. L’entropie protège la porte du transport ; DNSSEC vérifie l’autorité des données. Aucun de ces deux contrôles ne doit revendiquer la fonction de l’autre.

La Spécification initiale minimale de Heng Lu permet de tracer la limite commune : exiger la correspondance exacte de la réponse et l’imprévisibilité nécessaire, sans imposer l’allocateur de sockets d’un fournisseur. Le choix du générateur, le repli TCP, le calendrier de livraison et la surveillance restent locaux. L’adoption volontaire ne transforme pas le refus en délit ; elle permet aux clients de refuser, eux aussi, de dépendre d’un résolveur dont le comportement observé est insuffisant.

Limites de la preuve

Les sources établissent une exposition multivendeur et une attaque devenue beaucoup plus pratique. Elles n’établissent pas un défaut identique partout, un déploiement universel le 8 juillet, ni une durée d’attaque valable pour tout réseau. Les ports aléatoires ont fortement durci l’attaque hors chemin selon des hypothèses explicites ; ils n’ont pas éliminé tout empoisonnement. DNSSEC apportait une preuve d’origine, mais sa publication ne prouvait pas sa validation dans les résolveurs réels.

La conclusion utile est plus précise : une partie de la confiance DNS reposait sur une petite course dont de nombreux systèmes réduisaient involontairement l’incertitude. La réparation a agrandi cette incertitude, l’a rendue mesurable et a laissé l’authentification cryptographique comme chantier distinct.

Sources