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

2025-12-27 21:23:07 -08:00 · 2025-06-25 00:23:15 +00:00
parent 14003d07fa
commit f11164973e
2 changed files with 78 additions and 37 deletions
--- 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,28 +1,38 @@
-# Abusare di Github Actions
+# Abusing Github Actions

 {{#include ../../../banners/hacktricks-training.md}}

-## Informazioni di Base
+## Tools
+
+I seguenti strumenti sono utili per trovare i flussi di lavoro di Github Action e persino trovare quelli vulnerabili:
+
+- [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) - Controlla anche la sua checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+
+## Basic Information

 In questa pagina troverai:

 - Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a una Github Action
- Diversi modi per **ottenere accesso a un'azione**:
+- Modi diversi per **ottenere accesso a un'azione**:
 - Avere **permessi** per creare l'azione
 - Abusare dei trigger relativi alle **pull request**
 - Abusare di **altre tecniche di accesso esterno**
- **Pivotare** da un repository già compromesso
+- **Pivotare** da un repo già compromesso
 - Infine, una sezione sulle **tecniche di post-exploitation per abusare di un'azione dall'interno** (causando gli impatti menzionati)

-## Riepilogo degli Impatti
+## Impacts Summary

 Per un'introduzione su [**Github Actions controlla le informazioni di base**](../basic-github-information.md#github-actions).

 Se puoi **eseguire codice arbitrario in GitHub Actions** all'interno di un **repository**, potresti essere in grado di:

 - **Rubare segreti** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
- **Compromettere i deployment** e altri **artifacts**.
- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla supply chain.
+- **Compromettere distribuzioni** e altri **artifacts**.
+- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla catena di fornitura.
 - **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare verso altri sistemi.
 - **Sovrascrivere il codice del repository**, a seconda dei permessi associati al `GITHUB_TOKEN`.

@@ -35,7 +45,7 @@ Questo "**segreto**" (proveniente da `${{ secrets.GITHUB_TOKEN }}` e `${{ github
 Questo token è lo stesso che una **Github Application utilizzerà**, quindi può accedere agli stessi endpoint: [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 dovrebbe rilasciare un [**flusso**](https://github.com/github/roadmap/issues/74) che **consente l'accesso cross-repository** all'interno di GitHub, in modo che un repo possa accedere ad altri repo interni utilizzando il `GITHUB_TOKEN`.
+> Github dovrebbe rilasciare un [**flow**](https://github.com/github/roadmap/issues/74) che **consente l'accesso cross-repository** all'interno di GitHub, in modo che un repo possa accedere ad altri repo interni utilizzando il `GITHUB_TOKEN`.

 Puoi vedere i possibili **permessi** di questo token in: [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)

@@ -174,7 +184,7 @@ branches:

 ### `pull_request`

-Il trigger del workflow **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: per impostazione predefinita, se è la **prima volta** che stai **collaborando**, alcuni **maintainer** dovranno **approvare** l'**esecuzione** del workflow:
+Il trigger del workflow **`pull_request`** eseguirà il workflow ogni volta che viene ricevuta una pull request con alcune eccezioni: per impostazione predefinita, se è la **prima volta** che stai **collaborando**, un **maintainer** dovrà **approvare** l'**esecuzione** del workflow:

 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>

@@ -190,18 +200,18 @@ Inoltre, per impostazione predefinita **previene i permessi di scrittura** e **l
 Un attaccante potrebbe modificare la definizione del Github Action per eseguire cose arbitrarie e aggiungere azioni arbitrarie. Tuttavia, non sarà in grado di rubare segreti o sovrascrivere il repo a causa delle limitazioni menzionate.

 > [!CAUTION]
-> **Sì, se l'attaccante cambia nella PR l'azione github che verrà attivata, la sua Github Action sarà quella utilizzata e non quella del repo di origine!**
+> **Sì, se l'attaccante cambia nella PR l'azione github che verrà attivata, la sua Github Action sarà quella utilizzata e non quella del repository originale!**

-Poiché l'attaccante controlla anche il codice in esecuzione, anche se non ci sono segreti o permessi di scrittura sul `GITHUB_TOKEN`, un attaccante potrebbe ad esempio **caricare artefatti dannosi**.
+Poiché l'attaccante controlla anche il codice eseguito, anche se non ci sono segreti o permessi di scrittura sul `GITHUB_TOKEN`, un attaccante potrebbe ad esempio **caricare artefatti malevoli**.

 ### **`pull_request_target`**

-Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** sul repository target e **accesso ai segreti** (e non richiede permesso).
+Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** al repository target e **accesso ai segreti** (e non richiede permesso).

-Nota che il trigger del workflow **`pull_request_target`** **viene eseguito nel contesto di base** e non in quello fornito dalla PR (per **non eseguire codice non attendibile**). Per ulteriori informazioni su `pull_request_target` [**controlla la documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Nota che il trigger del workflow **`pull_request_target`** **viene eseguito nel contesto base** e non in quello fornito dalla PR (per **non eseguire codice non attendibile**). Per ulteriori informazioni su `pull_request_target` [**controlla la documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
 Inoltre, per ulteriori informazioni su questo specifico uso pericoloso, controlla questo [**post del blog di github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

-Potrebbe sembrare che poiché il **workflow eseguito** è quello definito nella **base** e **non nella PR**, sia **sicuro** utilizzare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**.
+Potrebbe sembrare che poiché il **workflow eseguito** è quello definito nel **base** e **non nella PR**, sia **sicuro** utilizzare **`pull_request_target`**, ma ci sono **alcuni casi in cui non lo è**.

 E questo avrà **accesso ai segreti**.

@@ -228,7 +238,7 @@ TODO

 TODO: Controlla se quando eseguito da un pull_request il codice utilizzato/scaricato è quello dell'origine o da PR forkato

-## Abuso dell'Esecuzione Forkata
+## Abusare dell'Esecuzione Forkata

 Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe riuscire a far eseguire un workflow di github, ora diamo un'occhiata a come queste esecuzioni, se configurate male, potrebbero essere abusate:

@@ -269,10 +279,10 @@ message: |
 Thank you!
 </code></pre>

-Il codice **potenzialmente non attendibile viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i **pacchetti referenziati sono controllati dall'autore del PR**.
+Il potenziale **codice non attendibile viene eseguito durante `npm install` o `npm build`** poiché gli script di build e i pacchetti referenziati sono controllati dall'autore del PR.

 > [!WARNING]
-> Un github dork per cercare azioni vulnerabili è: `event.pull_request pull_request_target extension:yml`, tuttavia, ci sono diversi modi per configurare i lavori da eseguire in modo sicuro anche se l'azione è configurata in modo insicuro (come utilizzare condizioni su chi è l'attore che genera il PR).
+> Un dork di github per cercare azioni vulnerabili è: `event.pull_request pull_request_target extension:yml`, tuttavia, ci sono diversi modi per configurare i lavori da eseguire in modo sicuro anche se l'azione è configurata in modo insicuro (come utilizzare condizioni su chi è l'attore che genera il PR).

 ### Iniezioni di Script nel Contesto <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>

@@ -292,13 +302,53 @@ Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-esc

 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>

-### Azioni Github di Terze Parti Vulnerabili
+### Dependabot e altri bot fidati
+
+Come indicato in [**questo post del blog**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), diverse organizzazioni hanno un'azione Github che unisce qualsiasi PRR da `dependabot[bot]` come 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
+```
+Qual è un problema perché il campo `github.actor` contiene l'utente che ha causato l'ultimo evento che ha attivato il workflow. E ci sono diversi modi per far sì che l'utente `dependabot[bot]` modifichi un PR. Ad esempio:
+
+- Forkare il repository della vittima
+- Aggiungere il payload malevolo alla tua copia
+- Abilitare Dependabot sul tuo fork aggiungendo una dipendenza obsoleta. Dependabot creerà un branch per correggere la dipendenza con codice malevolo.
+- Aprire una Pull Request al repository della vittima da quel branch (il PR sarà creato dall'utente quindi non succederà nulla per ora)
+- Poi, l'attaccante torna al PR iniziale che Dependabot ha aperto nel suo fork e esegue `@dependabot recreate`
+- Poi, Dependabot esegue alcune azioni in quel branch, che modificano il PR sul repository della vittima, il che rende `dependabot[bot]` l'attore dell'ultimo evento che ha attivato il workflow (e quindi, il workflow viene eseguito).
+
+Passando oltre, cosa succede se invece di unire, l'azione Github avesse un'iniezione di comando come 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 }}
+```
+Bene, il post originale propone due opzioni per abusare di questo comportamento, la seconda è:
+
+- Forkare il repository della vittima e abilitare Dependabot con qualche dipendenza obsoleta.
+- Creare un nuovo branch con il codice di iniezione di shell malevolo.
+- Cambiare il branch predefinito del repo in quello.
+- Creare una PR da questo branch al repository della vittima.
+- Eseguire `@dependabot merge` nella PR che Dependabot ha aperto nel suo fork.
+- Dependabot unirà le sue modifiche nel branch predefinito del tuo repository forkato, aggiornando la PR nel repository della vittima, rendendo ora `dependabot[bot]` l'attore dell'ultimo evento che ha attivato il workflow e utilizzando un nome di branch malevolo.
+
+### Github Actions di Terze Parti Vulnerabili

 #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)

-Come menzionato in [**questo post del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Azione Github consente di accedere agli artifact da diversi workflow e persino repository.
+Come menzionato in [**questo post del blog**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), questa Github Action consente di accedere agli artifact da diversi workflow e persino repository.

-Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere utilizzati o persino eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusare di questo per compromettere altri workflow che si fidano dell'Artifact.
+Il problema è che se il parametro **`path`** non è impostato, l'artifact viene estratto nella directory corrente e può sovrascrivere file che potrebbero essere utilizzati o persino eseguiti nel workflow. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusarne per compromettere altri workflow che si fidano dell'Artifact.

 Esempio di workflow vulnerabile:
 ```yaml
@@ -347,7 +397,7 @@ path: ./script.py
 Se un account cambia nome, un altro utente potrebbe registrare un account con quel nome dopo un po' di tempo. Se un repository aveva **meno di 100 stelle prima del cambio di nome**, Github permetterà al nuovo utente registrato con lo stesso nome di creare un **repository con lo stesso nome** di quello cancellato.

 > [!CAUTION]
-> Quindi, se un'azione sta utilizzando un repo di un account non esistente, è ancora possibile che un attaccante possa creare quell'account e compromettere l'azione.
+> Quindi, se un'azione sta utilizzando un repo da un account inesistente, è ancora possibile che un attaccante possa creare quell'account e compromettere l'azione.

 Se altri repository stavano utilizzando **dipendenze da questi repo utente**, un attaccante sarà in grado di hijackarli. Qui hai una spiegazione più completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)

@@ -368,7 +418,7 @@ gh-actions-cache-poisoning.md

 ### Artifact Poisoning

-I workflow potrebbero utilizzare **artifact da altri workflow e persino repo**, se un attaccante riesce a **compromettere** l'azione Github che **carica un artifact** che viene poi utilizzato da un altro workflow, potrebbe **compromettere gli altri workflow**:
+I workflow potrebbero utilizzare **artifacts da altri workflow e persino repo**. Se un attaccante riesce a **compromettere** l'azione Github che **carica un artifact** che viene poi utilizzato da un altro workflow, potrebbe **compromettere gli altri workflow**:

 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -456,7 +506,7 @@ cat /home/runner/work/_temp/*
 - ```bash
 ps axe | grep node
 ```
- Per un **'azione personalizzata'**, il rischio può variare a seconda di come un programma utilizza il segreto ottenuto dall'**argomento**:
+- Per un **azione personalizzata**, il rischio può variare a seconda di come un programma utilizza il segreto ottenuto dall'**argomento**:

 ```yaml
 uses: fakeaction/publish@v3
@@ -468,7 +518,7 @@ key: ${{ secrets.PUBLISH_KEY }}

 Il modo per trovare quali **Github Actions vengono eseguite in infrastrutture non-Github** è cercare **`runs-on: self-hosted`** nella configurazione yaml dell'azione Github.

-I runner **self-hosted** potrebbero avere accesso a **informazioni extra sensibili**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? servizio di metadata?) o, anche se isolati e distrutti, **più di un'azione potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i segreti** dell'altra.
+I runner **self-hosted** potrebbero avere accesso a **informazioni extra sensibili**, ad altri **sistemi di rete** (endpoint vulnerabili nella rete? servizio di metadata?) o, anche se è isolato e distrutto, **più di un'azione potrebbe essere eseguita contemporaneamente** e quella malevola potrebbe **rubare i segreti** dell'altra.

 Nei runner self-hosted è anche possibile ottenere i **segreti dal processo \_Runner.Listener**\_\*\* che conterrà tutti i segreti dei flussi di lavoro in qualsiasi fase dumpando la sua memoria:
 ```bash
@@ -477,7 +527,7 @@ sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ prin
 ```
 Controlla [**questo post per ulteriori informazioni**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).

-### Github Docker Images Registry
+### Registro delle Immagini Docker di Github

 È possibile creare azioni Github che **costruiranno e memorizzeranno un'immagine Docker all'interno di Github**.\
 Un esempio può essere trovato nel seguente espandibile:
@@ -530,24 +580,15 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens

 ### Informazioni sensibili nei log di Github Actions

-Anche se **Github** cerca di **rilevare valori segreti** nei log delle azioni e **evitare di mostrarli**, **altri dati sensibili** che potrebbero essere stati generati nell'esecuzione dell'azione non saranno nascosti. Ad esempio, un JWT firmato con un valore segreto non sarà nascosto a meno che non sia [specificamente configurato](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Anche se **Github** cerca di **rilevare valori segreti** nei log delle azioni e **evitare di mostrarli**, **altri dati sensibili** che potrebbero essere stati generati durante l'esecuzione dell'azione non saranno nascosti. Ad esempio, un JWT firmato con un valore segreto non sarà nascosto a meno che non sia [specificamente configurato](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).

 ## Coprire le tue tracce

-(Tecnica da [**qui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub target. In GitHub per impostazione predefinita, **non possiamo eliminare un PR da internet**, ma c'è un colpo di scena. Per gli account GitHub che sono **sospesi** da Github, tutti i loro **PR vengono automaticamente eliminati** e rimossi da internet. Quindi, per nascondere la tua attività, devi o far **sospendere il tuo account GitHub o far segnare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (fondamentalmente rimuovere tutti i tuoi PR di exploit)
+(Tecnica da [**qui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub target. In GitHub per impostazione predefinita, **non possiamo eliminare un PR da internet**, ma c'è un colpo di scena. Per gli account GitHub che sono **sospesi** da Github, tutti i loro **PR vengono automaticamente eliminati** e rimossi da internet. Quindi, per nascondere la tua attività, devi o far **sospendere il tuo account GitHub o far segnare il tuo account**. Questo **nasconderebbe tutte le tue attività** su GitHub da internet (fondamentalmente rimuovere tutti i tuoi exploit PR)

-Un'organizzazione in GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" in un Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e così hai reso il tuo exploit invisibile su github.
+Un'organizzazione su GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" in un Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e così hai reso il tuo exploit invisibile su github.

 > [!WARNING]
 > L'unico modo per un'organizzazione di capire di essere stata presa di mira è controllare i log di GitHub da SIEM poiché dall'interfaccia di GitHub il PR verrebbe rimosso.

-## Strumenti
-
-I seguenti strumenti sono utili per trovare flussi di lavoro di Github Action e persino trovare quelli vulnerabili:
-
- [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}}