Subdomain takeover : le danger des sous-domaines oubliés

Un sous-domaine créé pour une campagne, une documentation ou une préproduction, puis oublié : c'est la porte d'entrée d'une attaque discrète et redoutable, le subdomain takeover (prise de contrôle de sous-domaine). L'attaquant ne pirate ni votre serveur ni votre registrar. Il récupère simplement une ressource que vous avez abandonnée chez un fournisseur tiers, et votre propre DNS se charge de lui envoyer vos visiteurs. Voici comment cela fonctionne, comment le vérifier vous-même avec dig, et comment corriger puis surveiller.

Qu'est-ce qu'un subdomain takeover ?

La plupart des services en ligne (hébergement de fichiers statiques, plateformes d'applications, outils de documentation, boutiques hébergées) vous demandent de faire pointer un sous-domaine vers eux, en général avec un enregistrement CNAME. Par exemple :

docs.exemple.fr.   3600   IN   CNAME   agence-exemple.github.io.

Le jour où le projet s'arrête, on supprime la ressource chez le fournisseur (le dépôt, le bucket, l'application), mais on oublie l'enregistrement DNS. On parle alors d'enregistrement DNS pendant (dangling DNS). Si le fournisseur permet à n'importe quel client de créer une ressource portant le même nom, ou de revendiquer le même nom de domaine personnalisé, un attaquant peut le faire. À partir de là, docs.exemple.fr affiche le contenu de son choix.

Pourquoi c'est plus grave qu'une simple page défigurée

• Hameçonnage crédible : une fausse page de connexion hébergée sur un vrai sous-domaine de votre marque, avec un certificat HTTPS valide que l'attaquant peut obtenir puisqu'il contrôle le contenu servi.
• Vol de cookies : les cookies posés pour .exemple.fr sont envoyés à tous les sous-domaines, y compris celui qui a été détourné.
• Contournement de politiques de sécurité : listes blanches CORS, Content-Security-Policy ou URL de redirection OAuth qui autorisent *.exemple.fr.
• Atteinte au référencement : pages de spam indexées sous votre nom de domaine.

Un scénario type : le bucket S3 d'une campagne terminée

Prenons un cas fictif mais très représentatif. Une agence héberge une page de jeu-concours sur Amazon S3 en mode site statique. Pour utiliser un sous-domaine personnalisé, le bucket doit porter exactement le nom du sous-domaine :

jeu.client.fr.   300   IN   CNAME   jeu.client.fr.s3-website.eu-west-3.amazonaws.com.

Trois mois plus tard, la campagne est finie. Un développeur supprime le bucket pour réduire la facture. Personne ne touche au DNS du client, que l'agence ne gère d'ailleurs pas directement. En visitant http://jeu.client.fr, on obtient une erreur S3 :

404 Not Found
Code: NoSuchBucket
Message: The specified bucket does not exist

Les noms de buckets S3 sont uniques au niveau mondial, mais ils redeviennent disponibles une fois supprimés. N'importe qui peut donc créer un bucket nommé jeu.client.fr dans la même région, sur son propre compte AWS, et y déposer une page. Le CNAME du client fait le reste.

Les variantes les plus courantes

• GitHub Pages : le sous-domaine pointe vers quelquun.github.io, mais le dépôt ou la configuration du domaine personnalisé a disparu. La page affiche « There isn't a GitHub Pages site here. » GitHub propose une vérification de domaine qui empêche un autre compte de revendiquer vos sous-domaines ; activez-la.
• Heroku : l'application supprimée affiche « No such app ». L'exploitation dépend de conditions particulières.
• Cible qui ne résout plus : un CNAME vers monapp.azurewebsites.net ou monapp.cloudapp.net dont le nom a été libéré répond NXDOMAIN. Si le fournisseur réattribue ce nom au premier qui le demande, le sous-domaine est récupérable.
• Délégation NS orpheline : un sous-domaine délégué (labo.client.fr NS ns-123.awsdns-45.com) vers une zone supprimée chez l'hébergeur DNS. Selon le fournisseur, un attaquant peut recréer la zone et contrôler tout le sous-domaine, enregistrements MX compris.
• CNAME ou MX vers un domaine expiré : la cible est un nom de domaine tiers qui n'a pas été renouvelé. Il suffit de le racheter.

Quels services sont réellement vulnérables ?

Tous les fournisseurs ne se valent pas : certains exigent une preuve de propriété du domaine avant de l'associer à un compte, d'autres non. Le projet communautaire can-i-take-over-xyz, maintenu sur GitHub, recense les services, leur statut et l'« empreinte » à rechercher dans la réponse HTTP. Voici un extrait de ses classements au moment où nous écrivons ces lignes :

Ces statuts évoluent à mesure que les fournisseurs renforcent leurs contrôles : consultez la liste à jour avant de conclure. Et un statut « non vulnérable » ne justifie pas de garder un enregistrement qui pointe dans le vide.

Vérifier manuellement ses sous-domaines avec dig

Étape 1 : établir la liste des sous-domaines

Vous ne pouvez pas vérifier ce que vous ne connaissez pas. Trois sources complémentaires :

1. L'export de la zone DNS chez votre hébergeur DNS : c'est la source la plus fiable.
2. Les journaux Certificate Transparency : tout certificat public émis pour un sous-domaine y est enregistré. Une recherche sur https://crt.sh/?q=%25.client.fr fait souvent ressurgir des noms oubliés.
3. La documentation des projets passés : devis, tickets, fichiers de configuration.

Nous avons détaillé pourquoi cet inventaire compte dans l'article Pourquoi surveiller vos sous-domaines est aussi important que votre domaine principal.

Étape 2 : repérer les CNAME vers des services tiers

dig +short CNAME jeu.client.fr
jeu.client.fr.s3-website.eu-west-3.amazonaws.com.

Pour traiter une liste entière :

while read sub; do
  cible=$(dig +short CNAME "$sub")
  [ -n "$cible" ] && echo "$sub -> $cible"
done < sous-domaines.txt

Étape 3 : tester si la cible existe encore

Regardez le statut de la réponse complète :

dig jeu.client.fr A

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41872
;; ANSWER SECTION:
jeu.client.fr.  300  IN  CNAME  ancienne-app.azurewebsites.net.

Un NXDOMAIN accompagné d'un CNAME signifie que votre enregistrement existe, mais que sa cible n'existe plus : c'est un signal d'alerte fort.

Étape 4 : chercher l'empreinte HTTP

Si la cible résout encore, interrogez le service et cherchez l'empreinte correspondante :

curl -s http://jeu.client.fr | grep -i -E "NoSuchBucket|No such app|There isn't a GitHub Pages site"

Étape 5 : contrôler les délégations et les domaines cibles

Pour une délégation de sous-domaine, interrogez directement les serveurs délégués :

dig +short NS labo.client.fr
dig @ns-123.awsdns-45.com labo.client.fr SOA

Une réponse REFUSED ou SERVFAIL indique que la zone n'existe plus chez ce fournisseur. Pour un CNAME ou un MX pointant vers un domaine tiers, vérifiez que ce domaine est toujours enregistré, via notre outil WHOIS ou une requête RDAP.

Corriger un sous-domaine vulnérable

1. Supprimez l'enregistrement DNS en premier, avant de supprimer la ressource chez le fournisseur. C'est l'ordre à inscrire dans toutes vos procédures de décommissionnement.
2. Si le sous-domaine doit continuer à exister, recréez immédiatement la ressource à votre nom (bucket, application, dépôt) pour la « réoccuper », puis faites pointer le sous-domaine vers une destination maîtrisée.
3. Vérifiez s'il a déjà été détourné : consultez le contenu servi et recherchez dans les journaux Certificate Transparency des certificats récents émis pour ce sous-domaine par une autorité que vous n'utilisez pas.
4. Activez la vérification de domaine chez les fournisseurs qui la proposent (enregistrement TXT de preuve de propriété, domaines vérifiés GitHub).
5. Réduisez la portée des cookies : un cookie de session posé sur www.exemple.fr plutôt que sur .exemple.fr limite l'impact d'un détournement.
6. Nettoyez les jokers dans vos politiques CORS et CSP : listez des sous-domaines précis plutôt que *.exemple.fr.

Checklist de prévention

• Chaque sous-domaine a un responsable et une raison d'exister, documentés.
• La procédure de fin de projet commence par la suppression des enregistrements DNS.
• Les zones DNS sont relues au moins à chaque départ d'un prestataire ou d'un collaborateur.
• Les CNAME vers des domaines tiers sont listés, et l'expiration de ces domaines est connue.
• Les délégations NS de sous-domaines sont vérifiées régulièrement.
• Les nouveaux certificats émis pour vos domaines sont suivis dans les journaux CT.

Surveiller en continu plutôt qu'une fois par an

Un audit ponctuel ne suffit pas : un sous-domaine devient vulnérable le jour où quelqu'un supprime une ressource, pas le jour de l'audit. La vérification doit être répétée automatiquement, sur une liste de sous-domaines elle-même tenue à jour.

C'est ce que fait Domains Defender sur les plans Pro et Enterprise : la détection de subdomain takeover analyse vos sous-domaines surveillés et ceux découverts dans les journaux Certificate Transparency. Elle repère les CNAME vers des ressources supprimées (empreintes HTTP inspirées de can-i-take-over-xyz), les cibles en NXDOMAIN, les délégations NS orphelines et les CNAME ou MX pointant vers des domaines expirés, puis vous alerte avec la preuve observée.

Pour commencer tout de suite, passez vos sous-domaines un par un dans notre outil DNS Lookup gratuit : repérez chaque CNAME qui pointe vers un service tiers et vérifiez que la ressource correspondante vous appartient toujours. C'est le meilleur quart d'heure de sécurité que vous passerez cette semaine.