mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-13 21:36:23 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -12,7 +12,7 @@ Weitere Informationen finden Sie in:
|
||||
|
||||
### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
|
||||
|
||||
Nur mit einer dieser Berechtigungen reicht es aus, um einen Build mit einem neuen Buildspec auszulösen und das Token der IAM-Rolle zu stehlen, die dem Projekt zugewiesen ist:
|
||||
Nur mit einer dieser Berechtigungen reicht es aus, um einen Build mit einem neuen Buildspec auszulösen und das Token der IAM-Rolle, die dem Projekt zugewiesen ist, zu stehlen:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="StartBuild" }}
|
||||
@@ -61,13 +61,13 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
|
||||
**Hinweis**: Der Unterschied zwischen diesen beiden Befehlen ist:
|
||||
|
||||
- `StartBuild` löst einen einzelnen Build-Job mit einem bestimmten `buildspec.yml` aus.
|
||||
- `StartBuildBatch` ermöglicht es Ihnen, eine Batch von Builds mit komplexeren Konfigurationen zu starten (wie das gleichzeitige Ausführen mehrerer Builds).
|
||||
- `StartBuildBatch` ermöglicht es Ihnen, eine Batch von Builds mit komplexeren Konfigurationen zu starten (wie das Ausführen mehrerer Builds parallel).
|
||||
|
||||
**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu angehängten AWS Codebuild-Rollen.
|
||||
|
||||
### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
|
||||
|
||||
Ein Angreifer mit den Berechtigungen **`iam:PassRole`, `codebuild:CreateProject` und `codebuild:StartBuild` oder `codebuild:StartBuildBatch`** wäre in der Lage, **die Privilegien auf jede Codebuild IAM-Rolle zu eskalieren**, indem er eine laufende erstellt.
|
||||
Ein Angreifer mit den Berechtigungen **`iam:PassRole`, `codebuild:CreateProject` und `codebuild:StartBuild` oder `codebuild:StartBuildBatch`** wäre in der Lage, **die Berechtigungen auf jede Codebuild IAM-Rolle zu eskalieren**, indem er eine laufende erstellt.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Example1" }}
|
||||
@@ -302,7 +302,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
|
||||
|
||||
### SSM
|
||||
|
||||
Wenn man **genug Berechtigungen hat, um eine SSM-Sitzung zu starten**, ist es möglich, **in ein Codebuild-Projekt** einzudringen, das gerade gebaut wird.
|
||||
Mit **ausreichenden Berechtigungen, um eine SSM-Sitzung zu starten**, ist es möglich, **in ein Codebuild-Projekt** einzudringen, das gerade gebaut wird.
|
||||
|
||||
Das Codebuild-Projekt muss einen Haltepunkt haben:
|
||||
|
||||
@@ -323,7 +323,7 @@ Für weitere Informationen [**siehe die Dokumentation**](https://docs.aws.amazon
|
||||
|
||||
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
|
||||
|
||||
Ein Angreifer, der in der Lage ist, einen Build eines bestimmten CodeBuild-Projekts zu starten/neuzustarten, dessen `buildspec.yml`-Datei in einem S3-Bucket gespeichert ist, auf den der Angreifer Schreibzugriff hat, kann eine Befehlsausführung im CodeBuild-Prozess erlangen.
|
||||
Ein Angreifer, der in der Lage ist, einen Build eines bestimmten CodeBuild-Projekts zu starten/neuzustarten, das seine `buildspec.yml`-Datei in einem S3-Bucket speichert, auf den der Angreifer Schreibzugriff hat, kann die Ausführung von Befehlen im CodeBuild-Prozess erlangen.
|
||||
|
||||
Hinweis: Die Eskalation ist nur relevant, wenn der CodeBuild-Arbeiter eine andere Rolle hat, hoffentlich mit mehr Berechtigungen, als die des Angreifers.
|
||||
```bash
|
||||
@@ -354,7 +354,7 @@ commands:
|
||||
**Auswirkungen:** Direkte Privilegieneskalation zu der Rolle, die vom AWS CodeBuild-Arbeiter verwendet wird, die normalerweise hohe Berechtigungen hat.
|
||||
|
||||
> [!WARNING]
|
||||
> Beachten Sie, dass das buildspec im Zip-Format erwartet werden könnte, sodass ein Angreifer die `buildspec.yml` aus dem Stammverzeichnis herunterladen, entpacken, ändern, erneut zippen und hochladen müsste.
|
||||
> Beachten Sie, dass das buildspec im Zip-Format erwartet werden könnte, sodass ein Angreifer herunterladen, entpacken, die `buildspec.yml` im Stammverzeichnis ändern, erneut zippen und hochladen müsste.
|
||||
|
||||
Weitere Details finden Sie [hier](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Mehr **Info über ECS** in:
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Ein Angreifer, der die Berechtigung `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Aufgabenbeschreibung** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **ausführt**.
|
||||
Ein Angreifer, der die Berechtigungen `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Aufgabenbeschreibung** mit einem **bösartigen Container** erstellen, der die Metadaten-Anmeldeinformationen stiehlt und **ausführt**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
@@ -140,7 +140,7 @@ aws ecs run-task \
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Dieses Szenario ist wie die vorherigen, aber **ohne** die Berechtigung **`iam:PassRole`**.\
|
||||
Das ist immer noch interessant, denn wenn Sie einen beliebigen Container ausführen können, auch wenn es ohne Rolle ist, könnten Sie **einen privilegierten Container ausführen, um** zum Knoten zu entkommen und **die EC2 IAM-Rolle** sowie die **anderen ECS-Containerrollen**, die im Knoten ausgeführt werden, zu **stehlen**.\
|
||||
Das ist immer noch interessant, denn wenn Sie einen beliebigen Container ausführen können, auch wenn es ohne Rolle ist, könnten Sie **einen privilegierten Container ausführen, um** zum Knoten zu entkommen und **die EC2 IAM-Rolle** sowie die **anderen ECS-Containerrollen** zu stehlen, die im Knoten ausgeführt werden.\
|
||||
Sie könnten sogar **andere Aufgaben zwingen, innerhalb der EC2-Instanz** zu laufen, die Sie kompromittieren, um deren Anmeldeinformationen zu stehlen (wie im [**Privesc zu Knoten Abschnitt**](aws-ecs-privesc.md#privesc-to-node) besprochen).
|
||||
|
||||
> [!WARNING]
|
||||
@@ -187,12 +187,12 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle ausführen** innerhalb eines laufenden Containers und die angehängte IAM-Rolle exfiltrieren (man benötigt die Beschreibungsberechtigungen, da es notwendig ist, `aws ecs execute-command` auszuführen).\
|
||||
Um dies zu tun, muss die Container-Instanz jedoch den **ExecuteCommand-Agenten** ausführen (was standardmäßig nicht der Fall ist).
|
||||
Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle ausführen** innerhalb eines laufenden Containers und die angehängte IAM-Rolle exfiltrieren (du benötigst die Beschreibungsberechtigungen, da es notwendig ist, `aws ecs execute-command` auszuführen).\
|
||||
Um dies zu tun, muss die Container-Instanz jedoch den **ExecuteCommand-Agent** ausführen (was standardmäßig nicht der Fall ist).
|
||||
|
||||
Daher könnte der Angreifer versuchen:
|
||||
|
||||
- **Versuchen, einen Befehl** in jedem laufenden Container auszuführen.
|
||||
- **Versuche, einen Befehl** in jedem laufenden Container auszuführen.
|
||||
```bash
|
||||
# List enableExecuteCommand on each task
|
||||
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
|
||||
@@ -221,7 +221,7 @@ Du kannst **Beispiele für diese Optionen** in **früheren ECS privesc Abschnitt
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
Überprüfe auf der **ssm privesc Seite**, wie du diese Berechtigung ausnutzen kannst, um **privesc zu ECS** zu erreichen:
|
||||
Überprüfe auf der **ssm privesc Seite**, wie du diese Berechtigung missbrauchen kannst, um **privesc zu ECS** zu erhalten:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
@@ -229,7 +229,7 @@ aws-ssm-privesc.md
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Überprüfe auf der **ec2 privesc Seite**, wie du diese Berechtigungen ausnutzen kannst, um **privesc zu ECS** zu erreichen:
|
||||
Überprüfe auf der **ec2 privesc Seite**, wie du diese Berechtigungen missbrauchen kannst, um **privesc zu ECS** zu erhalten:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
|
||||
@@ -32,6 +32,6 @@ Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-The
|
||||
```css
|
||||
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Thema, Nachrichtenexposition oder Themenmanipulation durch unbefugte Benutzer oder Dienste, Störung der normalen Funktionalität von Anwendungen, die auf das Thema angewiesen sind.
|
||||
**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Thema, Nachrichtenexposition oder Themenmanipulation durch unbefugte Benutzer oder Dienste, Störung der normalen Funktion für Anwendungen, die auf das Thema angewiesen sind.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -29,7 +29,7 @@ Ein Angreifer mit den Berechtigungen **`states:TestState`** & **`iam:PassRole`**
|
||||
```bash
|
||||
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 erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
|
||||
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 erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
|
||||
|
||||
- **stateDefinition.json**:
|
||||
```json
|
||||
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
|
||||
|
||||
### `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 verfügbar für Standard-Workflows**, **nur für Ausdruckszustandsmaschinen**) um eine Ausführung über die Zustandsmaschine zu starten.
|
||||
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 müssen auch die Berechtigungen **`states:StartExecution`** oder **`states:StartSyncExecution`** haben (**`states:StartSyncExecution`** ist **nicht verfügbar für Standard-Workflows**, **nur für Ausdruckszustandsmaschinen**), um eine Ausführung über die Zustandsmaschine 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>]\
|
||||
@@ -142,7 +142,7 @@ Ein Angreifer mit der Berechtigung **`states:UpdateStateMachine`** wäre in der
|
||||
|
||||
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.
|
||||
1. **Permissive IAM-Rolle**: Wenn die mit der Zustandsmaschine verbundene IAM-Rolle bereits permissiv ist (sie hat beispielsweise die angehängte **`arn:aws:iam::aws:policy/AdministratorAccess`**-Richtlinie), 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.
|
||||
```bash
|
||||
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
|
||||
@@ -151,7 +151,7 @@ aws states update-state-machine --state-machine-arn <value> [--definition <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.
|
||||
|
||||
> [!WARNING]
|
||||
> 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 angehängt).
|
||||
> 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 angehängt).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Legit State Machine" }}
|
||||
|
||||
Reference in New Issue
Block a user