Abusing Github Actions
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)
Auf dieser Seite findest du:
Eine Zusammenfassung aller Auswirkungen, wenn es einem Angreifer gelingt, auf eine Github Action zuzugreifen
Verschiedene Möglichkeiten, um Zugriff auf eine Action zu erhalten:
Berechtigungen zum Erstellen der Action haben
Missbrauch von Pull-Request-bezogenen Triggern
Missbrauch von anderen externen Zugriffstechniken
Pivoting von einem bereits kompromittierten Repo
Schließlich ein Abschnitt über Post-Exploitation-Techniken, um eine Action von innen zu missbrauchen (um die genannten Auswirkungen zu verursachen)
Für eine Einführung über Github Actions, siehe die grundlegenden Informationen.
Wenn du beliebigen Code in GitHub Actions innerhalb eines Repositories ausführen kannst, könntest du in der Lage sein:
Geheime Daten zu stehlen, die in die Pipeline eingebunden sind, und die Befugnisse der Pipeline zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten.
Bereitstellungen und andere Artefakte zu kompromittieren.
Wenn die Pipeline Assets bereitstellt oder speichert, könntest du das Endprodukt ändern, was einen Supply-Chain-Angriff ermöglicht.
Code in benutzerdefinierten Workern auszuführen, um Rechenleistung zu missbrauchen und auf andere Systeme zu pivotieren.
Repository-Code zu überschreiben, abhängig von den Berechtigungen, die mit dem GITHUB_TOKEN
verbunden sind.
Dieses "Geheimnis" (stammend von ${{ secrets.GITHUB_TOKEN }}
und ${{ github.token }}
) wird gegeben, wenn der Administrator diese Option aktiviert:
Dieses Token ist dasselbe, das eine Github-Anwendung verwenden wird, sodass sie auf dieselben Endpunkte zugreifen kann: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps
Github sollte einen Flow veröffentlichen, der cross-repository Zugriff innerhalb von GitHub ermöglicht, sodass ein Repo auf andere interne Repos mit dem GITHUB_TOKEN
zugreifen kann.
Du kannst die möglichen Berechtigungen dieses Tokens hier einsehen: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
Beachte, dass das Token nach Abschluss des Jobs abläuft.
Diese Tokens sehen so aus: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7
Einige interessante Dinge, die du mit diesem Token tun kannst:
Beachten Sie, dass Sie in mehreren Fällen Github-Benutzertoken in den Umgebungsvariablen von Github Actions oder in den Geheimnissen finden können. Diese Token können Ihnen mehr Berechtigungen über das Repository und die Organisation geben.
Es ist möglich, die Berechtigungen eines Github Tokens in den Repositories anderer Benutzer durch Überprüfung der Protokolle der Aktionen zu überprüfen:
Dies wäre der einfachste Weg, Github-Aktionen zu kompromittieren, da dieser Fall voraussetzt, dass Sie ein neues Repo in der Organisation erstellen können oder Schreibrechte über ein Repository haben.
Wenn Sie sich in diesem Szenario befinden, können Sie einfach die Post Exploitation Techniken überprüfen.
Falls Mitglieder einer Organisation neue Repos erstellen können und Sie Github-Aktionen ausführen können, können Sie ein neues Repo erstellen und die auf Organisationsebene festgelegten Geheimnisse stehlen.
Wenn Sie einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github Action enthält, können Sie diese modifizieren, den Inhalt hochladen und dann diese Aktion aus dem neuen Branch ausführen. Auf diese Weise können Sie Geheimnisse auf Repository- und Organisationsebene exfiltrieren (aber Sie müssen wissen, wie sie genannt werden).
Sie können die modifizierte Aktion manuell ausführbar machen, wenn ein PR erstellt wird oder wenn einige Codes gepusht werden (je nachdem, wie auffällig Sie sein möchten):
Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine Github Action eines anderen Repositories auszuführen. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.
pull_request
Der Workflow-Trigger pull_request
wird den Workflow jedes Mal ausführen, wenn ein Pull-Request eingeht, mit einigen Ausnahmen: standardmäßig, wenn es das erste Mal ist, dass Sie mitarbeiten, muss ein Maintainer die Ausführung des Workflows genehmigen:
Da die Standardbeschränkung für Erstbeiträge gilt, könnten Sie einen gültigen Bug/Tippfehler beheben und dann andere PRs senden, um Ihre neuen pull_request
-Befugnisse auszunutzen.
Ich habe das getestet und es funktioniert nicht: Eine andere Möglichkeit wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat und dessen Konto gelöscht wurde.
Darüber hinaus verhindert standardmäßig Schreibberechtigungen und Zugriff auf Geheimnisse für das Ziel-Repository, wie in den Docs erwähnt:
Mit Ausnahme von
GITHUB_TOKEN
werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow aus einem geforkten Repository ausgelöst wird. DasGITHUB_TOKEN
hat nur Lesezugriff in Pull-Requests von geforkten Repositories.
Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Aktionen anzuhängen. Er wird jedoch nicht in der Lage sein, Geheimnisse zu stehlen oder das Repo zu überschreiben, aufgrund der genannten Einschränkungen.
Ja, wenn der Angreifer im PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem ursprünglichen Repo!
Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsweise bösartige Artefakte hochladen, selbst wenn es keine Geheimnisse oder Schreibberechtigungen für das GITHUB_TOKEN
gibt.
pull_request_target
Der Workflow-Trigger pull_request_target
hat Schreibberechtigungen für das Ziel-Repository und Zugriff auf Geheimnisse (und fragt nicht nach Erlaubnis).
Beachten Sie, dass der Workflow-Trigger pull_request_target
im Basis-Kontext und nicht im durch den PR gegebenen Kontext ausgeführt wird (um nicht untrusted Code auszuführen). Für weitere Informationen zu pull_request_target
überprüfen Sie die Docs.
Darüber hinaus finden Sie weitere Informationen zu dieser spezifischen gefährlichen Verwendung in diesem Github-Blogbeitrag.
Es könnte so aussehen, als wäre der ausgeführte Workflow der, der in der Basis definiert ist und nicht im PR, was es sicher macht, pull_request_target
zu verwenden, aber es gibt einige Fälle, in denen dies nicht der Fall ist.
Und dieser hat Zugriff auf Geheimnisse.
workflow_run
Der workflow_run Trigger ermöglicht es, einen Workflow von einem anderen auszuführen, wenn er completed
, requested
oder in_progress
ist.
In diesem Beispiel ist ein Workflow so konfiguriert, dass er nach Abschluss des separaten "Run Tests"-Workflows ausgeführt wird:
Moreover, according to the docs: Der durch das workflow_run
-Ereignis gestartete Workflow kann Geheimnisse abrufen und Token schreiben, auch wenn der vorherige Workflow nicht.
Diese Art von Workflow könnte angegriffen werden, wenn sie von einem Workflow abhängt, der von einem externen Benutzer über pull_request
oder pull_request_target
ausgelöst werden kann. Einige anfällige Beispiele können in diesem Bloggefunden werden. Der erste besteht darin, dass der durch workflow_run
ausgelöste Workflow den Code des Angreifers herunterlädt: ${{ github.event.pull_request.head.sha }}
Der zweite besteht darin, ein Artifact vom nicht vertrauenswürdigen Code an den workflow_run
-Workflow zu übergeben und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die es anfällig für RCE macht.
workflow_call
TODO
TODO: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der aus dem Ursprung oder vom geforkten PR stammt
Wir haben alle Möglichkeiten erwähnt, wie ein externer Angreifer einen GitHub-Workflow ausführen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten:
Im Fall von pull_request
wird der Workflow im Kontext des PR ausgeführt (er wird also den bösartigen PR-Code ausführen), aber jemand muss ihn zuerst autorisieren, und er wird mit einigen Einschränkungen ausgeführt.
Im Fall eines Workflows, der pull_request_target
oder workflow_run
verwendet und von einem Workflow abhängt, der von pull_request_target
oder pull_request
ausgelöst werden kann, wird der Code aus dem ursprünglichen Repo ausgeführt, sodass der Angreifer den ausgeführten Code nicht kontrollieren kann.
Wenn jedoch die Aktion einen expliziten PR-Checkout hat, der den Code vom PR (und nicht von der Basis) holt, wird der vom Angreifer kontrollierte Code verwendet. Zum Beispiel (siehe Zeile 12, wo der PR-Code heruntergeladen wird):
Der potenziell nicht vertrauenswürdige Code wird während npm install
oder npm build
ausgeführt, da die Build-Skripte und die referenzierten Pakete vom Autor des PR kontrolliert werden.
Ein GitHub-Dork, um nach anfälligen Aktionen zu suchen, ist: event.pull_request pull_request_target extension:yml
, jedoch gibt es verschiedene Möglichkeiten, die Jobs sicher auszuführen, selbst wenn die Aktion unsicher konfiguriert ist (zum Beispiel durch die Verwendung von Bedingungen darüber, wer der Akteur ist, der den PR generiert).
Beachten Sie, dass es bestimmte GitHub-Kontexte gibt, deren Werte vom Benutzer erstellt werden, der den PR erstellt. Wenn die GitHub-Aktion diese Daten verwendet, um irgendetwas auszuführen, könnte dies zu willkürlicher Codeausführung führen:
Aus den Dokumenten: Sie können eine Umgebungsvariable für alle nachfolgenden Schritte in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die GITHUB_ENV
-Umgebungsdatei schreiben.
Wenn ein Angreifer irgend einen Wert in diese env-Variable einschleusen könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten wie LD_PRELOAD oder NODE_OPTIONS Code ausführen könnten.
Zum Beispiel (dies und dies), stellen Sie sich einen Workflow vor, der einem hochgeladenen Artifact vertraut, um seinen Inhalt in der GITHUB_ENV
-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren:
Wie in diesem Blogbeitrag erwähnt, ermöglicht diese GitHub-Aktion den Zugriff auf Artefakte aus verschiedenen Workflows und sogar Repositories.
Das Problem ist, dass, wenn der path
-Parameter nicht gesetzt ist, das Artifact im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden könnten. Daher könnte ein Angreifer dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen.
Beispiel eines anfälligen Workflows:
Dies könnte mit diesem Workflow angegriffen werden:
Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository weniger als 100 Sterne vor der Namensänderung hatte, erlaubt Github dem neu registrierten Benutzer mit demselben Namen, ein Repository mit demselben Namen wie das gelöschte zu erstellen.
Wenn eine Aktion ein Repo von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellen und die Aktion kompromittieren könnte.
Wenn andere Repositories Abhängigkeiten von diesen Benutzer-Repos verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine umfassendere Erklärung: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/
In diesem Abschnitt werden wir über Techniken sprechen, die es ermöglichen, von einem Repo zu einem anderen zu pivotieren, vorausgesetzt, wir haben eine Art von Zugriff auf das erste (siehe den vorherigen Abschnitt).
Ein Cache wird zwischen Workflow-Durchläufen im selben Branch aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein Paket kompromittiert, das dann im Cache gespeichert und von einem privilegierteren Workflow heruntergeladen und ausgeführt wird, er auch diesen Workflow kompromittieren kann.
Workflows könnten Artefakte von anderen Workflows und sogar Repos verwenden. Wenn es einem Angreifer gelingt, die Github Action zu kompromittieren, die ein Artefakt hochlädt, das später von einem anderen Workflow verwendet wird, könnte er die anderen Workflows kompromittieren:
Überprüfen Sie die folgenden Seiten:
Wenn Sie Inhalte in ein Skript injizieren, ist es interessant zu wissen, wie Sie auf Geheimnisse zugreifen können:
Wenn das Geheimnis oder Token auf eine Umgebungsvariable gesetzt ist, kann es direkt über die Umgebung mit printenv
zugegriffen werden.
Wenn das Geheimnis direkt in einem Ausdruck verwendet wird, wird das generierte Shell-Skript auf der Festplatte gespeichert und ist zugänglich.
cat /home/runner/work/_temp/*
Für eine benutzerdefinierte Aktion kann das Risiko variieren, je nachdem, wie ein Programm das Geheimnis verwendet, das es aus dem Argument erhalten hat:
Der Weg, um herauszufinden, welche Github Actions in nicht-Github-Infrastrukturen ausgeführt werden, besteht darin, nach runs-on: self-hosted
in der Github Action-Konfigurations-YAML zu suchen.
Selbst gehostete Runner könnten Zugang zu extra sensiblen Informationen, zu anderen Netzwerksystemen (anfällige Endpunkte im Netzwerk? Metadatenservice?) haben oder, selbst wenn sie isoliert und zerstört sind, könnten mehr als eine Aktion gleichzeitig ausgeführt werden und die bösartige könnte die Geheimnisse der anderen stehlen.
Bei selbst gehosteten Runnern ist es auch möglich, die Geheimnisse aus dem _Runner.Listener_** Prozess** zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher dumpet:
Überprüfen Sie diesen Beitrag für weitere Informationen.
Es ist möglich, Github-Aktionen zu erstellen, die ein Docker-Image innerhalb von Github erstellen und speichern. Ein Beispiel finden Sie im folgenden ausklappbaren Bereich:
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)