Subdomain takeover
Le subdomain takeover consiste à revendiquer un service cloud désaffecté vers lequel pointe encore un DNS, pour publier du contenu sous le domaine de la victime.
Le subdomain takeover, ou prise de contrôle de sous-domaine, exploite un décalage banal entre le DNS et la réalité. Une entreprise crée un enregistrement CNAME, disons blog.exemple.fr, vers un service hébergé, GitHub Pages, Azure, un CDN ; le service est un jour résilié, mais l'enregistrement DNS, lui, reste en place. N'importe qui peut alors revendiquer la ressource abandonnée chez l'hébergeur et servir son propre contenu sous blog.exemple.fr, avec la légitimité du domaine de la victime.
Les conséquences dépassent la défiguration. Le contenu hostile hérite de la confiance du domaine : hameçonnage crédible au possible, vol de cookies si leur portée couvre les sous-domaines, contournement de politiques de sécurité fondées sur l'origine. Et la vulnérabilité est activement recherchée, car sa détection s'automatise très bien : les enregistrements DNS pendants se repèrent à grande échelle.
La défense tient en une discipline : inventorier ses enregistrements DNS et supprimer ceux qui pointent vers des services fermés, dès la résiliation. Notre article sur le subdomain takeover détaille les signatures par hébergeur, et la surveillance de la surface d'attaque détecte ces enregistrements pendants avant qu'un attaquant ne les réclame.
Reconnaître un enregistrement pendant
La signature est presque toujours la même. Un CNAME résout vers un domaine de service, une adresse en github.io, un point d'entrée cloud ou un CDN, et ce service répond par une page d'erreur générique du type "aucun site n'est configuré à cette adresse". Ce message diffère d'un hébergeur à l'autre, et c'est précisément ce qui permet d'automatiser la détection à grande échelle. Attention au faux positif : certaines erreurs correspondent à une ressource bien réservée mais mal configurée, auquel cas la revendication échouera. La vérification finale se fait toujours au cas par cas, avant de conclure quoi que ce soit dans un rapport.
La prévention tient à l'ordre des opérations
La faille naît d'une résiliation faite dans le mauvais sens : on ferme le service, on oublie le DNS. La règle inverse ne coûte rien. On supprime d'abord l'enregistrement, on attend l'expiration du TTL, puis on libère la ressource chez l'hébergeur. Le reste est une question de gouvernance de zone : qui a le droit d'y créer un enregistrement, et qui vérifie que chaque entrée pointe encore vers quelque chose de vivant. La surveillance continue de la surface d'attaque fait ce contrôle sans intervention, et notre article sur le subdomain takeover détaille les signatures par hébergeur.
Questions fréquentes
Un sous-domaine sans enregistrement est-il vulnérable ?
Non, un nom qui ne résout pas ne mène nulle part. Le risque naît de l'enregistrement qui subsiste et pointe vers une ressource libérée chez un hébergeur tiers, que n'importe qui peut alors réserver à son nom.
Quel est l'impact réel d'un subdomain takeover ?
Il dépasse la défiguration. Le contenu hostile hérite de la confiance du domaine : hameçonnage très crédible, vol de cookies si leur portée couvre les sous-domaines, contournement de politiques de sécurité fondées sur l'origine, et parfois obtention d'un certificat valide au nom de la victime.
Les enregistrements NS sont-ils concernés ?
Oui, et c'est le cas le plus grave. Une délégation vers une zone qui n'existe plus chez le prestataire DNS permet à celui qui la recrée de contrôler l'ensemble des noms du sous-domaine délégué, pas seulement une page.