Domain/Subdomain takeover

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Domain takeover

Si vous découvrez un domaine (domain.tld) qui est utilisé par un service dans le scope mais dont la société a perdu la propriété, vous pouvez essayer de l’enregistrer (si peu coûteux) et prévenir la société. Si ce domaine reçoit des informations sensibles comme un session cookie via un paramètre GET ou dans l’en-tête Referer, c’est sûrement une vulnérabilité.

Subdomain takeover

Un sous-domaine de la société pointe vers un service tiers dont le nom n’est pas enregistré. Si vous pouvez créer un compte sur ce service tiers et enregistrer le nom utilisé, vous pouvez effectuer le subdomain takeover.

Il existe plusieurs outils avec des dictionnaires pour vérifier les takeovers possibles :

Subdomain Takeover Generation via DNS Wildcard

Quand un wildcard DNS est utilisé sur un domaine, tout sous-domaine demandé de ce domaine qui n’a pas d’autre enregistrement explicite sera résolu vers la même information. Cela peut être une adresse A, un CNAME…

Par exemple, si *.testing.com a un wildcard vers 1.1.1.1. Alors, not-existent.testing.com pointera vers 1.1.1.1.

Cependant, si au lieu de pointer vers une adresse IP, l’admin système le pointe vers un service tiers via CNAME, comme un GitHub subdomain par exemple (sohomdatta1.github.io). Un attaquant pourrait créer sa propre page sur ce service tiers (sur GitHub dans cet exemple) et dire que something.testing.com y pointe. Parce que le CNAME wildcard est accepté, l’attaquant pourra générer des sous-domaines arbitraires pour le domaine de la victime pointant vers ses pages.

Vous pouvez trouver un exemple de cette vulnérabilité dans le write-up du CTF : https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Exploiting a subdomain takeover

Subdomain takeover est essentiellement du spoofing DNS pour un domaine spécifique à travers Internet, permettant aux attaquants de définir des enregistrements A pour un domaine, ce qui amène les navigateurs à afficher le contenu du serveur de l’attaquant. Cette transparence dans les navigateurs rend les domaines vulnérables au phishing. Les attaquants peuvent employer le typosquatting ou des Doppelganger domains à cette fin. Les domaines particulièrement vulnérables sont ceux où l’URL dans un email de phishing apparaît légitime, trompant les utilisateurs et contournant les filtres anti-spam grâce à la confiance associée au domaine.

Check this post for further details

SSL Certificates

Les certificats SSL, si générés par des attaquants via des services comme Let’s Encrypt, ajoutent à la légitimité de ces faux domaines, rendant les attaques de phishing plus convaincantes.

La transparence des navigateurs s’étend aussi à la sécurité des cookies, régie par des politiques comme la Same-origin policy. Les cookies, souvent utilisés pour gérer les sessions et stocker les tokens de connexion, peuvent être exploités via un subdomain takeover. Les attaquants peuvent récupérer des session cookies simplement en dirigeant les utilisateurs vers un sous-domaine compromis, mettant en danger les données et la vie privée des utilisateurs.

CORS Bypass

Il peut être possible que chaque sous-domaine soit autorisé à accéder aux ressources CORS du domaine principal ou d’autres sous-domaines. Cela pourrait être exploité par un attaquant pour accéder à des informations sensibles en abusant des requêtes CORS.

CSRF - Same-Site Cookies bypass

Il pourrait être possible que le sous-domaine compromis soit autorisé à envoyer des cookies au domaine ou à d’autres sous-domaines alors que cela aurait dû être empêché par l’attribut Same-Site des cookies. Notez cependant que les tokens anti-CSRF empêcheront toujours cette attaque s’ils sont correctement implémentés.

OAuth tokens redirect

Il pourrait être possible que le sous-domaine compromis soit autorisé à être utilisé dans l’URL redirect_uri d’un flow OAuth. Cela pourrait être exploité par un attaquant pour voler le token OAuth.

CSP Bypass

Il pourrait être possible que le sous-domaine compromis (ou chaque sous-domaine) soit autorisé à être utilisé par exemple dans le script-src du CSP. Cela pourrait être exploité par un attaquant pour injecter des scripts malveillants et abuser de potentielles vulnérabilités XSS.

Emails and Subdomain Takeover

Un autre aspect du subdomain takeover implique les services email. Les attaquants peuvent manipuler les enregistrements MX pour recevoir ou envoyer des emails depuis un sous-domaine légitime, augmentant l’efficacité des attaques de phishing.

Higher Order Risks

D’autres risques incluent la prise de contrôle d’enregistrements NS. Si un attaquant prend le contrôle d’un enregistrement NS d’un domaine, il peut potentiellement rediriger une partie du trafic vers un serveur sous son contrôle. Ce risque est amplifié si l’attaquant définit un TTL (Time to Live) élevé pour les enregistrements DNS, prolongeant la durée de l’attaque.

CNAME Record Vulnerability

Les attaquants peuvent exploiter des enregistrements CNAME non revendiqués pointant vers des services externes qui ne sont plus utilisés ou ont été décommissionnés. Cela leur permet de créer une page sous le domaine de confiance, facilitant davantage le phishing ou la distribution de malware.

Mitigation Strategies

Les stratégies d’atténuation incluent :

  1. Supprimer les enregistrements DNS vulnérables - c’est efficace si le sous-domaine n’est plus nécessaire.
  2. Revendiquer le nom de domaine - enregistrer la ressource auprès du fournisseur cloud concerné ou racheter un domaine expiré.
  3. Surveillance régulière des vulnérabilités - des outils comme aquatone peuvent aider à identifier les domaines susceptibles. Les organisations doivent aussi revoir leurs processus de gestion d’infrastructure, en s’assurant que la création d’un enregistrement DNS est la dernière étape lors de la création d’une ressource et la première lors de sa destruction.

Pour les cloud providers, vérifier la propriété du domaine est crucial pour prévenir les subdomain takeovers. Certains, comme GitLab, ont reconnu ce problème et mis en place des mécanismes de validation de domaine.

Detection techniques

  • Find dangling DNS records : cherchez des enregistrements CNAME/A/AAAA/ALIAS/ANAME pointant vers des ressources inexistantes (buckets supprimés, apps, pages, load balancers).
  • Check provider error signatures : faire correspondre les réponses HTTP, les certs TLS, ou les erreurs DNS aux patterns de takeover connus (voir can-i-take-over-xyz).
  • Look for orphaned cloud assets : vérifier S3/CloudFront, Azure Websites, GCP App Engine/Storage, GitHub Pages, Heroku, Fastly, Netlify, Vercel, Zendesk, Shopify, Atlassian, et services similaires.
  • Passive DNS and historical records : les anciens CNAME révèlent souvent des services tiers précédemment utilisés qui peuvent encore être vulnérables.
  • Wildcard pitfalls : confirmer le wildcard DNS vs. les enregistrements explicites pour éviter les faux positifs et comprendre l’amplification du takeover.

APIs and data sources

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks