Pentesting CI/CD Methodology
VCS
VCS steht für Versionskontrollsystem, diese Systeme ermöglichen es Entwicklern, ihren Quellcode zu verwalten. Das gängigste ist git und Sie werden Unternehmen in der Regel eine der folgenden Plattformen verwenden sehen:
Github
Gitlab
Bitbucket
Gitea
Cloud-Anbieter (sie bieten ihre eigenen VCS-Plattformen an)
Pipelines
Pipelines ermöglichen es Entwicklern, die Ausführung von Code zu automatisieren (für Bau-, Test-, Bereitstellungs... Zwecke), nachdem bestimmte Aktionen erfolgt sind: Ein Push, ein PR, cron... Sie sind sehr nützlich, um alle Schritte von der Entwicklung bis zur Produktion zu automatisieren.
Diese Systeme müssen jedoch irgendwo ausgeführt werden und in der Regel mit privilegierten Anmeldeinformationen zum Bereitstellen von Code.
VCS-Pentesting-Methodik
Auch wenn einige VCS-Plattformen das Erstellen von Pipelines ermöglichen, 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 Personen müssen sehr vorsichtig mit den gewährten Berechtigungen innerhalb dieser Plattform sein. Dies sind einige häufige Probleme bei VCS-Plattformen, die ein Angreifer ausnutzen könnte:
Lecks: Wenn Ihr Code Lecks in den Commits enthält und der Angreifer auf das Repository zugreifen kann (weil es öffentlich ist oder weil er Zugriff hat), könnte er die Lecks entdecken.
Zugriff: Wenn ein Angreifer Zugriff auf ein Konto innerhalb der VCS-Plattform erlangen kann, könnte er mehr Sichtbarkeit und Berechtigungen erlangen.
Registrierung: Einige Plattformen erlauben nur externen Benutzern, ein Konto zu erstellen.
SSO: Einige Plattformen erlauben Benutzern nicht, sich zu registrieren, gestatten jedoch jedem, mit einem gültigen SSO zuzugreifen (so könnte ein Angreifer beispielsweise sein Github-Konto verwenden, um einzutreten).
Anmeldeinformationen: Benutzername+Passwort, 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 Repository zuzugreifen.
Webhooks: VCS-Plattformen ermöglichen das Generieren von Webhooks. Wenn sie nicht mit nicht sichtbaren Geheimnissen geschützt sind, 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 steht, passiert dasselbe und der Angreifer hat auch das Geheimnis
Code-Kompromittierung: Wenn ein bösartiger Akteur irgendeine Art von Schreibzugriff auf die Repos hat, könnte er versuchen, bösartigen Code einzuschleusen. Um erfolgreich zu sein, müsste er möglicherweise Branch-Schutzmechanismen umgehen. Diese Aktionen können mit unterschiedlichen Zielen durchgeführt werden:
Kompromittierung des Hauptzweigs, um die Produktion zu kompromittieren.
Kompromittierung des Hauptzweigs (oder anderer Zweige), um die Entwicklermaschinen zu kompromittieren (da sie normalerweise Tests, Terraform oder andere Dinge im Repository auf ihren Maschinen ausführen).
Kompromittierung der Pipeline (siehe nächster Abschnitt)
Pipelines-Pentesting-Methodik
Der häufigste Weg, eine Pipeline zu definieren, besteht darin, eine CI-Konfigurationsdatei im Repository zu hosten, 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 in der Regel einen konsistenten Namen und ein Format, zum Beispiel — 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, zieht der Pipeline-Job den Code aus der ausgewählten Quelle (z.B. Commit / Branch) und führt die im CI-Konfigurationsfile angegebenen Befehle gegen diesen Code aus.
Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder die ausgeführten Befehle auf irgendeine Weise zu kompromittieren.
PPE - Vergiftete Pipeline-Ausführung
Der Pfad der vergifteten Pipeline-Ausführung (PPE) 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, manipulieren, um schädliche Befehle einzuschließen. Dies "vergiftet" die CI-Pipeline und führt zur Ausführung dieser schädlichen Befehle.
Damit ein bösartiger Akteur erfolgreich einen PPE-Angriff durchführen kann, 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-Methodik 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.
Dafür muss er möglicherweise in der Lage sein, Branch-Schutzmechanismen 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).
Öffentliche PPE oder 3PE: In einigen Fällen können die Pipelines von Benutzern ausgelöst werden, die keinen Schreibzugriff im Repository haben (und möglicherweise nicht einmal Teil der Organisation sind), da sie einen PR senden können.
3PE-Befehlsinjektion: Normalerweise werden CI/CD-Pipelines Umgebungsvariablen mit Informationen über den PR setzen. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (wie der Titel des PR) und an einer gefährlichen Stelle verwendet wird (wie das Ausführen von sh-Befehlen), könnte ein Angreifer Befehle einschleusen.
Ausnutzungsvorteile
Nachdem die 3 Varianten zum Vergiften einer Pipeline bekannt sind, schauen wir uns an, was ein Angreifer nach einer erfolgreichen Ausnutzung erhalten könnte:
Geheimnisse: Wie bereits erwähnt, erfordern Pipelines Berechtigungen für ihre Jobs (den Code abrufen, erstellen, bereitstellen...) und diese Berechtigungen werden normalerweise in Geheimnissen erteilt. 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.
Je nach Pipeline-Plattform muss der Angreifer 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 kann, die die Pipeline hat.
Berechnung: Der Code wird irgendwo ausgeführt, je nachdem, wo er ausgeführt wird, könnte ein Angreifer weiter 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, aber auch IAM-Rollen/Servicekonten Tokens exfiltrieren, um weiteren Zugriff innerhalb der Cloud zu erhalten.
Plattformmaschine: Manchmal werden die Jobs innerhalb der Plattformmaschinen der Pipelines ausgeführt, die normalerweise in einer Cloud ohne weiteren Zugriff sind.
Auswählen: Manchmal wird die Pipelines-Plattform mehrere Maschinen konfiguriert haben, 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 versuchen, sie weiter auszunutzen.
Produktionskompromittierung: Wenn Sie sich in der Pipeline befinden und die endgültige Version erstellt und von dort 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, bei dem Risiken von der Codierungszeit bis zur Bereitstellungszeit aufgedeckt werden können.
Top 10 CI/CD Sicherheitsrisiken
Lesen Sie diesen interessanten Artikel über die Top 10 CI/CD-Risiken gemäß Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
Auf jeder Plattform, die Sie lokal ausführen können, finden Sie Anleitungen zur lokalen Ausführung, damit Sie sie nach Ihren Wünschen konfigurieren und testen können.
Gitea + Jenkins Lab: https://github.com/cider-security-research/cicd-goat
Automatische Tools
Checkov: Checkov ist ein statisches Code-Analysetool für Infrastruktur als Code.
Referenzen
Last updated
