Le retour d'Alain Thivillon sur la vulnérabilité DNS annoncée par Dan Kaminsky tombe à point, alors que tout (et parfois aussi son contraire) a été écrit sur le sujet. Kaminsky, lui, n'a pas encore présenté officiellement sa découverte, mais des exploits circulent déjà.

Chez HSC, on a reproduit l'attaque et on l'a étudié sous toutes les coutures. Mais avant d'entrer dans le détail technique, Alain Thivillon a la bonne idée de rappeler l'objectif de l'attaquant : prévoir les numéros d'identifiants des questions (TXID) qui circulent. Jusqu'à présent, on pouvait y parvenir de différentes manières :

- Profiter d'une faille d'un serveur DNS qui choisirai mal ses numéros d'identifiants. C'est alors le problème du serveur (comme cela a été le cas avec Bind à plusieurs reprises)

- Museler le serveur DNS victime de l'attaque (par un déni de service par exemple) afin de prendre sa place.

- Exploiter un bug grossier dans certains serveurs (Windows en 2000) qui leur fait répondre à des questions qu'ils n'ont pas posés.

- Sniffer le réseau.

Alain Thivillon explique que la nouveauté dans l'approche de Dan Kaminsky est de faire abstraction de tout ces pré-requis pour lui préférer une approche statistique plus générique : puisque l'objectif est de découvrir à l'avance des numéros censés être inconnus, on va générer pour chaque question posée au serveur de multiples réponses avec des identifiants différents. Vraiment beaucoup. Et avec le temps, on ne peut que tomber sur les bons.

-- Statistiquement, en ne pouvant "glisser" dans l'intervalle avant la réponse du serveur que 20 fausses réponses, cela fait 0.03% chances de succès. Mais si on réessaye 1000 fois, on est déjà à 30%... ---, écrit le consultant.

Dit comme ça, l'attaque n'est qu'un vulgaire assaut de force brute et n'aurait que peu de chance de réussir considérant la faiblesse de l'intervalle laissé pour manipuler les requêtes.

Et c'est précisément là que réside le secret de Dan Kaminsky et toute la beauté de sa découverte : il modifie la partie "Auhority" d'une fausse réponse afin de la faire pointer vers un serveur DNS qu'il contrôle et qui sera en mesure de faire ses manipulations au passage. Selon le RFC ad-hoc le serveur victime doit en effet conserver cette information et la servir pendant 100 heures à toutes les requêtes. Largement de quoi générer *naturellement* un nombre important de requêtes sur un serveur très sollicité, en laissant faire pour cela ses utilisateurs légitimes. C'est de l'attaque collaborative 2.0, en quelque sorte...

Reste à pouvoir empoisonner un serveur DNS auquel on n'a pas accès. Les exploits actuels, qu'Alain Thivillon qualifie de "médiocres", ne peuvent en effet fonctionner qu'avec des DNS "ouverts" qui acceptent que n'importe qui (et donc le pirate) puisse leur soumettre un grand nombre de requêtes.

Ceux-ci sont cependant plus rares car depuis longtemps vulnérables à toutes sorte d'attaques. Bien souvent les serveurs DNS accessibles publiquement sont soit bien configurés (chez les FAI), soit ils ne sont pas visibles depuis Internet (chez les entreprises).

La beauté de l'attaque de Dan Kaminsky est qu'elle exploitable aussi contre les DNS bien configurés, que le pirate ne peut a priori pas requêter directement. Il suffit pour cela de faire faire de nombreuses requêtes à un client autorisé (client du FAI ou collaborateur de l'entreprise, serveur web) vers un serveur DNS contrôlé par le pirate. Celui-ci va recevoir les requêtes du client légitime et les renvoyer grâce à un alias CNAME vers le domaine à usurper. Cela permet de "traverser la frontière des domaines", note Alain Thivillon.

Pour mener une telle attaque, le consultant de HSC note la possibilité d'envoyer un email qui contiendrait plusieurs centaines de liens "images" vers le serveur du pirate (donc une requête par image à récupérer) ou même de soumettre un email à un serveur SMTP avec, en copie, de nombreuses adresses appartenant au domaine contrôlé par le pirate, et laisser le serveur SMTP se charger des requêtes.

Du côté des risques encourus par les utilisateurs d'un résolveur DNS ainsi piraté, Alain Thivillon revient bien entendu sur le risque de phishing, mais signale une attaque plus sournoise encore : en usurpant l'adresse des serveurs de mise à jour de logiciels dont les updates ne sont pas signées (une terrible erreur), il est possible de faire installer n'importe quoi à n'importe qui. Et on trouve parmi les mauvais élèves de la sécurité, qui ne signent pas leurs mises à jour, Sun pour sa JVM ou encore Apple pour les mises à jour de iTunes et même... d'OS X !

Le rapport complet chez HSC
http://www.hsc-news.com/archives/2008/000047.html