diff --git a/src/images/CH_logo_ads.png b/src/images/CH_logo_ads.png new file mode 100644 index 000000000..b407c8929 Binary files /dev/null and b/src/images/CH_logo_ads.png differ 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 b46f809fc..5ce57b003 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 @@ -2,13 +2,23 @@ {{#include ../../../banners/hacktricks-training.md}} +## Werkzeuge + +Die folgenden Werkzeuge sind nützlich, um Github Action-Workflows zu finden und sogar verwundbare zu identifizieren: + +- [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) - Überprüfen Sie auch die Checkliste unter [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) + ## Grundinformationen Auf dieser Seite finden Sie: - Eine **Zusammenfassung aller Auswirkungen**, wenn ein Angreifer Zugriff auf eine Github Action erhält - Verschiedene Möglichkeiten, um **Zugriff auf eine Action zu erhalten**: -- Berechtigungen zum Erstellen der Action haben +- Berechtigungen, um die Action zu erstellen - Missbrauch von **Pull-Request**-bezogenen Triggern - Missbrauch von **anderen externen Zugriffstechniken** - **Pivoting** von einem bereits kompromittierten Repo @@ -16,28 +26,28 @@ Auf dieser Seite finden Sie: ## Zusammenfassung der Auswirkungen -Für eine Einführung zu [**Github Actions überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions). +Für eine Einführung zu [**Github Actions, überprüfen Sie die grundlegenden Informationen**](../basic-github-information.md#github-actions). -Wenn Sie **beliebigen Code in GitHub Actions** innerhalb eines **Repositories** ausführen können, könnten Sie in der Lage sein: +Wenn Sie **beliebigen Code in GitHub Actions** innerhalb eines **Repositories** ausführen können, könnten Sie in der Lage sein zu: -- **Geheime Daten** zu stehlen, die in die Pipeline eingebunden sind, und die **Berechtigungen der Pipeline** zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten. +- **Geheimnisse** zu stehlen, die in die Pipeline eingebunden sind, und die **Berechtigungen der Pipeline** zu missbrauchen, um unbefugten Zugriff auf externe Plattformen wie AWS und GCP zu erhalten. - **Deployments** und andere **Artefakte** zu kompromittieren. - Wenn die Pipeline Assets bereitstellt oder speichert, könnten Sie das Endprodukt ändern, was einen Supply-Chain-Angriff ermöglicht. -- **Code in benutzerdefinierten Workern ausführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren. -- **Repository-Code überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind. +- **Code in benutzerdefinierten Workern auszuführen**, um Rechenleistung zu missbrauchen und zu anderen Systemen zu pivotieren. +- **Repository-Code zu überschreiben**, abhängig von den Berechtigungen, die mit dem `GITHUB_TOKEN` verbunden sind. ## GITHUB_TOKEN -Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird vergeben, wenn der Administrator diese Option aktiviert: +Dieses "**Geheimnis**" (stammend von `${{ secrets.GITHUB_TOKEN }}` und `${{ github.token }}`) wird gegeben, wenn der Administrator diese Option aktiviert:
Dieses Token ist dasselbe, das eine **Github-Anwendung verwenden wird**, sodass es auf dieselben Endpunkte zugreifen kann: [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 **den Zugriff über Repositories hinweg** innerhalb von GitHub ermöglicht, 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 auf andere interne Repos mit dem `GITHUB_TOKEN` zugreifen kann. -Sie können die möglichen **Berechtigungen** dieses Tokens hier einsehen: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) +Sie können die möglichen **Berechtigungen** dieses Tokens 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) einsehen. Beachten Sie, dass das Token **nach Abschluss des Jobs abläuft**.\ Diese Tokens sehen so aus: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` @@ -56,7 +66,7 @@ https://api.github.com/repos///pulls//merge \ -d "{\"commit_title\":\"commit_title\"}" ``` {{#endtab }} -{{#tab name="PR genehmigen" }} +{{#tab name="Approve PR" }} ```bash # Approve a PR curl -X POST \ @@ -67,7 +77,7 @@ https://api.github.com/repos///pulls//reviews \ -d '{"event":"APPROVE"}' ``` {{#endtab }} -{{#tab name="Create PR" }} +{{#tab name="PR erstellen" }} ```bash # Create a PR curl -X POST \ @@ -81,11 +91,11 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungsvariablen von Github Actions oder in den Secrets** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation geben. +> Beachten Sie, dass Sie in mehreren Fällen **Github-Benutzertokens in den Umgebungen von Github Actions oder in den Geheimnissen** finden können. Diese Tokens können Ihnen mehr Berechtigungen über das Repository und die Organisation geben.
-Liste der Secrets im Github Action-Ausgabe +Liste der Geheimnisse im Github Action-Ausgang ```yaml name: list_env on: @@ -145,13 +155,13 @@ Es ist möglich, die Berechtigungen, die einem Github-Token in den Repositories > > Wenn Sie sich in diesem Szenario befinden, können Sie einfach die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) überprüfen. -### Ausführung aus der Repo-Erstellung +### Ausführung bei Repo-Erstellung Falls Mitglieder einer Organisation **neue Repos erstellen** können und Sie Github-Aktionen ausführen können, können Sie **ein neues Repo erstellen und die auf Organisationsebene festgelegten Geheimnisse stehlen**. -### Ausführung aus einem neuen Branch +### Ausführung von einem neuen Branch -Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion aus dem neuen Branch ausführen**. Auf diese Weise können Sie **Geheimnisse auf Repository- und Organisationsebene exfiltrieren** (aber Sie müssen wissen, wie sie genannt werden). +Wenn Sie **einen neuen Branch in einem Repository erstellen können, das bereits eine konfigurierte Github-Aktion enthält**, können Sie diese **modifizieren**, den Inhalt **hochladen** und dann **diese Aktion vom neuen Branch ausführen**. Auf diese Weise können Sie **Geheimnisse auf Repository- und Organisationsebene exfiltrieren** (aber Sie müssen wissen, wie sie genannt werden). Sie können die modifizierte Aktion **manuell** ausführbar machen, wenn ein **PR erstellt wird** oder wenn **einige Codes gepusht werden** (je nachdem, wie auffällig Sie sein möchten): ```yaml @@ -170,27 +180,27 @@ branches: ## Forked Execution > [!NOTE] -> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** auszuführen. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren. +> Es gibt verschiedene Trigger, die es einem Angreifer ermöglichen könnten, eine **Github Action eines anderen Repositories** **auszuführen**. Wenn diese auslösbaren Aktionen schlecht konfiguriert sind, könnte ein Angreifer in der Lage sein, sie zu kompromittieren. ### `pull_request` -Der Workflow-Trigger **`pull_request`** wird jedes Mal den Workflow ausführen, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** den **Lauf** des Workflows **genehmigen**: +Der Workflow-Trigger **`pull_request`** wird den Workflow jedes Mal ausführen, wenn ein Pull-Request empfangen wird, mit einigen Ausnahmen: standardmäßig, wenn es das **erste Mal** ist, dass Sie **mitarbeiten**, muss ein **Maintainer** den **Lauf** des Workflows **genehmigen**:
> [!NOTE] -> Da die **Standardbeschränkung** für **Erstbeitragsleistende** gilt, könnten Sie **einen gültigen Bug/Tippfehler beheben** und dann **andere PRs senden, um Ihre neuen `pull_request`-Befugnisse auszunutzen**. +> Da die **Standardbeschränkung** für **Erstbeiträge** gilt, könnten Sie **einen gültigen Bug/Tippfehler beheben** und dann **andere PRs senden, um Ihre neuen `pull_request`-Befugnisse auszunutzen**. > > **Ich habe das getestet und es funktioniert nicht**: ~~Eine andere Möglichkeit wäre, ein Konto mit dem Namen von jemandem zu erstellen, der zum Projekt beigetragen hat und dessen Konto gelöscht wurde.~~ -Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** 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: +Darüber hinaus **verhindert standardmäßig Schreibberechtigungen** und **Zugriff auf Geheimnisse** 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: > Mit Ausnahme von `GITHUB_TOKEN` werden **Geheimnisse nicht an den Runner übergeben**, wenn ein Workflow von einem **forked** Repository ausgelöst wird. Das **`GITHUB_TOKEN` hat nur Lesezugriff** in Pull-Requests **von geforkten Repositories**. Ein Angreifer könnte die Definition der Github Action ändern, um beliebige Dinge auszuführen und beliebige Aktionen anzuhängen. Er wird jedoch nicht in der Lage sein, Geheimnisse zu stehlen oder das Repo zu überschreiben, aufgrund der genannten Einschränkungen. > [!CAUTION] -> **Ja, wenn der Angreifer im PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem ursprünglichen Repo!** +> **Ja, wenn der Angreifer im PR die Github Action ändert, die ausgelöst wird, wird seine Github Action verwendet und nicht die aus dem Ursprungsrepo!** Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsweise **bösartige Artefakte hochladen**, selbst wenn es keine Geheimnisse oder Schreibberechtigungen für das `GITHUB_TOKEN` gibt. @@ -198,7 +208,7 @@ Da der Angreifer auch den ausgeführten Code kontrolliert, könnte er beispielsw Der Workflow-Trigger **`pull_request_target`** hat **Schreibberechtigungen** für das Ziel-Repository und **Zugriff auf Geheimnisse** (und fragt nicht nach Erlaubnis). -Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext ausgeführt wird (um **nicht untrusted code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ +Beachten Sie, dass der Workflow-Trigger **`pull_request_target`** **im Basis-Kontext** und nicht im durch den PR gegebenen Kontext ausgeführt wird (um **nicht vertrauenswürdigen Code auszuführen**). Für weitere Informationen zu `pull_request_target` [**überprüfen Sie die Docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ Darüber hinaus finden Sie weitere Informationen zu dieser spezifischen gefährlichen Verwendung in diesem [**Github-Blogbeitrag**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). Es könnte so aussehen, als wäre der **ausgeführte Workflow** der, der im **Basis** definiert ist und **nicht im PR**, was es **sicher** macht, **`pull_request_target`** zu verwenden, aber es gibt **einige Fälle, in denen dies nicht der Fall ist**. @@ -217,29 +227,29 @@ workflows: [Run Tests] types: - completed ``` -Außerdem, laut den Dokumenten: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **Geheimnisse und Token schreiben, selbst wenn der vorherige Workflow nicht**. +Außerdem, laut den Dokumenten: Der durch das `workflow_run`-Ereignis gestartete Workflow kann **Geheimnisse abrufen und Token schreiben, auch wenn der vorherige Workflow dies nicht konnte**. -Dieser Art von Workflow könnte angegriffen werden, wenn er **von einem Workflow abhängt**, der von einem externen Benutzer über **`pull_request`** oder **`pull_request_target`** **ausgelöst** werden kann. Einige anfällige Beispiele können [**in diesem Blog**](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** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`** Workflow zu übergeben und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die **anfällig für RCE** ist. +Diese Art von Workflow könnte angegriffen werden, wenn sie **von** einem **Workflow** abhängt, der von einem externen Benutzer über **`pull_request`** oder **`pull_request_target`** **ausgelöst** werden kann. Einige anfällige Beispiele können [**in diesem 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** vom **nicht vertrauenswürdigen** Code an den **`workflow_run`**-Workflow zu **übergeben** und den Inhalt dieses Artifacts auf eine Weise zu verwenden, die **anfällig für RCE** ist. ### `workflow_call` TODO -TODO: Überprüfen, ob der verwendete/heruntergeladene Code, wenn er von einem pull_request ausgeführt wird, der aus dem Ursprung oder vom geforkten PR stammt. +TODO: Überprüfen, ob der verwendete/heruntergeladene Code bei der Ausführung von einem pull_request der aus dem Ursprung oder vom geforkten PR stammt ## Missbrauch von geforkter Ausführung -Wir haben alle Möglichkeiten erwähnt, wie ein externer Angreifer einen GitHub-Workflow ausführen könnte. Schauen wir uns nun an, wie diese Ausführungen, wenn sie schlecht konfiguriert sind, missbraucht werden könnten: +Wir haben alle Möglichkeiten 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: -### Nicht vertrauenswürdige Checkout-Ausführung +### Unsichere Checkout-Ausführung Im Fall von **`pull_request`** wird der Workflow im **Kontext des PR** ausgeführt (er wird also den **bösartigen PR-Code** ausführen), aber jemand muss ihn **zuerst autorisieren**, und er wird mit einigen [Einschränkungen](#pull_request) ausgeführt. -Im Fall eines Workflows, der **`pull_request_target` oder `workflow_run`** verwendet und von einem Workflow abhängt, der von **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem ursprünglichen Repo ausgeführt, sodass der **Angreifer den ausgeführten Code nicht kontrollieren kann**. +Im Fall eines Workflows, der **`pull_request_target` oder `workflow_run`** verwendet und von einem Workflow abhängt, der von **`pull_request_target` oder `pull_request`** ausgelöst werden kann, wird der Code aus dem ursprünglichen Repository ausgeführt, sodass der **Angreifer den ausgeführten Code nicht kontrollieren kann**. > [!CAUTION] -> Wenn die **Aktion** jedoch einen **expliziten PR-Checkout** hat, der **den Code vom PR** (und nicht von der Basis) **holt**, wird der vom Angreifer kontrollierte Code verwendet. Zum Beispiel (siehe Zeile 12, wo der PR-Code heruntergeladen wird): +> Wenn jedoch die **Aktion** einen **expliziten PR-Checkout** hat, der **den Code vom PR** (und nicht von der Basis) **holt**, wird der vom Angreifer kontrollierte Code verwendet. Zum Beispiel (siehe Zeile 12, wo der PR-Code heruntergeladen wird): 
# UNSICHER. Nur als Beispiel bereitgestellt.
 on:
@@ -269,7 +279,7 @@ message: |
 Danke!
-Der potenziell **nicht vertrauenswürdige Code wird während `npm install` oder `npm build`** ausgeführt, da die Build-Skripte und referenzierten **Pakete vom Autor des PR** kontrolliert werden. +Der potenziell **nicht vertrauenswürdige Code wird während `npm install` oder `npm build`** ausgeführt, da die Build-Skripte und die referenzierten **Pakete vom Autor des PR** kontrolliert werden. > [!WARNING] > Ein GitHub-Dork, um nach anfälligen Aktionen zu suchen, ist: `event.pull_request pull_request_target extension:yml`, jedoch gibt es verschiedene Möglichkeiten, die Jobs sicher auszuführen, selbst wenn die Aktion unsicher konfiguriert ist (wie die Verwendung von Bedingungen darüber, wer der Akteur ist, der den PR generiert). @@ -286,21 +296,61 @@ gh-actions-context-script-injections.md Laut den Dokumenten: Sie können eine **Umgebungsvariable für alle nachfolgenden Schritte** in einem Workflow-Job verfügbar machen, indem Sie die Umgebungsvariable definieren oder aktualisieren und dies in die **`GITHUB_ENV`**-Umgebungsdatei schreiben. -Wenn ein Angreifer **irgendeinen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**. +Wenn ein Angreifer **irgend einen Wert** in diese **env**-Variable **einschleusen** könnte, könnte er Umgebungsvariablen injizieren, die in nachfolgenden Schritten Code ausführen könnten, wie **LD_PRELOAD** oder **NODE_OPTIONS**. -Zum Beispiel ([**dies**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**dies**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stellen Sie sich einen Workflow vor, der einem hochgeladenen Artifact vertraut, um seinen Inhalt in der **`GITHUB_ENV`**-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren: +Zum Beispiel ([**dies**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) und [**dies**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stellen Sie sich einen Workflow vor, der ein hochgeladenes Artifact vertraut, um seinen Inhalt in der **`GITHUB_ENV`**-Umgebungsvariable zu speichern. Ein Angreifer könnte etwas wie dies hochladen, um es zu kompromittieren:
-### Anfällige Drittanbieter-GitHub-Aktionen +### Dependabot und andere vertrauenswürdige Bots + +Wie in [**diesem Blogbeitrag**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) angegeben, haben mehrere Organisationen eine GitHub-Aktion, die jeden PR von `dependabot[bot]` zusammenführt, wie in: +```yaml +on: pull_request_target +jobs: +auto-merge: +runs-on: ubuntu-latest +if: ${ { github.actor == 'dependabot[bot]' }} +steps: +- run: gh pr merge $ -d -m +``` +Welches ein Problem darstellt, da das Feld `github.actor` den Benutzer enthält, der das letzte Ereignis verursacht hat, das den Workflow ausgelöst hat. Und es gibt mehrere Möglichkeiten, den Benutzer `dependabot[bot]` dazu zu bringen, einen PR zu ändern. Zum Beispiel: + +- Forken Sie das Opfer-Repository +- Fügen Sie die bösartige Payload zu Ihrer Kopie hinzu +- Aktivieren Sie Dependabot in Ihrem Fork, indem Sie eine veraltete Abhängigkeit hinzufügen. Dependabot wird einen Branch erstellen, der die Abhängigkeit mit bösartigem Code behebt. +- Öffnen Sie einen Pull Request zum Opfer-Repository von diesem Branch (der PR wird vom Benutzer erstellt, also wird noch nichts passieren) +- Dann geht der Angreifer zurück zu dem ursprünglichen 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 Opfer-Repo modifizieren, wodurch `dependabot[bot]` der Akteur des letzten Ereignisses wird, das den Workflow ausgelöst hat (und daher der Workflow ausgeführt wird). + +Kommen wir nun dazu, was wäre, wenn anstelle des Zusammenführens die Github Action eine Befehlsinjektion hätte wie in: +```yaml +on: pull_request_target +jobs: +just-printing-stuff: +runs-on: ubuntu-latest +if: ${ { github.actor == 'dependabot[bot]' }} +steps: +- run: echo ${ { github.event.pull_request.head.ref }} +``` +Nun, der ursprüngliche Blogbeitrag schlägt zwei Optionen vor, um dieses Verhalten auszunutzen, wobei die zweite ist: + +- Forken Sie das Opfer-Repository und aktivieren Sie Dependabot mit einer veralteten Abhängigkeit. +- Erstellen Sie einen neuen Branch mit dem bösartigen Shell-Injektionscode. +- Ändern Sie den Standardbranch des Repos auf diesen. +- Erstellen Sie einen PR von diesem Branch zum Opfer-Repository. +- Führen Sie `@dependabot merge` im PR aus, den Dependabot in seinem Fork geöffnet hat. +- Dependabot wird seine Änderungen im Standardbranch Ihres geforkten Repositories zusammenführen und den PR im Opfer-Repository aktualisieren, wodurch `dependabot[bot]` der Akteur des letzten Ereignisses wird, das den Workflow ausgelöst hat, und einen bösartigen Branch-Namen verwendet. + +### Verwundbare Drittanbieter Github Actions #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) -Wie in [**diesem Blogbeitrag**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, ermöglicht diese GitHub-Aktion den Zugriff auf Artefakte aus verschiedenen Workflows und sogar Repositories. +Wie in [**diesem Blogbeitrag**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) erwähnt, ermöglicht diese Github Action den Zugriff auf Artefakte aus verschiedenen Workflows und sogar Repositories. -Das Problem ist, dass, wenn der **`path`**-Parameter nicht gesetzt ist, das Artifact im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden könnten. Daher könnte ein Angreifer, wenn das Artifact anfällig ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artifact vertrauen. +Das Problem ist, dass, wenn der **`path`** Parameter nicht gesetzt ist, das Artefakt im aktuellen Verzeichnis extrahiert wird und Dateien überschreiben kann, die später im Workflow verwendet oder sogar ausgeführt werden könnten. Daher könnte ein Angreifer, wenn das Artefakt verwundbar ist, dies ausnutzen, um andere Workflows zu kompromittieren, die dem Artefakt vertrauen. -Beispiel eines anfälligen Workflows: +Beispiel für einen verwundbaren Workflow: ```yaml on: workflow_run: @@ -344,12 +394,12 @@ path: ./script.py ### Gelöschte Namespace-Repo-Hijacking -Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository **weniger als 100 Sterne vor der Namensänderung hatte**, erlaubt Github dem neu registrierten Benutzer mit demselben Namen, ein **Repository mit demselben Namen** wie das gelöschte zu erstellen. +Wenn ein Konto seinen Namen ändert, könnte ein anderer Benutzer nach einiger Zeit ein Konto mit diesem Namen registrieren. Wenn ein Repository **weniger als 100 Sterne vor der Namensänderung hatte**, erlaubt Github dem neuen registrierten Benutzer mit demselben Namen, ein **Repository mit demselben Namen** wie das gelöschte zu erstellen. > [!CAUTION] -> Wenn eine Aktion also ein Repo von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellen und die Aktion kompromittieren könnte. +> Wenn eine Aktion ein Repo von einem nicht existierenden Konto verwendet, ist es immer noch möglich, dass ein Angreifer dieses Konto erstellen und die Aktion kompromittieren könnte. -Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu übernehmen. Hier haben Sie eine umfassendere 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 **Abhängigkeiten von diesen Benutzer-Repos** verwendet haben, wird ein Angreifer in der Lage sein, sie zu hijacken. Hier haben Sie eine umfassendere Erklärung: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) --- @@ -360,7 +410,7 @@ Wenn andere Repositories **Abhängigkeiten von diesen Benutzer-Repos** verwendet ### Cache-Poisoning -Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** **kompromittiert**, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann. +Ein Cache wird zwischen **Workflow-Ausführungen im selben Branch** aufrechterhalten. Das bedeutet, dass, wenn ein Angreifer ein **Paket** kompromittiert, das dann im Cache gespeichert und von einem **privilegierteren** Workflow **heruntergeladen** und ausgeführt wird, er auch diesen Workflow **kompromittieren** kann. {{#ref}} gh-actions-cache-poisoning.md @@ -368,7 +418,7 @@ gh-actions-cache-poisoning.md ### Artifact-Poisoning -Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action, die ein **Artefakt hochlädt**, das später von einem anderen Workflow verwendet wird, zu **kompromittieren**, könnte er **die anderen Workflows kompromittieren**: +Workflows könnten **Artefakte von anderen Workflows und sogar Repos** verwenden. Wenn es einem Angreifer gelingt, die Github Action zu **kompromittieren**, die ein **Artefakt hochlädt**, das später von einem anderen Workflow verwendet wird, könnte er **die anderen Workflows kompromittieren**: {{#ref}} gh-actions-artifact-poisoning.md @@ -466,11 +516,11 @@ key: ${{ secrets.PUBLISH_KEY }} ### Missbrauch von selbstgehosteten Runnern -Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastrukturen** ausgeführt werden, besteht darin, nach **`runs-on: self-hosted`** in der Github Action-Konfigurations-YAML zu suchen. +Der Weg, um herauszufinden, welche **Github Actions in nicht-Github-Infrastrukturen ausgeführt werden**, besteht darin, nach **`runs-on: self-hosted`** in der Github Action-Konfigurations-YAML zu suchen. **Selbstgehostete** Runner könnten Zugang zu **extra sensiblen Informationen**, zu anderen **Netzwerksystemen** (anfällige Endpunkte im Netzwerk? Metadatenservice?) haben oder, selbst wenn sie isoliert und zerstört sind, **könnten mehr als eine Aktion gleichzeitig ausgeführt werden** und die bösartige könnte die **Geheimnisse** der anderen stehlen. -Bei selbstgehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher dumpet: +Bei selbstgehosteten Runnern ist es auch möglich, die **Geheimnisse aus dem \_Runner.Listener**\_\*\* Prozess\*\* zu erhalten, der alle Geheimnisse der Workflows zu jedem Zeitpunkt enthält, indem man seinen Speicher ausliest: ```bash sudo apt-get install -y gdb sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')" @@ -530,24 +580,15 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens ### Sensible Informationen in Github Actions-Protokollen -Selbst wenn **Github** versucht, **Geheimwerte** in den Aktionsprotokollen zu **erkennen** und **zu vermeiden**, dass sie angezeigt werden, werden **andere sensible Daten**, die während der Ausführung der Aktion generiert wurden, nicht verborgen. Zum Beispiel wird ein mit einem Geheimwert signiertes JWT nicht verborgen, es sei denn, es ist [speziell konfiguriert](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). +Selbst wenn **Github** versucht, **Geheimwerte** in den Aktionsprotokollen zu **erkennen** und **zu vermeiden**, dass sie angezeigt werden, werden **andere sensible Daten**, die während der Ausführung der Aktion generiert wurden, nicht verborgen. Zum Beispiel wird ein JWT, das mit einem Geheimwert signiert ist, nicht verborgen, es sei denn, es ist [speziell konfiguriert](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). ## Spuren verwischen -(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig **einen PR aus dem Internet nicht löschen**, aber es gibt einen Haken. Für GitHub-Konten, die von Github **suspendiert** wurden, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto suspendiert bekommen oder Ihr Konto als verdächtig markieren lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen). +(Technik von [**hier**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Zunächst einmal ist jeder PR, der erstellt wird, für die Öffentlichkeit in Github und für das Ziel-GitHub-Konto deutlich sichtbar. In GitHub können wir standardmäßig **einen PR aus dem Internet nicht löschen**, aber es gibt einen Haken. Für GitHub-Konten, die von Github **suspendiert** werden, werden alle ihre **PRs automatisch gelöscht** und aus dem Internet entfernt. Um also Ihre Aktivitäten zu verbergen, müssen Sie entweder Ihr **GitHub-Konto suspendiert bekommen oder Ihr Konto als verdächtig markieren lassen**. Dies würde **alle Ihre Aktivitäten** auf GitHub aus dem Internet verbergen (im Grunde alle Ihre Exploit-PRs entfernen). Eine Organisation in GitHub ist sehr proaktiv darin, Konten an GitHub zu melden. Alles, was Sie tun müssen, ist, „einige Dinge“ in einem Issue zu teilen, und sie werden sicherstellen, dass Ihr Konto in 12 Stunden suspendiert wird :p und da haben Sie es, Ihr Exploit ist auf GitHub unsichtbar gemacht. > [!WARNING] > Der einzige Weg für eine Organisation herauszufinden, dass sie ins Visier genommen wurde, besteht darin, die GitHub-Protokolle von SIEM zu überprüfen, da der PR aus der GitHub-Benutzeroberfläche entfernt würde. -## Werkzeuge - -Die folgenden Werkzeuge sind nützlich, um Github Action-Workflows zu finden und sogar verwundbare zu finden: - -- [https://github.com/CycodeLabs/raven](https://github.com/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) - {{#include ../../../banners/hacktricks-training.md}}