Pentesting CI/CD Methodologie

Reading time: 8 minutes

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 Methodologie

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 auf ihren Maschinen im Repo ausführen).
• Kompromittierung der Pipeline (siehe nächsten Abschnitt).

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, auf irgendeine Weise diese Konfigurationsdateien oder die Befehle, die sie ausführen, zu kompromittieren.

PPE - Vergiftete Pipeline-Ausführung

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.
• 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.

Ausbeutungsnutzen

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 (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.
• 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.

Weitere relevante Informationen

Tools & CIS Benchmark

• 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. 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 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/

Labs

• 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

Automatische Tools

• Checkov: Checkov ist ein statisches Code-Analyse-Tool für Infrastruktur als Code.

Referenzen

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422