Internet : la faille de l'été n'est pas colmatée
En juillet, la vulnérabilité du protocole DNS a défrayé la chronique. Un remède concocté par les éditeurs reporte l'échéance d'une migration des serveurs DNS vers une version où tout échange est chiffré.
01net.
le 25/09/08 à 00h00
Crainte justifiée ? Brassage médiatique ? Internet a-t-il vraiment failli perdre son identité ? Ces derniers mois, l'apparition d'une faille dans les serveurs DNS (Domain Name System, les annuaires d'internet) autorisait théoriquement les pirates à détourner les noms de domaine. Le danger ? Déclencher une sorte de superphishing, où la victime se rend d'autant moins compte qu'elle est redirigée vers le faux site de sa banque et que l'adresse qu'elle a saisie dans son navigateur est la bonne et reste inchangée. Et s'il prend possession de l'entièreté du domaine cible, le pirate contrôle tout ce qui a trait à la résolution de nom, au niveau du site web comme des serveurs de messagerie. ' Il peut ensuite s'arranger pour positionner un TTL (Time To Live) très long dans ses réponses empoisonnées pour faire en sorte que la victime maintienne la donnée erronée en cache le plus longtemps possible ', précise Bernard Ourghanlian, directeur technologie et sécurité chez Microsoft France. En cause, les serveurs DNS qui s'interrogent régulièrement pour mettre à jour leur copie de l'annuaire mondial, mais ne vérifient pas suffisamment qui leur répond. Sous réserve que sa réponse arrive la première, un pirate peut ainsi tromper un DNS. Si toutefois il répond avec le même numéro d'identifiant que celui, généré aléatoirement sur 16 bits, émis lors de la requête du DNS. Et sous réserve qu'il réponde aux éventuelles requêtes sur le même nom de domaine situées dans la file d'attente du DNS avec des identifiants là encore aléatoires.
Les grands éditeurs s'unissent pour faire face
La solution pour le pirate : envoyer lui-même une requête que le DNS ne saura pas interpréter et générer très rapidement ?" en quelques fractions de seconde ?" les 65 536 déclinaisons possibles d'une même réponse, toutes avec un identifiant différent. Une opération gourmande en ressources que permettent les performances des toutes dernières générations de PC, un fait qui n'avait même pas été imaginé. Le chercheur Dan Kaminsky en a démontré la faisabilité en février et en a informé les principaux acteurs d'internet. Une parade a donc été élaborée. Elle consiste à repousser le nombre de réponses à fournir à 134 millions, en utilisant 11 bits supplémentaires pour définir l'identifiant. Bien sûr, cela ne fait que remettre le problème à plus tard.
Le correctif a été publié simultanément par plus de 60 éditeurs. Danny Mc Pherson, directeur de la sécurité chez l'éditeur Arbor Networks, s'en félicite : ' Un tel niveau de collaboration n'a été atteint qu'une fois ou deux dans l'histoire de l'informatique ! ' Sébastien Tricaud, responsable du département des détections d'intrusion chez l'intégrateur INL, donne l'ampleur de l'événement : ' Nous avons frôlé la panique mondiale. La coopération entre tous les éditeurs s'est d'autant mieux faite que la faille concernait non pas des produits, mais le protocole DNS, à savoir la moelle épinière d'internet, dont ils se partagent la responsabilité. ' Les acteurs impliqués sont tous les éditeurs d'un OS serveur ou réseau, de Microsoft à Cisco, en passant par Sun ou Red Hat. Seul Apple a attendu le 8 août pour réagir.
Une faille découverte par hasard
Dan Kaminsky a découvert cette faille alors qu'il mettait au point une méthode pour optimiser les requêtes entre les serveurs de Wikipédia. Réalisant l'ampleur de sa trouvaille, le chercheur a tout de suite alerté le Centre de réaction aux attaques informatiques (CERT) américain, le consortium des systèmes internet (ISC) qui maintient le serveur DNS le plus répandu (Bind) et... Microsoft. Car c'est sur le campus de ce dernier qu'est hébergé le laboratoire de Dan Kaminsky. Organisant dès lors les rencontres entre tous les éditeurs concernés, Microsoft sonnera le départ pour la distribution de tous les correctifs le 8 juillet, non sans omettre de communiquer sur son rôle central. ' Alors que l'on considérait jusqu'ici la dangerosité de ce genre de failles comme bénigne, toutes les craintes se sont cristallisées autour de l'annonce de Microsoft ', soulève Renaud Bidou, expert en sécurité chez Radware. Pour lui, l'affaire relève plus du coup marketing que d'un grave problème de sécurité : ' Tous nos clients ont réagi au buzz de cette histoire. Mais qu'ils soient opérateurs, hébergeurs ou simples entreprises utilisatrices, aucun d'eux n'a été la cible d'attaques sur leur DNS '.
Il n'en reste pas moins que le correctif se contente de rendre plus aléatoire la découverte d'un identifiant valable pour que le serveur DNS accepte de référencer des machines pirates. ' Il s'agit clairement d'une politique à court terme, s'emballe Fabien le Mentec, ingénieur sécurité et réseaux chez l'éditeur SkyRecon Systems. De nombreux protocoles ont été conçus de façon non sécurisée depuis vingt ans et l'on ne peut rien y faire à cause des problèmes de rétro-compatibilité que cela engendrerait. '
Un remède : tout crypter
Sur le papier, une solution existe : DNSsec, à savoir une évolution du protocole DNS dans laquelle tous les échanges sont cryptés. Bernard Ourghanlian se désole de la difficulté de remplacer les serveurs DNS par d'autres en DNSsec : ' Il faut non seulement gérer partout les clés associées au cryptage, ce qui est loin d'être facile en terme de déploiement, mais aussi remplacer toutes les anciennes plates-formes qui ne supportent pas DNSsec. ' Pour David Maciejak, analyste chez Fortinet : ' Le c?"ur d'internet est basé sur DNS. Il faudrait une coordination technique globale pour en changer. Ça n'existe pas et nous nous retrouvons exactement dans la situation d'IPv6, sans personne pour l'installer à la place d'IPv4. ' Bernard Ourghanlian se veut cependant optimiste : ' Les opérateurs des domaines de premier niveau (.com, .net...) déploient de plus en plus DNSsec. L'Icann s'est lui-même officiellement déclaré favorable à son adoption. Et l'on peut raisonnablement penser que la faille DNS découverte cette année va accélérer la volonté de ce déploiement. '
Pour Danny Mc Pherson, la solution la plus immédiate serait plutôt de songer à protéger le fonctionnement périphérique des DNS : ' Il suffirait, par exemple, de détecter et d'interdire les envois en masse de réponses. Voire, au niveau des répartiteurs réseau, de déployer des contre-mesures contre l'usurpation d'identité. ' Selon lui, le protocole BCP 38, en cours de ratification à l'IETF, résoudrait tous ces problèmes...
' sans qu'il soit besoin de faire redémarrer tout internet '.
Chronologie des faits
2006 : premier correctif DNS suite à une attaque. Désormais le numéro de transaction (Transaction ID) sera généré de façon aléatoire.
Février 2008 : le chercheur Dan Kaminsky découvre une vulnérabilité de fonctionnement des DNS.
Mars 2008 : Microsoft, suite à ce problème, réunit toute la communauté.
Avril 2008 : en collaboration avec Dan Kaminsky, les éditeurs (près de 60) élaborent un patch.
Juin 2008 : après des tests draconiens, le patch peut être déployé sur les serveurs DNS et les routeurs.
Juillet 2008 : annonce de la faille.
Septembre 2008 : Apple, lanterne rouge, lance son correctif.
Comment un serveur DNS est attaqué
1- Requête. Le pirate envoie une requête vers ' pirate.sitebancaire.com ', sachant qu'il n'y a pas de machine ainsi nommée sur le Net.
2- Renseignement. Le DNS qui reçoit la requête ne connaît pas la machine ' pirate.site-bancaire.com '. Il envoie la requête à l'un des 13 DNS maîtres dans l'espoir qu'elle rebondisse de DNS en DNS jusqu'à trouver la réponse.
3- Authentification. La requête est identifiée avec un numéro, le Transaction ID, compris entre 0 et 65 535. Ce numéro devra apparaître sur la réponse pour que celle-ci soit valide.
4- Rafale. Le pirate fait croire qu'il est un DNS qui connaît la réponse. Pour être reconnu en tant que tel, il génère 65 536 exemplaires de la réponse, chacune avec un numéro de Transaction ID différent.
5- Tromperie. En substance, la réponse signifie : ' Je ne connais pas la machine
" pirate.sitebancaire.com ", mais la machine 6.6.6.6 qui se charge du nom de domaine sitebancaire.com connaît la réponse. '
6- Retard. Un vrai DNS qui connaît le nom de domaine ' sitebancaire.com ' répond qu'il n'existe pas de machine ' pirate.sitebancaire.com '. Trop tard. Le DNS initialement interrogé n'attend plus de réponse.
7- Contamination. Lorsqu'un utilisateur envoie une requête vers ' sitebancaire.com ', le DNS renvoie la réponse conservée dans son cache. Réponse qui pointe vers une autre machine du pirate qui héberge un faux site.
1- Les machines sont désormais suffisamment puissantes pour générer très rapidement un faux paquet pour chacune des 65 536 valeurs que peut avoir l'identifiant Transaction ID.
2- Le port source était toujours le même jusqu'à l'été 2008. Désormais, sa valeur est choisie aléatoirement parmi 2 048 numéros possibles. Cela étend à plus de 134 millions le nombre de paquets à falsifier.
Ce qu'ils en pensent
L'utilisateur - Mathieu Perrière (SQLI) : ' réagir vite face à l'effet contre-productif du tapage '
' Nous avons corrigé la faille sur nos DNS dans les 24 heures qui ont suivi la disponibilité des correctifs. Nous nous sommes dépêchés car l'annonce de cette faille a été très médiatisée. Or, par expérience, ce genre de publicité a un effet accélérateur sur le développement d'outils malveillants, ce qui augmente soudainement le risque. Le tapage qui a été fait a été disproportionné par rapport à la dangerosité de la faille. A mon avis, l'événement réside plus dans la collaboration rarissime entre de nombreux grands concurrents du marché. Paradoxalement, ce n'est pas une de leurs solutions que nous avons prise. Nous avons préféré générer nous-mêmes des binaires de nos DNS depuis le nouveau code Open Source de Bind. Le coût de l'opération a été presque nul puisque seule une personne a été mobilisée pendant 30 minutes. '
Le prestataire - Nicolas Fischbach (Colt Telecom) : ' gérer une crise à la fois technique et médiatique '
' Nous nous sommes retrouvés dans une situation de crise médiatique. Au-delà de l'aspect technique de la correction de la faille, que nous avons complétée de contre-mesures pour détecter les attaques, il y a aussi eu la nécessité de rassurer nos clients face à une situation montée en épingle. D'autant que certains outils de tests déclaraient à tort que nos DNS étaient " moyennement vulnérables ", parce qu'ils ne testaient que la quantité d'aléatoire sur le choix d'un port source sans tenir compte des barrages placés en amont. Il a fallu déclarer nos serveurs en liste blanche auprès des développeurs de ces outils et mettre en place un plan de communication pour nos clients, notamment au travers dune cellule frontale qui les a renseignés de manière proactive sur les mesures techniques que nous avions prises. '
nos newsletters
Abonnez-vous à Micro Hebdo : 4,90 €/mois
Abonnez-vous à l'Ordinateur Individuel : 3 €/mois
Abonnez-vous à SVM mac : 4 €/mois
Abonnez-vous à 01 Informatique : 19 €/mois
