Exostats/Exoscan |
Nombre de tests inclus
|
24445
|
|
Tests ajoutés |
Aujourd'hui |
Ce
mois |
23 |
23 |
|
|
Exploitation en cours de la faille DNS
Par Ludovic Blin,
secuobs.com
Le 04/08/2008
Résumé : La faille DNS dont les détails seront prochainement officiellement révélés par Dan Kaminsky, a fait l’objet de nombreuses recherches, aboutissant à la sortie de plusieurs exploits publics et privés.
Au début du mois de juillet, le chercheur en sécurité américain Dan Kaminsky annonçait la découverte d’une faille dans le protocole DNS, dont les détails, tenus secrets, avaient été révélés aux développeurs des principaux serveurs DNS pour leur permettre de sortir d’une manière coordonnée des nouvelles versions corrigeant ce problème. Le chercheur avait prévu de divulguer les détails de sa découverte lors de la conférence Black Hat de Las Vegas, le 7 aout.
Certaines indications avaient cependant filtré. D’une part le résultat de l’attaque : la possibilité d’insérer une adresse arbitraire dans un cache DNS en remplacement de l’adresse légitime. Concrètement, un attaquant peut ainsi rediriger n’importe quel adresse web vers une machine sous son contrôle, pour les utilisateurs d’un serveur DNS donné.
D’autre part, l’analyse des patchs a montré que la faille tirait parti d’une mauvaise entropie au niveau des TXID et des ports sources des requêtes DNS. En effet, puisque le protocole DNS est basé sur UDP, l’échange d’information entre le cache DNS et le serveur ayant autorité se fait sur un mode non connecté. Les développeurs ont donc prévu un mécanisme pour s’assurer que le paquet de réponse provenait bien du serveur auquel la requête a été envoyée. Un paquet est ainsi refusé, si celui-ci ne contient pas le bon identifiant de transaction (sur 16bit) ainsi que le bon port source (16bit également).
Si dans la théorie, cette technique semble plutôt sure (a part si l’attaquant est entre les 2 serveurs), la plupart des serveurs DNS, à l’exception notable de DJBDNS, se contentent d’utiliser des ports sources fixes et des identifiants de transaction prédictibles. Il devient donc possible d’empoisonner durablement un cache DNS. Le tout est de deviner le bon couple port source/TXID, en sachant qu’autant d’essais que nécessaire sont accordés. En pratique, le processus prend quelques minutes.
Il n’aura fallu que peu de temps à la communauté des chercheurs pour redécouvrir les détails de la faille de Kaminsky. C’est un post sur le blog d’Halvar Flake, qui a mis le feu aux poudres, suivi d’une « fuite » sur le blog de Matasano, dont les rédacteurs faisaient parti des « happy few », confirmant les spéculations. Peu de temps après, HD Moore publiait un exploit pour la plate-forme Metasploit.
La technique consiste en fait à envoyer au cache des requêtes concernant un sous domaine du domaine cible (par exemple aaaa.secuobs.com, aaab.secuobs.com …), ainsi qu’un certain nombre de réponses spoofées, chacune dotée d’un essai de TXID. Précisons qu’une section AUTHORITY doit être ajoutée pour réaliser effectivement l’empoisonnement du cache via le remplacement de l’enregistrement NS du domaine ciblé. Etant donnée que l’information provient, du point de vue du serveur DNS, d’un serveur ayant autorité, la nouvelle adresse va même remplacer celle qui était présente dans le cache. Par ailleurs, l’attaquant contrôlant le TTL, il est libre de le positionner au plus haut, entraînant de ce fait un empoisonnement durable du cache.
Cette faille peut donc avoir un impact relativement large, en fonction du serveur DNS de la connexion internet utilisée. Si on peut penser que les plus gros fournisseurs d’accès ont mis à jour leurs serveurs, il peut subsister certaines versions non mises à jour. Ainsi, ironie du sort, le chercheur HD Moore a constaté qu’un des serveurs DNS utilisé par le fournisseur d’accès de son entreprise était d’une part vulnérable, mais de plus exploité par des pirates, redirigeant les requêtes vers Google vers une version du moteur de recherche agrémentée de publicités (en utilisant des Iframes).
Il est donc conseillé de tester son serveur DNS, pour chaque connexion utilisée. En cas de serveur DNS géré en interne, l’application des mises à jours voire la migration vers un cache sûr comme DJBDNS est fortement conseillée.
Test DNS : lien https externe url: [click]
Le blog de Sid: lien http externe url: [click]
Le blog de Halvar Flake : lien http externe url: [click]
Le blog de Matasano: lien http externe url: [click]
DJBDNS : lien http externe url: [click]
CVE : lien http externe url: [click]
| Mini-Tagwall des articles publiés sur SecuObs : | | | | sécurité, windows, exploit, réseau, vulnérabilité, microsoft, attaque, système, virus, audit, internet, fonction, présentation, données, outil, linux, bluetooth, shell, vista, gestion, trames, wishmaster, sysun, metasploit, engineering, paquets, téléphone, fonctions |
| Mini-Tagwall de l'annuaire video : | | | | virus, spyware, vmware, firmware, biometric, lockpicking, wimax, password, spammer, kernel, malware, windows, iphone, symantec, phish, knoppix, adware, security, botnet, linux, tutorial, cryptography, internet, attack, server, wireshark, virtual, metasploit, intel, protect, openbsd, hitbsecconf2006, jailbreak, rootkit, ubuntu, norton, exploit, hijackthis, ettercap, samsung, screen, fingerprint, vista, flash, desktop |
| Mini-Tagwall des articles de la revue de presse : | | | | security, microsoft, windows, vulnérabilité, network, google, vulnerability, hacker, attack, inject, remote, mobile, server, exploit, apple, internet, iphone, black, yahoo, sécurité, malware, vista, intel, patch, crypt, drive, access, protect, virtual, laptop, linux, source, biometric, research, ebook, business, virus, office, phish, adobe, chine, facebook, opera, flash, wireless |
|
|
|
|
|
