mirror of
https://github.com/carlospolop/hacktricks
synced 2025-02-18 15:08:29 +00:00
292 lines
21 KiB
Markdown
292 lines
21 KiB
Markdown
# Cookies Hacking
|
|
|
|
{% hint style="success" %}
|
|
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
|
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
**Try Hard Security Group**
|
|
|
|
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
***
|
|
|
|
## Attributs des Cookies
|
|
|
|
Les cookies possèdent plusieurs attributs qui contrôlent leur comportement dans le navigateur de l'utilisateur. Voici un aperçu de ces attributs dans un style plus passif :
|
|
|
|
### Expire et Max-Age
|
|
|
|
La date d'expiration d'un cookie est déterminée par l'attribut `Expires`. En revanche, l'attribut `Max-age` définit le temps en secondes jusqu'à ce qu'un cookie soit supprimé. **Optez pour `Max-age` car il reflète des pratiques plus modernes.**
|
|
|
|
### Domaine
|
|
|
|
Les hôtes qui reçoivent un cookie sont spécifiés par l'attribut `Domain`. Par défaut, cela est défini sur l'hôte qui a émis le cookie, sans inclure ses sous-domaines. Cependant, lorsque l'attribut `Domain` est explicitement défini, il englobe également les sous-domaines. Cela rend la spécification de l'attribut `Domain` une option moins restrictive, utile dans les scénarios où le partage de cookies entre sous-domaines est nécessaire. Par exemple, définir `Domain=mozilla.org` rend les cookies accessibles sur ses sous-domaines comme `developer.mozilla.org`.
|
|
|
|
### Chemin
|
|
|
|
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
|
|
|
|
Lorsque deux cookies portent le même nom, celui choisi pour l'envoi est basé sur :
|
|
|
|
* Le cookie correspondant au chemin le plus long dans l'URL demandée.
|
|
* Le cookie le plus récemment défini si les chemins sont identiques.
|
|
|
|
### 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** : 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.
|
|
|
|
N'oubliez pas, lors de la configuration des cookies, que comprendre ces attributs peut aider à garantir qu'ils se comportent comme prévu dans différents scénarios.
|
|
|
|
| **Type de Requête** | **Code Exemple** | **Cookies Envoyés Quand** |
|
|
| ------------------- | ---------------------------------- | ------------------------- |
|
|
| Lien | \<a href="...">\</a> | NotSet\*, Lax, None |
|
|
| Prerender | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None |
|
|
| Formulaire GET | \<form method="GET" action="..."> | NotSet\*, Lax, None |
|
|
| Formulaire POST | \<form method="POST" action="..."> | NotSet\*, None |
|
|
| iframe | \<iframe src="...">\</iframe> | NotSet\*, None |
|
|
| AJAX | $.get("...") | NotSet\*, None |
|
|
| Image | \<img src="..."> | NetSet\*, None |
|
|
|
|
Tableau provenant de [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) et légèrement modifié.\
|
|
Un cookie avec l'attribut _**SameSite**_ **atténuera les attaques CSRF** où une session connectée est nécessaire.
|
|
|
|
**\*Notez qu'à partir de Chrome80 (février 2019), le comportement par défaut d'un cookie sans attribut SameSite** **sera lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
|
|
Notez qu'après avoir appliqué ce changement, les **cookies sans politique SameSite** **dans Chrome seront** **traités comme None** pendant les **premières 2 minutes, puis comme Lax pour les requêtes POST inter-domaines de niveau supérieur.**
|
|
|
|
## Drapeaux des Cookies
|
|
|
|
### HttpOnly
|
|
|
|
Cela empêche le **client** d'accéder au cookie (via **Javascript**, par exemple : `document.cookie`)
|
|
|
|
#### **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 sur [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.
|
|
* Il est possible de **surcharger les cookies HttpOnly** en effectuant une attaque de débordement de Cookie Jar :
|
|
|
|
{% content-ref url="cookie-jar-overflow.md" %}
|
|
[cookie-jar-overflow.md](cookie-jar-overflow.md)
|
|
{% endcontent-ref %}
|
|
|
|
* Il est possible d'utiliser l'attaque [**Cookie Smuggling**](./#cookie-smuggling) pour exfiltrer ces cookies.
|
|
|
|
### Secure
|
|
|
|
La requête **n'enverra** le cookie que dans une requête HTTP si la requête est transmise par un canal sécurisé (typiquement **HTTPS**).
|
|
|
|
## Préfixes des Cookies
|
|
|
|
Les cookies préfixés par `__Secure-` doivent être définis avec le drapeau `secure` des pages sécurisées par HTTPS.
|
|
|
|
Pour les cookies préfixés par `__Host-`, plusieurs conditions doivent être remplies :
|
|
|
|
* Ils doivent être définis avec le drapeau `secure`.
|
|
* Ils doivent provenir d'une page sécurisée par HTTPS.
|
|
* Ils sont interdits de spécifier un domaine, empêchant leur transmission aux sous-domaines.
|
|
* Le chemin pour ces cookies doit être défini sur `/`.
|
|
|
|
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.
|
|
|
|
### Surcharger les cookies
|
|
|
|
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) ([**papier**](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="../../.gitbook/assets/image (6) (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 d'écraser les cookies `__HOST-` :
|
|
|
|
<figure><img src="../../.gitbook/assets/image (7) (1).png" alt="" width="373"><figcaption></figcaption></figure>
|
|
|
|
## 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.
|
|
|
|
### Décodage et Manipulation des Cookies
|
|
|
|
Les données sensibles intégrées dans les cookies doivent toujours être examinées. Les cookies encodés en Base64 ou dans des formats similaires peuvent souvent être décodés. Cette vulnérabilité permet aux attaquants de modifier le contenu du cookie et d'usurper d'autres utilisateurs en réencodant leurs données modifiées dans le cookie.
|
|
|
|
### Détournement de Session
|
|
|
|
Cette attaque consiste à voler le cookie d'un utilisateur pour obtenir un accès non autorisé à son compte dans une application. En utilisant le cookie volé, un attaquant peut usurper l'utilisateur légitime.
|
|
|
|
### Fixation de Session
|
|
|
|
Dans ce scénario, un attaquant trompe une victime pour qu'elle utilise un cookie spécifique pour se connecter. Si l'application n'attribue pas un nouveau cookie lors de la connexion, l'attaquant, possédant le cookie original, peut usurper la victime. Cette technique repose sur le fait que la victime se connecte avec un cookie fourni par l'attaquant.
|
|
|
|
Si vous avez trouvé un **XSS dans un sous-domaine** ou si vous **contrôlez un sous-domaine**, lisez :
|
|
|
|
{% content-ref url="cookie-tossing.md" %}
|
|
[cookie-tossing.md](cookie-tossing.md)
|
|
{% endcontent-ref %}
|
|
|
|
### Don de Session
|
|
|
|
Ici, l'attaquant convainc la victime d'utiliser le cookie de session de l'attaquant. La victime, croyant qu'elle est connectée à son propre compte, effectuera involontairement des actions dans le contexte du compte de l'attaquant.
|
|
|
|
Si vous avez trouvé un **XSS dans un sous-domaine** ou si vous **contrôlez un sous-domaine**, lisez :
|
|
|
|
{% content-ref url="cookie-tossing.md" %}
|
|
[cookie-tossing.md](cookie-tossing.md)
|
|
{% endcontent-ref %}
|
|
|
|
### [Cookies JWT](../hacking-jwt-json-web-tokens.md)
|
|
|
|
Cliquez sur le lien précédent pour accéder à une page expliquant les défauts possibles dans JWT.
|
|
|
|
Les JSON Web Tokens (JWT) utilisés dans les cookies peuvent également présenter des vulnérabilités. Pour des informations approfondies sur les défauts potentiels et comment les exploiter, il est recommandé d'accéder au document lié sur le hacking JWT.
|
|
|
|
### Cross-Site Request Forgery (CSRF)
|
|
|
|
Cette attaque force un utilisateur connecté à exécuter des actions non désirées sur une application web dans laquelle il est actuellement authentifié. Les attaquants peuvent exploiter les cookies qui sont automatiquement envoyés avec chaque requête vers le site vulnérable.
|
|
|
|
### Cookies Vides
|
|
|
|
(Vérifiez plus de détails dans la [recherche originale](https://blog.ankursundara.com/cookie-bugs/)) Les navigateurs permettent la création de cookies sans nom, ce qui peut être démontré par JavaScript comme suit :
|
|
```js
|
|
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;`. 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}`;
|
|
}
|
|
|
|
setCookie("", "a=b"); // Setting the empty cookie modifies another cookie's value
|
|
```
|
|
Cela conduit le navigateur à envoyer un en-tête de cookie interprété par chaque serveur web comme un cookie nommé `a` avec une valeur `b`.
|
|
|
|
#### Bug Chrome : Problème de Codepoint de Surrogate Unicode
|
|
|
|
Dans Chrome, si un codepoint de surrogate Unicode fait partie d'un cookie défini, `document.cookie` devient corrompu, renvoyant une chaîne vide par la suite :
|
|
```js
|
|
document.cookie = "\ud800=meep";
|
|
```
|
|
Cela entraîne que `document.cookie` renvoie une chaîne vide, indiquant une corruption permanente.
|
|
|
|
#### Cookie Smuggling en raison de problèmes de parsing
|
|
|
|
(Voir plus de détails dans la [recherche originale](https://blog.ankursundara.com/cookie-bugs/)) Plusieurs serveurs web, y compris ceux de Java (Jetty, TomCat, Undertow) et Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), gèrent mal les chaînes de cookies en raison d'un support obsolète de RFC2965. Ils lisent une valeur de cookie entre guillemets comme une seule valeur même si elle inclut des points-virgules, qui devraient normalement séparer les paires clé-valeur :
|
|
```
|
|
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
|
```
|
|
#### Vulnérabilités d'injection de cookies
|
|
|
|
(Voir plus de détails dans la [recherche originale](https://blog.ankursundara.com/cookie-bugs/)) L'analyse incorrecte des cookies par les serveurs, notamment Undertow, Zope, et ceux utilisant `http.cookie.SimpleCookie` et `http.cookie.BaseCookie` de Python, crée des opportunités pour des attaques par injection de cookies. Ces serveurs ne parviennent pas à délimiter correctement le début de nouveaux cookies, permettant aux attaquants de falsifier des cookies :
|
|
|
|
* Undertow s'attend à un nouveau cookie immédiatement après une valeur entre guillemets sans point-virgule.
|
|
* Zope recherche une virgule pour commencer à analyser le cookie suivant.
|
|
* Les classes de cookies de Python commencent à analyser sur un caractère d'espace.
|
|
|
|
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.
|
|
|
|
### Vérifications supplémentaires des cookies vulnérables
|
|
|
|
#### **Vérifications de base**
|
|
|
|
* Le **cookie** est le **même** chaque fois que vous **vous connectez**.
|
|
* Déconnectez-vous et essayez d'utiliser le même cookie.
|
|
* Essayez de vous connecter avec 2 appareils (ou navigateurs) au même compte en utilisant le même cookie.
|
|
* Vérifiez si le cookie contient des informations et essayez de le modifier.
|
|
* Essayez de créer plusieurs comptes avec des noms d'utilisateur presque identiques et vérifiez si vous pouvez voir des similitudes.
|
|
* Vérifiez l'option "**se souvenir de moi**" si elle existe pour voir comment elle fonctionne. Si elle existe et pourrait être vulnérable, utilisez toujours le cookie de **se souvenir de moi** sans aucun autre cookie.
|
|
* Vérifiez si le cookie précédent fonctionne même après avoir changé le mot de passe.
|
|
|
|
#### **Attaques avancées sur les cookies**
|
|
|
|
Si le cookie reste le même (ou presque) lorsque vous vous connectez, cela signifie probablement que le cookie est lié à un champ de votre compte (probablement le nom d'utilisateur). Ensuite, vous pouvez :
|
|
|
|
* Essayer de créer beaucoup de **comptes** avec des noms d'utilisateur très **similaires** et essayer de **deviner** comment l'algorithme fonctionne.
|
|
* Essayer de **bruteforcer le nom d'utilisateur**. Si le cookie est enregistré uniquement comme méthode d'authentification pour votre nom d'utilisateur, alors vous pouvez créer un compte avec le nom d'utilisateur "**Bmin**" et **bruteforcer** chaque **bit** de votre cookie car l'un des cookies que vous allez essayer sera celui appartenant à "**admin**".
|
|
* Essayer **Padding** **Oracle** (vous pouvez déchiffrer le contenu du cookie). Utilisez **padbuster**.
|
|
|
|
**Padding Oracle - Exemples de Padbuster**
|
|
```bash
|
|
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
|
|
# When cookies and regular Base64
|
|
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf
|
|
|
|
# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
|
|
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
|
|
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2
|
|
```
|
|
Padbuster fera plusieurs tentatives et vous demandera quelle condition est la condition d'erreur (celle qui n'est pas valide).
|
|
|
|
Ensuite, il commencera à déchiffrer le cookie (cela peut prendre plusieurs minutes)
|
|
|
|
Si l'attaque a été réalisée avec succès, vous pourriez essayer de chiffrer une chaîne de votre choix. Par exemple, si vous souhaitez **encrypt** **user=administrator**
|
|
```
|
|
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
|
|
```
|
|
Cette exécution vous donnera le cookie correctement chiffré et encodé avec la chaîne **user=administrator** à l'intérieur.
|
|
|
|
**CBC-MAC**
|
|
|
|
Peut-être qu'un cookie pourrait avoir une certaine valeur et pourrait être signé en utilisant CBC. Ensuite, l'intégrité de la valeur est la signature créée en utilisant CBC avec la même valeur. Comme il est recommandé d'utiliser comme IV un vecteur nul, ce type de vérification d'intégrité pourrait être vulnérable.
|
|
|
|
**L'attaque**
|
|
|
|
1. Obtenez la signature du nom d'utilisateur **administ** = **t**
|
|
2. Obtenez la signature du nom d'utilisateur **rator\x00\x00\x00 XOR t** = **t'**
|
|
3. Mettez dans le cookie la valeur **administrator+t'** (**t'** sera une signature valide de **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00**
|
|
|
|
**ECB**
|
|
|
|
Si le cookie est chiffré en utilisant ECB, il pourrait être vulnérable.\
|
|
Lorsque vous vous connectez, le cookie que vous recevez doit toujours être le même.
|
|
|
|
**Comment détecter et attaquer :**
|
|
|
|
Créez 2 utilisateurs avec presque les mêmes données (nom d'utilisateur, mot de passe, e-mail, etc.) et essayez de découvrir un certain motif à l'intérieur du cookie donné.
|
|
|
|
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, 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
|
|
|
|
* [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
|
|
* [https://www.linkedin.com/posts/rickey-martin-24533653\_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653\_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd)
|
|
|
|
**Try Hard Security Group**
|
|
|
|
<figure><img src="../../.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
{% hint style="success" %}
|
|
Apprenez et pratiquez le Hacking AWS :<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Apprenez et pratiquez le Hacking GCP : <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Soutenir HackTricks</summary>
|
|
|
|
* Vérifiez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop)!
|
|
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
|
|
|
|
</details>
|
|
{% endhint %}
|