Domain/Subdomain takeover
Last updated
Last updated
Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui :
Si vous découvrez un domaine (domaine.tld) qui est utilisé par un service dans le périmètre mais que l'entreprise en a perdu la propriété, vous pouvez essayer de l'enregistrer (si le prix est abordable) et informer l'entreprise. Si ce domaine reçoit des informations sensibles telles qu'un cookie de session via un paramètre GET ou dans l'en-tête Referer, il s'agit certainement d'une vulnérabilité.
Un sous-domaine de l'entreprise pointe vers un service tiers avec un nom non enregistré. Si vous pouvez créer un compte dans ce service tiers et enregistrer le nom en cours d'utilisation, vous pouvez effectuer la prise de contrôle du sous-domaine.
Il existe plusieurs outils avec des dictionnaires pour vérifier les prises de contrôle possibles :
Les vérifications de prise de contrôle de sous-domaine sont incluses dans l'énumération de sous-domaine par défaut de BBOT. Les signatures sont directement extraites de https://github.com/EdOverflow/can-i-take-over-xyz.
Lorsqu'un DNS wildcard est utilisé dans un domaine, tout sous-domaine demandé de ce domaine qui n'a pas explicitement une adresse différente sera résolu avec les mêmes informations. Cela pourrait être une adresse IP A, un CNAME...
Par exemple, si *.testing.com est 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'administrateur système le pointe vers un service tiers via CNAME, comme un sous-domaine github par exemple (sohomdatta1.github.io). Un attaquant pourrait créer sa propre page tierce (dans ce cas-ci, sur Github) et dire que something.testing.com pointe là-bas. Parce que le wildcard CNAME acceptera, 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 CTF : https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api
La prise de contrôle de sous-domaine est essentiellement du spoofing DNS pour un domaine spécifique à travers Internet, permettant aux attaquants de définir des enregistrements A pour un domaine, amenant 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 utiliser le typosquatting ou les domaines Doppelganger à cette fin. Sont particulièrement vulnérables les domaines où l'URL dans un e-mail de phishing semble légitime, trompant les utilisateurs et évitant les filtres anti-spam en raison de la confiance inhérente au domaine.
Consultez ce post pour plus de détails
Les certificats SSL, s'ils sont 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 du navigateur s'étend également à la sécurité des cookies, régie par des politiques comme la politique Same-origin. Les cookies, souvent utilisés pour gérer les sessions et stocker des jetons de connexion, peuvent être exploités via une prise de contrôle de sous-domaine. Les attaquants peuvent collecter des cookies de session simplement en redirigeant les utilisateurs vers un sous-domaine compromis, mettant en danger les données et la vie privée des utilisateurs.
Un autre aspect de la prise de contrôle de sous-domaine concerne les services e-mail. Les attaquants peuvent manipuler les enregistrements MX pour recevoir ou envoyer des e-mails à partir d'un sous-domaine légitime, améliorant l'efficacité des attaques de phishing.
D'autres risques incluent la prise de contrôle des enregistrements NS. Si un attaquant prend le contrôle d'un enregistrement NS d'un domaine, il peut potentiellement diriger 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.
Les attaquants peuvent exploiter des enregistrements CNAME non réclamés pointant vers des services externes qui ne sont plus utilisés ou ont été désactivés. Cela leur permet de créer une page sous le domaine de confiance, facilitant davantage le phishing ou la distribution de logiciels malveillants.
Les stratégies d'atténuation incluent :
Supprimer les enregistrements DNS vulnérables - C'est efficace si le sous-domaine n'est plus nécessaire.
Réclamer le nom de domaine - Enregistrer la ressource auprès du fournisseur cloud respectif ou racheter un domaine expiré.
Surveillance régulière des vulnérabilités - Des outils comme aquatone peuvent aider à identifier les domaines susceptibles. Les organisations devraient également réviser leurs processus de gestion de l'infrastructure, en s'assurant que la création d'enregistrements DNS est la dernière étape dans la création de ressources et la première étape dans la destruction de ressources.
Pour les fournisseurs cloud, vérifier la propriété du domaine est crucial pour prévenir les prises de contrôle de sous-domaine. Certains, comme GitLab, ont reconnu ce problème et mis en place des mécanismes de vérification de domaine.
Utilisez Trickest pour construire et automatiser facilement des workflows alimentés par les outils communautaires les plus avancés au monde. Accédez dès aujourd'hui :
