Audits de sécurité du protocole DNS
Contents
1 Introduction à la sécurité du protocole DNS
DNS est utilisé dans la majeure partie des réseaux locaux cependant il a été développé avec des contraintes fortes de performance, au détriment de sa sécurité, afin de ne pas dégrader le trafic régulier de par le nombre conséquent de requêtes qui est associé à la nature de ce protocole.
DNS ( Domain Naming System ) est un des protocoles clefs d'Internet, avec plusieurs grands protocoles de routage et notamment BGPv4 ( Border Gateway Protocol ). Il est également utilisé dans la majeure partie des réseaux locaux actuels avec, selon la topologie retenue, un ou plusieurs serveur(s) DNS interne(s).
Cet ancien protocole n'a pas été développé avec des contraintes fortes de sécurité, mais principalement des contraintes de performances. Le critère retenu étant à l'époque l'optimisation des performances qui ne devaient globalement pas dégrader le trafic en raison de la fréquence importante de ces requêtes.
DNS étant au centre de toutes les communications IP (comment Internet pourrait-il fonctionner aujourd’hui sans la résolution des noms ?), il représente un pilier des communications et est donc une cible de choix pour des attaquants désireux de détourner du trafic afin de l’écouter, le modifier, ou directement en injecter.
DNS, dans sa version originale - celle qui est encore actuellement la plus utilisée - comporte plusieurs failles intrinsèques qui ne peuvent être corrigées, à moins d'utiliser DNSSec ou combiner différentes couches de sécurité à plusieurs niveaux différents ( IPSec , etc.).
Il est cependant possible de limiter considérablement les risques en adaptant la topologie du réseau (Local Area Network, zone démilitarisée DMZ, etc.). Les DNS secondaires (mis à jour avec les fameux « transferts de zone ») peuvent également être la cible d’attaques visant un réseau particulier.
La majeure partie des transactions DNS s’effectue sur le port 53/UDP, hormis les requêtes de tailles trop importantes ou les transferts de zone qui transitent sur le port 53/TCP. Tout au long de cet article, les attaques et contre-mesures décrites concernent quasi-exclusivement les paquets UDP du trafic DNS.
DNSA (DNS Auditing tool) est un "couteau suisse" de la sécurité du point de vue de la résolution de noms. Il peut être utilisé conjointement avec un scanner de vulnérabilités pour identifier les différents serveurs DNS (primaires et secondaires), identifier les types et versions des serveurs, etc.
Des outils tels que DIG ( Domain Information Groper ), host, ou encore nslookup permettent d’interroger les serveurs DNS de façon interactive et ainsi récolter de nombreuses informations qui seront ensuite utiles au traitement avec DNSA.
2 Mises en évidence des failles DNS
Les failles DNS peuvent être exploitées par des attaques de type DNS ID Spoofing et des d’attaques conceptuelles intrinsèques au protocole DNS. Les attaques de ce dossier sont basées sur l'usurpation afin d'exécuter une élévation de privilèges, l’exemple d'attaque de Cache Poisoning concerne ici la corruption du champ « additional record ».
Les failles DNS abordées dans cet article sont toutes implémentées dans l’outil DNSA. Il s’agit, pour les attaques de DNS ID Spoofing, d’attaques conceptuelles intrinsèques au protocole DNS. Comme pour toutes les attaques dites de « Spoofing » ou usurpation, le but est de se faire passer pour un tiers afin d’obtenir des privilèges supplémentaires.
Dans toutes les attaques présentées ci-dessous, du « spoofing » est utilisé pour que la machine sur laquelle tourne DNSA passe pour le serveur DNS légitime interrogé. Pour l’attaque de Cache Poisoning (corruption de cache DNS ), celle retenue dans l’outil DNSA est la corruption du champ « additional record ».
2.1 Capture d’une requête DNS standard et inverse
root@linbox]\# tcpdump -i eth0 udp and port 53 tcpdump: listening on ath0 linbox.32783 > ns1.fai.fr.domain: 30679+ A? www.google.fr. (30) (DF) ns1.fai.fr.domain > linbox.32783: 30679 2/5/1 CNAME[|domain] (DF) ns1.fai.fr.domain > linbox.32784: 25190* 1/4/4 (224) (DF) linbox.32785 > ns1.fai.fr.domain: 30680+ PTR? 99.9.102.66.in-addr.arpa. (42) (DF)
Une requête DNS standard est une requête de type A. A est un nom d’hôte, CNAME un alias, MX un serveur de mail, etc… Il est également possible d’effectuer des requêtes inverses avec les enregistrements PTR afin de connaître le nom d’hôte d’une machine à partir de son IP.
2.2 DNS ID Spoofing
L’attaque de DNS ID Spoofing utilise principalement :
- Les faiblesses du protocole UDP qui n’assure aucune intégrité ou suivi des paquets. Des injections de trafic sont donc possibles sans disposer d’informations préalables ;
- La connaissance ou le faible aléa du DNS ID, seule information codée sur 16 bits, soit 65535 combinaisons possibles, permettant de reconnaître la réponse à une requête envoyée.
- Dans le cas d’un DNS ID connu (même brin Ethernet, compromission d’une DMZ, etc.), l’attaque par DNS ID Spoofing est triviale en utilisant l’information récupérée dans l’écoute du trafic DNS et forgeant ensuite la réponse telle qu’elle aurait été envoyée par le serveur légitime.
- Pour un DNS ID inconnu (cas typique d’Internet avec 2 clients distants par exemple), des attaques sont possibles en réduisant la fenêtre des DNS ID possibles dans le cas d’un faible aléa avec des attaques dites de prédiction. De telles attaques ont déjà été implémentées sur les numéros de séquence TCP (p0f l’outil de reconnaissance passive d’OS utilisant cette technique ) et peuvent être élargies au cas de DNS.
2.3 DNS ID d’une transaction DNS
Dans une attaque typique, en considérant que le DNS ID peut être récupéré par une écoute passive du trafic, le principe est simple :
- L'attaquant est à l’écoute des requêtes DNS
- Quand la requête à détourner est émise, il en extrait le DNS ID
- Il forge alors une réponse adéquate avec un paquet IP/UDP/DNS ayant le payload nécessaire, c'est-à-dire contenant l’IP source du serveur DNS légitime, l’IP destination du client qui avait émis la requête, le DNS ID récupéré ci-dessus, et les informations qu’il souhaite insérer.
Tous les « moteurs » de résolution de noms des systèmes d'exploitation actuels fonctionnent de la même façon : ils prennent en compte la première réponse à une requête effectuée puis ignorent les réponses suivantes. C’est le cas ici : DNSA répondant avant le serveur de noms légitime (car optimisé pour répondre très rapidement grâce aux fonctions de call-back de la libpcap), la requête du serveur légitime est alors ensuite ignorée.
2.4 Attaque de DNS ID Spoofing sur un serveur DNS
Puisqu’un serveur DNS peut se comporter comme un client quand il ne dispose pas de l’information en cache, celui-ci peut être détourné de la même façon qu’un client classique avec une attaque de DNS ID Spoofing. La condition nécessaire (et suffisante !) pour que l’attaque soit menée est d’être placé sur le même brin Ethernet que le serveur attaqué.
Plusieurs scénarios sont possibles (compromission d’une machine de la DMZ, d’un client du LAN…). Des exemples détaillés ont été présentés au Symposium 2005 sur la Sécurité des Technologies et des systèmes d’Information et de Communication...
2.5 DNS Cache poisoning
Quand un client interroge son serveur de noms, si celui-ci dispose de l’information en cache (« l’hôte www.hote.com est disponible à l’adresse IP x.x.x.x »), il lui répond directement. Dans le cas contraire, le serveur se comporte comme un client standard afin d’interroger le serveur DNS responsable du domaine.
Celui-ci lui répond alors avec l’information demandée, et peut s’il est configuré pour, inclure des enregistrements additionnels (additional records, ou addRR) afin d’éviter une surcharge de requêtes futures. Cette « option » a d’abord été intégrée sans vérification des domaines inscrits en enregistrements additionnels.
Un serveur pouvait donc répondre en incluant des addRR ne concernant pas le domaine pour lequel il répondait. Le détournement de flux est alors possible : un serveur contrôlé par un utilisateur malicieux pouvait, par exemple, renvoyer un enregistrement additionnel concernant le domaine microsoft.com et le faisant ainsi pointer vers la machine de son choix.
2.6 Payload d’un paquet DNS
Byte |---------------|---------------|---------------|---------------| 1 2 3 4 ID (cont) QR,OP,AA,TC,RD RA,0,AD,CD,CODE |---------------|---------------|---------------|---------------| 4 # Questions 5 (Cont) 6 # Answers 7 (Cont) |---------------|---------------|---------------|---------------| 8 # Authority 9 (Cont) 10 # Additional 11 (Cont) |---------------|---------------|---------------|---------------| Question Section |---------------|---------------|---------------|---------------| Answer Section |---------------|---------------|---------------|---------------| Authority Section |---------------|---------------|---------------|---------------| Additional Section Champ addRR |---------------|---------------|---------------|---------------|
Le payload d’un paquet DNS (ici après les en-têtes IP puis UDP) se compose de différents champs :
- Le transaction ID (DNS ID), champs de 2 octets.
- Différents « flags » (drapeaux) positionnés afin de définir le type de paquet DNS : requête, réponse, etc…
- Le nombre de « questions » posées.
- Le nombre de « réponses » données.
- Les questions
- Les réponses.
- Les serveurs de noms (NS pour Name Server) responsables de la zone.
- Le fameux champ additionnel dans lequel diverses informations complémentaires peuvent être fournies.
3 Installation et configuration de DNSA
dnsa-ng-0.6 utilise les librairies libnet-ng et libpcap qui devront être préalablement installées de préférence avec les versions de développement afin de disposer des fichiers d’en-tête les plus récents. Retrouvez également les explications et les détails sur le fonctionnement de bas niveau de l'outil DNSA (DNS Auditing Tool).
DNSA est disponible sur le site securitech.homeunix.org en archive au format tar.gz. Il utilise les librairies libnet ( libnet-ng dans ses versions récentes ) et libpcap, qui devront être installées préalablement.
Les détails de l'installation porteront sur la dernière version en date : dnsa-ng-0.6.
L'installation de la libpcap peut s'effectuer, sur la grande majorité des architectures/distributions, via les paquets (deb, rpm, ...).
Il faut cependant veiller à installer la version de développement (en général, selon les distributions, suffixée par « -dev » ou « -devel ») afin de disposer des fichiers d’en-tête, de l’aide, des pages « man », etc…
La libnet-ng - Libnet Next Generation - est disponible à l'adresse suivante http://www.security-labs.org/libnetng. Son installation s’effectue via les sources (archives tar.gz disponibles).
Pour une installation standard, la procédure est la suivante :
tar -zxvf ng-libnet-current.tar.gz cd libnet-ng ./configure make make install
Le "make install" est facultatif car le chemin vers le repertoire de la libnet-ng peut être spécifié en argument lors de l'installation de DNSA. DNSA requiert les droits superutilisateurs (root) pour fonctionner, il est donc conseillé d'installer la libnet-ng en incluant la phase du "make install".
En effet, il n’est pas possible à un utilisateur « normal » de forger des paquets et de les envoyer sur une interface de son choix, pas plus que d’écouter passivement le trafic capturé son par l’interface réseau.
L'installation de DNSA peut commencer :
tar -zxvf dnsa-ng-0.6.tar.gz cd dnsa-ng-0.6 cd sources ./configure
La verbosité et le mode "debug" sont accessibles en compilant DNSA avec les options --with-ldflags=-lefence et --enable-debug. Il est possible de fixer les chemin vers la libpcap ou la libnet-ng avec les arguments "--with-libnet=[CHEMIN]" et "--with-libpcap=[CHEMIN]"
make make install
3.1 Fichiers
DNSA est livré avec une documentation détaillée permettant de l'utiliser de façon optimale.
docs/ contient des articles relatifs aux failles DNS ainsi que des exemples d'utilisation.
sources/ contient l’ensemble des codes sources de DNSA et le binaire après compilation.
man/ est actuellement vide dans la dernière version
3.2 Fonctionnement « bas niveau »
DNSA peut être utilisé dans 3 modes différents :
- « DNS ID Spoofing » DNSA a été crée à l'origine pour mettre en évidence la simplicité d'attaques par DNS ID Spoofing. Ce mode est en général utilisé sur un même brin ethernet, même si des attaques complémentaires peuvent permettre des schémas très évolués.
- « DNS ID Sniffing » Ce mode permet principalement de faire des analyses statistiques sur les distributions de DNS ID selon les serveurs ou OS utilisés. En effet, si l'aléa des distributions de DNS ID étaient dépendantes des anciens serveurs, l'aléa est désormais pris en charge par le système d'exploitation sur lequel le serveur tourne. Un exemple basé sur gnuplot, logiciel de tracé opensource ( libre ), est décrit dans la documentation de DNSA. Des évolutions futures du logiciel intégreront différents tests statistiques basés sur des regressions linéaires multiples.
- « DNS cache poisoning » Ce mode est destiné aux serveurs faillibles à ces types d'attaques. Citons notamment d'anciens Bind, MS Windows, ou plus récemment des appliances propriétaires de pare-feux. Le principe est de répondre au serveur attaqué avec des additional records forgés contenant des informations relatives à des domaines différents de celui interrogé. Les contre-mesures à ce type d'attaques sont donc faciles à mettre en place. Bien heureusement, de moins en moins de serveurs sont vulnérables aux attaques de DNS cache poisoning.
La dernière version de DNSA supporte les attaques sur des réseaux sans fil, au travers de deux cartes 802.11. De nouveaux patches sur différents drivers ( madwifi notamment ), permettent l'écoute et l'injection simultanées. Le mode "WiFi" permet d'écouter le trafic DNS sur la première carte, et d'injecter les trames forgées grâce à la seconde. Le mode "ether" est le mode standard utilisant des filtres pcap afin de sélectionner le contenu approprié.
DNSA n’a pas de moteur d’événements. Il utilise les fonctions de call-back de la librairie lipcap : le principe est de déclencher, lors du passage de paquets spécifiques définis à l’aide des filtres pcap, une fonction contenant le payload du paquet capturé ainsi que différents autres arguments :
void callback_dnsspoof(u_char *args, const struct pcap_pkthdr *pkthdr, const u_char *packet)
{
(…)
}Les paquets sont forgés à l’aide de la libnet(-ng) et de ses constructeurs prédéfinis pour la majorités des protocoles connus.
4 Utilisation de DNSA
Description de l'exploitation, avec DNSA, des attaques présentées en partie 2 du dossier "DNS Auditing Tool". Les exemples d'exploitation avec DNSA sont disponibles en version Ethernet et en version WIFI.
4.1 Présentation générale
Usage: ./dnsa-ng [OPTIONS] DNS Swiss knife tool REQUIRED : -m [mode] where mode can be raw4 or link (depending of your network topology) REQUIRED : -t [media] where media can be 'wifi' or 'ether' * 'wifi' : needs 2 cards as describe in the documentation, needs the -I option to specify the interface which will inject packets * 'ether' : doesn't need further options) -1 DNS ID spoofing [ Required : -S ] -D [www.domain.org] Hostname query to fool. Don't use it if every DNS request sniffed has to be spoofed -S [IP] IP address to send for DNS queries -s [IP] IP address of the host to fool -i [interface] IP address to send for DNS queries -2 DNS IDs Sniffing [ Required : -s ] (Beta and not finished) -s [IP] IP address of the server which makes queries -w [file] Output file for DNS IDs -3 DNS cache poisoning [ Required : -S AND -a AND -b] -a [host.domain.org] Hostname to send in the additional record -b [IP] IP to send in the additional record -D [www.domain.org] Hostname for query. Use it if you want to fool just one -S [IP] IP address to send for DNS queries (the normal one) -s [IP] IP address of the server to fool -i [interface] IP address to send for DNS queries -h Print usage Bug reports to Pierre BETOUIN
4.2 Utilisation
Le mode « -1 » concerne les attaques par DNS ID Spoofing.
4.2.1 Utilisation Ethernet
./dnsa-ng -m [raw4 ou link] -1 -D [NOM DE DOMAINE OU DE MACHINE] -S IP_A_ENVOYER -s CLIENT_A_LEURRER -i INTERFACE -t ether
Les arguments « -S » et « -s » sont donc des filtres permettant d’affiner les restrictions des clients à attaquer. S’ils ne sont pas spécifiés, toutes les requêtes DNS seront concernées.
4.2.2 Utilisation WiFi
./dnsa-ng -m [raw4 ou link] -1 -D [NOM DE DOMAINE OU DE MACHINE] -S IP_A_ENVOYER -s CLIENT_A_LEURRER -i ath0 -t wifi -I wlan0
L’utilisation en WiFi est la même, à la spécification des interfaces près. Dans le mode WiFi, une interface capture le trafic brut et une autre se charge d’injecter le trafic. L’interface « -i » capture le trafic passivement tandis que l’interface « -I » injecte les paquets forgés. Le mode « -3 » concerne les attaques de DNS cache poisoning décrites plus haut, la commande générique de cette attaque est la suivante :
./dnsa-ng -t ether -m [raw4 ou link] -3 -D [HOTE RECHERCHE] -S [IP LEGITIME DE L’HOTE] -s [SERVEUR DNS EFFECUANT LA REQUETE] -a [ADDRR A AJOUTER] -b [IP DE L’ADDRR A AJOUTER] -i [INTERFACE]
L’exemple suivant concerne une requête effectuée sur le domaine pirate.org à la recherche du nom d’hôte « hacker » ayant pour IP 100.101.102.103. Le serveur DNS effectuant la recherche est le serveur 192.168.1.100. L’enregistrement additionnel concerne le FQDN www.microsoft.com en lui affectant l’IP 1.2.3.4. L’interface d’injection est la carte réseau eth0.
./dnsa-ng -t ether -m [raw4 or link] -3 -D hacker.pirate.org -S 100.101.102.103 –s 192.168.1.100 -a www.microsoft.com -b 1.2.3.4 -i eth0
Après corruption du cache DNS, nous pouvons constater que le serveur a mis en cache l’information forgée :
$ ping www.microsoft.com PING www.microsoft.com (1.2.3.4): 56 data bytes
5 Conclusion
DNS est un protocole sensible au détournement de trafic. Sa place, son trafic et la facilité de l'exploitation des attaques le concernant en font un élément essentiel dont le niveau de sécurisation peut être audité à l'aide de DNSA, les contres-mesures n'étant pas pour autant simples à mettre en place.
DNS est un protocole de choix pour des utilisateurs malicieux désirant détourner du trafic. Son utilisation abondante et la simplicité des attaques possibles en font un élément très sensible de l’infrastructure.
DNSA permet d’auditer le niveau de sécurité des échanges DNS avec une approche offensive telle qu’elle le serait dans le cas d’une réelle attaque.
Les contre-mesures ne sont cependant pas simples à mettre en œuvre : la plus répandue étant actuellement DNSSec qui utilise le chiffrement asymétrique pour garantir l’intégrité et l’authenticité des echanges.
DNSA peut également être couplé à d’autres outils tels qu’arp-sk pour contourner les switches ( ARP cache poisoning ), dsniff , ettercap , etc.
Les possibilités sont multiples. Un scénario très réaliste a été présenté à SSTIC 2005 avec la compromission totale d’une architecture classique (DMZ + LAN) à partir d’un serveur Web, jusqu’à l’ensemble des postes clients du LAN.
