Prise de contrôle de sous-domaine : comment un enregistrement DNS oublié devient le site de quelqu'un d'autre

Une prise de contrôle de sous-domaine (subdomain takeover) se produit lorsqu'un enregistrement DNS de votre domaine pointe encore vers un service externe que vous n'utilisez plus. Si ce service permet à n'importe qui de revendiquer le nom que vous avez abandonné, un inconnu peut l'enregistrer et commencer à publier son propre contenu sur promo.yourcompany.com. Les visiteurs voient votre domaine dans la barre d'adresse et n'ont donc aucune raison de douter de la page.

La cause est presque toujours la même : un enregistrement dit « DNS orphelin » (dangling DNS). Quelqu'un a lancé un site de campagne, un centre d'aide ou une application de test sur une plateforme cloud, a fait pointer un sous-domaine vers celle-ci, puis a supprimé l'application mais pas l'enregistrement DNS. Microsoft décrit exactement ce scénario pour Azure, et le même schéma s'applique à de nombreuses plateformes d'hébergement, de stockage et SaaS.

La bonne nouvelle : c'est un problème de tenue d'inventaire, et vous pouvez le vérifier vous-même avec quelques requêtes DNS.

Comment un enregistrement orphelin devient une prise de contrôle

Le problème suit généralement 3 étapes :

1. Création. Une équipe crée yourcompany-promo.azurewebsites.net (ou un bucket, un site Pages, un point de terminaison CDN) et ajoute un CNAME pour que promo.yourcompany.com pointe vers lui.
2. Déprovisionnement. La campagne se termine, l'application est supprimée, mais personne ne retire le CNAME. Le sous-domaine pointe désormais vers un nom qui ne vous appartient plus.
3. Prise de contrôle. Quelqu'un remarque le nom orphelin, crée une ressource portant le même nom sur la même plateforme et, à partir de ce moment, contrôle ce qu'affiche promo.yourcompany.com.

Toutes les plateformes ne permettent pas la dernière étape. Le projet communautaire can-i-take-over-xyz tient une liste de services, indique lesquels sont vulnérables et recense le message d'erreur que chacun affiche pour un nom non revendiqué, par exemple « The specified bucket does not exist » pour Amazon S3.

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

Un sous-domaine détourné n'est pas seulement une page embarrassante. Selon les recommandations de Microsoft, les risques sont notamment :

• Le vol de cookies. De nombreuses applications web rattachent les cookies de session à *.yourcompany.com, si bien que n'importe quel sous-domaine peut les lire.
• Un certificat valide pour l'attaquant. Qui contrôle le sous-domaine peut obtenir un certificat TLS pour celui-ci : le cadenas s'affiche donc aussi.
• Un hameçonnage convaincant. Une page de connexion sur votre vrai domaine est bien plus difficile à repérer qu'une page sur un domaine sosie.
• L'interception d'e-mails. Un enregistrement MX orphelin peut permettre à quelqu'un de recevoir les e-mails envoyés à ce sous-domaine.

Le guide de test de sécurité web de l'OWASP ajoute la variante la plus grave : un enregistrement NS qui délègue un sous-domaine à des serveurs de noms situés sur un domaine qui n'est plus enregistré. Qui enregistre ce domaine contrôle toute la zone déléguée.

Comment vérifier votre propre DNS

Commencez par une liste de tous vos sous-domaines. L'export de zone de votre fournisseur DNS est la meilleure source. L'historique des certificats est une deuxième source utile, car presque chaque certificat émis pour vos noms est enregistré dans les journaux Certificate Transparency.

Pour chaque sous-domaine, regardez vers où il pointe :

dig +short CNAME promo.yourcompany.com
dig +short NS dev.yourcompany.com
dig +short MX shop.yourcompany.com

Vérifiez ensuite que chaque cible existe toujours et vous appartient toujours :

dig promo.yourcompany.com
curl -sI https://promo.yourcompany.com

Signaux d'alerte :

• la cible du CNAME renvoie NXDOMAIN (le nom n'existe plus),
• la page affiche une erreur de plateforme comme « No such app », « Repository not found » ou « There isn't a GitHub Pages site here »,
• un enregistrement NS pointe vers des serveurs de noms d'un domaine que vous ne reconnaissez pas ou qui a expiré,
• personne dans l'entreprise ne sait à quoi servait le sous-domaine.

Ne testez que des noms de votre propre domaine. N'essayez pas de revendiquer une ressource pour « prouver » le problème ; supprimer l'enregistrement suffit.

Comment corriger

1. Supprimez l'enregistrement orphelin de votre zone DNS. C'est la correction recommandée par Microsoft comme par l'OWASP.
2. Si le sous-domaine est encore nécessaire, recréez la ressource sous votre propre compte avant d'y renvoyer du trafic.
3. Vérifiez s'il s'est passé quelque chose pendant que l'enregistrement était orphelin : certificats inhabituels pour ce nom, liens dans votre application ou vos e-mails qui l'utilisent encore, URL de redirection OAuth qui l'incluent.
4. Utilisez la vérification de propriété lorsque la plateforme la propose. Azure App Service, par exemple, prend en charge un enregistrement TXT asuid.<subdomain> afin qu'aucun autre abonnement ne puisse valider le domaine personnalisé.
5. Corrigez le processus, pas seulement l'enregistrement. Ajoutez « supprimer l'entrée DNS » à la liste de contrôle de fermeture de tout service, et tenez un inventaire simple indiquant quel sous-domaine pointe vers quelle plateforme et qui en est responsable.

Une courte liste de contrôle

• Exportez votre zone DNS et listez chaque enregistrement CNAME, NS et MX.
• Pour chacun, confirmez que la cible existe et appartient à votre entreprise.
• Supprimez les enregistrements des services arrêtés.
• Comparez votre zone avec les noms des journaux Certificate Transparency pour trouver les sous-domaines non documentés.
• Refaites le point à chaque fin de campagne, de produit ou de contrat fournisseur.

Les enregistrements orphelins côtoient souvent d'autres éléments oubliés, comme les anciens serveurs de préproduction et de test. Nettoyer les deux en même temps est généralement le gain le plus rapide.

La place de Datahorses

Datahorses surveille votre entreprise depuis l'extérieur chaque jour : il dresse la liste de vos sous-domaines, vérifie vers où pointe chaque CNAME et signale les enregistrements qui mènent à des services qui n'existent plus. Nous n'entrons pas dans vos systèmes et n'avons besoin d'aucun accès, et chaque constat est accompagné des étapes exactes pour votre développeur. Consultez la liste complète de ce que nous surveillons ou le tableau de bord d'exemple.