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 f1742dd44..07d9d03a9 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,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:
@@ -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! -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 @@ -292,13 +302,53 @@ Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-esc
-### 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}}