Vulnérabilité du DNS rendant l'empoisonnement plus facile
Première rédaction de cet article le 9 juillet 2008
Dernière mise à jour le 22 juillet 2008
Le 8 juillet, l'avis VU#800113 du CERT a révélé publiquement une faille du protocole DNS. Cette faille permet un empoisonnement relativement facile des caches DNS.
On peut trouver un bon résumé dans l'article Fixes Released for Massive Internet Security Issue. L'attaque a été découverte par Dan Kaminsky et repose sur une vulnérabilité classique du DNS. Le résolveur DNS (serveur récursif) accepte en effet une réponse si la question posée, le Query ID (RFC 1035, section 4.1.1) et le port UDP où arrive la réponse coïncident avec une question en attente. Mais Kaminsky a découvert un mécanisme pour envoyer une fausse réponse ayant de très bonnes chances d'être acceptée. (Le mécanisme détaillé est expliqué dans un autre article.) Indépendamment de cette attaque spécifique, il faut noter que la vulnérabilité est connue depuis longtemps (voir par exemple l'article DNS and BIND Security Issues de Paul Vixie qui dit With only 16 bits worth of query ID and 16 bits worth of UDP port number, it's hard not to be predictable. A determined attacker can try all the numbers in a very short time and can use patterns derived from examination of the freely available BIND code. Even if we had a white noise generator to help randomize our numbers, it's just too easy to try them all.) C'est pour cela que certains résolveurs ne sont pas vulnérables (ils mettaient en œuvre des mécanismes de défense depuis longtemps).
Depuis le site Web de l'auteur de la découverte, on peut tester la
vulnérabilité de son résolveur. Mais ledit site Web est très chargé et le code Javascript bogué. Si on veut tester via le Web, il faut mieux utiliser https://www.dns-oarc.net/oarc/services/dnsentropy. Si on préfère tester en local,
une bonne solution est le script de
Michael C. Toren :
% perl noclicky-1.00.pl 192.0.2.225 Looking up zqq0wi2odh5x.toorrr.com against 192.0.2.225 Fetching http://209.200.168.66/fprint/zqq0wi2odh5x Requests seen for zqq0wi2odh5x.toorrr.com: 192.0.2.225:32769 TXID=2234 192.0.2.225:32769 TXID=22512 192.0.2.225:32769 TXID=17521 192.0.2.225:32769 TXID=32880 192.0.2.225:32769 TXID=40914 Your nameserver appears vulnerable; all requests came from the same port.
Aïe, cette machine est vulnérable.
Et une autre solution pour tester la vulnérabilité de son serveur
récursif, ne nécessitant que le traditionnel dig, est de demander à
porttest.dns-oarc.net :
% dig +short porttest.dns-oarc.net TXT z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "192.0.2.248 is POOR: 26 queries in 4.5 seconds from 1 ports with std dev 0.00 "
On voit que cette machine est vulnérable : toutes les requêtes DNS sont émises depuis le même port.
Enfin, deux autres outils plus graphiques, entièrement via le Web, et que je recommande, DNS ENtropy, de l'OARC et le test de GRC.
Les logiciels peuvent diminuer leur vulnérabilité en utilisant un port source UDP aléatoire. C'est ce que font toutes les mises à jour qui viennent d'être publiées (voir par exemple communiqué de l'ISC). Le seul fait de choisir le Query ID au hasard est nécessaire mais pas suffisant (il ne fait que 16 bits de large). Certains résolveurs comme PowerDNS ou bien Unbound avaient déjà ce mécanisme et n'étaient donc pas vulnérables (pour Unbound, voir leur analyse complète et aussi celle de PowerDNS).
Attention : il ne suffit pas de faire la mise à jour du logiciel,
encore faut-il tester que la configuration du serveur de noms ne force
pas l'usage d'un port unique. C'est par exemple un problème possible
avec BIND si le fichier
named.conf contient une ligne du genre
query-source port 53;. Cette ligne, qui force l'usage d'un
port unique annule tout l'effet du patch
correctif ! (Et c'est détecté par les tests ci-dessus.)
Ces méthodes sont décrites dans un Internet-Draft nommé Measures for making DNS more resilient against forged answers.
Les systèmes comme Debian ou Gentoo ont très vite intégré les patches et la mise à jour normale suffit donc.
On peut noter que ce patch peut perturber
certains coupe-feux, qui
s'étonneraient des réponses arrivant à un grand nombre de ports. Par
exemple, il semble que Zone Alarm sur
Windows XP proteste et qu'il faille passer son
niveau de sécurité à Medium si la machine fait
tourner un BIND sécurisé (voir http://www.pcinpact.com/actu/news/44747-zonealarm-windows-dns-internet-probleme.htm et http://www.zdnet.fr/actualites/informatique/0,39040745,39382271,00.htm.
Comme le rappelle le communiqué de l'ISC cité plus haut, la solution idéale est de passer à DNSSEC (RFC 4033, RFC 4034 et RFC 4035). Mais c'est une opération très lourde, nécessitant des mise à jour des logiciels, l'action des registres, celle des gérants de résolveurs, etc. Et DNSSEC apporte ses propres vulnérabilités et la complication de gestion qui est associé aux systèmes utilisant la cryptographie. Réclamer son déploiement est donc assez yakafokon.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)
