Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD Methodik
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,7 +6,7 @@
 
 ## VCS
 
-VCS stands for **Version Control System**, dieses System ermöglicht Entwicklern, ihren **Source Code zu verwalten**. Das gebräuchlichste ist **git** und man findet es in der Regel bei Unternehmen auf einer der folgenden **Plattformen**:
+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:
 
 - Github
 - Gitlab
@@ -18,81 +18,81 @@ VCS stands for **Version Control System**, dieses System ermöglicht Entwicklern
 
 ## CI/CD Pipelines
 
-CI/CD pipelines ermöglichen 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 z. B. code pushes, pull requests oder geplante Tasks. Sie sind nützlich, um den Prozess von der Entwicklung zur Produktion zu straffen.
+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.
 
-Allerdings müssen diese Systeme **irgendwo ausgeführt** werden und oft mit **privilegierten Credentials, um Code zu deployen oder auf sensitive Informationen zuzugreifen**.
+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**.
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> 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.
+> Selbst wenn einige VCS platforms erlauben, pipelines zu erstellen, werden wir in diesem Abschnitt nur potenzielle Angriffe auf die Kontrolle des Quellcodes analysieren.
 
-Plattformen, die den Source Code deines Projekts enthalten, bergen sensitive Informationen und es ist wichtig, sehr sorgfältig mit den vergebenen Berechtigungen innerhalb dieser Plattform umzugehen. Dies sind einige häufige Probleme in VCS Plattformen, die ein Angreifer ausnutzen könnte:
+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:
 
-- **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 Zugriff hat), könnte er diese Leaks entdecken.
-- **Access**: Wenn ein Angreifer **Zugriff auf ein Konto innerhalb der VCS platform** erhält, könnte er **mehr Sichtbarkeit und Berechtigungen** erlangen.
-- **Register**: Manche Plattformen erlauben es externen Benutzern einfach, ein Konto zu erstellen.
-- **SSO**: Manche Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann zugreifen (z. B. könnte ein Angreifer sein Github-Konto verwenden, um zuzugreifen).
-- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt mehrere Arten von Tokens, die ein Benutzer 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 steckt, gilt das Gleiche und der Angreifer hat das Secret ebenfalls.
-- **Code compromise:** Wenn ein böswilliger Akteur irgendeine Art von **write**-Zugriff auf die Repos hat, könnte er versuchen, **malicious code zu injecten**. Um erfolgreich zu sein, muss er möglicherweise Branch-Protections **bypassen**. Diese Aktionen können mit unterschiedlichen Zielen ausgeführt werden:
+- **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 **Entwickler-Maschinen zu kompromittieren** (da diese normalerweise Tests, terraform oder andere Dinge im Repo auf ihren Maschinen ausführen).
+  - 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)
 
 ## Pipelines Pentesting Methodology
 
-Die gebräuchlichste Art, 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 Einstellungen der Build-Umgebung.\
-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 die Pipeline ausgelöst wird, **holt der Pipeline-Job den Code** aus der gewählten Quelle (z. B. Commit / Branch) und **führt die in der CI configuration file angegebenen Befehle** gegen diesen Code aus.
+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.
 
-Das ultimative Ziel des Angreifers ist daher, diese Konfigurationsdateien oder die Befehle, die sie ausführen, auf irgendeine Weise zu **compromisen**.
+Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder die Befehle, die sie ausführen, irgendwie zu **kompromittieren**.
 
 ### 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 nötigen Berechtigungen können CI config Dateien oder andere Dateien, die vom Pipeline-Job verwendet werden, modifizieren, um bösartige Befehle einzufügen. Dadurch wird die CI Pipeline "poisoned" und diese bösartigen Befehle ausgeführt.
+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.
 
 Damit ein böswilliger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er:
 
-- **Write access to the VCS platform** haben, da Pipelines in der Regel ausgelöst werden, wenn ein Push oder ein Pull Request erfolgt. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, um Zugriff zu erhalten).
-- Beachte, dass manchmal ein **external PR als "write access"** gilt.
-- Selbst wenn er write permissions hat, muss er sicherstellen können, dass er die **CI config file oder andere Dateien, auf die die Config angewiesen ist, modifizieren** kann.
-- Dafür muss er möglicherweise Branch-Protections **bypassen**.
+- **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**.
 
-Es gibt 3 PPE-Varianten:
+Es gibt 3 PPE-Flavours:
 
-- **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 die CI config angewiesen ist (z. B. ein Makefile oder eine terraform config).
-- **Public PPE or 3PE**: In einigen Fällen können Pipelines von Benutzern ausgelöst werden, die **kein write access im Repo** haben (und vielleicht nicht einmal Teil der Org sind), weil sie ein PR senden können.
-- **3PE Command Injection**: Üblicherweise setzen CI/CD pipelines **environment variables** 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 (z. B. beim Ausführen von **sh commands**), könnte ein Angreifer **Befehle injizieren**.
+- **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**.
 
 ### Exploitation Benefits
 
-Wenn man die 3 Varianten kennt, schauen wir uns an, was ein Angreifer nach erfolgreicher Exploitation erreichen könnte:
+Wenn man die 3 Flavours kennt, schauen wir, was ein Angreifer nach einer erfolgreichen Ausnutzung erreichen könnte:
 
-- **Secrets**: Wie bereits erwähnt, benötigen Pipelines **Privilegien** für ihre Jobs (Code abrufen, bauen, deployen ...) und diese Privilegien werden üblicherweise in **Secrets** hinterlegt. Diese Secrets sind oft über **env variables oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Secrets wie möglich zu exfiltrieren.
-- Abhängig von der Pipeline-Plattform **muss der Angreifer die Secrets vielleicht in der Config angeben**. Das bedeutet, wenn der Angreifer die CI configuration pipeline nicht ändern kann (z. B. bei I-PPE), könnte er **nur die Secrets exfiltrieren, die diese Pipeline bereits hat**.
-- **Computation**: Der Code wird irgendwo ausgeführt; abhängig davon, wo, könnte ein Angreifer weiter pivotieren.
-- **On-Premises**: Wenn die Pipelines on-premises ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk** landen mit Zugriff auf weitere Ressourcen.
-- **Cloud**: Der Angreifer könnte **andere Maschinen in der Cloud** erreichen, aber auch IAM roles/service accounts **tokens** exfiltrieren, um **weiteren Zugang in der Cloud** zu erhalten.
-- **Platforms machine**: Manchmal werden Jobs innerhalb der **Pipelines platform machines** ausgeführt, die normalerweise in einer Cloud laufen und **keinen weiteren Zugang** haben.
-- **Select it:** Manchmal hat die **Pipelines platform mehrere Maschinen konfiguriert** und wenn du die CI config ändern kannst, kannst du **angeben, wo der malicious code laufen soll**. In diesem Fall wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse Shell starten, um weiter zu versuchen, sie auszunutzen.
-- **Compromise production**: Wenn du in der Pipeline bist und die finale Version von dort gebaut und deployed wird, könntest du den Code kompromittieren, der letztlich in Production läuft.
+- **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.
+- **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**.
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Auditierung deiner Software Supply Chain für Security Compliance, 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 bis Deploy aufdecken.
+- [**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.
 
 ### Top 10 CI/CD Security Risk
 
-Siehe diesen interessanten Artikel über die 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/)
+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/)
 
 ### Labs
 
-- Für jede 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 du lokal ausführen kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst.
 - Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
 ### Automatic Tools