Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) pipelines spielen eine entscheidende Rolle bei der Erleichterung einer rationalisierten Softwareentwicklung. Doch da diese pipelineDa Sicherheitslücken immer wichtiger werden, ist der Schutz vor Schwachstellen immer wichtiger. Diese eingehende Untersuchung konzentriert sich auf ein prominentes Risiko, das in den OWASP Top-10 identifiziert wurde. CI/CD Sicherheitsrisiken: Vergiftet Pipeline Ausführung (PSA).
Was ist vergiftet Pipeline Ausführung (PSA)
Laut OWASP Top-10 CI/CD Sicherheitsrisiken, „Vergiftet Pipeline Ausführung (PSA) Risiko bezieht sich auf die Fähigkeit eines Angreifers mit Zugriff auf Quellcodeverwaltungssysteme – und ohne Zugriff auf die Build-Umgebung – den Build-Prozess zu manipulieren, indem man bösartigen Code/Befehle in den Build einschleust pipeline Konfiguration, im Wesentlichen 'Vergiftung' der pipeline und Ausführen von Schadcode als Teil des Build-Prozesses“
In wenigen Worten: Poisoned Pipeline Ausführung (PPE) wird erzeugt, wenn Der Angreifer kann die pipeline Logik.
Es gibt zwei Varianten:
- Direkte PSA (D-PSA): In einem D-PPE-Szenario Der Angreifer ändert die CI-Konfigurationsdatei in einem Repository, auf das sie Zugriff haben, entweder indem sie die Änderung direkt in einen ungeschützten Remote-Zweig im Repository pushen oder indem sie einen PR mit der Änderung von einem Zweig oder Fork übermitteln. Da die CI pipeline Die Ausführung wird durch die Befehle in der geänderten CI-Konfigurationsdatei definiert. Die bösartigen Befehle des Angreifers werden letztendlich im Build-Knoten ausgeführt, sobald der Build pipeline ausgelöst wird.
- Indirekte PSA (I-PSA): In bestimmten Fällen steht einem Gegner mit Zugang zu einer SCM Repository (z. B. wenn die pipeline ist so konfiguriert, dass die CI-Konfigurationsdatei aus einem separaten, geschützten Zweig im selben Repository abgerufen wird). In einem solchen Szenario, anstatt die pipeline selbst injiziert ein Angreifer bösartigen Code in Dateien, auf die von der pipeline (Beispiel: Skripte, auf die innerhalb des pipeline Konfigurationsdatei)
In beiden Fällen, GitHub führt die geänderte pipeline ohne dass eine vorherige Überprüfung oder Genehmigung erforderlich ist.
Früherkennung von PSA
Wie können wir diese Art von Schwachstelle erkennen?
Sehen wir uns dieses Beispiel an pipeline :
name: PR CI
on:
pull_request:
branches: [ main ]
env:
MY_SECRET: ${{ secrets.MY_SECRET }}
jobs:
pr_build_test_and_merge:
runs-on: ubuntu-latest
steps:
# checkout PR code
- name: Checkout repository
uses: actions/checkout@v4
# Simulation of a compilation
- name: Building ...
run: |
echo $MY_SECRET
mkdir ./bin
touch ./bin/mybin.exe
# Simulation of running tests
- name: Running tests ...
id : run_tests
run: |
echo Running tests..
chmod +x runtests.sh
./runtests.sh "${{ github.event.pull_request.user.login }}" "${{ github.workflow }}"
echo Tests executed.
Und der Inhalt eines Dummy-Shell-Skripts (runtests.sh):
#!/usr/bin/bash
echo "Executing Tests script [from user $1 at $2]" >> runtests.out
exit 0
Das pipeline ist ganz einfach: Ziel ist es, dem Gutachter einige vorläufige Hinweise für die Pull Request (PR) Annahmeprozess:
- Es wird ausgelöst am Pull_Anfrage (d. h. immer wenn ein PR erstellt wird)
- Es überprüft den PR-Code (also den beigesteuerten Code)
- Es wird den Build
- Es werden Tests des beigesteuerten Codes durchgeführt (z. B. durch Ausführen eines Shell-Skripts).
Die Schritte 3 (Build erstellen) und 4 (Test ausführen) schlagen fehl, wenn der Code nicht kompiliert wird oder die Tests nicht besteht. Diese Schritte sind also eine notwendige, aber nicht hinreichende Voraussetzung für die Annahme des PR. Bei erfolgreichem Abschluss überprüft der Repo-Administrator den bereitgestellten Code und akzeptiert/lehnt den PR auf dieser Grundlage ab/kommentiert ihn.
Xygeni-Scanner
Xygeni stellt eine CLI (die „Xygeni-Scanner”), die in ein pipeline oder in einer Befehlszeile ausführen. Der Xygeni Scanner verarbeitet die pipelines zum Suchen nach Schwachstellen und, sofern ein GitHub PAT bereitgestellt wird, wird eine Verbindung zu GitHub hergestellt, um Schwachstellen auf Org-/Repo-Ebene zu erkennen.
Xygeni-Inventar
Wenn wir Xygeni Scanner auf diesem Repo ausführen, entdeckt es einen nützlichen Satz von Assets (die Xygeni-Inventar). Das Inventar wird mit vielen verschiedenen Arten von CI/CD Aktiva, Wie:
- Das SCM System wo das Repo gespeichert ist
- Das SCM Plugins installiert/verwendet
- Das Code-Repository selbst
- Das SCM Organisation wohin das Repo gehört
- Das CI/CD Pipelines und Jobs
- Das CI/CD System Laufen die pipelines
- IaC Ressourcen im Repo definiert
- Extern Abhängigkeiten
- etc..
In unserem Beispiel können wir das Inventar nach einem bestimmten Asset-Typ filtern (SCM- und CICD-bezogene Vermögenswerte), sodass wir Folgendes sehen können:
- SCM System ist GitHub Cloud
- Repo wird in der GitHub-Cloud gespeichert und gehört zu einer bestimmten GitHub-Organisation
- Es gibt zwei pipelinewird von GitHub bereitgestellt (CI/CD System)
- Jede pipeline enthält einen bestimmten Schritt
Durch Auswahl der oben pipeline Wir können einige Schwachstellen erkennen:
- At pipeline Ebene ist es anfällig für beide Direkt und Indirekte PSA.
Wir können die Details der Vergifteten sehen Pipeline Ausführungsschwachstellen
Xygeni erkennt, dass es anfällig für D-PPE weil es ausgelöst wird durch ein Pull Request Ereignis und es gibt keine zusätzlichen Sicherheitskontrollen, so dass jeder Repo-Benutzer die pipeline und diese Änderungen werden ohne Überprüfung oder Genehmigung ausgeführt.
In diesem Sinne erkennt Xygeni auch, dass es anfällig für I-PPE wegen des Aufrufs des Shell-Skripts aus dem pipeline: Jeder Repo-Benutzer kann das Shell-Skript ändern und diese Änderungen werden ohne Überprüfung oder Genehmigung ausgeführt.
Willst du mehr wissen?
Ausnutzung von PSA
Um die PSA auszunutzen, betrachten wir ein Szenario, in dem es Zwei Arten von Repo-Benutzern:
- An interner Benutzer (ein interner Entwickler, der an diesem Repo arbeitet), mit Schreibberechtigung für das Repo
- An externer Benutzer (ein ausgelagerter Entwickler, der an diesem Repo arbeitet, aber Leseberechtigung für das Repo hat), d. h. er darf das Repo nicht verzweigen und ist gezwungen, an einem Fork zu arbeiten.
Stellen wir uns vor, dass beide böswillige Angreifer sind (oder von einem böswilligen Akteur imitiert werden). Das Repo enthält ein Geheimnis und beide wollen das Repo-Geheimnis stehlen und senden Sie es an einen von Hackern kontrollierten Server. Dazu nutzen sie die Poisoned Pipeline Ausführungsschwachstellen des pipeline.
In beiden Fällen (externer und interner Benutzer) öffnen sie ein Pull Request mit den gleichen Modifikationen:
- Das pipeline und das Shell-Skript werden geändert zu Lies das Geheimnis aus der Umwelt und Senden Sie es an einen von Hackern kontrollierten Server
Mögliche Änderungen sind:
Beide Benutzer erstellen eine Pull Request mit den Modifikationen. Nach der Erstellung des PR GitHub führt beide Änderungen aus (ohne dass eine vorherige Überprüfung oder Genehmigung erforderlich ist), was zu folgendem Ergebnis führt:
Dasselbe gilt für Schreib- und Lesebenutzer. in beiden Fällen werden D-PPE und I-PPE ausgeführt, mit dem Unterschied, dass der Lesebenutzer kann nicht auf die Geheimnisse zugreifen. (!!!!)
Der Grund hierfür ist, Im Falle eines PR, der aus einem Fork stammt, erlaubt GitHub keinen Zugriff auf die Repo-Geheimnisse. Obwohl der Lesebenutzer die Geheimnisse nicht lesen kann, kann er/sie dennoch jedes andere Programm ausführen. Ein typisches Angriffsbeispiel ist das Erstellen von PRs, die einen Krypto-Miner herunterladen, sodass der GitHub-Runner den Krypto-Miner ausführt, wenn er einen vergifteten pipeline.
Dies ist natürlich keine sichere Umgebung!! Was kann der Repo-Administrator tun, um dies zu vermeiden?
Nach einigem Googeln entscheidet sich der Repo-Administrator, die pipeline ausgelöst werden durch Pull_Anfrage_Ziel Ereignis. Warum? Weil pipelines, die auf pull_request_target ausgelöst werden, erlauben keine Ausführung pipeline Änderungen, d. h. trotz aller Benutzeränderungen bleibt das „Original“ pipeline wird durchgeführt.
Nach unserem Beispiel wird der Angriff derselbe sein wie zuvor. Was wird dann danach passieren? pipeline Änderung?
Wie erwartet, D-PPE wird nicht ausgeführt aber weil I-PPE immer noch da ist, der Lesebenutzer kann jetzt auf das Repo-Geheimnis zugreifen!!!
Was ist der Grund dafür, dass der Lesebenutzer nun Zugriff auf Geheimnisse hat? Obwohl der pipeline nicht geändert werden kann, ist es weiterhin möglich, das Shell-Skript zu ändern. Wenn eine pipeline wird bei pull_request_target ausgelöst und im privilegierten Modus ausgeführt so es wird auch das Shell-Skript sein, was dazu führt, dass das Shell-Skript Zugriff auf Repo-Geheimnisse hat!!
Vorsichtsmaßnahmen
GitHub bietet einige Maßnahmen zum Schutz vor bösartigen PRs.
Regeln zum Schutz von Zweigstellen
Mit GitHub können Sie Branch Protection-Regeln für ausgewählte Zweige definieren.
Für Ihre geschützten Zweigstellen können Sie eine Richtlinie festlegen, die benötigt ein pull request vor dem Zusammenschluss (sowie zusätzliche Bedingungen wie eine erforderliche Anzahl an Genehmigungen, Überprüfungen durch Codebesitzer usw.)
Einige Bedingungen, die besondere Beachtung verdienen, sind:
- "Erlauben Sie den angegebenen Akteuren, die erforderlichen pull requests".
- "Umgehen der oben genannten Einstellungen nicht zulassen"
Während die meisten dieser Bedingungen die Richtlinie strenger machen, stellen diese Bedingungen eine Lockerung der Richtlinie dar, was böswilligen Aktivitäten Tür und Tor öffnen könnte, beispielsweise wenn „privilegierte“ Akteure Anmeldeinformationen stehlen.
GITHUB_TOKEN-Berechtigungen einschränken (geringste Berechtigung)
Beschränken Sie die GitHub-Token-Berechtigungen nur auf die erforderlichen. Auf diese Weise können Angreifer, selbst wenn sie erfolgreich Ihre pipeline, werden sie nicht viel tun können.
Vermeiden Sie die Interpolation von Zeichenfolgen durch die Verwendung pipeline Umgebungsvariablen
Wenn Sie Eingabevariablen in Ihrem pipeline, beachten Sie, dass diese standardmäßig als „nicht vertrauenswürdige“ Daten betrachtet werden sollten (ihr Inhalt wird vom Endbenutzer kontrolliert). Siehe Nicht vertrauenswürdige Aktionen und Workflows absichern und Erfahren Sie mehr über Github Actions.
Sie sollten zum Einfügen von Eingabevariablen in Skripte immer Umgebungsvariablen verwenden und nicht die Zeichenfolgeninterpolation.
Workflow-Ausführungen und Genehmigungsanforderungen
Für Öffentlichkeit repos, GitHub ermöglicht die Angabe wie man mit „externen“ PRs arbeitet.
In den GitHub-Organisationseinstellungen („Org >> Einstellungen >> Aktionen >> Allgemein“) können Sie angeben, wie externe PRs verwaltet werden:
Standardmäßig verlangt GitHub für erstmalige Mitwirkende eine PR-Genehmigung, was böswillige Anfrageangriffe komplizierter macht. Trotzdem könnte der Angreifer das Vertrauen der Projektbetreuer gewinnen, indem er beispielsweise harmlose pull request vor dem eigentlichen Angriff.
In diesem Sinne ist die Die 3. Option (Genehmigung aller externen Mitarbeiter erforderlich) bietet ein höheres Maß an Kontrolle.
Für privat Repos, GitHub bietet auch hilfreiche Kontrolle sowohl auf Organisations- als auch auf Repo-Ebene.
"Ausführen von Workflows von Pull Requests” (standardmäßig nicht aktiviert) ermöglicht es Benutzern, Workflows von Fork-PRs aus auszuführen (mit einem GITHUB_TOKEN mit schreibgeschützten Berechtigungen und ohne Zugriff auf Geheimnisse). Durch Auswahl dieser Option zusammen mit der letzten (“Genehmigung für Fork-PR-Workflows erforderlich“) können Sie eine ähnliche Richtlinie für private Repos erreichen (wie oben gezeigt).
Wie wir im PPE-Exploit eines Lesebenutzers gesehen haben, Ermöglichen des Ausführens von Workflows vom Fork pull requests ist unsicher!!
Die verbleibenden Optionen („Senden Sie Schreibtoken vom Fork an Workflows pull requests" und "Senden Sie Geheimnisse und Variablen an Workflows von für pull requests") das Sicherheitsniveau verringern auf Fork-PRs angewendet.
Sie können diese Fork-Richtlinie entweder auf Organisationsebene oder auf Repository-Ebene definieren. Wenn die Richtlinie auf Organisationsebene deaktiviert ist, kann sie nicht auf Repository-Ebene aktiviert werden. Wenn die Richtlinie jedoch auf Organisationsebene aktiviert ist, kann sie auf Repository-Ebene deaktiviert werden.
Rekapitulieren
Wir hoffen, Sie haben erkannt, welche Auswirkungen es hat, pipeline anfällig für Vergiftung Pipeline Ausführung. Es ist zu einfach, commit eine verletzliche pipeline, und es ist schwierig, eine sichere zu schreiben.
Daher ist es äußerst wertvoll, den Xygeni Scanner zu verwenden, um sich solcher Schwachstellen bewusst zu sein.
Sie können eine Schwachstelle nicht beheben, wenn Sie sich ihrer Existenz nicht bewusst sind!!
Aber… Es bleibt noch eine Frage offen… Wie vermeidet man die I-PPE?
Dies wird das Thema unseres nächsten Beitrags sein 🙂 … Indirekt vergiftet Pipeline Ausführung (I-PPE) !!
