Symptôme : rien de spectaculaire. Un audit de sécurité de routine sur un parc de trente domaines clients relève une page d’erreur générique en visitant demo-ancien.exemple.fr, un sous-domaine que personne dans l’équipe ne reconnaît. Aucune alerte, aucun email de plainte, juste une page qui ne devrait pas exister.
Cet article ne traite pas de la sécurité applicative de WordPress elle-même, sujet distinct et déjà couvert par ailleurs. Il détaille précisément comment repérer ce type de sous-domaine oublié, comprendre pourquoi il constitue un risque réel de prise de contrôle, et le corriger correctement plutôt que de simplement le désactiver en apparence.
Symptôme : un CNAME qui pointe vers un service désactivé
Une requête dig cname demo-ancien.exemple.fr révèle que le sous-domaine pointe vers ancien-projet.herokuapp.com, une application qui n’existe plus depuis longtemps sur la plateforme cible. Le service tiers vers lequel pointe l’enregistrement CNAME a été supprimé, mais l’enregistrement DNS, lui, n’a jamais été nettoyé de la zone du domaine principal.
C’est exactement la configuration qui rend un subdomain takeover possible : sur de nombreuses plateformes d’hébergement d’applications (Heroku, GitHub Pages, Azure, certains services de CDN), un nom d’application ou de projet devenu disponible peut être revendiqué par n’importe quel tiers. Si un attaquant enregistre un nouveau projet sous ce même nom, le CNAME orphelin du client pointera automatiquement vers l’infrastructure de cet attaquant, sans qu’aucune modification DNS ne soit nécessaire de son côté.
Diagnostic : confirmer le risque avant de s’alarmer
Toutes les pages d’erreur sur un sous-domaine ne signalent pas un risque de takeover. Le diagnostic consiste à vérifier trois éléments : l’enregistrement DNS pointe-t-il vers un service tiers externe (et non vers une infrastructure propre) ? Ce service renvoie-t-il un message d’erreur caractéristique de « ressource introuvable » ou « domaine non configuré » plutôt qu’une erreur générique de serveur ? Le nom de projet ou d’application référencé est-il potentiellement disponible à l’enregistrement chez ce fournisseur ?
Dans notre cas, la page renvoyait précisément le message « No such app » caractéristique de Heroku lorsqu’un nom d’application référencé par un CNAME externe n’existe plus sur la plateforme — un signal quasiment sans ambiguïté.
Un correctif qui ne s’arrête pas à la désactivation
Le premier réflexe consiste souvent à simplement supprimer l’enregistrement CNAME, ce qui règle effectivement le risque de takeover immédiat. Mais cette suppression seule laisse deux questions ouvertes : depuis combien de temps ce sous-domaine était-il exposé, et un tiers a-t-il pu, entre-temps, revendiquer le service et servir du contenu malveillant sous ce nom pendant une période donnée ?
- Vérifier dans les journaux d’accès disponibles si le sous-domaine a reçu du trafic récent (visiteurs, robots d’indexation).
- Contrôler si le sous-domaine a été référencé dans un moteur de recherche, ce qui indiquerait une exposition prolongée.
- Documenter et supprimer l’enregistrement, plutôt que de le laisser en l’état « au cas où ».
- Étendre l’audit à l’ensemble de la zone DNS du domaine, pas seulement au sous-domaine détecté.
Prévention : un audit de zone périodique et systématique
Sur le parc concerné, l’audit complet des trente domaines a permis de retrouver quatre sous-domaines orphelins similaires, la plupart hérités d’anciens projets de démonstration jamais nettoyés après la fin d’une collaboration. Aucun n’avait été effectivement revendiqué par un tiers au moment de l’audit, mais rien ne garantissait que cela resterait vrai indéfiniment.
for sub in $(cat sous-domaines.txt); do
cname=$(dig +short cname "$sub")
if [ -n "$cname" ]; then
echo "$sub -> $cname"
fi
doneCe script trivial, exécuté trimestriellement sur la liste de tous les sous-domaines connus du parc, permet de repérer rapidement les enregistrements CNAME pointant vers des services externes et de vérifier manuellement leur validité.
Un sous-domaine désactivé n’est jamais un sous-domaine sans risque tant que son enregistrement DNS reste actif. Le nettoyage de zone doit suivre le nettoyage de projet, pas s’en dispenser.
En résumé
Le subdomain takeover reste un risque discret, rarement détecté par les outils de sécurité applicative classiques puisqu’il ne touche pas directement le code du site. Un audit périodique de la zone DNS, croisé avec la disponibilité réelle des services tiers référencés, reste la seule prévention fiable. La liste des services vulnérables à ce type de risque est maintenue par la communauté sur GitHub et vaut la peine d’être consultée régulièrement : github.com/EdOverflow/can-i-take-over-xyz.
