AWS - ECS Privesc
ECS
More info about ECS in:
iam:PassRole
, ecs:RegisterTaskDefinition
, ecs:RunTask
iam:PassRole
, ecs:RegisterTaskDefinition
, ecs:RunTask
An attacker abusing the iam:PassRole
, ecs:RegisterTaskDefinition
and ecs:RunTask
permission in ECS can generate a new task definition with a malicious container that steals the metadata credentials and run it.
Potential Impact: Direct privesc to a different ECS role.
iam:PassRole
, ecs:RegisterTaskDefinition
, ecs:StartTask
iam:PassRole
, ecs:RegisterTaskDefinition
, ecs:StartTask
Just like in the previous example an attacker abusing the iam:PassRole
, ecs:RegisterTaskDefinition
, ecs:StartTask
permissions in ECS can generate a new task definition with a malicious container that steals the metadata credentials and run it.
However, in this case, a container instance to run the malicious task definition need to be.
Potential Impact: Direct privesc to any ECS role.
iam:PassRole
, ecs:RegisterTaskDefinition
, (ecs:UpdateService|ecs:CreateService)
iam:PassRole
, ecs:RegisterTaskDefinition
, (ecs:UpdateService|ecs:CreateService)
Just like in the previous example an attacker abusing the iam:PassRole
, ecs:RegisterTaskDefinition
, ecs:UpdateService
or ecs:CreateService
permissions in ECS can generate a new task definition with a malicious container that steals the metadata credentials and run it by creating a new service with at least 1 task running.
Potential Impact: Direct privesc to any ECS role.
iam:PassRole
, (ecs:UpdateService|ecs:CreateService)
iam:PassRole
, (ecs:UpdateService|ecs:CreateService)
Actually, just with those permissions it's possible to use overrides to executer arbitrary commands in a container with an arbitrary role with something like:
Potential Impact: Direct privesc to any ECS role.
ecs:RegisterTaskDefinition
, (ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)
ecs:RegisterTaskDefinition
, (ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)
This scenario is like the previous ones but without the iam:PassRole
permission.
This is still interesting because if you can run an arbitrary container, even if it's without a role, you could run a privileged container to escape to the node and steal the EC2 IAM role and the other ECS containers roles running in the node.
You could even force other tasks to run inside the EC2 instance you compromise to steal their credentials (as discussed in the Privesc to node section).
This attack is only possible if the ECS cluster is using EC2 instances and not Fargate.
ecs:ExecuteCommand
, ecs:DescribeTasks,
(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)
ecs:ExecuteCommand
, ecs:DescribeTasks,
(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)
An attacker with the ecs:ExecuteCommand
, ecs:DescribeTasks
can execute commands inside a running container and exfiltrate the IAM role attached to it (you need the describe permissions because it's necessary to run aws ecs execute-command
).
However, in order to do that, the container instance need to be running the ExecuteCommand agent (which by default isn't).
Therefore, the attacker cloud try to:
Try to run a command in every running container
If he has
ecs:RunTask
, run a task withaws ecs run-task --enable-execute-command [...]
If he has
ecs:StartTask
, run a task withaws ecs start-task --enable-execute-command [...]
If he has
ecs:CreateService
, create a service withaws ecs create-service --enable-execute-command [...]
If he has
ecs:UpdateService
, update a service withaws ecs update-service --enable-execute-command [...]
You can find examples of those options in previous ECS privesc sections.
Potential Impact: Privesc to a different role attached to containers.
ssm:StartSession
ssm:StartSession
Check in the ssm privesc page how you can abuse this permission to privesc to ECS:
iam:PassRole
, ec2:RunInstances
iam:PassRole
, ec2:RunInstances
Check in the ec2 privesc page how you can abuse these permissions to privesc to ECS:
?ecs:RegisterContainerInstance
?ecs:RegisterContainerInstance
TODO: Is it possible to register an instance from a different AWS account so tasks are run under machines controlled by the attacker??
ecs:CreateTaskSet
, ecs:UpdateServicePrimaryTaskSet
, ecs:DescribeTaskSets
ecs:CreateTaskSet
, ecs:UpdateServicePrimaryTaskSet
, ecs:DescribeTaskSets
TODO: Test this
An attacker with the permissions ecs:CreateTaskSet
, ecs:UpdateServicePrimaryTaskSet
, and ecs:DescribeTaskSets
can create a malicious task set for an existing ECS service and update the primary task set. This allows the attacker to execute arbitrary code within the service.
Potential Impact: Execute arbitrary code in the affected service, potentially impacting its functionality or exfiltrating sensitive data.
References
Last updated