Détournement de sous-domaine : comment un enregistrement DNS oublié devient une vulnérabilité
Le détournement de sous-domaine ne nécessite aucune intrusion — il exploite un enregistrement DNS que personne n'a pensé à supprimer, pointant vers une ressource que plus personne ne possède.
Ce que c'est
Un détournement de sous-domaine se produit quand un enregistrement DNS — généralement un CNAME — pointe encore vers une ressource tierce (un bucket de stockage cloud, une app sur une plateforme PaaS, un hébergeur de site statique) qui a depuis été supprimée, alors que l'enregistrement lui-même n'a jamais été retiré. Quiconque peut réclamer ce même nom de ressource sur la plateforme contrôle désormais ce qui est servi sous votre sous-domaine.
Comment cela se produit
- Une équipe fait pointer promo.example.fr vers un service tiers — un bucket de stockage objet, une app PaaS, un hébergeur de site statique — via un CNAME
- Plus tard, cette ressource est supprimée ou l'abonnement expire, mais l'enregistrement CNAME dans le DNS reste en place
- Le nom de la ressource redevient disponible sur cette plateforme, car celle-ci n'a aucun moyen de savoir que le DNS de quelqu'un d'autre y fait encore référence
- Un attaquant réclame exactement le même nom de ressource sur la plateforme
- Le trafic vers promo.example.fr atteint désormais la ressource de l'attaquant, car le CNAME ne pointait jamais vers l'infrastructure propre de votre domaine — il pointait depuis toujours vers un nom sur la plateforme de quelqu'un d'autre
Pourquoi c'est efficace
Le contenu ainsi servi tourne sous le domaine de la victime, ce qui lui permet de contourner les listes blanches basées sur le domaine, de paraître légitime dans des liens de phishing puisque le domaine visible est vraiment le vrai, et dans certains cas d'obtenir même un certificat TLS valide pour ce sous-domaine — car l'attaquant contrôle réellement la ressource vers laquelle pointe l'enregistrement DNS.
Comment les attaquants trouvent des cibles
L'énumération des sous-domaines fait apparaître chaque CNAME pointant vers des plateformes tierces ; vérifier lesquelles de ces cibles renvoient une erreur caractéristique de type « introuvable » ou « no such bucket » — la signature d'une ressource non réclamée — réduit la liste à celles exploitables.
Prévention
Supprimez l'enregistrement DNS au moment même où une ressource est mise hors service — c'est la seule correction complète, puisqu'un enregistrement sans rien de légitime derrière constitue à lui seul toute la vulnérabilité. Auditer périodiquement les sous-domaines, surtout après toute migration hors d'un service tiers, rattrape ce que les listes de vérification de mise hors service oublient.
Auditez vos propres sous-domaines
Voyez la théorie en pratique — lancez Détecteur de sous-domaines pour votre propre domaine.