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.

22 juil. 2008

Security/Networking libs et temps qu'il reste à vivre

Je me suis offert récement l'excellent ouvrage de Mike Schiffman "Building open source security tools".

L'auteur y présente les paradigmes des outils de sécurité réseau, les librairies pratiques :

  • Libpcap : capture de paquets
  • Libnet : création/injection de paquets - écrite par l'auteur -
  • Libnids : monitoring et évaluation d'évènements réseau
  • Libdnet : manipulations sur les basses couches du réseau (accès au cache ARP du noyau, analyse des interfaces réseau, construction de paquets...)
  • LibSf : OS fingerprinting
  • LibOpenSSL : cryptographie

Mais aussi des présentations des techniques de reconnaissance passive et active, des techniques d'attaque, de défense et - wouhou!- un gros chapitre sur Firewalk! Pour ceux qui ne connaissent pas, Firewalk permet de déterminer les règles appliquées par un firewall (ACL).

Tout comme traceroute, Firewalk se base sur l'IP expiration (décrémentation du champ TTL des paquets IP à chaque `hop') pour tester le fonctionnement d'un firewall sans connaissance de l'état des machines qu'il protège.

Le champ TTL (Time to Live) d'un packet IP permet d'éviter les boucles de routage. Lorsqu'un packet est émis, ce champ est remplit d'une valeur plus ou moins arbitraire, décrémentée par chaque routeur que le paquet traverse. Lorsqu'il arrive à zero, le routeur (s'il se comporte normalement) doit émettre un paquet "ICMP detination unreachable" à l'émetteur. Ainsi, l'outil traceroute tente de joindre une cible donnée avec un ttl de 1, puis de 2 puis 3 etc... afin de déterminer par quels routeurs passent les packets pour atteindre la cible.

Firewalk détermine donc d'abord la distance (en hops bien sûr!) qui le sépare du firewall. Disons 3.

Il débute ensuite un scan d'une machine - réelle - au sein du réseau, située à plus d'un hop du firewall, tout en fixant le TTL des paquets envoyés à 4. Ainsi, ils doivent passer le firewall, sans néanmoins atteindre la machine scannée. Les paquets sont envoyés en UDP et TCP, port par port ('fin selon ce que l'on spécifie quoi!).

Si le paquet respecte une règle du firewall ("autorisé à passer"), Firewalk reçoit un message "ICMP destination unreachable" (Time to Live insuffisant pour atteindre la machine scannée)

Sinon, le timeout expire : le port est bloqué par le firewall.

C'est tout bête, c'est super efficace, c'est bien écrit, c'est open source, c'est du old school, rhâââ que c'est beau!!

J'utilise actuelement les libpcap et libnet pour un projet de stage, et je suis impressionné par la puissance qu'elles offrent, bien que le côté "opaque" des manipulations me gène un petit peu, l'écriture des softs est simple et les libs assez matures pour ne pas perdre en possibilités.

Savoir que le code produit est portable est également motivant. Je ne pense pas finalement réécrire RARPing avec ces librairies, mais APing aurait sans doute à y gagner (portabilité, lisibilité, rapidité etc...)

Stay tuned! (hum inutile d'être trop trop `tuned' quand même, vu le temps libre dont je dispose, ça sera pas fait demain non plus...)

Et non je ne parlerais pas de Dan Kaminsky avant sa conf au Black Hat 2008!! Par contre les noms des nominés aux  pwnies awards sont maintenant publiés sur http://pwnie-awards.org/2008/awards.html et ça c'est marrant!

13 juil. 2008

The Nmap book, par Fyodor

Bon, inutile je suppose de s'attarder sur les présentations, Nmap est de l'avis de tous le scanner de ports le plus puissant aujourd'hui. Il dispose aussi de la capacité à reconnaitre un OS à distance, d'une détection des versions des services, d'un moteur de script, et d'innombrables projets auxiliaires (GUI, nping, ncat, base de scripts...)

Le projet a commencé ici par Fyodor. Le même Fyodor est en train de terminer l'écriture d'un livre au sujet de Nmap. Il a récemment mis en ligne presque la moitié de son livre, en attendant une sortie définitive (prévue pour début/mi aout).

Ces chapitres sont disponibles ici : http://nmap.org/book/toc.html