[DNS Auditing Tool – Partie 2] Mises en évidence des failles DNS

Par Rédaction, secuobs.com
Le 19/12/2007

---

Résumé : 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 ». - Lire l'article



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 ».


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.


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 - lien ) et peuvent être élargies au cas de DNS.


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.


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 ( lien )..

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.


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.


Autres ressources dans ce dossier :

[DNS Auditing Tool – Partie 1] Introduction à la sécurité du protocole DNS – lien

[DNS Auditing Tool – Partie 3] Installation et configuration de DNSA – lien

[DNS Auditing Tool – Partie 4] Utilisation de DNSA – lien

[DNS Auditing Tool – Partie 5] Conclusion et webographie – lien