**La métadonnée** peut être accédée depuis n'importe quelle machine EC2 et offre des informations intéressantes à son sujet. Elle est accessible à l'URL : `http://169.254.169.254` ([informations sur la métadonnée ici](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
Il y a **2 versions** de la métadonnée. La **première** permet d'**accéder** à la métadonnée via des requêtes **GET** (donc toute **SSRF peut l'exploiter**). Pour la **version 2**, [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html), vous devez demander un **jeton** en envoyant une requête **PUT** avec un **en-tête HTTP** et ensuite utiliser ce jeton pour accéder à la métadonnée avec un autre en-tête HTTP (donc c'est **plus compliqué à exploiter** avec une SSRF).
Dans la **version 2**, le **TTL par défaut est de 1**. Cela garantit que les appareils réseau mal configurés (pare-feux, dispositifs NAT, routeurs, etc.) ne transfèrent pas le paquet. Cela signifie également que les **conteneurs Docker** utilisant la configuration de réseau par défaut (mode bridge) **ne pourront pas atteindre** le service de métadonnées de l'instance.\
**IMDSv2** bloquera également les demandes de récupération d'un jeton qui incluent l'en-tête `X-Forwarded-For`. Cela empêche les serveurs proxy inverses mal configurés d'y accéder.
Vous pouvez trouver des informations sur les [points de terminaison de la métadonnée dans la documentation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-categories.html). Dans le script suivant, des informations intéressantes sont obtenues à partir de celui-ci :
En tant qu'exemple d'exposition de **credentials IAM disponibles publiquement**, vous pouvez visiter : [http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws](http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws)
Vous pouvez également vérifier les **credentials de sécurité EC2 publics** sur : [http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance](http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance)
Vous pouvez ensuite prendre **ces credentials et les utiliser avec AWS CLI**. Cela vous permettra de faire **tout ce que le rôle a les autorisations** de faire.
[**PACU**](https://github.com/RhinoSecurityLabs/pacu) peut être utilisé avec les identifiants découverts pour découvrir vos privilèges et essayer de les escalader.
**ECS** est un groupe logique d'instances EC2 sur lesquelles vous pouvez exécuter une application sans avoir à mettre à l'échelle votre propre infrastructure de gestion de cluster car ECS s'en charge pour vous. Si vous parvenez à compromettre le service en cours d'exécution dans **ECS**, les **points de terminaison de métadonnées changent**.
Si vous accédez à _**http://169.254.170.2/v2/credentials/\<GUID>**_, vous trouverez les informations d'identification de la machine ECS. Mais d'abord, vous devez **trouver le \<GUID>**. Pour trouver le \<GUID>, vous devez lire la variable **environ****AWS\_CONTAINER\_CREDENTIALS\_RELATIVE\_URI** à l'intérieur de la machine.\
Vous pourriez être en mesure de le lire en exploitant une **traversal de chemin** vers `file:///proc/self/environ`\
L'adresse http mentionnée devrait vous donner les **AccessKey, SecretKey et token**.
Notez que dans **certains cas**, vous pourrez accéder à l'**instance de métadonnées EC2** à partir du conteneur (vérifiez les limitations de TTL IMDSv2 mentionnées précédemment). Dans ces scénarios, à partir du conteneur, vous pourriez accéder à la fois au rôle IAM du conteneur et au rôle IAM EC2.
Dans ce cas, les **informations d'identification sont stockées dans des variables d'environnement**. Ainsi, pour y accéder, vous devez accéder à quelque chose comme **`file:///proc/self/environ`**.
De plus, en plus des informations d'identification IAM, les fonctions Lambda ont également des **données d'événement qui sont transmises à la fonction lorsqu'elle est démarrée**. Ces données sont mises à disposition de la fonction via l'[interface d'exécution](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html) et pourraient contenir des **informations sensibles** (comme à l'intérieur des **stageVariables**). Contrairement aux informations d'identification IAM, ces données sont accessibles via SSRF standard à **`http://localhost:9001/2018-06-01/runtime/invocation/next`**.
Notez que les **informations d'identification lambda** se trouvent dans les **variables d'environnement**. Ainsi, si la **trace de pile** du code lambda imprime les variables d'environnement, il est possible de les **exfiltrer en provoquant une erreur** dans l'application.
Vous pouvez [**trouver ici la documentation sur les points de terminaison de métadonnées**](https://cloud.google.com/appengine/docs/standard/java/accessing-instance-metadata).
Nécessite l'en-tête "Metadata-Flavor: Google" ou "X-Google-Metadata-Request: True" et vous pouvez accéder au point de terminaison de métadonnées avec les URL suivantes:
Il n'y a pas de choses comme les rôles AWS ou les comptes de service GCP, donc ne vous attendez pas à trouver des informations d'identification de bot de métadonnées.
Documentation disponible sur [`https://developers.digitalocean.com/documentation/metadata/`](https://developers.digitalocean.com/documentation/metadata/)
Les environnements cloud sont de plus en plus populaires et sont souvent utilisés pour héberger des applications web. Les fournisseurs de services cloud tels que AWS, GCP et Azure offrent des services tels que des machines virtuelles, des conteneurs, des fonctions sans serveur et des bases de données. Ces services sont souvent utilisés pour héberger des applications web.
Les applications web hébergées dans des environnements cloud peuvent être vulnérables aux attaques SSRF. Les attaques SSRF dans les environnements cloud peuvent être plus dangereuses que les attaques SSRF dans les environnements traditionnels car les machines virtuelles, les conteneurs et les fonctions sans serveur ont souvent des autorisations élevées pour accéder à d'autres services cloud.
Les attaquants peuvent utiliser SSRF pour accéder à des services cloud sensibles tels que les métadonnées de la machine virtuelle, les clés d'API et les fichiers de configuration. Les attaquants peuvent également utiliser SSRF pour accéder à des services cloud appartenant à d'autres clients du même fournisseur de services cloud.
Les attaquants peuvent utiliser SSRF pour accéder à des services cloud sensibles tels que les métadonnées de la machine virtuelle, les clés d'API et les fichiers de configuration. Les attaquants peuvent également utiliser SSRF pour accéder à des services cloud appartenant à d'autres clients du même fournisseur de services cloud.
Les attaquants peuvent utiliser SSRF pour accéder à des services cloud sensibles tels que les métadonnées de la machine virtuelle, les clés d'API et les fichiers de configuration. Les attaquants peuvent également utiliser SSRF pour accéder à des services cloud appartenant à d'autres clients du même fournisseur de services cloud.
À partir de **env**, vous pouvez obtenir les valeurs de `IDENTITY_HEADER`_et_`IDENTITY_ENDPOINT`. Vous pouvez les utiliser pour récupérer un jeton pour communiquer avec le serveur de métadonnées.
Notez que par défaut, les métadonnées ne sont pas activées dans IBM, il est donc possible que vous ne puissiez pas y accéder même si vous êtes à l'intérieur d'une machine virtuelle IBM Cloud.
Les instances Oracle Cloud ont une API REST qui peut être utilisée pour effectuer des actions sur les instances. Cette API est accessible via l'URL `http://169.254.169.254/opc/v1/`. En utilisant une SSRF, un attaquant peut envoyer des requêtes à cette API pour récupérer des informations sensibles telles que les clés d'API, les informations d'identification et les métadonnées de l'instance.
Voici un exemple de requête SSRF pour récupérer les informations d'identification de l'instance :
```
http://169.254.169.254/opc/v1/instance/identity
```
### Bypassing Instance Metadata Service
Oracle Cloud a mis en place des mesures de sécurité pour empêcher les attaques SSRF. Cependant, il est possible de contourner ces mesures en utilisant des techniques telles que l'injection de caractères null (`%00`) ou l'utilisation de l'URL `http://127.0.0.1/`.
Voici un exemple de requête SSRF contournant les mesures de sécurité en utilisant l'injection de caractères null :
Oracle Cloud propose une fonctionnalité appelée Cloud Shell qui permet aux utilisateurs d'exécuter des commandes dans un environnement de shell Linux directement depuis le navigateur. Cette fonctionnalité est accessible via l'URL `https://shell.cloud.oracle.com/`.
En utilisant une SSRF, un attaquant peut envoyer des requêtes à l'API REST de Cloud Shell pour exécuter des commandes arbitraires sur l'instance.
Voici un exemple de requête SSRF pour exécuter la commande `ls` sur l'instance :
Alibaba Cloud est un fournisseur de services cloud chinois qui propose une large gamme de services, notamment des serveurs, des bases de données, des services de sécurité et des solutions d'analyse de données. Les services cloud d'Alibaba sont utilisés par de nombreuses entreprises en Chine et dans le monde entier.
Les vulnérabilités SSRF sont courantes sur les serveurs Alibaba Cloud. Les attaquants peuvent utiliser ces vulnérabilités pour accéder à des ressources internes, telles que des bases de données, des fichiers et des clés d'API. Les attaquants peuvent également utiliser des vulnérabilités SSRF pour effectuer des attaques de rebond, dans lesquelles ils utilisent un serveur vulnérable pour attaquer d'autres serveurs.
Les attaquants peuvent également utiliser des vulnérabilités SSRF pour accéder à des informations sensibles, telles que des informations d'identification et des clés d'API. Les attaquants peuvent utiliser ces informations pour accéder à des ressources sensibles, telles que des bases de données et des fichiers.
Il est important de surveiller les vulnérabilités SSRF sur les serveurs Alibaba Cloud et de les corriger dès que possible. Les entreprises doivent également mettre en place des mesures de sécurité pour protéger leurs ressources sensibles, telles que des bases de données et des fichiers.
Docker est une plateforme de conteneurisation qui permet de créer, déployer et exécuter des applications dans des conteneurs. Les conteneurs sont des environnements isolés qui contiennent tout ce dont une application a besoin pour fonctionner, y compris le code, les bibliothèques et les dépendances. Docker est souvent utilisé pour créer des environnements de développement et de test, ainsi que pour déployer des applications dans des environnements de production.
Les attaques SSRF contre les conteneurs Docker peuvent être particulièrement dangereuses, car les conteneurs sont souvent utilisés pour exécuter des applications sensibles, telles que des bases de données et des serveurs Web. Si un attaquant peut exploiter une vulnérabilité SSRF pour accéder à ces applications, il peut potentiellement voler des données sensibles ou prendre le contrôle complet du système.
Il est important de noter que les attaques SSRF contre les conteneurs Docker peuvent être plus difficiles à exploiter que les attaques SSRF contre les serveurs Web traditionnels. Cela est dû au fait que les conteneurs sont souvent configurés pour n'écouter que sur des ports spécifiques, ce qui peut limiter les options d'attaque pour un attaquant. Cependant, il est toujours important de prendre des mesures pour protéger les conteneurs Docker contre les attaques SSRF, telles que la configuration de règles de pare-feu pour limiter l'accès aux ports sensibles et la mise en place de contrôles d'accès pour les applications sensibles.
Rancher est une plateforme de gestion de conteneurs qui permet de déployer et de gérer des clusters Kubernetes. Elle est souvent utilisée pour gérer des environnements de production dans le cloud. Les versions antérieures à la version 2.5.8 ont été affectées par une vulnérabilité SSRF qui permettait à un attaquant de contourner les restrictions de sécurité et d'envoyer des requêtes HTTP depuis le serveur vers des ressources internes ou externes. Cette vulnérabilité a été corrigée dans la version 2.5.8 et les versions ultérieures. Si vous utilisez une version antérieure, il est recommandé de mettre à jour votre installation Rancher dès que possible pour éviter toute exploitation potentielle de cette vulnérabilité.
* 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**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) **groupe Discord** ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
