23 juil. 2008

Faille DNS expliquée

Bon, je reconnais que j'ai peut être parlé un peu vite lorsqu'hier je disais que je ne parlerais pas de la faille intrinsèque à l'architecture de DNS découverte par D. Kaminsky toussa...

Ce que je voulais dire c'est que je n'en parlerais pas TANT QUE L'ATTAQUE NE SERAIT PAS CONNUE, et maintenant c'est fait! Qui a fait la boulette? on dira pas!

La faille à été extrêmement médiatisée (fun de voir les médias grand public tenter d'expliquer le DNS cache poisoning à M/Mme les-hackeurs-vont-m'envoyer-des-virus ), mais l'attaque en elle même est restée secrète, bon plus maintenant donc...

Pour capter le truc il faut avoir quelques notions sur le fonctionnement des DNS.

Basic: le DNS est le protocole qui permet de faire le lien entre noms d'hôtes ( www.google.com ) et addresses IP.

Pour ceux qui aiment les RFC et qui n'ont rien de prévu les 4 prochains mois voila de quoi s'occuper : http://www.dns.net/dnsrd/rfc pour les autres, la lecture de la RFC 1034 est déjà bien enrichissante (et pour coder la 1035 parle de l'implémentation)

Il reste du monde? Alors on peut reprendre. Une transaction DNS (requête + réponse) se fait autour d'un identifiant pseudo aléatoire, côdé sur 16 bits. Ainsi, pour fausser une réponse DNS, il faudrait connaitre cet identifiant, 16 bits c'est peu mais c'est quand même beaucoup à bruteforcer. Par contre, mathématiquement, si vous parvenez à faire éxécuter 1000 requêtes DNS à la victime, vous avez 1000 fois plus de chance de la piéger ^^

Le second élément à prendre en compte pour mener à bien l'attaque qui nous interesse est l'existence d'additionnal RRs (les RRs - ressource records - sont les champs du paquet qui contiennent l'objet des requêtes/réponses, voir les RFC). Si une requête sur aa.domain.com aboutit avec comme additionnal RRs bb.domain.com, les deux adresses sont mises en cache. En cas d'attaque, vous attaquez donc deux hôtes du même domaine à la fois. Forcément du même domaine? ouais parce que le DNS c'est un peu Disneyland mais les clients sont quand même conçus pour être pas trop stupides.

N'oublions pas que notre victime est un résolveur DNS, en lui envoyant des requêtes, il va interroger (via le mécanisme de récursion) des serveurs de contenu etc... Donc si vous faites en sorte que votre victime demande successivement aaaa.hackme.com, puis aaab.hackme.com etc... vous entrez en course contre le système récursif du serveur DNS cible. A chaque requête, le serveur rend un NXDOMAIN (domaine inconnu), vous êtes désavantagés à cause de l'existence de l'identifiant dont nous parlions au début, néanmoins, la force de l'attaque réside de le fait qu'il suffit d'une seule réussite (au sujet d'un hôte inexistant) à votre actif pour empoisonner le cache du serveur DNS victime pour n'importe quel autre du domaine, à l'aide des additional RRs!

Ainsi, vous empoisonnez le cache pour aaaa.google.com ce dont on se fout un peu, mais aussi www.google.com, ce qui est un petit peu plus gênant pour les prochains! Evidement, on placerait dans de telles requêtes un TTL le plus long possible, histoire que l'effet persiste.

Pour résumer : vous envoyez des requêtes à un résolveur, sur des hôtes inconnus, et envoyez également les réponses "du serveur" qu'il interrogera, jusqu'à ce que l'une de vos "réponse" soit prise à la place d'une vraie, vous avez alors empoisonné le cache pour bien plus qu'un hôte qui n'existe pas!

La solution de Kaminsky (et du consortium d'industriels qui a patché la faille dans un bel exemple de coopération) est de randomiser non seulement l'ID de transaction mais également le port source, ainsi, ce n'est plus seulement 16 mais 32 bits qu'il faut attaquer, et là c'est nettement plus chaud!

L'auteur de l'article qui m'a inspiré (retiré maintenant) estime à une dizaine de secondes le temps nécessaire pour mener à bien l'attaque avec une connection intrernet rapide.

Les patchs sont en cours de distribution, sinon vous pouvez passer sous OpenDNS, qui utilise des serveurs protégés, ou si vous maintenez un serveur DNS installer DJBDNS qui randomize son port source depuis des années. Attention aux phishers maintenant que l'attaque est disclosed et tous les serveurs non patchés!


UPDATE : |)ruid et HDM (metasploit project) ont publié ce matin un exploit fonctionnel sur Full-disclosure, intégré au metasploit framework, des attaques sont donc à prévoir.

Aucun commentaire: