gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-03-12 21:22:57 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2026-01-26 01:03:17 +00:00
parent 01bea91714
commit 9853209889
1 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md
View File

@@ -12,24 +12,24 @@ Für weitere Informationen zu diesem AWS-Service, siehe:
### Task-Ressourcen
Diese privilege escalation techniques erfordern die Verwendung einiger AWS Step Functions-Ressourcen, um die gewünschten privilege escalation Aktionen durchzuführen.
Für diese privilege escalation-Techniken ist es erforderlich, bestimmte AWS Step Functions-Ressourcen zu verwenden, um die gewünschten privilege escalation-Aktionen durchzuführen.
Um alle möglichen Aktionen zu prüfen, können Sie in Ihrem eigenen AWS-Konto die Aktion auswählen, die Sie verwenden möchten, und die verwendeten Parameter einsehen, wie z. B.:
Um alle möglichen Aktionen zu prüfen, können Sie in Ihrem AWS-Konto die gewünschte Aktion auswählen und die verwendeten Parameter einsehen, wie hier:
<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
Oder Sie können auch die AWS API-Dokumentation aufrufen und die Dokumentation jeder Aktion prüfen:
Oder Sie können auch in die API-Dokumentation von AWS gehen und die Dokumentation jeder Aktion prüfen:
- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
### `states:TestState` & `iam:PassRole`
Ein attacker mit den Berechtigungen **`states:TestState`** & **`iam:PassRole`** kann jeden State testen und jede IAM-Rolle an diesen übergeben, ohne eine vorhandene state machine zu erstellen oder zu aktualisieren, und damit potenziell unautorisierten Zugriff auf andere AWS-Services mit den Berechtigungen der Rolle ermöglichen. Kombiniert können diese Berechtigungen zu umfangreichen unautorisierten Aktionen führen, von der Manipulation von Workflows und der Änderung von Daten bis hin zu Datenverletzungen, Ressourcenmanipulation und privilege escalation.
Ein Angreifer mit den Berechtigungen **`states:TestState`** und **`iam:PassRole`** kann jeden State testen und beliebige IAM-Rollen an diesen übergeben, ohne eine bestehende state machine zu erstellen oder zu aktualisieren, was potenziell unbefugten Zugriff auf andere AWS-Services mit den Berechtigungen der Rollen ermöglicht. In Kombination können diese Berechtigungen zu umfangreichen unbefugten Aktionen führen — von der Manipulation von Workflows und der Änderung von Daten bis hin zu Datenlecks, Ressourcenmanipulation und privilege escalation.
```bash
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
aws stepfunctions test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
```
Die folgenden Beispiele zeigen, wie man einen State testet, der einen Access Key für den Benutzer **`admin`** erstellt, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung ausgenutzt werden. Diese permissive Rolle sollte mit einer hochprivilegierten Policy verknüpft sein (zum Beispiel **`arn:aws:iam::aws:policy/AdministratorAccess`**), die dem State erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
Die folgenden Beispiele zeigen, wie man einen State testet, der einen Access Key für den Benutzer **`admin`** erstellt, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung genutzt werden. Diese permissive Rolle sollte eine beliebige hochprivilegierte Policy zugeordnet haben (zum Beispiel **`arn:aws:iam::aws:policy/AdministratorAccess`**), die dem State erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
- **stateDefinition.json**:
```json
@@ -42,7 +42,7 @@ Die folgenden Beispiele zeigen, wie man einen State testet, der einen Access Key
"End": true
}
```
- **Befehl** ausgeführt, um das privesc durchzuführen:
- **Befehl** ausgeführt, um die privesc durchzuführen:
```bash
aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole
@@ -59,23 +59,23 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
"status": "SUCCEEDED"
}
```
**Potenzielle Auswirkungen**: Unautorisierte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.
**Potentielle 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 den **`states:CreateStateMachine`**- und **`iam:PassRole`**-Rechten könnte eine state machine erstellen und ihr jede beliebige IAM-Rolle zuweisen, wodurch unautorisierter Zugriff auf andere AWS-Services mit den Berechtigungen dieser Rollen möglich würde. Im Gegensatz zur vorherigen Privesc-Technik (**`states:TestState`** & **`iam:PassRole`**) führt sich diese nicht selbst aus; zusätzlich benötigen Sie die Berechtigung **`states:StartExecution`** oder **`states:StartSyncExecution`** (**`states:StartSyncExecution`** ist **nicht available for standard workflows**, **just to express state machines**), um die Ausführung der state machine zu starten.
Ein Angreifer mit den **`states:CreateStateMachine`** & **`iam:PassRole`** Rechten könnte eine state machine erstellen und ihr eine beliebige IAM-Rolle zuweisen, wodurch unbefugter Zugriff auf andere AWS-Services mit den Berechtigungen dieser Rolle möglich wird. Im Gegensatz zu der vorherigen privesc-Technik (**`states:TestState`** & **`iam:PassRole`**) führt sich diese nicht von selbst aus; Sie benötigen zusätzlich die Berechtigungen **`states:StartExecution`** oder **`states:StartSyncExecution`** (**`states:StartSyncExecution`** ist **nicht für standard workflows verfügbar**, **nur für express state machines**), um eine Ausführung der state machine zu starten.
```bash
# Create a state machine
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
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 states start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
aws stepfunctions 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>]
aws stepfunctions start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
```
Die folgenden Beispiele zeigen, wie man eine state machine erstellt, die einen Zugriffsschlüssel für den **`admin`**-Benutzer erzeugt und diesen Zugriffsschlüssel in einen vom Angreifer kontrollierten S3-Bucket exfiltriert, indem sie diese Berechtigungen und eine permissive Rolle der AWS-Umgebung ausnutzt. Diese permissive Rolle sollte eine hochprivilegierte Policy zugeordnet haben (z. B. **`arn:aws:iam::aws:policy/AdministratorAccess`**), die es der state machine erlaubt, die Aktionen **`iam:CreateAccessKey`** & **`s3:putObject`** auszuführen.
Die folgenden Beispiele zeigen, wie man eine state machine erstellt, die einen access key für den **`admin`**-Benutzer erzeugt und diesen access key in einen vom Angreifer kontrollierten S3-Bucket exfiltriert, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung ausgenutzt werden. Diese permissive Rolle sollte eine hochprivilegierte Policy enthalten (z. B. **`arn:aws:iam::aws:policy/AdministratorAccess`**), die der state machine erlaubt, die Aktionen **`iam:CreateAccessKey`** und **`s3:putObject`** auszuführen.
- **stateMachineDefinition.json**:
```json
@@ -115,7 +115,7 @@ Die folgenden Beispiele zeigen, wie man eine state machine erstellt, die einen Z
}
}
```
- **Befehl** ausgeführt, um **die Zustandsmaschine zu erstellen**:
- **Befehl** ausgeführt, um die Zustandsmaschine zu erstellen:
```bash
aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
{
@@ -123,7 +123,7 @@ aws stepfunctions create-state-machine --name MaliciousStateMachine --definition
"creationDate": "2024-07-09T20:29:35.381000+02:00"
}
```
- **Befehl** zum Starten einer Ausführung der zuvor erstellten state machine:
- **Befehl** ausgeführt, um eine Ausführung der zuvor erstellten state machine zu starten:
```json
aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
{
@@ -132,26 +132,26 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
}
```
> [!WARNING]
> Der vom Angreifer kontrollierte S3-Bucket sollte Berechtigungen haben, um eine s3:PutObject-Aktion aus dem Opferkonto zu akzeptieren.
> Der vom Angreifer kontrollierte S3 bucket sollte Berechtigungen haben, um eine s3:PutObject-Aktion vom Opferkonto zu akzeptieren.
**Mögliche Auswirkungen**: Unautorisierte Ausführung und Manipulation von Workflows sowie Zugriff auf sensitive Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.
**Mögliche Auswirkungen**: Unautorisierte Ausführung und Manipulation von Workflows und Zugriff auf sensible Ressourcen, was potenziell zu erheblichen Sicherheitsverletzungen führen kann.
### `states:UpdateStateMachine` & (not always required) `iam:PassRole`
### `states:UpdateStateMachine` & (nicht immer erforderlich) `iam:PassRole`
Ein Angreifer mit der **`states:UpdateStateMachine`**-Berechtigung könnte die Definition einer state machine ändern und zusätzliche, unauffällige States hinzufügen, die zu einer Privilegieneskalation führen. Wenn ein legitimer Benutzer eine Ausführung der state machine startet, wird dieser neue bösartige, versteckte State ausgeführt und die Privilegieneskalation ist erfolgreich.
Ein Angreifer mit der Berechtigung **`states:UpdateStateMachine`** wäre in der Lage, die Definition einer state machine zu ändern und zusätzliche, unauffällige States hinzuzufügen, die zu einer Privilegieneskalation führen können. Auf diese Weise wird beim Start einer Ausführung der state machine durch einen legitimen Benutzer dieser neue bösartige, versteckte State ausgeführt und die Privilegieneskalation erfolgreich.
Je nachdem, wie permissiv die mit der state machine verknüpfte IAM Role ist, steht der Angreifer vor 2 Situationen:
Abhängig davon, wie permissiv die der state machine zugewiesene IAM Role ist, würde der Angreifer vor 2 Situationen stehen:
1. **Permissive IAM Role**: Wenn die IAM Role, die mit der state machine verknüpft ist, bereits sehr weitreichende Rechte besitzt (z. B. die Policy **`arn:aws:iam::aws:policy/AdministratorAccess`** angehängt), dann wäre die **`iam:PassRole`**-Berechtigung nicht erforderlich, um Privilegien zu eskalieren, da es nicht nötig wäre, zusätzlich die IAM Role zu aktualisieren — die Änderung der state machine-Definition reicht aus.
2. **Not permissive IAM Role**: Im Gegensatz zum vorherigen Fall würde der Angreifer hier zusätzlich die **`iam:PassRole`**-Berechtigung benötigen, da es erforderlich wäre, eine permissive IAM Role der state machine zuzuordnen sowie die state machine-Definition zu ändern.
1. **Permissive IAM Role**: Wenn die der state machine zugeordnete IAM Role bereits permissive ist (z. B. hat sie die Richtlinie **`arn:aws:iam::aws:policy/AdministratorAccess`** angehängt), dann wäre die Berechtigung **`iam:PassRole`** für eine Eskalation nicht erforderlich, da es nicht nötig wäre, auch die IAM Role zu aktualisieren — die Änderung der state machine-Definition genügt.
2. **Not permissive IAM Role**: Im Gegensatz zum vorherigen Fall würde der Angreifer hier zusätzlich die Berechtigung **`iam:PassRole`** benötigen, da es notwendig wäre, neben der Änderung der state machine-Definition auch eine permissive IAM Role mit der state machine zu verknüpfen.
```bash
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
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>]
```
Die folgenden Beispiele zeigen, wie man eine legitime State Machine, die lediglich eine HelloWorld Lambda-Funktion aufruft, so aktualisiert, dass ein zusätzlicher State hinzugefügt wird, der den Benutzer **`unprivilegedUser`** zur IAM-Gruppe **`administrator`** hinzufügt. Auf diese Weise wird beim Start einer Ausführung der aktualisierten State Machine durch einen legitimen Benutzer dieser neue, bösartige, heimliche State ausgeführt und die Privilegieneskalation gelingt.
Die folgenden Beispiele zeigen, wie man eine legitime State Machine, die lediglich eine HelloWorld Lambda-Funktion aufruft, aktualisiert, um einen zusätzlichen State hinzuzufügen, der den Benutzer **`unprivilegedUser`** zur **`administrator`** IAM Group hinzufügt. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der aktualisierten State Machine startet, dieser neue, heimliche bösartige State ausgeführt und die Privilegieneskalation erfolgreich sein.
> [!WARNING]
> Wenn die State Machine nicht mit einer permissiven IAM-Rolle verknüpft ist, ist außerdem die Berechtigung **`iam:PassRole`** erforderlich, um die IAM-Rolle zu aktualisieren und eine permissive IAM-Rolle zuzuordnen (zum Beispiel eine Rolle mit der angehängten Richtlinie **`arn:aws:iam::aws:policy/AdministratorAccess`**).
> Falls die State Machine nicht mit einer permissiven IAM Role verknüpft ist, wird außerdem die Berechtigung **`iam:PassRole`** benötigt, um die IAM Role zu aktualisieren, damit eine permissive IAM Role zugewiesen werden kann (zum Beispiel eine mit der **`arn:aws:iam::aws:policy/AdministratorAccess`** Policy angehängt).
{{#tabs }}
{{#tab name="Legit State Machine" }}
@@ -218,7 +218,7 @@ Die folgenden Beispiele zeigen, wie man eine legitime State Machine, die ledigli
{{#endtab }}
{{#endtabs }}
- **Befehl** ausgeführt, um **die legitime State Machine** zu **aktualisieren**:
- **Befehl**, ausgeführt, um **die legitime State Machine** zu **aktualisieren**:
```bash
aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
{
@@ -226,6 +226,6 @@ aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-eas
"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
}
```
**Potentielle Auswirkungen**: Unbefugte Ausführung und Manipulation von Workflows und Zugriff auf sensible Ressourcen, was möglicherweise zu schwerwiegenden Sicherheitsverletzungen führen kann.
**Potenzielle Auswirkungen**: Unbefugte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was potenziell zu erheblichen Sicherheitsverletzungen führen kann.
{{#include ../../../../banners/hacktricks-training.md}}