AWS - Step Functions Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
For more information about this AWS service, check:
AWS - Step Functions EnumThese privilege escalation techniques are going to require to use some AWS step function resources in order to perform the desired privilege escalation actions.
In order to check all the possible actions, you could go to your own AWS account select the action you would like to use and see the parameters it's using, like in:
Or you could also go to the API AWS documentation and check each action docs:
states:TestState & iam:PassRoleAn attacker with the states:TestState & iam:PassRole permissions can test any state and pass any IAM role to it without creating or updating an existing state machine, enabling unauthorized access to other AWS services with the roles' permissions. potentially. Combined, these permissions can lead to extensive unauthorized actions, from manipulating workflows to alter data to data breaches, resource manipulation, and privilege escalation.
The following examples show how to test an state that creates an access key for the admin user leveraging these permissions and a permissive role of the AWS environment. This permissive role should have any high-privileged policy associated with it (for example arn:aws:iam::aws:policy/AdministratorAccess) that allows the state to perform the iam:CreateAccessKey action:
stateDefinition.json:
Command executed to perform the privesc:
Potential Impact: Unauthorized execution and manipulation of workflows and access to sensitive resources, potentially leading to significant security breaches.
states:CreateStateMachine & iam:PassRole & (states:StartExecution | states:StartSyncExecution)An attacker with the states:CreateStateMachine& iam:PassRole would be able to create an state machine and provide to it any IAM role, enabling unauthorized access to other AWS services with the roles' permissions. In contrast with the previous privesc technique (states:TestState & iam:PassRole), this one does not execute by itself, you will also need to have the states:StartExecution or states:StartSyncExecution permissions (states:StartSyncExecution is not available for standard workflows, just to express state machines) in order to start and execution over the state machine.
The following examples show how to create an state machine that creates an access key for the admin user and exfiltrates this access key to an attacker-controlled S3 bucket, leveraging these permissions and a permissive role of the AWS environment. This permissive role should have any high-privileged policy associated with it (for example arn:aws:iam::aws:policy/AdministratorAccess) that allows the state machine to perform the iam:CreateAccessKey & s3:putObject actions.
stateMachineDefinition.json:
Command executed to create the state machine:
Command executed to start an execution of the previously created state machine:
The attacker-controlled S3 bucket should have permissions to accept an s3:PutObject action from the victim account.
Potential Impact: Unauthorized execution and manipulation of workflows and access to sensitive resources, potentially leading to significant security breaches.
states:UpdateStateMachine & (not always required) iam:PassRoleAn attacker with the states:UpdateStateMachine permission would be able to modify the definition of an state machine, being able to add extra stealthy states that could end in a privilege escalation. This way, when a legitimate user starts an execution of the state machine, this new malicious stealth state will be executed and the privilege escalation will be successful.
Depending on how permissive is the IAM Role associated to the state machine is, an attacker would face 2 situations:
Permissive IAM Role: If the IAM Role associated to the state machine is already permissive (it has for example the arn:aws:iam::aws:policy/AdministratorAccess policy attached), then the iam:PassRole permission would not be required in order to escalate privileges since it would not be necessary to also update the IAM Role, with the state machine definition is enough.
Not permissive IAM Role: In contrast with the previous case, here an attacker would also require the iam:PassRole permission since it would be necessary to associate a permissive IAM Role to the state machine in addition to modify the state machine definition.
The following examples show how to update a legit state machine that just invokes a HelloWorld Lambda function, in order to add an extra state that adds the user unprivilegedUser to the administrator IAM Group. This way, when a legitimate user starts an execution of the updated state machine, this new malicious stealth state will be executed and the privilege escalation will be successful.
If the state machine does not have a permissive IAM Role associated, it would also be required the iam:PassRole permission to update the IAM Role in order to associate a permissive IAM Role (for example one with the arn:aws:iam::aws:policy/AdministratorAccess policy attached).
Command executed to update the legit state machine:
Potential Impact: Unauthorized execution and manipulation of workflows and access to sensitive resources, potentially leading to significant security breaches.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
