mlab Academy
EN
Sécuriser son domaine

Prise de contrôle de sous-domaine et DNS orphelin

Comment un CNAME ou un NS oublié permet à n'importe qui de publier sur votre sous-domaine, et comment repérer et nettoyer ces entrées avant un attaquant.

1 Introduction

Votre équipe marketing lance un site de campagne sur une plateforme d'hébergement et fait pointer promo.example.com dessus. Quelques mois plus tard, la campagne se termine et le compte d'hébergement est fermé. Personne ne touche au DNS : l'enregistrement pointe toujours vers la plateforme, mais vers un nom qui n'appartient plus à personne.

N'importe qui peut ouvrir un compte sur cette plateforme et réclamer le même nom. À partir de là, c'est lui qui décide de ce qu'affiche promo.example.com : une page de phishing sous votre propre domaine, avec un cadenas HTTPS valide, capable de lire les cookies définis pour .example.com. C'est une prise de contrôle de sous-domaine (subdomain takeover), et l'enregistrement oublié qui la permet s'appelle un DNS orphelin (dangling DNS).

1

Enregistrement DNS oublié suffit, aucun serveur à pirater

HTTPS

L'attaquant peut obtenir un certificat valide, puisqu'il contrôle désormais le nom

.example.com

Les cookies du domaine parent sont aussi envoyés au sous-domaine détourné

2 Comment ça marche

Une prise de contrôle suit toujours les mêmes quatre étapes. La cause racine est un ordre d'opérations : la ressource a été supprimée avant l'enregistrement DNS qui pointait vers elle.

1

promo.example.com CNAME example-promo.hosting.app

2

Le projet d'hébergement est supprimé. Le CNAME reste.

3

Un attaquant le repère (logs de certificats, scans DNS) et réserve example-promo sur la plateforme.

4

Votre sous-domaine sert désormais le contenu de l'attaquant.

Comment un scanner le détecte

Chaque plateforme répond à un nom non réservé par une page ou une erreur reconnaissable : NoSuchBucket sur Amazon S3, « There isn't a GitHub Pages site here », « No such app » sur Heroku, etc. Un scanner suit vos CNAME, compare la réponse à ces empreintes, et ne signale que les services où réserver un nom libre est encore possible. Le projet communautaire can-i-take-over-xyz recense les fournisseurs encore exploitables.

3 Analyse détaillée

Un scan de domaine remonte trois constats liés. Ils se distinguent par leur distance à une attaque réelle.

Prise de contrôle : un CNAME vers un service non réservé

Ce que ça veut dire

Un sous-domaine pointe vers une ressource cloud ou SaaS qui n'existe plus, sur une plateforme qui laisse n'importe qui réserver le nom. C'est le plus urgent des trois : l'exploitation prend quelques minutes.

Que faire tout de suite

Supprimez l'enregistrement DNS, ou réservez vous-même la ressource si le service est encore utile. Vérifiez ensuite le contenu récent du sous-domaine et ses journaux d'accès, s'il y en a, au cas où quelqu'un serait passé avant vous.

Services souvent concernés

Buckets de stockage, hébergement statique et plateformes applicatives (S3, Azure App Service et Cloud Services, GitHub Pages, Heroku), constructeurs de boutiques et de helpdesk. Plusieurs fournisseurs exigent désormais une preuve de propriété : c'est pour cela qu'un scanner vérifie le fournisseur avant de signaler.

Délégation orpheline : un NS ou un MX vers ce que vous ne contrôlez pas

Délégation vers une zone DNS supprimée

dev.example.com NS ns-123.awsdns-45.com confiait autrefois le sous-domaine à une zone hébergée chez un fournisseur DNS. Si cette zone a été supprimée, un attaquant peut en créer une nouvelle pour le même nom chez ce fournisseur et, chez certains, tomber sur les mêmes serveurs de noms. Il contrôle alors tous les enregistrements de ce sous-domaine, emails compris.

Des enregistrements qui visent un domaine expiré

Un serveur de noms, un MX ou une cible de CNAME comme ns1.ancienne-agence.com n'est pas plus sûr que ancienne-agence.com. Si ce domaine expire, celui qui le rachète hérite de votre délégation. Vérifiez l'enregistrement de chaque domaine externe dont dépend votre zone.

Que faire

Supprimez la délégation ou l'enregistrement, ou faites-le pointer vers une infrastructure que vous contrôlez. Même urgence qu'une prise de contrôle : l'impact est souvent plus large.

Sous-domaines fantômes : des noms qui ont existé

Ce que ça veut dire

Chaque certificat TLS est publié dans les journaux publics de Certificate Transparency. Un fantôme est un sous-domaine présent dans ces journaux qui ne se résout plus ou ne répond plus. Seul, ce n'est pas une vulnérabilité.

Pourquoi c'est signalé

Les fantômes sont l'emplacement des services décommissionnés, là où l'on trouve justement les enregistrements orphelins, et c'est la première liste qu'un attaquant dresse. Ils peuvent aussi révéler des noms internes (vpn-old, jira-staging) que vous préféreriez ne pas publier.

Que faire

Passez la liste en revue une fois : vérifiez qu'aucun enregistrement ne pointe encore quelque part pour chaque nom, et que personne ne compte le recréer vers un tiers. Rien à corriger si le nom a complètement disparu.

L'éviter pour de bon

1

Supprimer le DNS d'abord, la ressource ensuite. Inscrivez-le dans votre procédure de décommissionnement. C'est l'ordre inverse qui ouvre la fenêtre.

2

Gérer le DNS en code (Terraform, OctoDNS) à côté des ressources qu'il vise : supprimer l'une supprime l'autre.

3

Scanner régulièrement. Les équipes créent des sous-domaines plus vite que quiconque ne les relit ; un scan périodique attrape l'enregistrement oublié.

Trouvez vos DNS orphelins sur mlab.sh

Un scan de domaine énumère vos sous-domaines, suit leurs enregistrements et signale prises de contrôle, délégations orphelines et sous-domaines fantômes.

Scanner votre domaine sur mlab.sh

4 Red Flags

Un sous-domaine qui affiche la page « introuvable » d'un fournisseur

« NoSuchBucket », « There isn't a GitHub Pages site here », « No such app » : si l'un de vos noms répond ainsi, partez du principe que quelqu'un d'autre peut le réserver aujourd'hui.

Des NS pour un sous-domaine dont personne ne se souvient

Un sous-domaine délégué est une zone entière hors de votre DNS principal. Si aucune équipe n'en est responsable, vérifiez que la zone existe encore chez le fournisseur.

Des enregistrements qui dépendent du domaine d'une agence ou d'un prestataire

À la fin du contrat, leur domaine peut expirer. Vos enregistrements qui le visent répondent alors pour quelqu'un d'autre.

Des cookies de session valables pour tout le domaine

Un cookie défini pour .example.com est envoyé à tous les sous-domaines, y compris ceux qui ont été détournés. Limitez les cookies de session à l'hôte exact qui en a besoin.

Aucune procédure de décommissionnement

Si fermer un projet cloud n'inclut pas « supprimer ses enregistrements DNS », les prises de contrôle reviendront, quoi que vous nettoyiez aujourd'hui.

Propulsé par mlab.sh

Modules connexes

C'est quoi le DNS ?

L'annuaire d'Internet : comprendre comment le DNS traduit les noms de domaine en adresses IP.

C'est quoi un domaine ?

Des noms lisibles pour les humains : comment les domaines traduisent des adresses IP en noms faciles à retenir.

Les en-têtes de sécurité HTTP

HSTS, CSP, X-Frame-Options, attributs de cookies : ce que bloque chaque en-tête, ce que signifie son absence dans un scan, et une configuration de départ sûre.