ROOT‑ME · Défi : Service réseau

DNS — Transfert de zone

Catégorie : Service réseau — Points : 15 — Difficulté : ⭐ (1/5) — Auteur : g0uZ (20 mai 2013)
Rédigé par SPECTRA MZ — exploitation d’un transfert de zone AXFR ouvert.

ROOT‑ME DNS AXFR Transfert de zone dig / host

Sommaire

00Présentation & énoncé
01Vocabulaire DNS
02Théorie du transfert AXFR
03Reconnaissance avec dig
04Analyse de la zone
05Obtention du flag
06Remédiation

Phase 00

Présentation du challenge

📜 ÉNONCÉ OFFICIEL

Récupérer la clé secrète cachée dans la zone DNS du domaine ch11.challenge01.root-me.org, en exploitant un transfert de zone mal configuré.

Élément	Valeur
Challenge	DNS — Transfert de zone
Points	15
Catégorie	Service réseau
Auteur	g0uZ (20 mai 2013)
Difficulté	Facile (8% de réussite)
Hôte cible	`challenge01.root-me.org`
Protocole	DNS
Port	54011
Domaine	`ch11.challenge01.root-me.org`

Phase 01

Vocabulaire clé

DNS

Domain Name System — l’annuaire téléphonique d’Internet. Traduit les noms de domaine en adresses IP.

Zone DNS

Ensemble des enregistrements (SOA, NS, A, TXT, etc.) décrivant un domaine.

AXFR

Authoritative Transfer — requête TCP permettant de répliquer une zone complète entre serveurs DNS.

SOA

Start Of Authority — en-tête de la zone contenant le serial, le contact admin, et les paramètres de réplication.

TXT

Enregistrement texte libre — souvent utilisé pour SPF, vérifications de domaine, ou… des secrets !

allow-transfer

Directive BIND qui restreint les transferts de zone à une liste d’IP autorisées.

Phase 02

Théorie du transfert de zone (AXFR)

Principe

Ordinogramme — Transfert AXFR 1. Client envoie requête AXFR (TCP) → 2. Serveur DNS autoritaire → 3. Vérification de la directive allow-transfer → 4. Si ouverte → renvoie la zone complète → 5. Client récupère tous les enregistrements

Un transfert de zone (AXFR) est un mécanisme légitime de réplication entre serveurs DNS primaires et secondaires. Le serveur primaire envoie tous les enregistrements de la zone au secondaire. Si la directive allow-transfer est mal configurée et autorise 0.0.0.0/0 (tout le monde), alors n’importe quel client peut exfiltrer l’intégralité de la zone.

Pourquoi le transfert se fait en TCP ?

Une requête DNS classique utilise UDP (léger, sans connexion). Un AXFR peut être volumineux (potentiellement des milliers d’enregistrements). Il utilise donc TCP pour garantir la fiabilité et l’intégrité des données. C’est pourquoi les commandes dig et host basculent automatiquement en TCP pour un AXFR.

Phase 03

Reconnaissance avec `dig`

Première requête

Commande dig

spectrax@fedora:~$ dig @challenge01.root-me.org -p 54011 ch11.challenge01.root-me.org AXFR

Option	Rôle
`@challenge01.root-me.org`	Adresse du serveur DNS à interroger
`-p 54011`	Port non standard du challenge
`ch11.challenge01.root-me.org`	Zone à transférer
`AXFR`	Type de requête : transfert de zone complet

Résultat : le serveur répond sans restriction et renvoie la zone complète — 6 enregistrements. La vulnérabilité est confirmée.

Confirmation avec `host`

Commande host

spectrax@fedora:~$ host -T -p 54011 -t AXFR ch11.challenge01.root-me.org challenge01.root-me.org

-T : force le passage par TCP (obligatoire pour un AXFR).
-t AXFR : précise le type d’enregistrement demandé.
Le dernier argument est le serveur DNS.

Résultat identique : 6 réponses, status NOERROR → double vérification.

Phase 04

Analyse de la zone exfiltrée

Sortie de la requête AXFR

ch11.challenge01.root-me.org.  604800 IN SOA  ch11.challenge01.root-me.org. root.ch11.challenge01.root-me.org. 2 604800 86400 2419200 604800
ch11.challenge01.root-me.org.  604800 IN TXT  "DNS transfer secret key : CBkFRwfNMMtRjHY"
ch11.challenge01.root-me.org.  604800 IN NS   ch11.challenge01.root-me.org.
ch11.challenge01.root-me.org.  604800 IN A    127.0.0.1
challenge01.ch11.challenge01.root-me.org.  604800 IN A  192.168.27.101
ch11.challenge01.root-me.org.  604800 IN SOA  ch11.challenge01.root-me.org. root.ch11.challenge01.root-me.org. 2 604800 86400 2419200 604800

Les 6 enregistrements récupérés — le SOA est répété en fin de transfert (marqueur de fin AXFR).

Enregistrement	Valeur	Analyse
SOA	`serial 2, contact root@ch11...`	En‑tête de zone classique ; serial bas → zone jeune ou peu modifiée
TXT	`"DNS transfer secret key : CBkFRwfNMMtRjHY"`	💎 LE FLAG — la clé secrète stockée en clair
NS	`ch11.challenge01.root-me.org`	Le serveur est autoritaire pour sa propre zone
A	`127.0.0.1`	Le domaine pointe vers localhost (environnement isolé)
A	`192.168.27.101`	Sous‑domaine `challenge01` vers une IP privée — information d’énumération utile
SOA (répété)	`...`	Marqueur de fin de transfert imposé par la RFC 5936

Phase 05

🏁 Obtention du flag

Le flag est directement lisible dans l’enregistrement TXT :

Flag extrait

DNS transfer secret key : CBkFRwfNMMtRjHY

Flag final

CBkFRwfNMMtRjHY

La validation se fait en soumettant cette valeur sur la page du challenge Root‑Me.

Phase 06

Impact et remédiation

Impact réel

Un AXFR ouvert expose en production :

La cartographie complète du réseau interne (sous‑domaines, IP privées, serveurs) — facilitateur majeur pour la phase de reconnaissance d’un attaquant.
Les secrets stockés en TXT (clés API, jetons de vérification, mots de passe) — comme ici.
Les cibles prioritaires (serveurs MX, VPN, intranet, etc.) pour la suite de l’attaque.

Corrections à appliquer

Restreindre allow-transfer dans la configuration BIND aux seuls serveurs secondaires de confiance :
```
options {
    allow-transfer { 192.168.27.53; };  /* IP du secondaire légitime */
};
```
Utiliser TSIG (Transaction SIGnature, RFC 2845) : signer les transferts avec une clé partagée, pour que l’IP seule ne suffise pas.
Ne jamais stocker de secrets en enregistrements TXT — la zone DNS est lisible par quiconque peut la transférer (voire la requêter).
Auditer régulièrement ses zones : dig @ns1.mondomaine.com mondomaine.com AXFR depuis l’extérieur doit échouer.
Sur les serveurs publics, utiliser DNSSEC pour garantir l’intégrité et l’authenticité des réponses.