DNS Zone Transfers

Les transferts de zone DNS (DNS Zone Transfers) représentent une technique parfois sous-estimée mais très puissante lors d'une phase de reconnaissance web. Bien qu'ils soient conçus pour assurer la redondance et la cohérence des enregistrements DNS entre serveurs, une mauvaise configuration peut transformer cette fonctionnalité en véritable mine d'or pour un attaquant.

❔ Qu'est-ce qu'un transfert de zone DNS ?

Un transfert de zone est le processus par lequel un serveur DNS secondaire copie l'intégralité des enregistrements DNS d'un domaine à partir d'un serveur principal. Cela inclut les sous-domaines, adresses IP, enregistrements MX, etc. Ce processus est nécessaire pour :

  • Garantir la résilience du service DNS,

  • Assurer une cohérence des données DNS entre plusieurs serveurs,

  • Permettre une résolution rapide et fiable pour les utilisateurs finaux.

Mais s'il est mal configuré, tout utilisateur externe pourrait effectuer cette requête et recevoir une copie complète de la zone DNS, ce qui révèle des informations potentiellement sensibles.

🚫 Le risque des transferts non sécurisés

Historiquement, les serveurs DNS acceptaient les transferts de zone (à l'aide du type de requête AXFR) de n'importe qui. Aujourd'hui, cette pratique est considérée comme une faille de configuration majeure. Les informations qu'un attaquant peut collecter via un transfert de zone comprennent :

  • Une liste exhaustive des sous-domaines : services internes, interfaces d'administration, environnements de test...

  • Les adresses IP associées à chaque sous-domaine,

  • Les enregistrements MX révélant les serveurs mail internes,

  • Les serveurs NS (name server), fournissant des indices sur le prestataire DNS ou les infrastructures réseaux internes.

🔐 Méthode d'exploitation avec dig

Le transfert de zone peut être testé avec une simple commande dig. Voici un exemple contre un domaine volontairement vulnérable mis en place à des fins de démonstration :

0xH4shDumb@htb[/htb]$ dig axfr @nsztm1.digi.ninja zonetransfer.me

Sortie simplifiée :

zonetransfer.me.     7200    IN  SOA nsztm1.digi.ninja. robin.digi.ninja. 2019100801 172800 900 1209600 3600
zonetransfer.me.     300     IN  TXT "google-site-verification=..."
zonetransfer.me.     7200    IN  MX  0 ASPMX.L.GOOGLE.COM.
www.zonetransfer.me. 7200    IN  A   5.196.105.14
canberra-office.zonetransfer.me. 7200 IN A 202.14.81.230
...
;; XFR size: 50 records (messages 1, bytes 2085)

Ce résultat révèle de nombreux sous-domaines, leur correspondance IP, des enregistrements TXT, MX, PTR, etc. — l'ensemble des informations contenues dans la zone !

⚠️ Bonnes pratiques et mitigation

Pour se prémunir contre ces risques :

  • Restreindre les transferts de zone aux IP explicitement autorisées (serveurs secondaires légitimes).

  • Configurer les serveurs DNS pour refuser toute requête AXFR externe par défaut.

  • Utiliser des outils de supervision pour détecter toute tentative de transfert non autorisé.

🌐 En résumé

Les transferts de zone DNS sont un outil d'administration essentiel mais potentiellement dangereux en cas de mauvaise configuration. Pour un testeur d'intrusion, ils représentent un véritable raccourci vers une cartographie complète de la cible. C'est pourquoi ils doivent toujours être testés durant la phase de reconnaissance DNS, à condition d'être dans le cadre d'une mission autorisée.

After performing a zone transfer for the domain inlanefreight.htb on the target system, how many DNS records are retrieved from the target system's name server? Provide your answer as an integer, e.g, 123

Nous ajoutons dans un premier temps l'adresse IP fournie dans le fichier /etc/hosts associée au nom de domaine de la question : 

10.129.78.242 inlanefreight.htb

Utilisation de dig : 

$ dig axfr @10.129.78.242 inlanefreight.htb

inlanefreight.htb.	604800	IN	SOA	inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800
inlanefreight.htb.	604800	IN	NS	ns.inlanefreight.htb.
admin.inlanefreight.htb. 604800	IN	A	10.10.34.2
ftp.admin.inlanefreight.htb. 604800 IN	A	10.10.34.2
careers.inlanefreight.htb. 604800 IN	A	10.10.34.50
dc1.inlanefreight.htb.	604800	IN	A	10.10.34.16
dc2.inlanefreight.htb.	604800	IN	A	10.10.34.11
internal.inlanefreight.htb. 604800 IN	A	127.0.0.1
admin.internal.inlanefreight.htb. 604800 IN A	10.10.1.11
wsus.internal.inlanefreight.htb. 604800	IN A	10.10.1.240
ir.inlanefreight.htb.	604800	IN	A	10.10.45.5
dev.ir.inlanefreight.htb. 604800 IN	A	10.10.45.6
ns.inlanefreight.htb.	604800	IN	A	127.0.0.1
resources.inlanefreight.htb. 604800 IN	A	10.10.34.100
securemessaging.inlanefreight.htb. 604800 IN A	10.10.34.52
test1.inlanefreight.htb. 604800	IN	A	10.10.34.101
us.inlanefreight.htb.	604800	IN	A	10.10.200.5
cluster14.us.inlanefreight.htb.	604800 IN A	10.10.200.14
messagecenter.us.inlanefreight.htb. 604800 IN A	10.10.200.10
ww02.inlanefreight.htb.	604800	IN	A	10.10.34.112
www1.inlanefreight.htb.	604800	IN	A	10.10.34.111
inlanefreight.htb.	604800	IN	SOA	inlanefreight.htb. root.inlanefreight.htb. 2 604800 86400 2419200 604800

Nous pouvons alors observer que 22 records DNS sont présents.

Within the zone record transferred above, find the ip address for ftp.admin.inlanefreight.htb. Respond only with the IP address, eg 127.0.0.1

Grâce à la commande précédente, nous pouvons observer l'IP de ftp.admin.inlanefreight.htb : 10.10.34.2.

Within the same zone record, identify the largest IP address allocated within the 10.10.200 IP range. Respond with the full IP address, eg 10.10.200.1

Une nouvelle fois, la commande de la première question nous permet de relevée l'adresse IP la plus élevée présente dans le scope 10.10.200.x : 10.10.200.14 (associé à cluster14.us.inlanefreight.htb).

PrécédentSubdomain BruteforcingSuivantVirtual Hosts

Mis à jour