Pentesting CI/CD Methodology
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
VCS steht für Versionskontrollsystem, dieses System ermöglicht Entwicklern, ihren Quellcode zu verwalten. Das gebräuchlichste ist git und du wirst 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 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.
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 deines 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 dein Code Leaks in den Commits enthält und der Angreifer auf das Repo zugreifen kann (weil es öffentlich ist oder weil er Zugang hat), könnte er die Leaks entdecken.
Zugriff: Wenn ein Angreifer auf ein Konto innerhalb der VCS-Plattform zugreifen kann, 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 also 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 unterschiedlichen Zielen im Hinterkopf durchgeführt werden:
Den Hauptbranch kompromittieren, um die Produktion zu gefährden.
Den Hauptbranch (oder andere Branches) kompromittieren, um Entwicklermaschinen zu gefährden (da sie normalerweise Tests, Terraform oder andere Dinge auf ihren Maschinen im Repo ausführen).
Die Pipeline kompromittieren (siehe nächsten Abschnitt).
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.
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 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üfe die VCS-Pentesting-Methodologie für eine Zusammenfassung der Möglichkeiten, Zugriff zu erhalten).
Beachte, 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.
Wenn man die 3 Varianten kennt, um eine Pipeline zu vergiften, schauen wir uns an, 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ähle es aus: Manchmal hat die Pipelines-Plattform mehrere Maschinen konfiguriert und wenn du die CI-Konfigurationsdatei ändern kannst, kannst du angeben, wo du den bösartigen Code ausführen möchtest. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse-Shell ausführen, um zu versuchen, sie weiter auszunutzen.
Produktion kompromittieren: Wenn du innerhalb der Pipeline bist und die endgültige Version von dort erstellt und bereitgestellt wird, könntest du den Code kompromittieren, der letztendlich in der Produktion ausgeführt wird.
Chain-bench ist ein Open-Source-Tool zur Überprüfung deines 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, wo sie Risiken von der Codezeit bis zur Bereitstellungszeit aufdecken kann.
Überprüfe diesen interessanten Artikel über die Top 10 CI/CD-Risiken laut Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/
Auf jeder Plattform, die du lokal ausführen kannst, findest du, wie du sie lokal starten kannst, damit du sie nach deinen Wünschen konfigurieren kannst, um sie zu testen.
Gitea + Jenkins Lab: https://github.com/cider-security-research/cicd-goat
Checkov: Checkov ist ein statisches Code-Analyse-Tool für Infrastruktur als Code.
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
