Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/domain-subdomain-takeover.md

27 KiB
Raw Blame History

Prise de contrôle de domaine/sous-domaine

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


Utilisez Trickest pour créer et automatiser des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez un accè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 (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 le enregistrer (si c'est assez bon marché) 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, cela constitue certainement une vulnérabilité.

Prise de contrôle de sous-domaine

Un sous-domaine de l'entreprise pointe vers un service tiers dont le nom n'est pas 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 :

Analyse des sous-domaines piratables avec BBOT :

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

bbot -t evilcorp.com -f subdomain-enum

Génération de prise de contrôle de sous-domaine via un DNS wildcard

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 peut ê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 un CNAME, comme un sous-domaine GitHub par exemple (sohomdatta1.github.io). Un attaquant pourrait créer sa propre page tiers (dans ce cas, sur GitHub) et dire que something.testing.com pointe là-bas. Parce que le CNAME wildcard l'accepte, 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

Exploitation d'une prise de contrôle de sous-domaine

Ces informations ont été copiées depuis 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 souvent du mal à comprendre les risques que la prise de contrôle de sous-domaine présente. Dans cet article, je vais approfondir et couvrir les risques les plus importants de la prise de contrôle de sous-domaine selon mon point de vue.

Remarque : 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 liés à 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 lorsqu'un CNAME est impliqué :

Résolution DNS

Notez que l'étape n°7 demande sub.example.com plutôt que anotherdomain.com. C'est parce que le navigateur Web n'est pas conscient de l'existence de anotherdomain.com. Même si un enregistrement CNAME est utilisé, la barre d'URL du navigateur contient toujours sub.example.com. C'est la transparence pour le navigateur. Si vous y réfléchissez, le navigateur place toute sa confiance dans le résolveur DNS pour fournir des informations précises sur le domaine. En simplifiant, la prise de contrôle de sous-domaine est un détournement DNS pour un domaine particulier à travers Internet. Pourquoi ? Parce que tout navigateur effectuant la résolution DNS sur le domaine concerné reçoit un ensemble d'enregistrements A définis par un attaquant. Le navigateur affiche ensuite joyeusement ce qui est reçu de ce serveur (en pensant que c'est légitime).

Un tel domaine crée un scénario parfait pour le phishing. Les attaquants utilisent souvent le typosquatting ou les soi-disant Doppelganger domains pour imiter le domaine/site légitime à des fins de phishing. Après qu'un attaquant ait pris le contrôle d'un nom de domaine légitime, il est presque impossible pour un utilisateur régulier de savoir si le contenu du domaine est fourni par une partie légitime ou par un attaquant. Prenons par exemple une banque au hasard. 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 mener une campagne de spear phishing ou de phishing 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 ce qui se passe de malveillant. Les filtres anti-spam et autres mesures de sécurité sont également moins susceptibles de déclencher l'e-mail en tant que spam ou malveillant car il contient des noms de domaine ayant une plus grande confiance.

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

  • 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 récentes campagnes de phishing hébergent du contenu sur des domaines avec de longs noms de domaine qui incluent le nom de la marque (voir l'exemple d'Apple). Avec un certificat SSL valide (voir 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 créer facilement et automatiser des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Accédez-y dè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 améliorée en générant un certificat SSL valide. Les autorités de certification telles que Let's Encrypt permettent la vérification automatique de la propriété d'un domaine par la vérification du contenu :

Flux de Let's Encrypt

C'est-à-dire que si un contenu spécifique est placé sur un chemin d'URL spécifique, Let's Encrypt approuvera la délivrance d'un certificat pour un domaine donné. Étant donné qu'un attaquant a un contrôle total sur le contenu du domaine 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 réduire 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. Les navigateurs Web mettent en œuvre 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 ? Bien que HTTP soit un protocole sans état, les cookies sont utilisés pour suivre les sessions. Pour plus de commodité, les utilisateurs enregistrent souvent les cookies pendant une période prolongée afin de ne pas avoir à 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 piratage de session ont naturellement évolué à partir de ce concept.

Le navigateur présente automatiquement les cookies stockés avec chaque demande au domaine qui les a émis. Il existe une exception à cela, de sorte que les cookies peuvent être partagés entre les sous-domaines (lire ici, voir é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 les cookies. Avec SSO, un utilisateur peut se connecter en utilisant un sous-domaine et partager le même jeton de session sur un large éventail 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 y accéder 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 gravité élevée en utilisant la prise en charge de sous-domaine. Supposons qu'un domaine particulier utilise des cookies de session pour un domaine générique. S'il existe un sous-domaine vulnérable à la prise en charge de sous-domaine, la seule chose à faire pour collecter le jeton de session de l'utilisateur est de le tromper en visitant le sous-domaine vulnérable. Le cookie de session est automatiquement envoyé avec la requête HTTP.

Le navigateur met également en œuvre des mécanismes de sécurité supplémentaires pour les cookies :

  • Cookie HttpOnly - Les cookies peuvent par défaut être accessibles par le code JavaScript s'exécutant 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 par le biais des en-têtes de requête et de réponse HTTP.
  • Cookie sécurisé - 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 en charge de sous-domaine, un attaquant peut collecter les cookies émis par ce domaine dans le passé en trompant les utilisateurs pour qu'ils visitent ce site Web. Les drapeaux HttpOnly et Secure ne sont pas utiles car le cookie n'est pas accédé à l'aide de JavaScript et un certificat SSL peut être facilement généré pour le domaine pris.

Le vol de cookies en utilisant la prise en charge a été expliqué dans un rapport de prime de bug rapport 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 en charge de sous-domaine, pointant vers une distribution AWS CloudFront non réclamée. Étant donné qu'Ubiquiti Networks utilise SSO avec des cookies de session génériques, tous les utilisateurs visitant ping.ubnt.com pouvaient voir leurs cookies de session volés. Même si ce domaine pointe vers AWS CloudFront, les paramètres de distribution de CloudFront permettent de journaliser les cookies avec chaque requête. Par conséquent, le scénario d'extraction des cookies de session est tout à fait possible même avec des sous-domaines pointant vers AWS CloudFront. En 2017, Arne a également démontré une attaque similaire contre le système SSO d'Uber.

Le comportement expliqué ci-dessus ne se limite pas aux cookies. Étant donné que les scripts JavaScript ont un contrôle total sur les sites Web sur lesquels ils s'exécutent, la possibilité de remplacer de tels scripts sur le site légitime peut entraîner des conséquences catastrophiques. Supposons que le site Web utilise du code JavaScript provenant d'un fournisseur externe à l'aide de la balise script et de 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 n'effectue aucune tâche importante (par exemple, il est utilisé uniquement pour le suivi), ce fournisseur externe peut rester sur le site pendant une période prolongée. Un attaquant peut prendre le contrôle de ce domaine expiré, faire correspondre le chemin d'URL du code JavaScript fourni et ainsi prendre le contrôle de chaque visiteur qui visite le site d'origine.

Cependant, il existe un moyen de protéger l'intégrité des fichiers JavaScript dans un navigateur. Subresource Integrity a été proposé comme un mécanisme pour inclure une empreinte cryptographique en tant qu'attribut integrity dans la balise script en HTML5. Lorsque l'empreinte cryptographique fournie ne correspond pas au fichier téléchargé, le navigateur refuse de l'exécuter.

E-mails

Lorsqu'une prise en charge 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 sur un sous-domaine légitime d'une marque, ce qui est particulièrement utile dans les attaques de phishing (ciblées) où une interaction entre un attaquant et une victime est nécessaire. Les attaquants falsifient généralement l'en-tête Return-Path pour recevoir une réponse à l'e-mail. Avec les enregistrements MX corrects, 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 e-mails pour le domaine. SPF stocke la configuration dans les enregistrements DNS TXT. Avec la prise en charge de sous-domaine, les enregistrements TXT sont également contrôlés par 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 car vous n'avez pas un contrôle direct sur la zone DNS.

Risques d'ordre supérieur

Le concept de prise en charge 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 en charge de sous-domaine.

L'un des problèmes de la prise en charge de sous-domaine en utilisant l'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 au hasard 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 du ns.vulnerable.com, la situation du point de vue de l'utilisateur qui interroge sub.example.com est la suivante :

  1. Étant donné qu'il y a deux serveurs de noms, l'un est choisi au hasard. Cela signifie que la probabilité d'interroger un 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 renvoyé et est susceptible d'être 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 détenu par un attaquant), un attaquant peut fournir un faux résultat qui sera également mis en cache. Étant donné qu'un attaquant contrôle le serveur de noms, elle peut définir le TTL pour ce résultat particulier, par exemple une semaine.

Le processus ci-dessus est répété chaque fois que l'entrée du cache expire. Lorsqu'un attaquant choisit d'utiliser un TTL avec une valeur élevée, le faux résultat restera dans le cache DNS pendant 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 de 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. Cela est dû au fait que posséder un nom de domaine canonique de l'enregistrement NS signifie posséder la zone DNS complète du nom de domaine source.

En 2016, Matthew Bryant a démontré une prise en charge de sous-domaine en utilisant l'enregistrement NS sur maris.int. Le domaine de premier niveau .INT est un TLD spécial, et seuls quelques 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 sur des domaines arbitraires. Étant donné que l'un des serveurs de noms de maris.int était disponible à l'enregistrement (cobalt.aliis.be), la prise en charge de sous-domaine était possible

Atténuation

Les stratégies d'atténuation pour les noms de domaine déjà vulnérables à une prise en charge de sous-domaine sont assez simples :

  • Supprimer l'enregistrement DNS affecté - La solution la plus simple consiste à 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.
  • Revendiquer le nom de domaine - Cela signifie enregistrer la ressource auprès d'un fournisseur de cloud spécifique ou, dans le cas d'un domaine Internet régulier, racheter le domaine expiré.

Pour éviter une prise en charge de sous-domaine à l'avenir, les organisations doivent modifier le processus de création et de destruction des ressources de leur infrastructure. En cas de création de ressources, 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 inexistant à un moment donné. Pour la destruction des ressources, l'inverse est vrai : l'enregistrement DNS doit être supprimé en tant que première étape de ce processus. Des outils tels que aquatone incluent des vérifications de prise en charge de sous-domaine. Les vérifications doivent être effectuées périodiquement par une équipe de sécurité d'une organisation pour vérifier l'absence 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 doit également être prise en compte. Les services cloud ne vérifient pas la propriété du domaine. La raison en est principalement la commodité. Le fournisseur de cloud n'introduit aucune vulnérabilité en ne vérifiant pas la propriété d'un nom de domaine source. Il incombe 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 client de ce service. Les fournisseurs de cloud se posent alors la question : pourquoi devrions-nous nous en soucier ?

Des fournisseurs tels que GitLab ont réalisé que la prise en charge de sous-domaine est un problème et ont mis en place un mécanisme de vérification de domaine.

Certaines parties de cet article sont extraites de ma thèse de maîtrise.

À la prochaine !

Patrik


Utilisez Trickest pour créer et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui :

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥