Exploitation malicieuse du protocole DNS
Posted by Daniel on 16 Mar 2008 at 02:22 | Tagged as: sécurité
Article publié en 2002 dans MISC 4, co-écrit avec Eric Detoisien.
L'un des services à la fois le moins visible et le plus important d'Internet est le Domain Name System, ou tout simplement DNS. Du fait de son omniprésence, c'est une cible de choix pour un certain nombre d'attaques. Nous ne reviendrons pas ici sur le principe du DNS. Pour une rapide présentation, le lecteur se reportera à l'article L'homme du milieu[1] dans ce même numéro, et pour une étude plus approfondie, à l'excellent ouvrage DNS et BIND[2]. Nous allons en revanche présenter un peu plus en détails certains aspects du protocole qu'il est important de bien visualiser pour comprendre les différentes attaques possibles.Un peu de théorie
Format des messages
La plupart du temps, les messages DNS sont contenus dans un paquet UDP unique au format de la figure 1. L'en-tête précise quels autres champs (question, réponse, ...) sont présents dans le message. Pour une description complète des différents éléments du message, on se reportera à la RFC 1035[3].|
|
| Fig. 1 : Format d'un message DNS |
|
|
| Fig. 2 : Format d'un enregistrement (RR) |
|
|
| Fig. 3 : En-tête d'un message DNS |
- QR : précise si le message est une requête (0) ou une réponse (1).
- Opcode : type de la requête, standard (0), inverse (1) ou statut du serveur (2).
- AA : précise si le serveur fait autorité pour la réponse.
- TC : indique que le message est tronqué.
- RD : demande de récursivité pour une requête.
- RA : indique dans une réponse si la récursivité est disponible.
- Z : non utilisé, doit être à 0.
- RCODE : code de la réponse (0 s'il n'y a pas eu d'erreur).
Requêtes récursives et itératives
Les deux types de requête gérés par le DNS, récursives et itératives, diffèrent considérablement dans leur mode de résolution.- Lors d'une requête récursive à un serveur DNS, celui-ci va interroger lui-même d'autres serveurs, jusqu'à obtenir une réponse (ou échouer dans la résolution), et renvoie au client une réponse complète (ou une erreur s'il n'a pas pu résoudre le nom). À chaque fois qu'un serveur de noms effectue une requête récursive, il peut recevoir de nombreuses informations, qu'il va stocker dans son cache. Imaginons par exemple un utilisateur du domaine misc.fr, désireux de compléter son éducation, qui cherche à joindre la machine www.education.gouv.fr (figure 4)
Il est à noter que dans ce cas, le serveur DNS local connaît déjà vraisemblablement le serveur faisant autorité pour la zone .fr, et qu'il n'a donc pas besoin de passer par un serveur racine pour obtenir cette information.
Fig. 4 : Les requêtes récursives - Dans le cas d'une requête itérative, le serveur ne va pas faire de nouvelles requêtes, et se contentera de fournir une réponse basée sur les informations dont il dispose déjà. Cela peut consister en une redirection vers des serveurs de noms plus appropriés (autorités du domaine concerné par la requête).
Un problème courant : les fuites d'informations
Un serveur de noms est installé dans le seul but de fournir des informations à des clients. Cependant, il est courant qu'un serveur DNS fournisse trop d'informations, pouvant ainsi parfois faciliter la tâche d'un éventuel pirate.Le transfert de zone
Le transfert de zone est une fonction normalement utilisée pour fournir à un serveur de noms esclave toutes les données concernant la ou les zones qu'il doit servir. Cependant, cette fonctionnalité peut également être utilisée par un pirate, fournissant de précieuses informations sur la zone servie. Dans certains cas, il se peut que le pirate n'apprenne rien d'intéressant. Dans d'autres, cela peut permettre la découverte de machines sur un réseau, machines qui pourraient par exemple être dissimulées par le biais de filtres divers. Par exemple, prenons le domaine fictif misc.fr, défini uniquement sur un serveur de noms local. La commande host va nous permettre de demander un transfert de zone (on pourrait aussi utiliser nslookup) :On peut également obtenir des informations sur la configuration des zones :$ host -l misc.fr localhost misc.fr. NS ambre.misc.fr. elendil.misc.fr. A 172.16.1.13 ambre.misc.fr. A 172.16.1.11
misc.fr. SOA ambre.misc.fr. dpo.ambre.misc.fr. (
1 ;serial (version)
10800 ;refresh period (3 hours)
3600 ;retry interval (1 hour)
604800 ;expire time (1 week)
86400 ;default ttl (1 day)
)
misc.fr. NS ambre.misc.fr.
elendil.misc.fr. A 172.16.1.13
www.misc.fr. CNAME elendil.misc.fr.
ambre.misc.fr. A 172.16.1.11
La directive allow-transfer { none; }; dans la déclaration d'une zone dans le fichier named.conf (Bind 8.x) permet d'interdire totalement les transferts de zones. La déclaration none peut être remplacée par une liste d'adresses correspondant aux serveurs esclaves autorisés à faire ce type de requêtes.
$ host -l misc.fr localhost misc.fr AXFR record query refused by localhost No nameservers for misc.fr responded
Les zones internes
De nombreux réseaux connectés à internet utilisent des adresses dites privées[4], théoriquement non routables sur internet, par exemple 192.168.1.0/24. Cependant, si le serveur de noms de ce réseau est accessible de l'extérieur, et s'il propose des tables inverses (dans notre exemple, 1.168.192.in-addr.arpa.), il est possible de découvrir assez rapidement quelles adresses privées sont utilisées en effectuant une série de requêtes sur les plages les plus classiques. A partir de là, un attaquant pourrait utiliser ces informations pour par exemple créer des paquets spoofés à destination du réseau interne.Le serveur DNS, un outil de déni de service
Les attaques par réflexion
Les attaques par réflexion sont une catégorie de déni de service dont le principe est simple : le ou les attaquants ne contactent jamais directement la victime, se contentant de générer des paquets spoofés avec comme adresse source celle de la victime, et d'envoyer ces paquets à des serveurs légitimes, qui répondront ensuite directement à la victime (figure 5)).|
|
| Fig. 5 : Principe d'une attaque par réflexion |
Le cas du DNS
Une requête DNS fera toujours un minimum de 18 octets : 12 octets d'en-tête, et un minimum de 6 octets pour le champ 'question'. Une requête sur ambre.misc.fr, par exemple, sera représentée par un message de 32 octets. La réponse à cette requête, quant à elle, constitue un message de 77 octets. Avec une simple requête, nous obtenons une réponse deux fois plus grosse. Si l'on considère maintenant une demande de transfert de la zone misc.fr, la requête représente 27 octets et la réponse 312 octets, ce qui fait un rapport de un pour dix, dans le cas peu favorable d'une toute petite zone. En rajoutant une dizaine d'enregistrements dans la zone, on arrive à un rapport 25 entre la requête et la réponse, et il s'agit encore d'une petite zone. En rassemblant une liste modérée de serveurs de noms supportant le transfert de zone, on peut donc très simplement monter une attaque d'une amplitude de plus de 25 fois la bande passante de l'attaquant. En prenant l'exemple d'un simple particulier utilisant le câble, il y a de quoi saturer une ligne de 12 Mbit/s. Pour un étudiant disposant d'une bande passante de plusieurs Mbit/s, il devient possible d'attaquer de très gros sites, par exemple.Attaques liées au protocole DNS
Le principe des attaques liées au protocole DNS est relativement simple. Il consiste à corrompre la correspondance entre le nom d'une machine et l'adresse IP qui lui est normalement associée, typiquement pour rediriger du trafic initialement destiné à un serveur légitime vers une machine contrôlée par le pirate. Pour cela il existe deux grands types d'attaque, le DNS ID Spoofing qui agit directement au niveau de la communication DNS et le DNS Cache Poisoning qui exploite le cache des serveurs DNS ou des clients DNS.DNS ID Spoofing
Lors de la description de l'en-tête du protocole DNS, il a été vu qu'un identifiant est utilisé pour la corrélation entre la question émise et la réponse reçue. La capture suivante montre ce processus :L'identifiant de cette requête DNS est 64561 et une réponse provenant du serveur DNS parvient avec ce même numéro. Par conséquent un moyen de corrompre la correspondance nom/ip est d'envoyer une réponse falsifiée à une requête légitime. Pour mener à bien cette opération et forger le paquet adéquate, l'identifiant est un des éléments indispensables. Le DNS ID Spoofing est réalisable à la foiscontre une machine cliente ou un serveur DNS. A partir de là, deux cas d'attaque sont possibles. Attaque sur un réseau local Sur un LAN cette attaque est triviale puisqu'il est possible de capturer le trafic via un quelconque sniffer. Afin de ne pas être gêné par un switch une attaque de type ARP Cache Poisoning fera en sorte de rediriger le trafic vers la machine de l'attaquant. Une analyse des requêtes DNS aboutit à la récupération de l'adresse IP source, du port UDP source, de l'identifiant DNS et de la question. La réponse est forgée en fonction de la requête et elle indique une fausse adresse IP. Il existe plusieurs outils automatisant cette attaque sur une réseau local comme dnsspoof (package dnsiff), ADMsniffID ou WinDNSSpoof (pour Windows). A noter qu'il est indispensable de répondre avant le serveur DNS carseule la première réponse est prise en compte. Pour s'en assurer les requêtesDNS rédirigées normalement par le pirate sont bloquées par un firewall. Il estpossible de ne laisser sortir que les requêtes qui ne sont pas destinées à êtrespoofées afin de ne pas bloquer l'intégralité des flux DNS de la victime. Une extension NetFilter sous Linux (patch 'string' d'Emmanuel Roger) analysant le contenu du paquet est une solution, de même sous Windows cette fonctionalité est incluse dans WinDNSSpoof couplé à un simple firewall personnel. L'exemple d'utilisation de WinDNSSpoof suivant illustre cette attaque en local : la machine du pirate lance WinDNSSpoof afin qu'il intercepte une requête sur le nom192.168.0.2.32769 > 192.168.0.1.domain: 64561+ A? www.toto.com. 192.168.0.1.domain > 192.168.0.2.32769: 64561 q: A? www.toto.com. 1/0/0 www.toto.com. A 123.123.123.123
www.supersecret.fr pour le rediriger vers l'adresse IP 123.123.123.123
Du côté de la victime, la commande host montre le résultat.D:\>wds -n www.supersecret.fr -i 123.123.123.123 -g 00-C0-24-EE-49-EF + listening [www.supersecret.fr] DNS query + DNS query [www.supersecret.fr] from 192.168.0.2 + DNS response [123.123.123.123] to 192.168.0.2
[victime@chezlui]# host www.supersecret.fr www.supersecret.fr has address 123.123.123.123Une victime utilisant un navigateur pour surfer sur le site
www.supersecret.fr se retrouve alors sur un faux site capable de récupérer des informations confidentielles.
Attaque depuis une machine distante
Une attaque non locale est nettement plus difficile à mettre en oeuvre. Dans le cas d'un client DNS, le moment de la requête doit être connu ainsi que l'adresse IP du serveur DNS utilisé, le port source UDP et l'identifiant DNS. Et seulement avec ces informations, une requête forgée est possible. Cette attaque contre un client DNS n'est pas envisageable dans cette situation au vu de la difficulté à récupérer ces informations. En ce qui concerne le serveur DNS les conditions de l'attaque sont moins contraignantes.
Soit mechant qui est propriétaire du domaine mechant.org et qui a de plus la main sur le serveur DNS associé à celui-ci. La victime est le serveur DNS du domaine victime.org. La première étape est l'envoi d'une requête sur www.mechant.org par mechant sur le serveur DNS de victime.org. A noter que cela n'est possible que si le serveur DNS de victime.org accepte les requêtes récursives. La figure 6 illustre cette étape :
|
|
| Fig. 6 : DNS ID Spoofing - Etape 1 |
mechant.org a sniffé l'identifiant de la requête du serveur DNS de victime.org. Pour la suite mechant émet une requête sur www.supersecret.fr à destination du serveur DNS de victime.org. La difficulté de l'attaque réside dans l'aptitude de mechant à forger une réponse DNS qui semblera valide au serveur de victime.org c'est à dire avec l'adresse IP du serveur DNS supersecret.fr) et le bon identifiant DNS. Il est donc impératifde trouver, de connaître ou de prédire celui-ci. La figure 7 expose cette partie de l'attaque :
|
|
| Fig. 7 : DNS ID Spoofing - Etape 2 |
|
|
| Fig. 8 : Générateur d'ID DNS - Windows 2000 SP2 DNS Server |
|
|
| Fig. 9 : Générateur d'ID DNS - Bind 9.2.1 DNS Server |
DNS Cache Poisoning
La RFC 1035 préconise l'utilisation d'un cache DNS. Sa fonction est de garder en "mémoire" les couples nom/ip que le serveur DNS ou un client DNS aurait déjà récupéré lors de requêtes précédentes. Ainsi, il n'est pas obligé d'émettre à nouveau une requête s'il est interrogé sur une correspondance déjà présente dans son cache. Une attaque de type Cache Poisoning consiste donc à corrompre ce cache avec des couples nom/ip falsifiés. Pour cela deux techniques sont utilisables. Prédiction des identifiants Cette attaque est celle décrite dans la partie consacrée au DNS ID Spoofing. Si la prédiction des identifiants DNS est simple, le nombre de réponses forgées est plus faible et la probabilité d'obtenir le bon identifiant très forte. Ainsi, si une de ces réponses est valide, la fausse adresse IP DNS est mise en cache. Celui-ci est alors corrompu par un couple nom/ip falsifié (www.supersecret.fr avec l'adresse IP 66.66.66.66). Lorsque des clients font des requêtes sur le nom www.supersecret.fr à partir du serveur DNS victime.org, la fausse adresse IP est renvoyée.
Enregistrements de ressource forgés
Pour cette attaque il est inutile de prédire l'identifiant DNS. Néanmoins, le serveur cible doit accepter la récursivité et le pirate posséder son propre serveur DNS et son nom de domaine. mechant toujours propriétaire de mechant.org envoie une requête sur www.mechant.org sur le serveur DNS de victime.org. Le serveur DNS de mechant.org va alors renvoyer une réponse avec en plus un champ Additional record particulier :
HEADER:
opcode = QUERY, id = 7337, rcode = NOERROR
header flags: reply, auth. answer, recursion avail.
questions = 1, answers = 1, auth. records = 0, additional = 1
QUESTIONS:
www.mechant.org., type = XX, class = 1
ANSWERS:
-> www.mechant.org.
type = A, class = 1, ttl = 3355566, dlen = 4
IP address = 123.123.12.12
ADDITIONAL RECORDS:
-> www.supersecret.fr.
type = A, class = 1, ttl = 3355566, dlen = 4
IP address = 66.66.66.66
Ce RR contient la fausse information indiquant l'association entre www.supersecret.fr et l'adresse IP 66.66.66.66. Si le serveur DNS n'est pas protégé contre ce type d'attaque il garde en cache tous les RR contenus dans la réponse. Un serveur Bind (à partir de la 4.9.7 et de la8.1.2) ne garde aucun RR de type Additional record ainsi que ceux ne concernant pas le domaine de la question. Seul un RR Authority record est falsifiable mais l'information est un nom de machine et non une adresse IP. Cependant les serveur DNS Windows mettent en cache les Additional record par défaut[8].
Après avoir aborder le cas des serveurs DNS, quelques mots sur le DNS Cache Poisoning des clients DNS sont indispensables. Les systèmes d'exploitation Windows NT/2000/XP possèdent leur propre cache DNS, son contenu est visualisé par la commande : ipconfig /displaydns. Il possède la particularité de prendre en compte tous les types RR. Il est donc possible possible d'attaquer directement une machine cliente si le serveur DNS qu'il utilise a la récursivité d'activé. L'exemple suivant illustre plus clairement ce cas. Dans un premier temps mechant doit forcer la victime à émettre une requête DNS sur www.mechant.org. Pour cela une simple page HTML, avec un tag quelconque prenant en paramètre une URL, envoyé par e-mail suffit. Cette requête est transmise par le serveur DNS victime.org, à noter que c'est un serveur interne et donc qu'il est forcément récursif. Le faux serveur DNS de mechant.org envoie alors une réponse avec de faux RR :
HEADER:
opcode = QUERY, id = 7416, rcode = NOERROR
header flags: reply, auth. answer, recursion avail.
questions = 1, answers = 1, auth. records = 0, additional = 2
QUESTIONS:
www.mechant.org., type = XX, class = 1
ANSWERS:
-> www.mechant.org.
type = A, class = 1, ttl = 3355566, dlen = 4
IP address = 172.18.100.33
ADDITIONAL RECORDS:
-> www.supersecret.fr
type = A, class = 1, ttl = 3355566, dlen = 4
IP address = 66.66.66.66-> www.vraimentsupersecret.fr
type = A, class = 1, ttl = 3355566, dlen = 4
IP address = 77.77.77.77
La figure 10 illustre cette attaque :
|
|
| Fig. 10 : DNS Cache Poisoning du client |
victime.org transmet la réponse à la victime sans ôter les RR indésirables à l'instar des serveur DNS Windows NT/2000 et de certains Bind, le cache du client est corrompu. La commande ipconfig /displaydns est là pour le prouver :
Configuration IP de Windows 2000
www.supersecret.fr.
------------------------------------------------------
Nom Enregistrement . : www.supersecret.fr
Type Enregistrement . : 1
Durée de vie . . . . : 86393
Longueur Données . . : 4
Section . . . . . . . : Answer
Enregistr. A (Hôte) . :
66.66.66.66
www.vraimentsupersecret.fr.
------------------------------------------------------
Nom Enregistrement . : www.vraimentsupersecret.fr.
Type Enregistrement . : 1
Durée de vie . . . . : 8393
Longueur Données . . : 4
Section . . . . . . . : Answer
Enregistr. A (Hôte) . :
77.77.77.77
Ainsi quand la victime va surfer sur le site www.supersecret.fr, le navigateur regarde d'abord le cache local et utilise l'adresse IP 66.66.66.66 sans passer par le serveur DNS de victime.org. Et au pire ce server DNS a aussi son cache de corrompu.
Conclusion
DNSSEC : une extension de DNS
Les problèmes de sécurité du DNS sont connus depuis longtemps. En1997, la RFC 2065 (actuellement RFC 2535) a commencé à formaliser des extensions de sécurité pour le protocole, en se basant sur des fonctionnalités cryptographiques. Ces extensions permettent d'une part de garantir l'intégrité et l'authentification des informations retournées par un serveur DNS, parle biais de signatures des RR d'une zone par une clé privée propre à l'autorité de cette zone, et d'autre part de garantir l'intégrité des transactions en elles-mêmes, et en particulier de vérifier qu'une requête n'a pas été altérée avant d'atteindre le serveur DNS (qui pourrait alors retourner une réponse valide, mais ne correspondant pas à la vraie question). Pour plus de détails sur ces extensions, le lecteur se reportera aux RFC appropriées, notamment les RFC 2535[9] et 3007[10]. Malheureusement, malgré une base installée de serveurs supportant DNSSEC (en particulier toutes les versions de Bind depuis la 8.2), l'utilisation reste anecdotique, probablement à cause des problèmes de distribution des clés, et il faudra sans doute attendre encore quelque temps avant l'adoption massive de ce système. D'ici là, quelques règles d'hygiène vous permettront de limiter les risques ...Recommandations
Le protocole DNS tel qu'on l'utilise aujourd'hui n'est pas fiable et comporte des failles. Il est donc important d'en prendre conscience et de sécuriser son réseau et ses machines en conséquence. Concernant le DNS ID Spoofing en local, seul une surveillance accrue du réseau (détection de sniffer, protection contre l'ARP Cache Poisoning,...) est efficace. Un proxy minimise cette attaque car c'est lui qui effecte les requêtes DNS à condition qu'il ne soit pas dans le même réseau que les machines clientes. Contre le DNS Cache Poisoning au niveau des serveurs DNS publics, la récursivité doit être désactivée et des versions récentes utilisées. Pour les serveurs Windows NT/2000 le cache doit être sécurisé :HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters Value Name: SecureResponses Data Type: REG_DWORD Value: 1Enfin pour le cache DNS des machines Windows NT/2000/XP, la commande
ipconfig /flushdns vide le cache et doit être utilisée régulièrement (en l'automatisant à chaque connexion de l'utilisateur par exemple).
Références
[1] L'homme du milieu, P. Prados, MISC 4
[2] DNS et BIND, Paul Albitz & Cricket Liu, éditions O'Reilly
[3] RFC 1035 : Domain Names - Implementation and Specification
[4] RFC 1918 : Address Allocation for Private Internets
[5] Application-Level Reflection Attacks, Tom Vogt, http://web.lemuria.org/security/application-drdos.ps
[6] Strange Attractors and TCP/IP Sequence Number Analysis, Michal Zalewski, http://razor.bindview.com/publish/papers/tcpseq.html
[7] DNS ID Hacking, ADM, http://packetstormsecurity.nl/groups/ADM/ADM-DNS-SPOOF/ADMID.txt
[8] Windows NT/2000 DNS server cache poisoning vulnerability, CERT, http://www.kb.cert.org/vuls/id/109475
[9] RFC 2535 : Domain Name System Security Extensions
[10] RFC 3007 : Secure Domain Name System (DNS) Dynamic Update
Flux RSS 2.0