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

Prise de contrôle de domaine/sous-domaine

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

• Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT!
• Découvrez The PEASS Family, notre collection exclusive de NFTs
• Obtenez le swag officiel PEASS & HackTricks
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
• Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Utilisez Trickest pour créer 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" %}

Prise de contrôle de domaine

Si vous découvrez un domaine (domaine.tld) qui est utilisé par un service dans le cadre mais que l'entreprise a perdu la propriété de celui-ci, vous pouvez essayer de l'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 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 cours d'utilisation, vous pouvez effectuer la prise de contrôle de 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/ArifulProt

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 également 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 y a un sous-domaine vulnérable à la prise en charge de sous-domaine, la seule chose à faire pour recueillir 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 implémente également 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 peut être communiqué de nouveau au serveur Web uniquement si HTTPS est utilisé.

Si le domaine est vulnérable à la prise en charge de sous-domaine, un attaquant peut recueillir des 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 le 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 le rapport de prime de bogues report 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 pourraient avoir 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 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.

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 sont exécutés, la capacité de remplacer de tels scripts sur le site Web légitime pourrait entraîner des conséquences catastrophiques. Supposons que le site Web utilise du code Javascript provenant du 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 pas d'alertes visibles 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 peut rester sur le site Web 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 Web d'origine.

Il existe cependant un moyen de protéger l'intégrité des fichiers Javascript dans un navigateur. Subresource Integrity a été proposé comme mécanisme pour inclure le hachage cryptographique en tant qu'attribut integrity à la balise script dans HTML5. Lorsque le hachage cryptographique fourni ne correspond pas au fichier de téléchargement, le navigateur refuse de l'exécuter.

E-mails

Lorsque la prise en charge de sous-domaine CNAME est possible, des 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 certaine marque - particulièrement utile à nouveau dans les attaques de (spear) phishing où l'interaction entre un attaquant et une victime est nécessaire. Les attaquants falsifient généralement l'en-tête Return-Path pour recevoir