Subdomain takeover : détecter et corriger

Personne ne crée un takeover volontairement. C'est le résidu d'une mise hors service normale, arrêtée une étape trop tôt.

Une équipe fait pointer un sous-domaine vers un service tiers par un CNAME : un outil de documentation, une page de statut, un constructeur de pages, un CDN. Des mois plus tard, l'abonnement est résilié ou la ressource supprimée. L'enregistrement DNS, lui, reste — parce que le DNS est un autre système, tenu par une autre équipe, et que rien n'oblige les deux gestes à se produire ensemble.

docs.exemple.com.  CNAME  exemple-docs.unfournisseur.net.
le compte n'existe plus chez le fournisseur
le nom est de nouveau libre à réclamer

Celui qui enregistre ce nom chez le fournisseur sert désormais ce qu'il veut depuis docs.exemple.com. Pas un domaine sosie. Le vôtre.

L'asymétrie fait tout l'intérêt de la manœuvre : réclamer un emplacement inutilisé sur une plateforme SaaS ne coûte rien et prend une minute, alors que le nom obtenu porte une réputation construite sur des années.

Il vous faut deux choses : la liste complète de vos sous-domaines, et l'état de résolution de chaque CNAME.

L'énumération vient d'abord, et elle est entièrement passive : journaux de Certificate Transparency, DNS passif, index des moteurs. Les enregistrements à risque sont précisément ceux dont personne ne se souvient : travailler à partir de votre propre documentation est donc la seule méthode qui garantit de les manquer.

Résolvez ensuite chaque candidat :

> dig +short CNAME docs.exemple.com > exemple-docs.unfournisseur.net. > > dig +short exemple-docs.unfournisseur.net > (vide — la cible ne résout pas)

Un CNAME dont la cible ne résout plus est votre candidat prioritaire. Mais une réponse vide est un signal, pas un verdict.

L'autre forme, plus facile à manquer Beaucoup d'enregistrements détournables résolvent parfaitement. Le fournisseur répond toujours, sur une infrastructure mutualisée, et renvoie une page d'erreur indiquant que la ressource n'est pas réclamée. Le DNS a l'air sain ; la vulnérabilité est dans la réponse HTTP.

C'est pourquoi la détection lit le corps de la réponse, et pas seulement la résolution. Chaque fournisseur a sa signature : « There isn't a GitHub Pages site here », « NoSuchBucket », « no such app » chez Heroku, une invitation à enregistrer le nom chez certains constructeurs de pages.

C'est là que la plupart des signalements de takeover se trompent, et ça compte : un faux positif vous coûte un après-midi et un peu de crédit.

Un CNAME pendant n'est pas automatiquement réclamable. Plusieurs fournisseurs ont ajouté des protections, précisément parce que cette classe de faille les a mis en difficulté :

• GitHub Pages exige une vérification de domaine avant qu'un domaine personnalisé puisse être rattaché à une nouvelle organisation.
• Certaines plateformes conservent un nom d'hôte réclamé pendant un délai de grâce après résiliation.
• D'autres lient définitivement le nom d'hôte au compte qui l'a vérifié en premier.

La séquence honnête est donc : l'enregistrement est pendant, le fournisseur renvoie une signature de ressource non réclamée, et ce fournisseur autorise encore un nouveau compte à rattacher ce nom d'hôte. Les trois ensemble seulement rendent la chose exploitable.

Ne testez pas en réclamant une ressource sur un domaine qui ne vous appartient pas, et n'hébergez pas de preuve de concept sur le sous-domaine vivant d'un tiers. Lisez plutôt la documentation du fournisseur sur les domaines personnalisés : elle vous dit si une vérification est requise, ce qui répond à la question sans rien toucher.

Note pratique : un enregistrement inexploitable aujourd'hui peut le devenir quand le fournisseur change sa politique. Un CNAME pendant doit être supprimé qu'il soit réclamable ou non, parce que le correctif coûte un changement DNS et que le risque, lui, n'est pas figé.

Le phishing est l'usage évident, et c'est le moins intéressant.

Parce que le nom d'hôte est authentiquement le vôtre, trois conséquences techniques suivent, que l'on anticipe rarement.

Les cookies Un cookie posé avec Domain=.exemple.com est envoyé à tous les sous-domaines, y compris celui passé sous le contrôle d'un tiers. Si votre cookie de session est délimité au domaine parent plutôt qu'à un hôte précis, un takeover le lit. À lui seul, ce point transforme une page de statut oubliée en détournement de session.

Les listes d’autorisation qui font confiance à votre propre wildcard Un peu partout dans votre pile, des configurations font silencieusement confiance à tout ce qui est sous votre domaine :

• des politiques CORS autorisant *.exemple.com
• des directives de Content Security Policy listant *.exemple.com comme source de scripts
• des listes d'URL de redirection OAuth acceptant n'importe quel sous-domaine

Chacune transforme un takeover en quelque chose de plus tranchant que du phishing : de l'exécution de script avalisée par votre propre CSP, ou un code d'autorisation délivré à un point de terminaison contrôlé par l'attaquant et que votre fournisseur d'identité juge légitime.

Certificats et réputation Le nouvel occupant peut obtenir un certificat TLS valide pour ce nom d'hôte, puisqu'il en démontre le contrôle. Cadenas, domaine correct, aucun avertissement. Et tout ce qu'il héberge vous est attribué, y compris par les listes noires.

Le correctif est court, c'est la bonne nouvelle.

• Supprimez l'enregistrement DNS si le service est réellement hors d'usage. C'est la bonne réponse dans la grande majorité des cas.
• Ou reprenez possession de la ressource chez le fournisseur si le sous-domaine sert encore, puis refaites-le pointer délibérément.

Faites-le dans cet ordre et faites-le maintenant : la fenêtre compte plus que la procédure. Un enregistrement pendant est exploitable par le premier qui le trouve, et l'énumération qui le trouve est à la portée de tous.

Vérifiez ensuite ce que ce nom pouvait atteindre. Si le sous-domaine est resté vivant un moment sous le contrôle d'un tiers, traitez l'épisode comme une exposition possible de sessions et d'identifiants plutôt que comme un défacement : revoyez la portée de vos cookies, et renouvelez tout ce qu'une page hébergée sur ce nom aurait pu collecter.

Toutes les organisations corrigent leurs enregistrements pendants une fois. Celles chez qui ça tient ont changé un processus, pas un enregistrement.

• Mettez le DNS dans la checklist de mise hors service. Retirer un service et retirer son enregistrement doivent être une seule tâche avec un seul responsable, pas deux tâches dans deux systèmes.
• Gérez le DNS comme du code, relu comme du code. Un CNAME pointant vers un fournisseur que personne ne reconnaît est attrapé en relecture, c'est-à-dire au moment le moins coûteux.
• Délimitez les cookies à l'hôte qui en a besoin, pas au domaine parent. Cela n'empêche pas le takeover : cela en supprime la pire conséquence.
• Préférez des sous-domaines explicites aux wildcards dans les listes CORS, CSP et OAuth, pour qu'un nom perdu n'hérite pas d'une confiance prévue pour tout le parc.
• Réénumérez périodiquement. La liste change à chaque projet livré.