hacktricks/pentesting-web/domain-subdomain-takeover.md

Prise de contrôle de domaine/sous-domaine

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

• Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT!
• Obtenez le merchandising officiel PEASS & HackTricks
• Découvrez La Famille PEASS, notre collection d'NFTs exclusifs
• Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦 @carlospolopm.
• Partagez vos astuces de piratage en soumettant des PR aux dépôts github HackTricks et HackTricks Cloud.

Utilisez Trickest pour construire et automatiser des workflows grâce aux outils communautaires les plus avancés.
Accédez-y dès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Prise de contrôle de domaine

Si vous découvrez un domaine (domain.tld) qui est utilisé par un service dans le périmètre mais que l'entreprise a perdu la propriété de celui-ci, vous pouvez essayer de le enregistrer (si le prix est raisonnable) et informer l'entreprise. Si ce domaine reçoit des informations sensibles comme un cookie de session via un paramètre GET ou dans l'en-tête Referer, c'est assurément une vulnérabilité.

Prise de contrôle de sous-domaine

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 usage, vous pouvez réaliser la prise de contrôle du sous-domaine.

Il existe plusieurs outils avec des dictionnaires pour vérifier les prises de contrôle possibles :

• https://github.com/EdOverflow/can-i-take-over-xyz
• https://github.com/blacklanternsecurity/bbot
• https://github.com/punk-security/dnsReaper
• https://github.com/haccer/subjack
• https://github.com/anshumanbh/tko-sub
• https://github.com/ArifulProtik/sub-domain-takeover
• https://github.com/SaadAhmedx/Subdomain-Takeover
• https://github.com/Ice3man543/SubOver
• https://github.com/m4ll0k/takeover
• https://github.com/antichown/subdomain-takeover
• https://github.com/musana/mx-takeover

Analyse des sous-domaines susceptibles d'être détournés avec BBOT :

Les vérifications de prise de contrôle de sous-domaine sont incluses dans l'énumération par défaut des sous-domaines de BBOT. Les signatures sont directement extraites de https://github.com/EdOverflow/can-i-take-over-xyz.

bbot -t evilcorp.com -f subdomain-enum

Prise de contrôle de sous-domaine via DNS Wildcard

Lorsqu'un DNS wildcard est utilisé dans un domaine, tout sous-domaine demandé de ce domaine qui n'a pas d'adresse explicitement 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 redirigé par 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, le sysadmin le redirige 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 (sur Github dans ce cas) et dire que something.testing.com pointe là-bas. Parce que, le CNAME wildcard sera d'accord, 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 compte-rendu du CTF : https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Exploiter une prise de contrôle de sous-domaine

Cette information a été copiée de https://0xpatrik.com/subdomain-takeover/

Récemment, j'ai écrit sur les bases de la prise de contrôle de sous-domaine. Bien que le concept soit maintenant généralement bien compris, j'ai remarqué que les gens ont généralement du mal à saisir les risques que cela représente. Dans cet article, je vais en profondeur et couvre les risques les plus notables de prise de contrôle de sous-domaine de mon point de vue.

Note : Certains risques sont atténués implicitement par le fournisseur de cloud. Par exemple, lorsque la prise de contrôle de sous-domaine est possible sur Amazon CloudFront, il n'y a aucun moyen de configurer des enregistrements TXT pour contourner les vérifications SPF. L'article vise donc à fournir des risques sur la prise de contrôle de sous-domaine en général. Néanmoins, la plupart de ces risques s'appliquent également aux fournisseurs de cloud.

Transparence pour un navigateur

Pour commencer, examinons la résolution DNS où CNAME est impliqué :

Notez que l'étape #7 demande sub.example.com plutôt que anotherdomain.com. C'est parce que le navigateur web n'est pas conscient que anotherdomain.com existe même. Même si l'enregistrement CNAME est utilisé, la barre d'URL dans le navigateur contient toujours sub.example.com. C'est la transparence pour le navigateur. Si vous y pensez, le navigateur fait entièrement confiance au résolveur DNS pour fournir des informations précises sur le domaine. Simplifié, la prise de contrôle de sous-domaine est un spoofing DNS pour un domaine particulier sur Internet. Pourquoi ? Parce que tout navigateur effectuant la résolution DNS sur le domaine affecté reçoit un enregistrement A défini par un attaquant. Le navigateur affiche alors joyeusement tout ce qui est reçu de ce serveur (pensant que c'est légitime).

Un tel domaine constitue un scénario parfait pour le phishing. Les attaquants utilisent souvent le typosquatting ou les soi-disant Doppelganger domains pour imiter le domaine/site web légitime à des fins de phishing. Après qu'un attaquant a pris le contrôle d'un nom de domaine légitime, il est presque impossible pour un utilisateur régulier de dire si le contenu sur le domaine est fourni par une partie légitime ou un attaquant. Prenons par exemple une banque aléatoire. Si l'un des sous-domaines de la banque est vulnérable à la prise de contrôle de sous-domaine, un attaquant peut créer un formulaire HTML qui imite le formulaire de connexion au système de banque en ligne de la banque. Ensuite, un attaquant peut lancer une campagne de phishing ciblée ou de masse demandant aux utilisateurs de se connecter et de changer leurs mots de passe. À ce stade, les mots de passe sont capturés par un attaquant qui contrôle le domaine en question. L'URL fournie dans l'e-mail de phishing est un sous-domaine légitime d'une banque. Par conséquent, les utilisateurs ne sont pas conscients de quelque chose de malveillant. Les filtres anti-spam et autres mesures de sécurité sont également moins susceptibles de déclencher l'e-mail comme spam ou malveillant car il contient des noms de domaine de confiance plus élevée.

En effet, le nom de domaine lui-même joue un rôle significatif dans une campagne réussie. Avoir un sous-domaine de 5ème niveau vulnérable à la prise de contrôle de sous-domaine est beaucoup moins "légitime" qu'avoir un sous-domaine de 2ème niveau avec un nom de sous-domaine convivial. J'ai vu plusieurs exemples de sous-domaines parfaits pour le phishing, y compris :

• purchases.SOMETHING.com
• www.SOMETHING.com
• online.SOMETHING.com
• shop.SOMETHING.com

Tous vulnérables à la prise de contrôle de sous-domaine. Tous étaient de grandes marques. Parler de phishing parfait ?

Néanmoins, les campagnes de phishing récentes hébergent du contenu sur des domaines avec de longs noms de domaine qui incluent le nom de la marque (voir exemple Apple). Ayant un certificat SSL valide (plus à ce sujet ci-dessous), un mot-clé dans le nom de domaine et un site web qui imite le site web de la marque ciblée, les gens ont tendance à tomber dans ces attaques. Pensez aux chances avec un sous-domaine légitime de cette marque.

Utilisez Trickest pour construire et automatiser des workflows alimentés par les outils communautaires les plus avancés.
Obtenez l'accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Certificats SSL

L'attaque ci-dessus peut être renforcée en générant un certificat SSL valide. Des autorités de certification telles que Let's Encrypt permettent la vérification automatique de la propriété d'un domaine par vérification de contenu :

C'est-à-dire, s'il y a un contenu spécifique placé sur un chemin d'URL spécifique, Let's Encrypt approuvera l'émission d'un certificat pour un domaine donné. Puisqu'un attaquant a un contrôle total sur le contenu du domaine qui est vulnérable à la prise de contrôle de sous-domaine, cette vérification peut être effectuée en quelques minutes. Par conséquent, les attaquants sont également capables de générer un certificat SSL pour un tel domaine, ce qui ne fait que diminuer les soupçons d'une attaque de phishing.

Vol de cookies

Cela va de pair avec la transparence du navigateur mais a des conséquences différentes. Le navigateur web implémente de nombreuses politiques de sécurité pour empêcher les sites web malveillants de causer des dommages. Cela inclut des choses telles que la politique de même origine. L'une des principales responsabilités de sécurité d'un navigateur est de sécuriser les cookies enregistrés. Pourquoi ? Alors que HTTP est un protocole sans état, les cookies sont utilisés pour suivre les sessions. Pour plus de commodité, les utilisateurs enregistrent souvent des cookies pour une période prolongée pour éviter de se connecter à chaque fois. Ces cookies agissent donc comme un jeton de connexion qui est présenté au serveur web et l'utilisateur est identifié. Des attaques telles que le détournement de session ont naturellement évolué à partir de ce concept.

Le navigateur présente automatiquement les cookies enregistrés à chaque requête au domaine qui les a émis. Il existe une exception à cela, à savoir que les cookies pourraient être partagés entre sous-domaines (lire ici, notez également la section 8.7). Cela se produit généralement lorsque le site web utilise un système de Single sign-on (SSO) basé sur des cookies. En utilisant SSO, un utilisateur peut se connecter en utilisant un sous-domaine et partager le même jeton de session sur une large gamme de sous-domaines. La syntaxe pour définir un cookie régulier est la suivante :

HTTP/1.1 200 OK
Set-Cookie: name=value

Si ce cookie est émis par un serveur web résidant sur example.com, seul ce serveur peut accéder à ce cookie ultérieurement. Cependant, le cookie peut être émis pour un domaine générique (pour les raisons expliquées ci-dessus) de la manière suivante :

HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com

Le cookie sera inclus dans les requêtes HTTP vers _example.com_ mais aussi vers tout autre sous-domaine tel que _subdomain.example.com_. Ce comportement crée une possibilité d'attaques de haute gravité utilisant la prise de contrôle de sous-domaine. Supposons qu'un domaine particulier utilise des cookies de session pour un domaine générique. S'il y a un sous-domaine vulnérable à la prise de contrôle de sous-domaine, la seule chose nécessaire pour recueillir le jeton de session de l'utilisateur est de le tromper pour qu'il visite le sous-domaine vulnérable. Le cookie de session est automatiquement envoyé avec la requête HTTP.

Le navigateur implémente également des mécanismes de sécurité supplémentaires pour les cookies :

* **Cookie HttpOnly** — Par défaut, les cookies peuvent être accédés par le code Javascript exécuté dans le contexte du site web qui a créé les cookies. Javascript peut lire, mettre à jour et supprimer les cookies. Le drapeau de cookie _HttpOnly_ (défini par le serveur web) indique que le cookie particulier ne peut pas être accédé par le code Javascript. La seule façon de l'obtenir est à travers les en-têtes de requête et de réponse HTTP.
* **Cookie Secure** — Lorsque le cookie a le drapeau _Secure_ défini par le serveur web, il ne peut être communiqué au serveur web que si HTTPS est utilisé.

Si le domaine est vulnérable à la prise de contrôle de sous-domaine, un attaquant peut recueillir des cookies émis par ce domaine dans le passé simplement en trompant les utilisateurs pour qu'ils visitent ce site web. Les drapeaux HttpOnly et Secure n'aident pas puisque le cookie n'est pas accédé en utilisant Javascript et un certificat SSL peut être facilement généré pour le domaine pris.

Le vol de cookies utilisant la prise de contrôle a été expliqué dans le [rapport](https://hackerone.com/reports/172137) de bug bounty par Arne Swinnen. Le rapport explique le problème avec l'un des sous-domaines de _Ubiquiti Networks_ (_ping.ubnt.com_). Ce sous-domaine était vulnérable à la prise de contrôle de sous-domaine, pointant vers une distribution AWS CloudFront non réclamée. Puisque Ubiquiti Networks utilise SSO avec des cookies de session génériques, tous les utilisateurs visitant _ping.ubnt.com_ pourraient se faire voler leurs cookies de session. Même si ce domaine pointe vers AWS CloudFront, les paramètres de distribution CloudFront permettent de consigner les cookies avec chaque requête. Par conséquent, le scénario d'extraction de cookies de session est entièrement possible même avec des sous-domaines pointant vers AWS CloudFront. En 2017, Arne a également démontré un vecteur d'attaque similaire contre [le système SSO d'Uber](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/).

Le comportement expliqué ci-dessus n'est pas limité aux cookies. Puisque les scripts Javascript ont un contrôle total sur les sites web sur lesquels ils sont exécutés, avoir la capacité de remplacer de tels scripts sur le site web légitime pourrait conduire à des conséquences catastrophiques. Supposons que le site web utilise du code Javascript d'un fournisseur externe en utilisant la balise _script_ et l'attribut _src_. Lorsque le domaine du fournisseur externe expire, le navigateur échoue silencieusement, c'est-à-dire qu'il ne déclenche aucune alerte visible pour les utilisateurs réguliers. Si le code externe ne fait rien d'important (par exemple, il est utilisé uniquement pour le suivi), un tel fournisseur externe pourrait rester sur le site web pendant une période prolongée. Un attaquant peut prendre le contrôle de ce domaine expiré, correspondre au chemin URL du code Javascript fourni et ainsi prendre le contrôle de chaque visiteur qui visite le site web original.

Cependant, il existe un moyen de protéger l'intégrité des fichiers Javascript dans un navigateur. _Subresource Integrity_ [a été proposé](https://www.w3.org/TR/2016/REC-SRI-20160623/) comme mécanisme pour inclure une empreinte cryptographique en tant qu'attribut _integrity_ à la balise _script_ dans HTML5. Lorsque l'empreinte cryptographique fournie ne correspond pas au fichier téléchargé, le navigateur refuse de l'exécuter.

### E-mails <a href="#emails" id="emails"></a>

Lorsqu'une prise de contrôle de sous-domaine CNAME est possible, les enregistrements MX peuvent également être configurés par un attaquant vers un serveur web arbitraire. Cela permet de recevoir des e-mails vers un sous-domaine légitime d'une marque - particulièrement utile encore une fois dans les attaques de (spear) phishing où une interaction entre un attaquant et une victime est nécessaire. Les attaquants usurpent généralement l'en-tête `Return-Path` pour recevoir une réponse à l'e-mail. Avec les bons enregistrements MX, ce problème est contourné.

D'autre part, l'envoi d'e-mails est également possible. Bien qu'il soit trivial de falsifier l'en-tête `From` pour inclure n'importe quelle adresse e-mail, les filtres SPF vérifient généralement l'en-tête `Return-Path` et les hôtes autorisés à envoyer des mails pour le domaine. SPF stocke la configuration dans les enregistrements DNS TXT. Avec la prise de contrôle de sous-domaine, les enregistrements TXT sont également sous le contrôle de l'attaquant - les vérifications SPF peuvent être facilement contournées.

_Comme je l'ai noté au début, ces tactiques ne fonctionnent généralement pas avec la majorité des fournisseurs de cloud puisque vous n'avez pas de contrôle direct sur la zone DNS._

### Risques de Haut Niveau <a href="#higherorderrisks" id="higherorderrisks"></a>

Le concept de prise de contrôle de sous-domaine peut être naturellement étendu aux enregistrements NS : Si le domaine de base d'au moins un enregistrement NS est disponible à l'enregistrement, le nom de domaine source est vulnérable à la prise de contrôle de sous-domaine.

L'un des problèmes de la prise de contrôle de sous-domaine utilisant un enregistrement NS est que le nom de domaine source a généralement plusieurs enregistrements NS. Plusieurs enregistrements NS sont utilisés pour la redondance et l'équilibrage de charge. Le serveur de noms est choisi aléatoirement avant la résolution DNS. Supposons que le domaine _sub.example.com_ ait deux enregistrements NS : _ns.vulnerable.com_ et _ns.nonvulnerable.com_. Si un attaquant prend le contrôle de _ns.vulnerable.com_, la situation du point de vue de l'utilisateur qui interroge _sub.example.com_ se présente comme suit :

1. Puisqu'il y a deux serveurs de noms, l'un est choisi aléatoirement. Cela signifie que la probabilité d'interroger le serveur de noms contrôlé par un attaquant est de 50%.
2. Si le résolveur DNS de l'utilisateur choisit _ns.nonvulnerable.com_ (serveur de noms légitime), le résultat correct est retourné et probablement mis en cache quelque part entre 6 et 24 heures.
3. Si le résolveur DNS de l'utilisateur choisit _ns.vulnerable.com_ (serveur de noms possédé par un attaquant), un attaquant peut fournir un faux résultat qui sera également mis en cache. Puisque l'attaquant contrôle le serveur de noms, elle peut définir le TTL pour ce résultat particulier à être par exemple une semaine.

Le processus ci-dessus est répété chaque fois que l'entrée de cache expire. Lorsqu'un attaquant choisit d'utiliser un TTL avec une valeur élevée, le faux résultat restera dans le cache DNS pour cette période. Pendant ce temps, toutes les requêtes vers _sub.example.com_ utiliseront le faux résultat DNS mis en cache par un attaquant. Cette idée est encore amplifiée lorsque des résolveurs DNS publics (par exemple, Google DNS) sont utilisés. Dans ce cas, les résolveurs publics sont susceptibles de mettre en cache les faux résultats, ce qui signifie que tous les utilisateurs utilisant le même résolveur DNS obtiendront des faux résultats jusqu'à ce que le cache soit révoqué.

En plus du contrôle sur le nom de domaine source, le contrôle sur tous les domaines de niveau supérieur du nom de domaine source est également acquis. C'est parce que posséder un nom de domaine canonique d'un enregistrement NS signifie posséder la zone DNS complète du nom de domaine source.

En 2016, Matthew Bryant [a démontré](https://thehackerblog.com/the-international-incident-gaining-control-of-a-int-domain-name-with-dns-trickery/index.html) une prise de contrôle de sous-domaine utilisant un enregistrement NS sur _maris.int_. Le domaine de premier niveau .INT est un TLD spécial, et seulement une poignée de domaines l'utilisent. Bryant a montré que même si l'enregistrement de tels noms de domaine est approuvé exclusivement par l'IANA, les serveurs de noms peuvent être définis vers des domaines arbitraires. Puisque l'un des serveurs de noms de _maris.int_ était disponible à l'enregistrement (_cobalt.aliis.be_), la prise de contrôle de sous-domaine était possible même sur ce TLD restreint.

Matthew a également [démontré](https://thehackerblog.com/the-io-error-taking-control-of-all-io-domains-with-a-targeted-registration/index.html) une attaque de gravité encore plus élevée où il a pu prendre le contrôle du serveur de noms du domaine de premier niveau .IO. Contrôler .IO signifie contrôler les réponses pour tous les noms de domaine .IO. Dans ce cas, l'un des serveurs de noms de .IO était _ns-a1.io_ qui était disponible à l'enregistrement. En enregistrant _ns-a1.io_, Bryant a pu recevoir des requêtes DNS et contrôler leurs réponses pour tous les domaines .IO.

### Atténuation <a href="#mitigation" id="mitigation"></a>

Les stratégies d'atténuation pour les noms de domaine déjà vulnérables à la prise de contrôle de sous-domaine sont plutôt simples :

* **Supprimer l'enregistrement DNS affecté** — La solution la plus simple est de supprimer l'enregistrement affecté de la zone DNS. Cette étape est généralement utilisée si l'organisation conclut que le nom de domaine source affecté n'est plus nécessaire.
* **Réclamer le nom de domaine** — Cela signifie enregistrer la ressource chez le fournisseur de cloud particulier ou, dans le cas d'un domaine Internet régulier, racheter le domaine expiré.

Pour prévenir la prise de contrôle de sous-domaine à l'avenir, les organisations devraient changer le processus de création et de destruction des ressources dans leur infrastructure. Dans le cas de la création de ressource, la création de l'enregistrement DNS doit être la _dernière étape_ de ce processus. Cette condition empêche l'enregistrement DNS de pointer vers un domaine non existant à tout moment. Pour la destruction de la ressource, l'opposé est vrai : l'enregistrement DNS doit être supprimé comme la _première étape_ de ce processus. Des outils tels que [aquatone](https://github.com/michenriksen/aquatone) incluent des vérifications pour la prise de contrôle de sous-domaine. Les vérifications devraient être effectuées périodiquement par une équipe de sécurité d'une organisation pour vérifier qu'il n'y a pas de domaines vulnérables. Les processus de collecte centralisée des noms de domaine exposés ne sont souvent pas efficaces au sein des organisations (en raison des équipes mondiales, etc.) et la surveillance externe est généralement la meilleure solution.

La stratégie d'atténuation pour les fournisseurs de cloud devrait également être considérée. Les services cloud ne vérifient pas la propriété du domaine. La raison derrière cela est principalement la commodité. Le fournisseur de cloud n'introduit pas de vulnérabilité en ne vérifiant pas la propriété d'un nom de domaine source. Il appartient donc à l'utilisateur de surveiller ses enregistrements DNS. Une autre raison est que, lorsque la ressource cloud est supprimée, l'utilisateur n'est généralement plus un client de ce service. La question que se posent alors les fournisseurs de cloud est : Pourquoi devrions-nous même nous en soucier ?

Des fournisseurs tels que [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/) ont réalisé que la prise de contrôle de sous-domaine est un problème et ont mis en place un mécanisme de vérification de domaine.

_Certaines parties de ce post sont des extraits de ma_ [_Thèse de Master_](https://is.muni.cz/th/byrdn/Thesis.pdf).

À la prochaine !

[Patrik](https://twitter.com/0xpatrik)

<figure><img src="../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

\
Utilisez [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) pour construire et **automatiser des workflows** alimentés par les outils communautaires **les plus avancés** au monde.\
Obtenez l'accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

<details>

<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Autres moyens de soutenir HackTricks :

* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux repos github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>