mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 06:30:35 -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" }}
|
||||
|
||||
@@ -17,7 +17,7 @@ Verschiedene Methoden, um herauszufinden, ob eine Webseite AWS zur Speicherung v
|
||||
#### Enumeration & OSINT:
|
||||
|
||||
- Verwendung des **wappalyzer** Browser-Plugins
|
||||
- Verwendung von burp (**Spidering** des Webs) oder durch manuelles Navigieren durch die Seite, alle **geladenen Ressourcen** werden im Verlauf gespeichert.
|
||||
- Verwendung von Burp (**Spidering** des Webs) oder durch manuelles Navigieren durch die Seite, alle **geladenen Ressourcen** werden im Verlauf gespeichert.
|
||||
- **Überprüfen Sie Ressourcen** in Domains wie:
|
||||
|
||||
```
|
||||
@@ -98,7 +98,7 @@ Non-authoritative answer:
|
||||
```
|
||||
Überprüfen Sie, ob die aufgelöste Domain das Wort "website" enthält.\
|
||||
Sie können auf die statische Website zugreifen, indem Sie zu: `flaws.cloud.s3-website-us-west-2.amazonaws.com` gehen\
|
||||
oder Sie können auf den Bucket zugreifen, indem Sie besuchen: `flaws.cloud.s3-us-west-2.amazonaws.com`
|
||||
oder Sie können auf den Bucket zugreifen, indem Sie `flaws.cloud.s3-us-west-2.amazonaws.com` besuchen.
|
||||
|
||||
|
||||
|
||||
@@ -136,7 +136,7 @@ https://{user_provided}.s3.amazonaws.com
|
||||
```
|
||||
### Konto-ID aus öffentlichem Bucket abrufen
|
||||
|
||||
Es ist möglich, eine AWS-Konto-ID zu bestimmen, indem man den neuen **`S3:ResourceAccount`** **Policy Condition Key** ausnutzt. Diese Bedingung **beschränkt den Zugriff basierend auf dem S3-Bucket**, in dem sich ein Konto befindet (andere kontobasierte Richtlinien beschränken den Zugriff basierend auf dem Konto, in dem sich der anfragende Principal befindet).\
|
||||
Es ist möglich, ein AWS-Konto zu bestimmen, indem man den neuen **`S3:ResourceAccount`** **Policy Condition Key** ausnutzt. Diese Bedingung **beschränkt den Zugriff basierend auf dem S3-Bucket**, in dem sich ein Konto befindet (andere kontobasierte Richtlinien beschränken den Zugriff basierend auf dem Konto, in dem sich der anfordernde Principal befindet).\
|
||||
Und da die Richtlinie **Wildcard-Zeichen** enthalten kann, ist es möglich, die Kontonummer **nur eine Ziffer nach der anderen** zu finden.
|
||||
|
||||
Dieses Tool automatisiert den Prozess:
|
||||
@@ -149,7 +149,7 @@ s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket
|
||||
# With an object
|
||||
s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext
|
||||
```
|
||||
Diese Technik funktioniert auch mit API Gateway-URLs, Lambda-URLs, Data Exchange-Datensätzen und sogar um den Wert von Tags zu erhalten (wenn Sie den Tag-Schlüssel kennen). Weitere Informationen finden Sie in der [**originalen Forschung**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) und dem Tool [**conditional-love**](https://github.com/plerionhq/conditional-love/), um diese Ausnutzung zu automatisieren.
|
||||
Diese Technik funktioniert auch mit API Gateway-URLs, Lambda-URLs, Data Exchange-Datensätzen und sogar um den Wert von Tags abzurufen (wenn Sie den Tag-Schlüssel kennen). Weitere Informationen finden Sie in der [**originalen Forschung**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) und dem Tool [**conditional-love**](https://github.com/plerionhq/conditional-love/), um diese Ausnutzung zu automatisieren.
|
||||
|
||||
### Bestätigen, dass ein Bucket zu einem AWS-Konto gehört
|
||||
|
||||
@@ -165,7 +165,7 @@ Wenn der Fehler "Zugriff verweigert" lautet, bedeutet das, dass die Kontonummer
|
||||
|
||||
### Verwendete E-Mails zur Enumeration des Root-Kontos
|
||||
|
||||
Wie in [**diesem Blogbeitrag**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) erklärt, ist es möglich zu überprüfen, ob eine E-Mail-Adresse mit einem AWS-Konto verbunden ist, indem man **versucht, einer E-Mail Berechtigungen** über einen S3-Bucket über ACLs zu gewähren. Wenn dies keinen Fehler auslöst, bedeutet das, dass die E-Mail ein Root-Benutzer eines AWS-Kontos ist:
|
||||
Wie in [**diesem Blogbeitrag**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) erklärt, ist es möglich zu überprüfen, ob eine E-Mail-Adresse mit einem AWS-Konto verknüpft ist, indem man **versucht, einer E-Mail Berechtigungen** über einen S3-Bucket über ACLs zu gewähren. Wenn dies keinen Fehler auslöst, bedeutet das, dass die E-Mail ein Root-Benutzer eines AWS-Kontos ist:
|
||||
```python
|
||||
s3_client.put_bucket_acl(
|
||||
Bucket=bucket_name,
|
||||
|
||||
Reference in New Issue
Block a user