gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-03-12 21:22:57 -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-01-26 01:09:29 +00:00
parent 5404a46233
commit 20a305a902
1 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md
View File

@@ -10,26 +10,26 @@ Per maggiori informazioni su questo servizio AWS, consulta:
../../aws-services/aws-stepfunctions-enum.md
{{#endref}}
### Risorse Task
### Task Resources
Queste privilege escalation techniques richiederanno l'uso di alcune risorse di AWS Step Functions per eseguire le azioni di privilege escalation desiderate.
Queste tecniche di escalation dei privilegi richiedono l'uso di alcune risorse di AWS Step Functions per eseguire le azioni di escalation dei privilegi desiderate.
Per verificare tutte le azioni possibili, puoi accedere al tuo account AWS, selezionare l'azione che vuoi usare e vedere i parametri che utilizza, come in:
Per verificare tutte le azioni possibili, puoi accedere al tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che utilizza, come in:
<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
Oppure puoi consultare la documentazione API di AWS e verificare la documentazione di ciascuna action:
Oppure puoi consultare la documentazione API di AWS e controllare la documentazione di ciascuna action:
- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
### `states:TestState` & `iam:PassRole`
Un attacker con i permessi **`states:TestState`** e **`iam:PassRole`** può testare qualsiasi state e passare qualsiasi IAM role ad esso senza creare o aggiornare una state machine esistente, abilitando potenzialmente accesso non autorizzato ad altri servizi AWS con i permessi del ruolo. Se combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei workflow e modifica dei dati a violazioni dei dati, manipolazione delle risorse e privilege escalation.
Un attacker con le autorizzazioni **`states:TestState`** & **`iam:PassRole`** può testare qualsiasi state e passare qualsiasi IAM role ad esso senza creare o aggiornare una state machine esistente, potenzialmente consentendo accesso non autorizzato ad altri servizi AWS con i permessi dei role. Combinate, queste autorizzazioni possono portare ad azioni non autorizzate estese, dalla manipolazione dei workflows e alterazione dei dati a data breaches, manipolazione delle risorse e privilege escalation.
```bash
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
aws stepfunctions test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
```
Gli esempi seguenti mostrano come testare uno state che crea un access key per l'utente **`admin`** sfruttando questi permessi e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alto privilegio (per esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consenta allo state di eseguire l'azione **`iam:CreateAccessKey`**:
Gli esempi seguenti mostrano come testare uno state che crea una chiave di accesso per l'utente **`admin`** sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy con privilegi elevati (per esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consenta allo state di eseguire l'azione **`iam:CreateAccessKey`**:
- **stateDefinition.json**:
```json
@@ -42,7 +42,7 @@ Gli esempi seguenti mostrano come testare uno state che crea un access key per l
"End": true
}
```
- **Command** eseguito per effettuare il privesc:
- **Comando** eseguito per effettuare il privesc:
```bash
aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole
@@ -59,23 +59,23 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
"status": "SUCCEEDED"
}
```
**Potential Impact**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, con potenziali gravi violazioni della sicurezza.
**Potential Impact**: Esecuzione e manipolazione non autorizzate di workflows e accesso a risorse sensibili, potenzialmente portando a violazioni di sicurezza significative.
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
Un attaccante in possesso di **`states:CreateStateMachine`**& **`iam:PassRole`** sarebbe in grado di creare una state machine e assegnarle qualsiasi IAM role, permettendo accessi non autorizzati ad altri servizi AWS con i permessi del role. A differenza della precedente privesc technique (**`states:TestState`** & **`iam:PassRole`**), questa non si esegue da sola: è inoltre necessario avere i permessi **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **non è disponibile per standard workflows**, **solo per express state machines**) per avviare un'esecuzione sulla state machine.
Un attacker con i permessi **`states:CreateStateMachine`** & **`iam:PassRole`** sarebbe in grado di creare una state machine e assegnarle qualsiasi ruolo IAM, permettendo l'accesso non autorizzato ad altri servizi AWS con le autorizzazioni del ruolo. In contrasto con la precedente tecnica di privesc (**`states:TestState`** & **`iam:PassRole`**), questa non si esegue da sola: avrai inoltre bisogno dei permessi **`states:StartExecution`** o **`states:StartSyncExecution`** (**`states:StartSyncExecution`** **non è disponibile per standard workflows**, **solo per express state machines**) per poter avviare un'esecuzione sulla state machine.
```bash
# Create a state machine
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
aws stepfunctions create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
# Start a state machine execution
aws states start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
aws stepfunctions start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
# Start a Synchronous Express state machine execution
aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
aws stepfunctions start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
```
Gli esempi seguenti mostrano come creare una state machine che crea un access key per l'utente **`admin`** e esfiltra questa access key in un bucket S3 controllato dall'attaccante, sfruttando questi permessi e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alto privilegio (per esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che permette alla state machine di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**.
Gli esempi seguenti mostrano come creare una macchina a stati che crea una access key per l'utente **`admin`** ed esfiltra questa access key in un bucket S3 controllato dall'attaccante, sfruttando questi permessi e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere una policy con privilegi elevati associata (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che permetta alla macchina a stati di eseguire le azioni **`iam:CreateAccessKey`** e **`s3:putObject`**.
- **stateMachineDefinition.json**:
```json
@@ -115,7 +115,7 @@ Gli esempi seguenti mostrano come creare una state machine che crea un access ke
}
}
```
- **Comando** eseguito per **creare la macchina a stati**:
- **Comando** eseguito per **creare la state machine**:
```bash
aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
{
@@ -123,7 +123,7 @@ aws stepfunctions create-state-machine --name MaliciousStateMachine --definition
"creationDate": "2024-07-09T20:29:35.381000+02:00"
}
```
- **Comando** eseguito per **avviare un'esecuzione** della state machine creata in precedenza:
- **Comando** eseguito per **avviare un'esecuzione** della state machine precedentemente creata:
```json
aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
{
@@ -134,24 +134,24 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
> [!WARNING]
> Il bucket S3 controllato dall'attaccante dovrebbe avere i permessi per accettare un'azione s3:PutObject dall'account vittima.
**Potential Impact**: Esecuzione non autorizzata e manipolazione dei workflow e accesso a risorse sensibili, potenzialmente portando a violazioni di sicurezza significative.
**Impatto Potenziale**: Esecuzione e manipolazione non autorizzate dei flussi di lavoro e accesso a risorse sensibili, con possibile conseguente di gravi violazioni della sicurezza.
### `states:UpdateStateMachine` & (not always required) `iam:PassRole`
### `states:UpdateStateMachine` & (non sempre richiesto) `iam:PassRole`
Un attaccante con il permesso **`states:UpdateStateMachine`** sarebbe in grado di modificare la definizione di una state machine, potendo aggiungere stati stealth aggiuntivi che potrebbero portare a una escalation di privilegi. In questo modo, quando un utente legittimo avvia l'esecuzione della state machine, questo nuovo stato malevolo stealth verrà eseguito e l'escalation di privilegi avrà successo.
Un attaccante con il permesso **`states:UpdateStateMachine`** potrebbe modificare la definizione di una state machine, aggiungendo stati furtivi che potrebbero portare a una privilege escalation. In questo modo, quando un utente legittimo avvia un'esecuzione della state machine, questo nuovo stato malevolo furtivo verrà eseguito e la privilege escalation avrà successo.
A seconda di quanto permissivo sia l'IAM Role associato alla state machine, un attaccante si troverebbe di fronte a 2 situazioni:
A seconda di quanto permissivo sia l'IAM Role associato alla state machine, un attaccante si troverà di fronte a 2 situazioni:
1. **Permissive IAM Role**: Se l'IAM Role associato alla state machine è già permissivo (ad esempio ha allegata la policy **`arn:aws:iam::aws:policy/AdministratorAccess`**), allora il permesso **`iam:PassRole`** non sarebbe richiesto per scalare i privilegi, poiché non sarebbe necessario aggiornare anche l'IAM Role; basta modificare la definizione della state machine.
2. **Not permissive IAM Role**: In contrasto con il caso precedente, qui un attaccante richiederebbe anche il permesso **`iam:PassRole`** poiché sarebbe necessario associare un IAM Role permissivo alla state machine oltre a modificare la definizione della state machine.
1. **IAM Role permissivo**: Se l'IAM Role associato alla state machine è già permissivo (ad esempio ha la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata), allora il permesso **`iam:PassRole`** non sarà necessario per eseguire la privilege escalation, poiché non è necessario aggiornare anche l'IAM Role: basta modificare la definizione della state machine.
2. **IAM Role non permissivo**: Al contrario del caso precedente, qui l'attaccante richiederà anche il permesso **`iam:PassRole`**, poiché sarà necessario associare un IAM Role permissivo alla state machine oltre a modificare la definizione della state machine.
```bash
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
aws stepfunctions update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
```
Gli esempi seguenti mostrano come aggiornare una state machine legittima che semplicemente invoca una HelloWorld Lambda function, per aggiungere uno stato extra che aggiunge l'utente **`unprivilegedUser`** al **`administrator`** IAM Group. In questo modo, quando un utente legittimo avvierà l'esecuzione della state machine aggiornata, questo nuovo stato malevolo stealth verrà eseguito e l'escalation di privilegi avrà successo.
Gli esempi seguenti mostrano come aggiornare una state machine legittima che invoca semplicemente una funzione HelloWorld Lambda, per aggiungere uno stato extra che aggiunge l'utente **`unprivilegedUser`** al gruppo IAM **`administrator`**. In questo modo, quando un utente legittimo avvia l'esecuzione della state machine aggiornata, questo nuovo stato malevolo nascosto verrà eseguito e l'elevazione di privilegi avrà successo.
> [!WARNING]
> Se la state machine non ha un IAM Role permissivo associato, sarà inoltre richiesta la permissione **`iam:PassRole`** per aggiornare l'IAM Role al fine di associare un IAM Role permissivo (per esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata).
> Se la state machine non ha un IAM Role permissivo associato, sarà inoltre richiesto il permesso **`iam:PassRole`** per aggiornare l'IAM Role in modo da associare un IAM Role permissivo (per esempio uno con la policy **`arn:aws:iam::aws:policy/AdministratorAccess`** allegata).
{{#tabs }}
{{#tab name="Legit State Machine" }}
@@ -218,7 +218,7 @@ Gli esempi seguenti mostrano come aggiornare una state machine legittima che sem
{{#endtab }}
{{#endtabs }}
- **Comando** eseguito per **aggiornare** **la state machine legittima**:
- **Comando** eseguito per **aggiornare** **la macchina a stati legittima**:
```bash
aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
{
@@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas
"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
}
```
**Impatto potenziale**: Esecuzione non autorizzata e manipolazione dei workflows e accesso a risorse sensibili, che potrebbero portare a gravi violazioni della sicurezza.
**Impatto potenziale**: Esecuzione e manipolazione non autorizzata dei flussi di lavoro e l'accesso a risorse sensibili, che potrebbe portare a gravi violazioni della sicurezza.
{{#include ../../../../banners/hacktricks-training.md}}