Subdomain takeover : comment ça arrive et comment l'éviter

Un subdomain takeover (prise de contrôle d'un sous-domaine) se produit quand un enregistrement DNS de votre zone pointe encore vers une ressource externe que vous ne contrôlez plus, et que quelqu'un d'autre s'approprie cette ressource. Le cas typique : shop.example.com est un CNAME vers une plateforme hébergée, la boutique a été résiliée, l'enregistrement est resté. Si la plateforme laisse n'importe qui enregistrer le nom libéré sans prouver le contrôle du domaine, un attaquant le fait et sert son contenu sur votre sous-domaine, avec un certificat valide. Le remède est ennuyeux et efficace : savoir quels enregistrements pointent hors de votre infrastructure, et supprimer l'enregistrement DNS avant de supprimer ce vers quoi il pointe. Ce guide couvre les variantes, l'impact, la détection avec dig et curl, et une liste de contrôle de prévention.

Comment fonctionne une prise de contrôle

Rien n'est piraté au sens habituel. Votre DNS déclare, avec votre autorité, « ce nom est servi là-bas », et « là-bas » est un espace de noms partagé avec tous les autres clients d'un fournisseur. La séquence :

Vous créez une ressource chez un fournisseur cloud ou SaaS (un espace de stockage, une application sur une plateforme, un site de support ou une page d'atterrissage) et vous faites pointer un sous-domaine vers elle avec un CNAME.
Plus tard, la ressource est supprimée : projet terminé, abonnement résilié, compte fermé.
Le CNAME reste dans la zone. Personne n'en est responsable, rien ne le rappelle à personne. C'est un enregistrement orphelin (dangling record).
Le fournisseur remet l'ancien nom de ressource à disposition et ne vérifie pas qui contrôle le domaine qui pointe vers lui.
Un attaquant enregistre ce nom. À partir de cet instant, votre sous-domaine livre le contenu de l'attaquant.

Que l'étape 4 soit possible dépend du fournisseur. Beaucoup exigent désormais un enregistrement TXT de vérification ou réservent les noms libérés, mais on connaît rarement la politique de chaque service jamais relié à son domaine.

Les variantes

Enregistrement orphelin	Ce dont l'attaquant a besoin	Ce qu'il obtient
CNAME vers une ressource cloud/SaaS supprimée	Réclamer le même nom de ressource chez le fournisseur	Du contenu web sur le sous-domaine
CNAME vers un hôte dont le domaine a expiré	Enregistrer ce domaine	Tout ce qui se trouve sous cette cible CNAME
Délégation NS d'une sous-zone vers un fournisseur DNS où la zone a été supprimée, ou vers des serveurs de noms sous un domaine expiré	Créer la zone chez ce fournisseur, ou enregistrer le domaine du serveur de noms	Le contrôle total de la sous-zone : chaque type d'enregistrement, chaque nom en dessous. Le pire cas
Enregistrement A vers une adresse IP cloud libérée	Se voir attribuer la même adresse IP : une affaire de chance et de répétition	Du contenu web ; opportuniste plutôt que ciblé
Enregistrement MX vers un service de messagerie décommissionné	Réclamer le domaine chez ce service de messagerie	Le courrier entrant du sous-domaine

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

Un sous-domaine de votre domaine hérite d'une confiance qu'un domaine imitant le vôtre n'obtient jamais :

De l'hameçonnage sous votre vrai nom. login-help.example.com passe toutes les formations « vérifiez la barre d'adresse ».
Les cookies. Les cookies posés avec Domain=example.com sont envoyés par le navigateur à chaque sous-domaine, y compris celui que l'attaquant exploite désormais. Selon les attributs, cela peut inclure les cookies de session.
Les listes d'autorisation qui font confiance à *.example.com. Configurations CORS, sources de Content Security Policy, URI de redirection OAuth et réglages d'authentification unique font souvent confiance au domaine entier. Un sous-domaine pris est à l'intérieur de cette confiance.
Des certificats reconnus publiquement. Quiconque contrôle le contenu d'un nom d'hôte peut réussir une validation de domaine par HTTP et obtenir un certificat valide pour ce nom.
Le courrier. Avec un MX orphelin, le courrier adressé au sous-domaine est livré à l'attaquant, y compris les réinitialisations de mot de passe des comptes créés avec ces adresses.

Comment trouver les enregistrements orphelins

Partez de votre zone, pas de l'extérieur (les types d'enregistrements sont expliqués dans les types d'enregistrements DNS). Exportez chaque zone que vous possédez et listez les enregistrements dont la cible n'est pas votre propre infrastructure : CNAME vers d'autres domaines, délégations NS, enregistrements MX, et enregistrements A/AAAA dans des plages d'adresses de fournisseurs cloud.

Puis testez chacun d'eux.

Les CNAME. Résolvez la cible. Une cible qui n'existe pas est le signe le plus clair :

$ dig +short CNAME shop.example.com
promo-example.cloudhost.example.

$ dig promo-example.cloudhost.example
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4711

NXDOMAIN pour la cible signifie que l'enregistrement ne pointe vers rien. Si la cible se résout (beaucoup de plateformes répondent pour n'importe quel nom grâce à un joker), regardez la réponse HTTP :

$ curl -sI https://shop.example.com | head -n 1
HTTP/2 404

Une page générique du fournisseur, « site inexistant », « bucket inexistant » ou « il n'y a encore rien ici », sur votre sous-domaine signifie que la ressource derrière a disparu. Vérifiez aussi que le domaine de chaque cible CNAME est toujours enregistré et appartient bien au fournisseur attendu.

Les délégations NS. Demandez directement à chaque serveur de noms délégué, sans récursion, s'il fait autorité pour la sous-zone :

$ dig +short NS sub.example.com
ns1.dns-host.example.
ns2.dns-host.example.

$ dig @ns1.dns-host.example sub.example.com SOA +norec
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1289

REFUSED, SERVFAIL ou une réponse sans le drapeau aa signifie que ce serveur ne détient pas votre zone. Une absence totale de réponse peut être un problème réseau : répétez le test avant de conclure.

Les noms que vous avez oubliés. L'export de zone trouve des enregistrements ; il ne trouve pas les zones dont vous avez oublié l'existence, ni les noms créés par une autre équipe chez un autre fournisseur DNS. Les journaux de Certificate Transparency aident ici : chaque certificat reconnu publiquement y est consigné, ils révèlent donc les noms d'hôte qui ont un jour obtenu un certificat. Ils révèlent aussi les certificats que vous n'avez pas demandés, ce qui est la trace que laisse une prise de contrôle.

Prévention

L'ordre des opérations. Cette seule règle évite la plupart des cas :

Décommissionnement : supprimez d'abord l'enregistrement DNS, attendez la fin du TTL, puis supprimez la ressource.
Mise en service : créez et vérifiez d'abord la ressource, ajoutez l'enregistrement DNS en dernier.

Donnez un responsable à chaque enregistrement. Faites passer les changements DNS par une revue, idéalement sous forme d'infrastructure as code dans le même dépôt que la ressource vers laquelle ils pointent, pour que supprimer la ressource et supprimer l'enregistrement soient une seule et même modification.

Choisissez des fournisseurs qui vérifient les domaines. Un fournisseur qui exige un enregistrement TXT de vérification de domaine avant de servir un domaine personnalisé ne peut pas être utilisé pour cette attaque par un inconnu.

Évitez les CNAME à joker vers des tiers. *.example.com CNAME something.provider.example fait de chaque nom possible un candidat.

Limitez ce qu'un sous-domaine peut faire. Utilisez des cookies limités à l'hôte (sans attribut Domain) pour les sessions. Listez des origines exactes dans les listes d'autorisation CORS, CSP et de redirection OAuth, plutôt que *.example.com.

Sachez ce que CAA fait et ne fait pas. Un enregistrement CAA restreint quelles autorités de certification peuvent émettre pour vos noms. Il n'empêche pas une prise de contrôle : l'attaquant utilise simplement une AC que vous autorisez. Surveiller la Certificate Transparency pour repérer les certificats que personne chez vous n'a demandés est le complément utile. Détails dans les enregistrements CAA expliqués.

Liste de contrôle

Toutes les zones chez tous les fournisseurs DNS sont connues et exportées.
Chaque enregistrement CNAME, NS, MX et A/AAAA vers une IP cloud a un responsable nommé et une raison d'être.
Chaque cible CNAME externe se résout, et son domaine est enregistré au nom du fournisseur attendu.
Chaque sous-zone déléguée reçoit une réponse faisant autorité de tous ses serveurs de noms.
La procédure de décommissionnement dit : enregistrement DNS d'abord, ressource ensuite.
Aucun CNAME à joker ne pointe vers un tiers.
Les cookies de session sont limités à l'hôte ; les listes d'autorisation nomment des hôtes exacts.
Les journaux CT sont passés en revue à la recherche de noms d'hôte inconnus et de certificats inattendus.

Si vous en trouvez un

Supprimez immédiatement l'enregistrement orphelin (ou, si le service est encore nécessaire, recréez d'abord la ressource dans votre propre compte). Supprimer l'enregistrement met fin à l'exposition dès que les caches expirent.
Déterminez s'il a déjà été réclamé. Que sert le sous-domaine en ce moment ?
Si c'est le cas : considérez les cookies portant sur le domaine parent comme exposés, et invalidez les sessions. Vérifiez les listes d'autorisation qui incluaient le sous-domaine.
Passez en revue les journaux CT à la recherche de certificats émis pour ce nom pendant l'exposition, et demandez à l'AC émettrice de révoquer ceux que vous n'avez pas demandés.
Corrigez le processus qui a laissé l'enregistrement derrière lui, puis auditez le reste de la zone : les enregistrements orphelins viennent rarement seuls.

Éthique et droit

Ne testez que les domaines dont vous êtes responsable ou que vous êtes autorisé par écrit à évaluer. Consulter le DNS public est inoffensif. Réclamer la ressource derrière l'enregistrement orphelin de quelqu'un d'autre est un acte différent : vous serviriez du contenu sous son nom, et recevriez peut-être les cookies ou le courrier de ses utilisateurs. C'est un accès non autorisé, même avec une page de « preuve » inoffensive et de bonnes intentions. Si vous remarquez un enregistrement orphelin sur un domaine qui n'est pas le vôtre, signalez-le au propriétaire par le contact de son fichier security.txt (le vérificateur security.txt montre s'il en publie un) et arrêtez-vous là.

Erreurs fréquentes

Supprimer d'abord la ressource cloud et « nettoyer le DNS plus tard ».
N'auditer que la zone principale et oublier les sous-zones déléguées.
Faire confiance à *.example.com dans les réglages CORS, CSP ou OAuth.
Croire qu'un enregistrement CAA empêche les prises de contrôle.

Vérifiez avec OrbitProbe

Le chercheur de sous-domaines d'OrbitProbe liste les noms d'hôte sous un domaine qui apparaissent dans les journaux publics de Certificate Transparency, avec la date du certificat le plus récent pour chacun. C'est un relevé de certificats, pas du DNS : un nom listé peut ne plus exister, et un nom qui n'a jamais utilisé qu'un certificat à joker en sera absent, si bien qu'il complète l'export de zone sans le remplacer. Utilisez-le sur les domaines dont vous êtes responsable pour repérer les hôtes oubliés et les certificats que personne ne se souvient d'avoir commandés, puis poursuivez chaque nom inconnu par une requête DNS pour voir vers quoi il pointe aujourd'hui.