Pentesting CI/CD Methodik

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

VCS

VCS steht für Versionskontrollsystem, dieses System erlaubt Entwicklern, ihren Quellcode zu verwalten. Das gebräuchlichste ist git und in Unternehmen findet man es meist auf einer der folgenden Plattformen:

  • 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, einschließlich Build, Tests und Deployment von Anwendungen. Diese automatisierten Workflows werden durch bestimmte Aktionen ausgelöst, wie Code-Pushes, Pull Requests oder geplante Tasks. Sie helfen, 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 Zugangsdaten, um Code zu deployen oder auf sensible Informationen zuzugreifen.

VCS Pentesting Methodik

Note

Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.

Plattformen, die den Quellcode eines Projekts enthalten, bewahren sensible Informationen, weshalb sehr sorgfältig mit den Berechtigungen innerhalb dieser Plattform umgegangen werden muss. Hier einige häufige Probleme auf VCS-Plattformen, die ein Angreifer ausnutzen könnte:

  • Leaks: Wenn dein Code leaks in den Commits enthält und ein Angreifer auf das Repo zugreifen kann (weil es public ist oder weil er Zugriff hat), könnte er die leaks entdecken.
  • Access: Wenn ein Angreifer Zugang zu einem Account auf der VCS-Plattform erlangen kann, könnte er mehr Sichtbarkeit und Berechtigungen gewinnen.
  • Register: Manche Plattformen erlauben externen Nutzern einfach, ein Konto zu erstellen.
  • SSO: Einige Plattformen erlauben keine Registrierung, aber jeder mit einem gültigen SSO kann sich anmelden (ein Angreifer könnte z. B. sein github-Konto benutzen).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… es gibt verschiedene Tokenarten, die ein Nutzer stehlen könnte, um in gewisser Weise auf ein Repo zuzugreifen.
  • Webhooks: VCS-Plattformen 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 ein Angreifer den Webhook der Drittanbieterplattform missbrauchen.
  • Wenn das Secret in der URL steckt, gilt dasselbe und der Angreifer hat ebenfalls das Secret.
  • Code compromise: Wenn ein böswilliger Akteur Schreibrechte über ein Repo hat, könnte er versuchen, bösartigen Code zu injizieren. Um erfolgreich zu sein, muss er möglicherweise Branch Protections umgehen. Diese Aktionen können mit verschiedenen Zielen durchgeführt werden:
    • Kompromittierung des main-Branch, um die Produktion zu kompromittieren.
    • Kompromittierung des main- (oder anderer) Branches, um Entwickler-Rechner zu kompromittieren (da diese oft Tests, terraform oder andere Dinge lokal aus dem Repo ausführen).
  • Compromise the pipeline (siehe nächsten Abschnitt)

Pipelines Pentesting Methodik

Die gebräuchlichste Methode, eine Pipeline zu definieren, ist die Verwendung einer CI-Konfigurationsdatei im Repository, das die Pipeline baut. Diese Datei beschreibt die Reihenfolge der ausgeführten Jobs, Bedingungen, die den Ablauf beeinflussen, und Einstellungen für die 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 unter .github/workflows. Wenn sie ausgelöst werden, zieht der Pipeline-Job den Code aus der ausgewählten Quelle (z. B. Commit / Branch) und führt die in der CI-Konfigurationsdatei angegebenen Befehle gegen diesen Code aus.

Daher ist das ultimative Ziel des Angreifers, auf irgendeine Weise diese Konfigurationsdateien zu kompromittieren oder die Befehle, die sie ausführen.

Tip

Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., “..”) to ingest host files during build and exfiltrate secrets. See:

{{#ref}} docker-build-context-abuse.md {{#endref}}

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 Rechten können CI-Konfigurationsdateien oder andere Dateien, die vom Pipeline-Job verwendet werden, so ändern, dass sie bösartige Befehle enthalten. 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:

  • Schreibzugriff auf die VCS-Plattform haben, da Pipelines in der Regel ausgelöst werden, wenn ein Push oder ein Pull Request durchgeführt wird. (Siehe die VCS pentesting methodology für eine Zusammenfassung der Wege, Zugriff zu bekommen).
  • Beachte, dass manchmal ein externer PR als “Schreibzugriff” gilt.
  • 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 Branch Protections umgehen.

Es gibt 3 PPE-Varianten:

  • D-PPE: Ein Direct PPE-Angriff findet statt, wenn der Akteur die CI-Konfigurationsdatei direkt verändert, die ausgeführt werden soll.
  • I-DDE: Ein Indirect PPE-Angriff tritt auf, wenn der Akteur eine Datei verändert, auf die die CI-Konfigurationsdatei angewiesen ist (z. B. ein Makefile oder eine Terraform-Konfiguration).
  • Public PPE or 3PE: In einigen Fällen können Pipelines von Nutzern ausgelöst werden, die keinen Schreibzugriff auf das Repo haben (und möglicherweise nicht einmal Teil der Organisation sind), weil sie einen PR senden können.
  • 3PE Command Injection: Üblicherweise setzen CI/CD-Pipelines Umgebungsvariablen mit Informationen über den PR. Wenn dieser Wert vom Angreifer kontrollierbar ist (z. B. der Titel des PR) und an einer gefährlichen Stelle verwendet wird (z. B. beim Ausführen von sh-Befehlen), könnte ein Angreifer Befehle dort injizieren.

Exploitation Benefits

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

  • Secrets: Wie zuvor erwähnt, benötigen Pipelines Privilegien für ihre Jobs (Code abrufen, bauen, deployen …) und diese Privilegien werden üblicherweise in secrets hinterlegt. Diese secrets sind oft über env-Variablen oder Dateien im System zugänglich. Daher wird ein Angreifer immer versuchen, möglichst viele secrets zu exfiltrieren.
  • Je nach Pipeline-Plattform muss der Angreifer die secrets in der Konfiguration angeben. Das bedeutet, wenn der Angreifer die CI-Konfiguration nicht modifizieren kann (z. B. I-PPE), könnte er nur die secrets exfiltrieren, die der Pipeline bereits zur Verfügung stehen.
  • Computation: Der Code wird irgendwo ausgeführt; je nachdem, wo, kann ein Angreifer weiter pivotieren.
  • On-Premises: Wenn die Pipelines On-Premises laufen, könnte ein Angreifer in ein internes Netzwerk gelangen und Zugriff auf weitere Ressourcen erhalten.
  • Cloud: Der Angreifer könnte andere Maschinen in der Cloud erreichen, aber auch IAM-Rollen/Service-Account-Token exfiltrieren, um weiteren Zugang in der Cloud zu erhalten.
  • Plattformmaschinen: Manchmal werden Jobs innerhalb der Pipeline-Plattform-Maschinen ausgeführt, die in der Regel in einer Cloud liegen und keinen weiteren Zugriff bieten.
  • Select it: Manchmal hat die Pipeline-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 diesem Fall wird ein Angreifer wahrscheinlich auf jeder möglichen Maschine eine Reverse-Shell starten, um weitere Exploits zu versuchen.
  • Compromise production: Wenn du dich in der Pipeline befindest und die finale Version von dort gebaut und deployed wird, könntest du den Code kompromittieren, der später in Produktion läuft.

Mehr relevante Informationen

Tools & CIS Benchmark

  • Chain-bench ist ein Open-Source-Tool zur Überprüfung deiner Software-Lieferkette auf Sicherheitskonformität basierend auf einem neuen CIS Software Supply Chain benchmark. Das Audit konzentriert sich auf den gesamten SDLC-Prozess und kann Risiken vom Code bis zum Deployment 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

Automatic Tools

  • Checkov: Checkov ist ein Static-Code-Analyse-Tool für Infrastructure-as-Code.

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks