mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/domain-subdomain-takeover.md', 'src/pent
This commit is contained in:
Translator
parent
b6bdb263ea
commit
2f601733b0
@ -2,10 +2,9 @@
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## 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 la **société** a **perdu** la **propriété** de celui-ci, vous pouvez essayer de **l'enregistrer** (si le prix est suffisamment bas) et informer la société. 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 certainement une **vulnérabilité**.
|
||||
Si vous découvrez un domaine (domain.tld) qui est **utilisé par un service dans le périmètre** mais que la **société** a **perdu** la **propriété** de celui-ci, vous pouvez essayer de **l'enregistrer** (si c'est assez bon marché) et informer la société. 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 certainement une **vulnérabilité**.
|
||||
|
||||
### Prise de contrôle de sous-domaine
|
||||
|
||||
@ -33,13 +32,13 @@ Lorsque le wildcard DNS est utilisé dans un domaine, tout sous-domaine demandé
|
||||
|
||||
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 G**ithub** par exemple (`sohomdatta1.github.io`). Un attaquant pourrait **créer sa propre page tierce** (sur Gihub dans ce cas) et dire que `something.testing.com` pointe là. Parce que, le **CNAME wildcard** permettra à l'attaquant de **générer des sous-domaines arbitraires pour le domaine de la victime pointant vers ses pages**.
|
||||
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 G**ithub** par exemple (`sohomdatta1.github.io`). Un attaquant pourrait **créer sa propre page tierce** (dans Gihub dans ce cas) et dire que `something.testing.com` pointe là-bas. Parce que, le **CNAME wildcard** permettra à l'attaquant de **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 rapport CTF : [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)
|
||||
|
||||
## Exploitation d'une prise de contrôle de sous-domaine
|
||||
|
||||
La prise de contrôle de sous-domaine est essentiellement un 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 du contenu depuis le serveur de l'attaquant. Cette **transparence** dans les navigateurs rend les domaines vulnérables au phishing. Les attaquants peuvent utiliser [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) ou [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) à 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.
|
||||
La prise de contrôle de sous-domaine est essentiellement un spoofing DNS pour un domaine spécifique sur Internet, permettant aux attaquants de définir des enregistrements A pour un domaine, amenant les navigateurs à afficher du contenu depuis le serveur de l'attaquant. Cette **transparence** dans les navigateurs rend les domaines vulnérables au phishing. Les attaquants peuvent utiliser [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) ou [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) à 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](https://0xpatrik.com/subdomain-takeover/)
|
||||
|
||||
@ -49,7 +48,23 @@ Les certificats SSL, s'ils sont générés par des attaquants via des services c
|
||||
|
||||
### **Sécurité des cookies et transparence des navigateurs**
|
||||
|
||||
La transparence des navigateurs s'étend également à la sécurité des cookies, régie par des politiques comme la [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Les cookies, souvent utilisés pour gérer les sessions et stocker les jetons de connexion, peuvent être exploités par la prise de contrôle de sous-domaine. Les attaquants peuvent **rassembler des cookies de session** simplement en dirigeant les utilisateurs vers un sous-domaine compromis, mettant en danger les données et la vie privée des utilisateurs.
|
||||
La transparence des navigateurs s'étend également à la sécurité des cookies, régie par des politiques comme la [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy). Les cookies, souvent utilisés pour gérer les sessions et stocker des jetons de connexion, peuvent être exploités par la prise de contrôle de sous-domaine. Les attaquants peuvent **rassembler des cookies de session** simplement en dirigeant les utilisateurs vers un sous-domaine compromis, mettant en danger les données et la vie privée des utilisateurs.
|
||||
|
||||
### Contournement CORS
|
||||
|
||||
Il pourrait ê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 - Contournement des cookies Same-Site
|
||||
|
||||
Il pourrait être possible que le sous-domaine soit autorisé à envoyer des cookies au domaine ou à d'autres sous-domaines, ce qui était empêché par l'attribut `Same-Site` des cookies. Cependant, notez que les jetons anti-CSRF empêcheront toujours cette attaque s'ils sont correctement implémentés.
|
||||
|
||||
### Redirection des jetons OAuth
|
||||
|
||||
Il pourrait être possible que le sous-domaine compromis soit autorisé à être utilisé dans l'URL `redirect_uri` d'un flux OAuth. Cela pourrait être exploité par un attaquant pour **voler le jeton OAuth**.
|
||||
|
||||
### Contournement CSP
|
||||
|
||||
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 des vulnérabilités potentielles XSS.
|
||||
|
||||
### **E-mails et prise de contrôle de sous-domaine**
|
||||
|
||||
@ -77,5 +92,6 @@ Pour les fournisseurs de cloud, vérifier la propriété du domaine est crucial
|
||||
|
||||
- [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
|
||||
- [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
|
||||
- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@ -16,7 +16,7 @@ Les hôtes qui reçoivent un cookie sont spécifiés par l'attribut `Domain`. Pa
|
||||
|
||||
### Chemin
|
||||
|
||||
Un chemin d'URL spécifique qui doit être présent dans l'URL demandée pour que l'en-tête `Cookie` soit envoyé est indiqué par l'attribut `Path`. Cet attribut considère le caractère `/` comme un séparateur de répertoire, permettant des correspondances dans les sous-répertoires également.
|
||||
Un chemin URL spécifique qui doit être présent dans l'URL demandée pour que l'en-tête `Cookie` soit envoyé est indiqué par l'attribut `Path`. Cet attribut considère le caractère `/` comme un séparateur de répertoire, permettant des correspondances dans les sous-répertoires également.
|
||||
|
||||
### Règles de Commande
|
||||
|
||||
@ -28,7 +28,7 @@ Lorsque deux cookies portent le même nom, celui choisi pour l'envoi est basé s
|
||||
### SameSite
|
||||
|
||||
- L'attribut `SameSite` dicte si les cookies sont envoyés lors de requêtes provenant de domaines tiers. Il offre trois paramètres :
|
||||
- **Strict** : Empêche l'envoi du cookie lors de requêtes tierces.
|
||||
- **Strict** : Restreint l'envoi du cookie lors de requêtes tierces.
|
||||
- **Lax** : Permet l'envoi du cookie avec des requêtes GET initiées par des sites web tiers.
|
||||
- **None** : Permet l'envoi du cookie depuis n'importe quel domaine tiers.
|
||||
|
||||
@ -56,9 +56,9 @@ Notez qu'après avoir appliqué ce changement, les **cookies sans politique Same
|
||||
|
||||
Cela empêche le **client** d'accéder au cookie (via **Javascript**, par exemple : `document.cookie`)
|
||||
|
||||
#### **Bypasses**
|
||||
#### **Contournements**
|
||||
|
||||
- Si la page **envoie les cookies en réponse** à des requêtes (par exemple dans une page **PHPinfo**), il est possible d'abuser de l'XSS pour envoyer une requête à cette page et **voler les cookies** de la réponse (voir un exemple dans [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/)).
|
||||
- Si la page **envoie les cookies en réponse** à une requête (par exemple dans une page **PHPinfo**), il est possible d'abuser de l'XSS pour envoyer une requête à cette page et **voler les cookies** de la réponse (voir un exemple dans [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/)).
|
||||
- Cela pourrait être contourné avec des requêtes **TRACE** **HTTP** car la réponse du serveur (si cette méthode HTTP est disponible) reflétera les cookies envoyés. Cette technique est appelée **Cross-Site Tracking**.
|
||||
- Cette technique est évitée par **les navigateurs modernes en ne permettant pas l'envoi d'une requête TRACE** depuis JS. Cependant, certains contournements ont été trouvés dans des logiciels spécifiques comme l'envoi de `\r\nTRACE` au lieu de `TRACE` à IE6.0 SP2.
|
||||
- Une autre méthode est l'exploitation de vulnérabilités zero-day des navigateurs.
|
||||
@ -72,7 +72,7 @@ cookie-jar-overflow.md
|
||||
|
||||
### Secure
|
||||
|
||||
La requête **n'enverra** le cookie que dans une requête HTTP si la requête est transmise sur un canal sécurisé (typiquement **HTTPS**).
|
||||
La requête n'enverra **que** le cookie dans une requête HTTP uniquement si la requête est transmise sur un canal sécurisé (typiquement **HTTPS**).
|
||||
|
||||
## Préfixes des Cookies
|
||||
|
||||
@ -87,17 +87,17 @@ Pour les cookies préfixés par `__Host-`, plusieurs conditions doivent être re
|
||||
|
||||
Il est important de noter que les cookies préfixés par `__Host-` ne sont pas autorisés à être envoyés à des superdomaines ou sous-domaines. Cette restriction aide à isoler les cookies d'application. Ainsi, utiliser le préfixe `__Host-` pour tous les cookies d'application peut être considéré comme une bonne pratique pour améliorer la sécurité et l'isolement.
|
||||
|
||||
### Surcharge des cookies
|
||||
### Surcharger les cookies
|
||||
|
||||
Ainsi, l'une des protections des cookies préfixés par `__Host-` est d'empêcher leur surcharge depuis des sous-domaines. Prévenir par exemple les [**attaques de Cookie Tossing**](cookie-tossing.md). Dans la présentation [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**document**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)), il est présenté qu'il était possible de définir des cookies préfixés par \_\_HOST- depuis un sous-domaine, en trompant le parseur, par exemple, en ajoutant "=" au début ou au début et à la fin... :
|
||||
Ainsi, l'une des protections des cookies préfixés par `__Host-` est d'empêcher leur écrasement depuis des sous-domaines. Prévenir par exemple les [**attaques de Cookie Tossing**](cookie-tossing.md). Dans la présentation [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**document**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)), il est présenté qu'il était possible de définir des cookies préfixés par __HOST- depuis un sous-domaine, en trompant le parseur, par exemple, en ajoutant "=" au début ou à la fin... :
|
||||
|
||||
<figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Ou en PHP, il était possible d'ajouter **d'autres caractères au début** du nom du cookie qui allaient être **remplacés par des caractères de soulignement**, permettant de surcharger les cookies `__HOST-` :
|
||||
Ou en PHP, il était possible d'ajouter **d'autres caractères au début** du nom du cookie qui allaient être **remplacés par des caractères de soulignement**, permettant d'écraser les cookies `__HOST-` :
|
||||
|
||||
<figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>
|
||||
|
||||
## Attaques sur les Cookies
|
||||
## Attaques par Cookies
|
||||
|
||||
Si un cookie personnalisé contient des données sensibles, vérifiez-le (surtout si vous participez à un CTF), car il pourrait être vulnérable.
|
||||
|
||||
@ -147,7 +147,7 @@ document.cookie = "a=v1"
|
||||
document.cookie = "=test value;" // Setting an empty named cookie
|
||||
document.cookie = "b=v2"
|
||||
```
|
||||
Le résultat dans l'en-tête de cookie envoyé est `a=v1; test value; b=v2;`. Il est intéressant de noter que cela permet la manipulation des cookies si un cookie avec un nom vide est défini, contrôlant potentiellement d'autres cookies en définissant le cookie vide à une valeur spécifique :
|
||||
Le résultat dans l'en-tête de cookie envoyé est `a=v1; test value; b=v2;`. Intriguement, cela permet la manipulation des cookies si un cookie avec un nom vide est défini, contrôlant potentiellement d'autres cookies en définissant le cookie vide à une valeur spécifique :
|
||||
```js
|
||||
function setCookie(name, value) {
|
||||
document.cookie = `${name}=${value}`
|
||||
@ -181,22 +181,47 @@ RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
||||
|
||||
Cette vulnérabilité est particulièrement dangereuse dans les applications web s'appuyant sur une protection CSRF basée sur des cookies, car elle permet aux attaquants d'injecter des cookies de token CSRF falsifiés, contournant potentiellement les mesures de sécurité. Le problème est aggravé par la gestion des noms de cookies en double par Python, où la dernière occurrence remplace les précédentes. Cela soulève également des préoccupations pour les cookies `__Secure-` et `__Host-` dans des contextes non sécurisés et pourrait entraîner des contournements d'autorisation lorsque des cookies sont transmis à des serveurs back-end susceptibles de falsification.
|
||||
|
||||
### Cookies $version et contournements de WAF
|
||||
### Cookies $version
|
||||
|
||||
#### Contournement de WAF
|
||||
|
||||
Selon [**cet article de blog**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), il pourrait être possible d'utiliser l'attribut de cookie **`$Version=1`** pour amener le back-end à utiliser une ancienne logique pour parser le cookie en raison de la **RFC2109**. De plus, d'autres valeurs comme **`$Domain`** et **`$Path`** peuvent être utilisées pour modifier le comportement du back-end avec le cookie.
|
||||
|
||||
#### Analyse de contournement de valeur avec encodage de chaîne entre guillemets
|
||||
#### Attaque de sandwich de cookies
|
||||
|
||||
Ce parsing indique de déséchapper les valeurs échappées à l'intérieur des cookies, donc "\a" devient "a". Cela peut être utile pour contourner les WAFS car :
|
||||
Selon [**cet article de blog**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique), il est possible d'utiliser la technique du sandwich de cookies pour voler des cookies HttpOnly. Voici les exigences et étapes :
|
||||
|
||||
- Trouver un endroit où un **cookie apparemment inutile est reflété dans la réponse**
|
||||
- **Créer un cookie appelé `$Version`** avec la valeur `1` (vous pouvez faire cela dans une attaque XSS depuis JS) avec un chemin plus spécifique afin qu'il obtienne la position initiale (certains frameworks comme Python n'ont pas besoin de cette étape)
|
||||
- **Créer le cookie qui est reflété** avec une valeur qui laisse des **guillemets doubles ouverts** et avec un chemin spécifique afin qu'il soit positionné dans la base de données des cookies après le précédent (`$Version`)
|
||||
- Ensuite, le cookie légitime viendra ensuite dans l'ordre
|
||||
- **Créer un cookie factice qui ferme les guillemets doubles** à l'intérieur de sa valeur
|
||||
|
||||
De cette manière, le cookie de la victime est piégé à l'intérieur du nouveau cookie version 1 et sera reflété chaque fois qu'il est reflété.
|
||||
```javascript
|
||||
document.cookie = `$Version=1;`;
|
||||
document.cookie = `param1="start`;
|
||||
// any cookies inside the sandwich will be placed into param1 value server-side
|
||||
document.cookie = `param2=end";`;
|
||||
```
|
||||
### Bypasses WAF
|
||||
|
||||
#### Cookies $version
|
||||
|
||||
Consultez la section précédente.
|
||||
|
||||
#### Analyse de contournement des valeurs avec l'encodage de chaînes entre guillemets
|
||||
|
||||
Cette analyse indique de déséchapper les valeurs échappées à l'intérieur des cookies, donc "\a" devient "a". Cela peut être utile pour contourner les WAFS car :
|
||||
|
||||
- `eval('test') => interdit`
|
||||
- `"\e\v\a\l\(\'\t\e\s\t\'\)" => autorisé`
|
||||
|
||||
#### Contournement des listes de blocage de noms de cookies
|
||||
#### Contournement des listes de blocage des noms de cookies
|
||||
|
||||
Dans la RFC2109, il est indiqué qu'une **virgule peut être utilisée comme séparateur entre les valeurs de cookie**. Et il est également possible d'ajouter **des espaces et des tabulations avant et après le signe égal**. Par conséquent, un cookie comme `$Version=1; foo=bar, abc = qux` ne génère pas le cookie `"foo":"bar, admin = qux"` mais les cookies `foo":"bar"` et `"admin":"qux"`. Remarquez comment 2 cookies sont générés et comment l'espace avant et après le signe égal a été supprimé pour admin.
|
||||
Dans le RFC2109, il est indiqué qu'une **virgule peut être utilisée comme séparateur entre les valeurs des cookies**. Et il est également possible d'ajouter **des espaces et des tabulations avant et après le signe égal**. Par conséquent, un cookie comme `$Version=1; foo=bar, abc = qux` ne génère pas le cookie `"foo":"bar, admin = qux"` mais les cookies `foo":"bar"` et `"admin":"qux"`. Remarquez comment 2 cookies sont générés et comment l'espace avant et après le signe égal a été supprimé pour admin.
|
||||
|
||||
#### Analyse de contournement de valeur avec séparation de cookies
|
||||
#### Contournement de l'analyse des valeurs avec le fractionnement des cookies
|
||||
|
||||
Enfin, différentes portes dérobées pourraient se joindre dans une chaîne de différents cookies passés dans différents en-têtes de cookies comme dans :
|
||||
```
|
||||
@ -273,7 +298,7 @@ Créez 2 utilisateurs avec presque les mêmes données (nom d'utilisateur, mot d
|
||||
|
||||
Créez un utilisateur appelé par exemple "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" et vérifiez s'il y a un motif dans le cookie (comme ECB chiffre avec la même clé chaque bloc, les mêmes octets chiffrés pourraient apparaître si le nom d'utilisateur est chiffré).
|
||||
|
||||
Il devrait y avoir un motif (avec la taille d'un bloc utilisé). Donc, en sachant comment un tas de "a" est chiffré, vous pouvez créer un nom d'utilisateur : "a"\*(taille du bloc)+"admin". Ensuite, vous pourriez supprimer le motif chiffré d'un bloc de "a" du cookie. Et vous aurez le cookie du nom d'utilisateur "admin".
|
||||
Il devrait y avoir un motif (avec la taille d'un bloc utilisé). Donc, sachant comment un tas de "a" est chiffré, vous pouvez créer un nom d'utilisateur : "a"\*(taille du bloc)+"admin". Ensuite, vous pourriez supprimer le motif chiffré d'un bloc de "a" du cookie. Et vous aurez le cookie du nom d'utilisateur "admin".
|
||||
|
||||
## Références
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user