# Pentesting CI/CD Methodology {{#include ../banners/hacktricks-training.md}}
## VCS VCS steht für **Version Control System**, dieses System ermöglicht Entwicklern, ihren **Quellcode zu verwalten**. Das gebräuchlichste ist **git** und Sie werden normalerweise Unternehmen finden, die es auf einer der folgenden **Plattformen** verwenden: - Github - Gitlab - Bitbucket - Gitea - Cloud-Anbieter (sie bieten ihre eigenen VCS-Plattformen an) ## CI/CD Pipelines CI/CD-Pipelines ermöglichen es Entwicklern, die **Ausführung von Code** für verschiedene Zwecke zu **automatisieren**, einschließlich des Erstellens, Testens und Bereitstellens von Anwendungen. Diese automatisierten Workflows werden durch **spezifische Aktionen** ausgelöst, wie z.B. Code-Pushes, Pull-Requests oder geplante Aufgaben. Sie sind nützlich, um den Prozess von der Entwicklung bis zur Produktion zu optimieren. 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 > [!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. Plattformen, die den Quellcode Ihres Projekts enthalten, enthalten sensible Informationen, und die Menschen müssen sehr vorsichtig mit den innerhalb dieser Plattform gewährten Berechtigungen sein. Dies sind einige häufige Probleme auf VCS-Plattformen, die Angreifer ausnutzen könnten: - **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. - **Zugriff**: Wenn ein Angreifer **Zugriff auf ein Konto innerhalb der VCS-Plattform** hat, könnte er **mehr Sichtbarkeit und Berechtigungen** erlangen. - **Registrierung**: Einige Plattformen erlauben externen Benutzern nur, ein Konto zu erstellen. - **SSO**: Einige Plattformen erlauben es Benutzern nicht, sich zu registrieren, erlauben jedoch jedem, mit einem gültigen SSO zuzugreifen (ein Angreifer könnte beispielsweise sein Github-Konto verwenden, um einzutreten). - **Anmeldeinformationen**: Benutzername+Pwd, persönliche Tokens, ssh-Schlüssel, Oauth-Tokens, Cookies... es gibt verschiedene Arten von Tokens, die ein Benutzer stehlen könnte, um auf irgendeine Weise auf ein Repo zuzugreifen. - **Webhooks**: VCS-Plattformen erlauben das Generieren von Webhooks. Wenn sie **nicht geschützt** sind mit nicht sichtbaren Geheimnissen, könnte ein **Angreifer sie ausnutzen**. - Wenn kein Geheimnis vorhanden ist, könnte der Angreifer den Webhook der Drittanbieterplattform ausnutzen. - 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 der Pipeline** (siehe nächsten Abschnitt). ## Pipelines Pentesting Methodology 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**. ### 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 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. 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**. - Dazu muss er möglicherweise in der Lage sein, **Branch-Schutzmaßnahmen zu umgehen**. Es gibt 3 PPE-Varianten: - **D-PPE**: Ein **Direkter PPE**-Angriff tritt auf, wenn der Akteur die **CI-Konfigurationsdatei** ändert, die ausgeführt werden soll. - **I-DDE**: Ein **Indirekter PPE**-Angriff tritt auf, wenn der Akteur eine **Datei** ändert, auf die die CI-Konfigurationsdatei, die ausgeführt werden soll, **angewiesen ist** (wie eine Make-Datei oder eine Terraform-Konfiguration). - **Ö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 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: - **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. - 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. - **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 ### 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 Ü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) ### Automatic Tools - [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** ist ein statisches Code-Analyse-Tool für Infrastruktur als Code. ## References - [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) {{#include ../banners/hacktricks-training.md}}