Un sous-domaine oublié est rarement vide. Quand une entreprise arrête d’utiliser GitHub Pages, Heroku, S3 ou un service équivalent sans supprimer l’enregistrement DNS qui pointait dessus, elle laisse une porte ouverte derrière elle. Le principe du subdomain takeover tient en une phrase : un enregistrement CNAME pointe vers une ressource cloud qui n’existe plus, et n’importe qui peut recréer cette ressource à l’identique pour récupérer le sous-domaine.
Pourquoi ça marche
La plupart des hébergeurs cloud valident la propriété d’un nom de domaine en vérifiant simplement qu’un CNAME pointe vers leur service. Ils ne vérifient pas qui a créé ce CNAME, ni quand. Si demo.exemple.com pointe vers exemple.github.io et que ce dépôt GitHub Pages a été supprimé, il suffit à un attaquant de créer un nouveau dépôt du même nom sur son propre compte GitHub pour que demo.exemple.com serve son contenu à lui, avec un certificat TLS valide signé pour le domaine de la victime.
Ce n’est pas un scénario théorique. Le projet Can I take over XYZ recense plus d’une soixantaine de services cloud vulnérables à ce pattern, et HackerOne publie régulièrement des rapports de ce type dans son Hacktivity.
Ce que ça permet à un attaquant
Une fois le sous-domaine récupéré, les usages malveillants sont nombreux : phishing sous un nom de domaine de confiance, contournement de règles de Content Security Policy qui autorisaient ce sous-domaine, vol de cookies si le sous-domaine partage le même domaine parent qu’une application sensible, ou simple atteinte à la réputation si le contenu affiché est désobligeant. Le détail technique précis dépend du service concerné, mais le résultat est toujours le même : un domaine qui appartient à l’entreprise sert du contenu qu’elle ne contrôle plus.
Pourquoi c’est difficile à détecter soi-même
Le problème ne vient presque jamais d’une négligence ponctuelle. Il s’accumule avec le temps : un stagiaire qui monte une démo sur Heroku, un sous-domaine de test créé pour un salon professionnel, un ancien prestataire qui avait configuré un bucket S3. Chaque sous-domaine individuellement a une raison d’exister au moment de sa création. Le risque apparaît des mois ou des années plus tard, quand la ressource cloud associée est supprimée mais que personne ne pense à retirer le CNAME correspondant.
Un audit manuel suppose de lister tous les sous-domaines existants (pas seulement ceux qu’on utilise encore), de vérifier chaque CNAME, et de tester si la ressource cible répond encore. Sur un domaine avec plusieurs dizaines de sous-domaines accumulés au fil des années, ce travail devient vite fastidieux à refaire à chaque audit.
Deux approches pour surveiller ça
La première consiste à tester une liste de sous-domaines courants (www, blog, shop, api, mail…) et à vérifier si l’un d’eux pointe vers une ressource abandonnée. Ça couvre les cas les plus fréquents sans nécessiter d’accès particulier.
La seconde consiste à interroger directement la zone DNS réelle via l’API du fournisseur (Cloudflare ou Route53, par exemple), ce qui donne une vue exhaustive sans dépendre d’une liste de noms devinés et fonctionne même derrière un proxy qui masque les enregistrements publics.
Dans les deux cas, l’essentiel est de refaire la vérification régulièrement, pas une seule fois à la mise en place.
Leave a Reply