Le nom qui ne pointe nulle part : prise de contrôle d'un CNAME orphelin
Le défi
Kestrel Bank tient une zone DNS bien rangée, et c'est justement le problème. L'un de ses sous-domaines a encore un CNAME qui pointe vers un bucket cloud que l'équipe marketing a supprimé à la fin d'une campagne. Le nom se résout, la cible n'existe pas, et n'importe qui peut aller chez ce fournisseur cloud et réclamer le nom vacant. Celui qui le fait peut servir du contenu depuis une véritable adresse kestrelbank.example. Croisez les enregistrements et indiquez le sous-domaine qui peut être repris.
Ce que tu vas apprendre
- Expliquer comment un CNAME vers une ressource déprovisionnée devient réclamable
- Reconnaître la réponse « n'existe pas » d'un fournisseur comme signature d'un takeover
- Croiser un export DNS avec des sondes en direct pour trouver l'enregistrement orphelin
- Décrire l'impact de la diffusion de contenu depuis un vrai sous-domaine
- Énoncer l'ordre sûr de décommissionnement des ressources DNS et cloud
Compétences testées
Prérequis
- Ce qu'est un enregistrement CNAME
- La notion de buckets cloud / ressources hébergées
Comment ça marche
Un subdomain takeover est possible quand un enregistrement DNS pointe vers une ressource tierce qui a été supprimée, mais dont le nom peut être recréé par n'importe qui. L'enregistrement résout toujours. Ce vers quoi il résout est un emplacement vide qui attend d'être réclamé.
L'indice, c'est la réponse de la cible. Une cible active répond normalement. Une cible réclamable renvoie l'erreur « n'existe pas » du fournisseur, comme NoSuchBucket. Cela signifie que la ressource a été démantelée alors que le CNAME qui pointait vers elle a été laissé en place.
Réclamer le nom permet à un attaquant de diffuser du contenu depuis un véritable sous-domaine de la victime, ce qui inspire une vraie confiance : cookies limités au domaine parent, familiarité des clients et possibilité d'obtenir un certificat valide.
Erreurs fréquentes
- Choisir un sous-domaine actif. status, docs et login pointent tous vers des cibles qui répondent normalement.
- Blâmer le bucket supprimé. Que le bucket ait disparu est normal. La vulnérabilité, c'est le CNAME laissé derrière.
- Répondre avec l'hôte cible. Le nom exposé au takeover est le sous-domaine Kestrel, pas la cible cloud vers laquelle il pointe.
- Ignorer la sonde. Sans vérifier la réponse de chaque cible, impossible de distinguer l'enregistrement orphelin des sains.
Comment s'en protéger
Liez le cycle de vie du DNS à celui des ressources.
- Supprimez ou redirigez un enregistrement DNS au moment où la ressource qui se trouve derrière est décommissionnée. Supprimez l'enregistrement avant la ressource, ou conservez le nom.
- Adoptez une checklist de démantèlement pour que le nettoyage DNS ne soit jamais l'étape oubliée.
- Analysez en continu vos zones à la recherche de CNAME dont les cibles renvoient des signatures de takeover connues, chez tous les fournisseurs que vous utilisez.