25 janv. 2008

Vous êtes bien au 72.14.207.191 et autres joies du DNS

Premier post de l'année 2008, je sais, le précédent remonte à un moment maintenant... J'en profite donc pour attaquer d'autant plus vite le sujet (merveilleuse introduction, vous admettrez!)

La mode les travaux du GnuCitizen de ces derniers jours sont tournés autour d' attaques au niveau de protocoles réseaux au sens strict, plus que web apps comme auparavant. Les deux ne sont pas complètement distincts non plus mais cela est une autre histoire (intéressante). Après quelques frappantes recherches concernant l'UPnP, voilà au tour du DNS de passer entre leurs neurones affutés. </éloges>

Le sujet me passionnant, à mon tour de m'essayer à la chose, sans aucune prétention de rivaliser.

Le protocole DNS (Domain Name Service) est, pour mémoire, ce protocole qui permet de transformer "hatch-the-hitch.blogspot.com" en "72.14.207.191". En effet vos applications n'ont strictement rien à faire de l'url, et votre mémoire de l'adresse ip (à moins d'une pulsion de consulter mon site sur un réseau aux DNS en panne mais bon là c'est pas pareil!). Cette résolution de noms se fait en envoyant une requête à un serveur, lequel transmet à d'autres serveurs DNS etc... jusqu'à l'obtention de l'adresse ou d'une erreur. Dans les deux cas la réponse remonte ensuite au client.

Ensuite il y a le mauvais élève, mDNS, pour multicast DNS, ou les requêts sont envoyées en broadcast 255.255.255.255, et répond qui veux (oui, le méchant pirate au fond de la salle, tu veux répondre?). Les produits Apple ou la Xbox360 utiliseraient ce protocole.

Un autre point notable est que ces communications se font via des paquets UDP, forgeables sans problèmes aucun par un utilisateur. Par contre les serveurs sont sur les ports 53, il faut donc être root pour les binder. Cela ne constitue pas un obstacle majeur étant donné, je le répète que n'importe quel utilisateur d'une machine connectée au réseau pourra forger des fausses réponses.

Forger des réponses DNS? Rien ne protège le client? Serions-nous alors face à un protocole infernal, pure invention du malin, voir d'un hippie? Non quand même pas. Lors d'une requête, la demande d'informations est "signée" d'un octet aléatoire. La réponse reprend le même octet. Bon, il s'entend qu'un bête sniffer permet de bypasser la chose. Ensuite un petit DOS sur le "vrai" serveur DNS et vous voila le roi du monde, un peu!

Le contrôle du traffic DNS d'un réseau se révèle quasiment synonyme du contrôle du réseau. En effet, il permet d'attaquer sur tous les fronts. Phishing, modification à la volée de pages web, à l'aide d'un serveur distant, Mitm attacks, dénis de service... je m'arrête là!

Les serveurs DNS sont donc des organes à protéger. Il existe différentes solutions pour cela. La plus "pratique" est l'utilisation d'IDS tels que SNORT. Ces logiciels peuvent détecter une attaque autour du protocole DNS. Charge à l'administrateur de prendre les mesures adaptées.
Une autre peut être la mise en place d'une architecture dnssec qui permet en autre d'éliminer les risques de DNS cache poisoning.