Pentesting CI/CD Methodik

Reading time: 8 minutes

VCS

VCS steht für Version Control System, dieses System ermöglicht Entwicklern, ihren Quellcode zu verwalten. Der gebräuchlichste ist git und üblicherweise findet man Unternehmen, die eines der folgenden platforms verwenden:

• Github
• Gitlab
• Bitbucket
• Gitea
• Gitblit
• Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines ermöglichen es Entwicklern, die Ausführung von Code zu automatisieren für verschiedene Zwecke, darunter Build, Testing und Deployment von Anwendungen. Diese automatisierten Workflows werden durch konkrete Aktionen ausgelöst, wie Code pushes, pull requests oder geplante Tasks. Sie sind nützlich, um den Prozess von der Entwicklung bis zur Produktion zu straffen.

Allerdings müssen diese Systeme irgendwo ausgeführt werden und in der Regel mit privilegierten Credentials, um Code zu deployen oder auf sensible Informationen zuzugreifen.

VCS Pentesting Methodology

Plattformen, die den Quellcode deines Projekts enthalten, bergen sensible Informationen und man muss sehr vorsichtig mit den Berechtigungen innerhalb dieser Plattform sein. Dies sind einige häufige Probleme in VCS platforms, die ein Angreifer ausnutzen könnte:

• Leaks: Wenn dein Code Leaks in den Commits enthält und der Angreifer auf das repo zugreifen kann (weil es public ist oder weil er Zugang hat), könnte er die Leaks entdecken.
• Access: Wenn ein Angreifer Zugriff auf ein Konto innerhalb der VCS platform erlangen kann, könnte er mehr Sichtbarkeit und Berechtigungen gewinnen.
• Register: Einige platforms erlauben externen Nutzern einfach, ein Konto zu erstellen.
• SSO: Manche platforms erlauben keine direkte Registrierung, aber jeder mit einem gültigen SSO kann Zugang erhalten (ein Angreifer könnte z.B. sein github-Konto verwenden).
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... es gibt verschiedene Arten von Tokens, die ein Nutzer stehlen könnte, um auf irgendeine Weise auf ein repo zuzugreifen.
• Webhooks: VCS platforms erlauben das Erstellen von webhooks. Wenn diese nicht mit nicht sichtbaren secrets geschützt sind, könnte ein Angreifer sie missbrauchen.
• Wenn kein secret vorhanden ist, könnte der Angreifer den webhook der Drittanbieter-Plattform missbrauchen.
• Wenn das secret in der URL enthalten ist, gilt dasselbe und der Angreifer hat auch das secret.
• Code compromise: Wenn ein böswilliger Akteur irgendeine Art von write-Zugriff auf die Repos hat, könnte er versuchen, bösartigen Code zu injecten. Um erfolgreich zu sein, muss er möglicherweise branch protections umgehen. Diese Aktionen können mit unterschiedlichen Zielen durchgeführt werden:
  • Kompromittiere den main branch, um die Production zu kompromittieren.
  • Kompromittiere den main (oder andere Branches), um Developer-Maschinen zu kompromittieren (da diese oft Tests, terraform oder andere Dinge innerhalb des repos auf ihren Maschinen ausführen).
  • Compromise the pipeline (siehe nächsten Abschnitt)

Pipelines Pentesting Methodology

Die gebräuchlichste Methode, eine pipeline zu definieren, ist die Verwendung einer CI configuration file, die im Repository gehostet wird, das die pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und die Build-Umgebungseinstellungen.
Diese Dateien haben typischerweise einen konsistenten Namen und ein Format, z. B. — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI) und die GitHub Actions YAML-Dateien unter .github/workflows. Wenn sie ausgelöst werden, holt der Pipeline-Job den Code aus der ausgewählten Quelle (z. B. Commit / Branch) und führt die in der CI configuration file angegebenen Befehle gegen diesen Code aus.

Daher ist das ultimative Ziel des Angreifers, diese Konfigurationsdateien oder die Befehle, die sie ausführen, irgendwie 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 notwendigen Berechtigungen können CI configuration files oder andere Dateien, die vom Pipeline-Job verwendet werden, so ändern, dass bösartige Befehle enthalten sind. Dies "vergiftet" die CI pipeline und führt zur Ausführung dieser bösartigen Befehle.

Damit ein böswilliger Akteur einen PPE-Angriff erfolgreich durchführen kann, muss er:

• Write access to the VCS platform haben, da Pipelines üblicherweise bei einem push oder pull request ausgelöst werden. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Möglichkeiten, Zugang zu erhalten).
• Beachte, dass manchmal ein external PR als "write access" zählt.
• Selbst wenn er write permissions hat, muss er sicher sein, dass er die CI config file oder andere Dateien, auf die die Konfiguration angewiesen ist, ändern kann.
• Dafür muss er möglicherweise in der Lage sein, branch protections zu umgehen.

Es gibt 3 PPE-Flavours:

• D-PPE: Ein Direct PPE-Angriff tritt auf, wenn der Akteur die CI config-Datei direkt verändert, die ausgeführt werden soll.
• I-DDE: Ein Indirect PPE-Angriff tritt auf, wenn der Akteur eine Datei ändert, auf die die CI config Datei, die ausgeführt werden soll, relyt (z. B. eine make file oder eine terraform config).
• Public PPE or 3PE: In einigen Fällen können Pipelines von Nutzern ausgelöst werden, die keinen write access im repo haben (und möglicherweise nicht einmal Teil der Org sind), weil sie einen PR senden können.
• 3PE Command Injection: Üblicherweise setzen CI/CD pipelines env variables mit Informationen über den PR. Wenn dieser Wert von einem Angreifer kontrolliert werden kann (z. B. der Titel des PR) und an einer gefährlichen Stelle verwendet wird (z. B. beim Ausführen von sh commands), könnte ein Angreifer Befehle darin injecten.

Exploitation Benefits

Wenn man die 3 Flavours kennt, schauen wir, was ein Angreifer nach einer erfolgreichen Ausnutzung erreichen könnte:

• Secrets: Wie bereits erwähnt, benötigen Pipelines Privileges für ihre Jobs (Code abrufen, builden, deployen ...) und diese Privilegien werden üblicherweise in secrets hinterlegt. Diese secrets sind meist über env variables oder Dateien im System zugänglich. Daher wird ein Angreifer stets versuchen, so viele secrets wie möglich zu exfiltrieren.
• Abhängig von der Pipeline-Plattform muss der Angreifer die secrets möglicherweise in der Konfiguration angeben. Das bedeutet, wenn der Angreifer die CI configuration pipeline nicht ändern kann (I-PPE zum Beispiel), könnte er nur die secrets exfiltrieren, die diese pipeline besitzt.
• Computation: Der Code wird irgendwo ausgeführt; abhängig davon, wo er ausgeführt wird, könnte ein Angreifer weiter pivotieren.
• On-Premises: Wenn die Pipelines on-premises ausgeführt werden, könnte ein Angreifer in einem internen Netzwerk mit Zugriff auf weitere Ressourcen landen.
• Cloud: Der Angreifer könnte auf andere Maschinen in der Cloud zugreifen, aber auch IAM roles/service accounts tokens exfiltrieren, um weiteren Zugriff innerhalb der Cloud zu erhalten.
• Platforms machine: Manchmal werden Jobs innerhalb der Pipelines platform machines ausgeführt, die üblicherweise in einer Cloud liegen und keinen weiteren Zugriff bieten.
• Select it: Manchmal hat die Pipelines platform mehrere Maschinen konfiguriert und wenn man die CI configuration file ändern kann, kann man angeben, wo man den bösartigen Code ausführen möchte. In dieser Situation wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine reverse shell starten, um weitere Exploits zu versuchen.
• Compromise production: Wenn man innerhalb der pipeline ist und die finale Version von dort gebaut und deployed wird, könnte man den Code kompromittieren, der letztlich in Production läuft.

More relevant info

Tools & CIS Benchmark

• Chain-bench ist ein Open-Source-Tool zur Überprüfung deiner Software-Supply-Chain-Stack-Sicherheit anhand eines neuen CIS Software Supply Chain benchmark. Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken vom Code-Zeitpunkt bis zur Deploy-Zeit aufdecken.

Top 10 CI/CD Security Risk

Sieh dir diesen interessanten Artikel über die Top 10 CI/CD Risiken laut Cider an: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• Auf jeder Plattform, die du lokal ausführen kannst, findest du Anleitungen, wie du sie lokal startest, damit du sie nach Belieben konfigurieren und testen kannst.
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkov ist ein statisches Code-Analyse-Tool für infrastructure-as-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