Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

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

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD Methodologie
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -20,7 +20,7 @@ CI/CD-Pipelines ermöglichen es Entwicklern, die **Ausführung von Code** für v
 
 Diese Systeme müssen jedoch **irgendwo ausgeführt werden** und normalerweise mit **privilegierten Anmeldeinformationen, um Code bereitzustellen oder auf sensible Informationen zuzugreifen**.
 
-## VCS Pentesting Methodology
+## VCS Pentesting Methodologie
 
 > [!NOTE]
 > Auch wenn einige VCS-Plattformen das Erstellen von Pipelines erlauben, werden wir in diesem Abschnitt nur potenzielle Angriffe auf die Kontrolle des Quellcodes analysieren.
@@ -37,25 +37,25 @@ Plattformen, die den Quellcode Ihres Projekts enthalten, enthalten sensible Info
 - Wenn das Geheimnis in der URL ist, passiert dasselbe und der Angreifer hat auch das Geheimnis.
 - **Code-Kompromittierung:** Wenn ein böswilliger Akteur eine Art von **Schreibzugriff** auf die Repos hat, könnte er versuchen, **bösartigen Code einzuschleusen**. Um erfolgreich zu sein, muss er möglicherweise **Branch-Schutzmaßnahmen umgehen**. Diese Aktionen können mit verschiedenen Zielen im Hinterkopf durchgeführt werden:
 - Kompromittierung des Hauptzweigs, um **die Produktion zu gefährden**.
-- Kompromittierung des Hauptzweigs (oder anderer Zweige), um **Entwicklermaschinen zu gefährden** (da sie normalerweise Tests, Terraform oder andere Dinge innerhalb des Repos auf ihren Maschinen ausführen).
+- Kompromittierung des Hauptzweigs (oder anderer Zweige), um **Entwicklermaschinen zu gefährden** (da sie normalerweise Tests, Terraform oder andere Dinge auf ihren Maschinen im Repo ausführen).
 - **Kompromittierung der Pipeline** (siehe nächsten Abschnitt).
 
-## Pipelines Pentesting Methodology
+## Pipelines Pentesting Methodologie
 
 Der gebräuchlichste Weg, eine Pipeline zu definieren, besteht darin, eine **CI-Konfigurationsdatei, die im Repository gehostet wird**, zu verwenden, das die Pipeline erstellt. 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 konsistentes Format, zum Beispiel — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien, die sich unter .github/workflows befinden. Wenn sie ausgelöst werden, **zieht der Pipeline-Job den Code** aus der ausgewählten Quelle (z.B. Commit / Branch) und **führt die im CI-Konfigurationsdatei angegebenen Befehle** gegen diesen Code aus.
 
-Daher ist das ultimative Ziel des Angreifers, irgendwie **diese Konfigurationsdateien** oder die **Befehle, die sie ausführen**, zu **kompromittieren**.
+Daher ist das ultimative Ziel des Angreifers, auf irgendeine Weise **diese Konfigurationsdateien** oder die **Befehle, die sie ausführen**, zu **kompromittieren**.
 
-### PPE - Poisoned Pipeline Execution
+### PPE - Vergiftete Pipeline-Ausführung
 
-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, ändern, um bösartige Befehle einzufügen. Dies "vergiftet" die CI-Pipeline und führt zur Ausführung dieser bösartigen Befehle.
+Der Vergiftete Pipeline-Ausführungs (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, ändern, um bösartige Befehle einzuschließen. Dies "vergiftet" die CI-Pipeline und führt zur Ausführung dieser bösartigen Befehle.
 
 Damit ein böswilliger Akteur bei einem PPE-Angriff erfolgreich ist, muss er in der Lage sein:
 
 - **Schreibzugriff auf die VCS-Plattform** zu haben, da Pipelines normalerweise ausgelöst werden, wenn ein Push oder ein Pull-Request durchgeführt wird. (Überprüfen Sie die VCS-Pentesting-Methodologie für eine Zusammenfassung der Möglichkeiten, Zugriff zu erhalten).
 - Beachten Sie, dass manchmal ein **externer PR als "Schreibzugriff" zählt**.
-- Selbst wenn er Schreibberechtigungen hat, muss er sicherstellen, dass er die **CI-Konfigurationsdatei oder andere Dateien, auf die die Konfiguration angewiesen ist, ändern kann**.
+- Selbst wenn er Schreibberechtigungen hat, muss er sicherstellen, dass er die **CI-Konfigurationsdatei oder andere Dateien, auf die die Konfiguration angewiesen ist**, **ändern** kann.
 - Dazu muss er möglicherweise in der Lage sein, **Branch-Schutzmaßnahmen zu umgehen**.
 
 Es gibt 3 PPE-Varianten:
@@ -65,39 +65,39 @@ Es gibt 3 PPE-Varianten:
 - **Öffentlicher PPE oder 3PE**: In einigen Fällen können die Pipelines von Benutzern **ausgelöst werden, die keinen Schreibzugriff im Repo haben** (und die möglicherweise nicht einmal Teil der Organisation sind), weil sie einen PR senden können.
 - **3PE-Befehlsinjektion**: Normalerweise setzen CI/CD-Pipelines **Umgebungsvariablen** mit **Informationen über den PR**. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (wie der Titel des PR) und in einem **gefährlichen Ort** (wie der Ausführung von **sh-Befehlen**) **verwendet** wird, könnte ein Angreifer **Befehle dort injizieren**.
 
-### Exploitation Benefits
+### Ausbeutungsnutzen
 
-Wenn man die 3 Varianten kennt, um eine Pipeline zu vergiften, lassen Sie uns überprüfen, was ein Angreifer nach einer erfolgreichen Ausnutzung erhalten könnte:
+Wenn man die 3 Varianten kennt, um eine Pipeline zu vergiften, lassen Sie uns überprüfen, was ein Angreifer nach einer erfolgreichen Ausbeutung erhalten könnte:
 
-- **Geheimnisse**: Wie bereits erwähnt, erfordern Pipelines **Berechtigungen** für ihre Jobs (Code abrufen, erstellen, bereitstellen...) und diese Berechtigungen werden normalerweise **in Geheimnissen gewährt**. Diese Geheimnisse sind normalerweise über **Umgebungsvariablen oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Geheimnisse wie möglich zu exfiltrieren.
+- **Geheimnisse**: Wie bereits erwähnt, erfordern Pipelines **Berechtigungen** für ihre Jobs (den Code abrufen, ihn erstellen, bereitstellen...) und diese Berechtigungen werden normalerweise **in Geheimnissen gewährt**. Diese Geheimnisse sind normalerweise über **Umgebungsvariablen oder Dateien im System** zugänglich. Daher wird ein Angreifer immer versuchen, so viele Geheimnisse wie möglich zu exfiltrieren.
 - Abhängig von der Pipeline-Plattform muss der Angreifer möglicherweise **die Geheimnisse in der Konfiguration angeben**. Das bedeutet, dass, wenn der Angreifer die CI-Konfigurationspipeline nicht ändern kann (**I-PPE** zum Beispiel), er **nur die Geheimnisse exfiltrieren könnte, die diese Pipeline hat**.
 - **Berechnung**: Der Code wird irgendwo ausgeführt, abhängig davon, wo er ausgeführt wird, könnte ein Angreifer in der Lage sein, weiter zu pivotieren.
-- **On-Premises**: Wenn die Pipelines vor Ort ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugriff auf mehr Ressourcen** enden.
-- **Cloud**: Der Angreifer könnte auf **andere Maschinen in der Cloud** zugreifen, könnte aber auch **IAM-Rollen/Dienstkonten-Tokens** von dort **exfiltrieren**, um **weiteren Zugriff innerhalb der Cloud** zu erhalten.
-- **Plattformmaschine**: Manchmal werden die Jobs innerhalb der **Pipelines-Plattformmaschinen** ausgeführt, die sich normalerweise in einer Cloud mit **keinem weiteren Zugriff** befinden.
+- **Vor Ort**: Wenn die Pipelines vor Ort ausgeführt werden, könnte ein Angreifer in einem **internen Netzwerk mit Zugang zu mehr Ressourcen** enden.
+- **Cloud**: Der Angreifer könnte auf **andere Maschinen in der Cloud** zugreifen, könnte aber auch **IAM-Rollen/Dienstkonten-Tokens** von dort **exfiltrieren**, um **weiteren Zugang innerhalb der Cloud** zu erhalten.
+- **Plattformmaschine**: Manchmal werden die Jobs innerhalb der **Pipelines-Plattformmaschinen** ausgeführt, die sich normalerweise in einer Cloud mit **keinem weiteren Zugang** befinden.
 - **Wählen Sie es aus:** Manchmal hat die **Pipelines-Plattform mehrere Maschinen konfiguriert**, und wenn Sie die **CI-Konfigurationsdatei ändern können**, können Sie **angeben, wo Sie den bösartigen Code ausführen möchten**. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse-Shell ausführen, um zu versuchen, sie weiter auszunutzen.
 - **Kompromittierung der Produktion**: Wenn Sie sich innerhalb der Pipeline befinden und die endgültige Version von dort erstellt und bereitgestellt wird, könnten Sie **den Code kompromittieren, der letztendlich in der Produktion ausgeführt wird**.
 
-## More relevant info
+## Weitere relevante Informationen
 
 ### Tools & CIS Benchmark
 
 - [**Chain-bench**](https://github.com/aquasecurity/chain-bench) ist ein Open-Source-Tool zur Überprüfung Ihres Software-Lieferketten-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). Die Überprüfung konzentriert sich auf den gesamten SDLC-Prozess, in dem Risiken von der Codezeit bis zur Bereitstellungszeit aufgedeckt werden können.
 
-### Top 10 CI/CD Security Risk
+### Top 10 CI/CD Sicherheitsrisiken
 
 Überprüfen Sie 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/)
 
 ### Labs
 
-- Auf jeder Plattform, die Sie lokal ausführen können, finden Sie, wie Sie sie lokal starten können, damit Sie sie nach Belieben konfigurieren und testen können.
-- Gitea + Jenkins-Labor: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- Auf jeder Plattform, die Sie lokal ausführen können, finden Sie, wie Sie sie lokal starten können, damit Sie sie nach Ihren Wünschen konfigurieren können, um sie zu testen.
+- Gitea + Jenkins Lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
 
-### Automatic Tools
+### Automatische Tools
 
 - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein statisches Code-Analyse-Tool für Infrastruktur als Code.
 
-## References
+## Referenzen
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)