mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 05:33:10 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -1,20 +1,20 @@
|
||||
# Abusing Github Actions
|
||||
# Abusare di Github Actions
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Informazioni di Base
|
||||
|
||||
In questa pagina troverai:
|
||||
|
||||
- Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a un'azione Github
|
||||
- Un **riassunto di tutti gli impatti** di un attaccante che riesce ad accedere a un'azione di Github
|
||||
- Diversi modi 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
|
||||
- Infine, una sezione sulle **tecniche di post-sfruttamento per abusare di un'azione dall'interno** (causando gli impatti menzionati)
|
||||
- Infine, una sezione sulle **tecniche di post-exploitation per abusare di un'azione dall'interno** (causando gli impatti menzionati)
|
||||
|
||||
## Impacts Summary
|
||||
## Riepilogo degli Impatti
|
||||
|
||||
Per un'introduzione su [**Github Actions controlla le informazioni di base**](../basic-github-information.md#github-actions).
|
||||
|
||||
@@ -22,8 +22,8 @@ Se puoi **eseguire codice arbitrario in GitHub Actions** all'interno di un **rep
|
||||
|
||||
- **Rubare segreti** montati nella pipeline e **abusare dei privilegi della pipeline** per ottenere accesso non autorizzato a piattaforme esterne, come AWS e GCP.
|
||||
- **Compromettere distribuzioni** e altri **artifacts**.
|
||||
- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla supply chain.
|
||||
- **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare verso altri sistemi.
|
||||
- Se la pipeline distribuisce o memorizza risorse, potresti alterare il prodotto finale, abilitando un attacco alla catena di approvvigionamento.
|
||||
- **Eseguire codice in worker personalizzati** per abusare della potenza di calcolo e pivotare su altri sistemi.
|
||||
- **Sovrascrivere il codice del repository**, a seconda dei permessi associati al `GITHUB_TOKEN`.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
@@ -151,7 +151,7 @@ Nel caso in cui i membri di un'organizzazione possano **creare nuovi repo** e tu
|
||||
|
||||
### Esecuzione da un Nuovo Branch
|
||||
|
||||
Se puoi **creare un nuovo branch in un repository che contiene già un'azione Github** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'azione dal nuovo branch**. In questo modo puoi **esfiltrare i segreti a livello di repository e organizzazione** (ma devi sapere come si chiamano).
|
||||
Se puoi **creare un nuovo branch in un repository che già contiene un'azione Github** configurata, puoi **modificarla**, **caricare** il contenuto e poi **eseguire quell'azione dal nuovo branch**. In questo modo puoi **esfiltrare i segreti a livello di repository e organizzazione** (ma devi sapere come si chiamano).
|
||||
|
||||
Puoi rendere l'azione modificata eseguibile **manualmente,** quando viene **creato un PR** o quando **alcuni codici vengono caricati** (a seconda di quanto vuoi essere evidente):
|
||||
```yaml
|
||||
@@ -170,7 +170,7 @@ branches:
|
||||
## Esecuzione Forked
|
||||
|
||||
> [!NOTE]
|
||||
> Ci sono diversi trigger che potrebbero consentire a un attaccante di **eseguire un Github Action di un altro repository**. Se quelle azioni attivabili sono configurate in modo errato, un attaccante potrebbe essere in grado di comprometterle.
|
||||
> Ci sono diversi trigger che potrebbero consentire a un attaccante di **eseguire un Github Action di un altro repository**. Se quelle azioni attivabili sono configurate male, un attaccante potrebbe essere in grado di comprometterle.
|
||||
|
||||
### `pull_request`
|
||||
|
||||
@@ -179,11 +179,11 @@ Il trigger del workflow **`pull_request`** eseguirà il workflow ogni volta che
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> Poiché la **limitazione predefinita** è per i **contributori alla prima esperienza**, potresti contribuire **correggendo un bug/errore valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi di `pull_request`**.
|
||||
> Poiché la **limitazione predefinita** è per i **contributori alla prima esperienza**, potresti contribuire **correggendo un bug/typo valido** e poi inviare **altre PR per abusare dei tuoi nuovi privilegi di `pull_request`**.
|
||||
>
|
||||
> **Ho testato questo e non funziona**: ~~Un'altra opzione sarebbe creare un account con il nome di qualcuno che ha contribuito al progetto e ha cancellato il suo account.~~
|
||||
|
||||
Inoltre, per impostazione predefinita **prevenire i permessi di scrittura** e **l'accesso ai segreti** al repository target come menzionato nella [**documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
Inoltre, per impostazione predefinita **previene i permessi di scrittura** e **l'accesso ai segreti** al repository di destinazione come menzionato nella [**documentazione**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> Con l'eccezione di `GITHUB_TOKEN`, **i segreti non vengono passati al runner** quando un workflow è attivato da un **repository forked**. Il **`GITHUB_TOKEN` ha permessi di sola lettura** nelle pull request **da repository forked**.
|
||||
|
||||
@@ -192,14 +192,14 @@ Un attaccante potrebbe modificare la definizione del Github Action per eseguire
|
||||
> [!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!**
|
||||
|
||||
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 dannosi**.
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** al repository target e **accesso ai segreti** (e non richiede permesso).
|
||||
Il trigger del workflow **`pull_request_target`** ha **permessi di scrittura** al repository di destinazione 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).\
|
||||
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/).
|
||||
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 è**.
|
||||
|
||||
@@ -209,7 +209,7 @@ E questo avrà **accesso ai segreti**.
|
||||
|
||||
Il trigger [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) consente di eseguire un workflow da un altro quando è `completato`, `richiesto` o `in_corso`.
|
||||
|
||||
In questo esempio, un workflow è configurato per essere eseguito dopo il completamento del separato workflow "Esegui Test":
|
||||
In questo esempio, un workflow è configurato per essere eseguito dopo che il separato workflow "Esegui Test" è completato:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -217,29 +217,29 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Inoltre, secondo la documentazione: Il flusso di lavoro avviato dall'evento `workflow_run` è in grado di **accedere ai segreti e scrivere token, anche se il flusso di lavoro precedente non lo era**.
|
||||
Inoltre, secondo la documentazione: Il workflow avviato dall'evento `workflow_run` è in grado di **accedere a segreti e scrivere token, anche se il workflow precedente non lo era**.
|
||||
|
||||
Questo tipo di flusso di lavoro potrebbe essere attaccato se **dipende** da un **flusso di lavoro** che può essere **attivato** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel flusso di lavoro attivato da **`workflow_run`** che scarica il codice degli attaccanti: `${{ github.event.pull_request.head.sha }}`\
|
||||
Il secondo consiste nel **passare** un **artifact** dal codice **non attendibile** al flusso di lavoro **`workflow_run`** e utilizzare il contenuto di questo artifact in un modo che lo rende **vulnerabile a RCE**.
|
||||
Questo tipo di workflow potrebbe essere attaccato se **dipende** da un **workflow** che può essere **attivato** da un utente esterno tramite **`pull_request`** o **`pull_request_target`**. Un paio di esempi vulnerabili possono essere [**trovati in questo blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Il primo consiste nel workflow attivato da **`workflow_run`** che scarica il codice degli attaccanti: `${{ github.event.pull_request.head.sha }}`\
|
||||
Il secondo consiste nel **passare** un **artifact** dal codice **non attendibile** al workflow **`workflow_run`** e utilizzare il contenuto di questo artifact in un modo che lo rende **vulnerabile a RCE**.
|
||||
|
||||
### `workflow_call`
|
||||
|
||||
TODO
|
||||
|
||||
TODO: Controlla se, quando eseguito da un pull_request, il codice utilizzato/scaricato è quello dell'origine o da PR forkato
|
||||
TODO: Controlla se quando eseguito da un pull_request il codice utilizzato/scaricato è quello dell'origine o da PR forkato
|
||||
|
||||
## Abuso dell'Esecuzione Forkata
|
||||
|
||||
Abbiamo menzionato tutti i modi in cui un attaccante esterno potrebbe riuscire a far eseguire un flusso di lavoro github, ora diamo un'occhiata a come queste esecuzioni, se configurate male, potrebbero essere abusate:
|
||||
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:
|
||||
|
||||
### Esecuzione di checkout non attendibile
|
||||
|
||||
Nel caso di **`pull_request`,** il flusso di lavoro verrà eseguito nel **contesto del PR** (quindi eseguirà il **codice malevolo del PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](./#pull_request).
|
||||
Nel caso di **`pull_request`,** il workflow verrà eseguito nel **contesto del PR** (quindi eseguirà il **codice malevolo del PR**), ma qualcuno deve **autorizzarlo prima** e verrà eseguito con alcune [limitazioni](./#pull_request).
|
||||
|
||||
Nel caso di un flusso di lavoro che utilizza **`pull_request_target` o `workflow_run`** che dipende da un flusso di lavoro che può essere attivato da **`pull_request_target` o `pull_request`**, il codice del repository originale verrà eseguito, quindi l'**attaccante non può controllare il codice eseguito**.
|
||||
Nel caso di un workflow che utilizza **`pull_request_target` o `workflow_run`** che dipende da un workflow che può essere attivato da **`pull_request_target` o `pull_request`**, il codice del repository originale verrà eseguito, quindi l'**attaccante non può controllare il codice eseguito**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Tuttavia, se l'**azione** ha un **checkout PR esplicito** che **prenderà il codice dal PR** (e non dalla base), utilizzerà il codice controllato dagli attaccanti. Ad esempio (controlla la riga 12 dove il codice PR viene scaricato):
|
||||
> Tuttavia, se l'**azione** ha un **checkout PR esplicito** che **prenderà il codice dal PR** (e non dalla base), utilizzerà il codice controllato dagli attaccanti. Ad esempio (controlla la riga 12 dove il codice del PR viene scaricato):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Fornito solo come esempio.
|
||||
on:
|
||||
@@ -269,14 +269,14 @@ message: |
|
||||
Thank you!
|
||||
</code></pre>
|
||||
|
||||
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.
|
||||
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 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>
|
||||
|
||||
Nota che ci sono certi [**contesti github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea il PR. Se l'azione github utilizza quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **esecuzione di codice arbitrario:**
|
||||
Nota che ci sono certi [**contesti di github**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) i cui valori sono **controllati** dall'**utente** che crea il PR. Se l'azione di github utilizza quei **dati per eseguire qualsiasi cosa**, potrebbe portare a **esecuzione di codice arbitrario:**
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
@@ -284,23 +284,23 @@ gh-actions-context-script-injections.md
|
||||
|
||||
### **Iniezione di Script GITHUB_ENV** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
Dalla documentazione: Puoi rendere una **variabile di ambiente disponibile per qualsiasi passaggio successivo** in un lavoro di flusso di lavoro definendo o aggiornando la variabile di ambiente e scrivendo questo nel file di ambiente **`GITHUB_ENV`**.
|
||||
Dalla documentazione: Puoi rendere una **variabile di ambiente disponibile per qualsiasi passaggio successivo** in un lavoro di workflow definendo o aggiornando la variabile di ambiente e scrivendo questo nel file di ambiente **`GITHUB_ENV`**.
|
||||
|
||||
Se un attaccante potesse **iniettare qualsiasi valore** all'interno di questa variabile **env**, potrebbe iniettare variabili di ambiente che potrebbero eseguire codice nei passaggi successivi come **LD_PRELOAD** o **NODE_OPTIONS**.
|
||||
|
||||
Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**questo**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un flusso di lavoro che si fida di un artifact caricato per memorizzare il suo contenuto all'interno della variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
|
||||
Ad esempio ([**questo**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**questo**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), immagina un workflow che si fida di un artifact caricato per memorizzare il suo contenuto all'interno della variabile di ambiente **`GITHUB_ENV`**. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Azioni Github di Terze Parti Vulnerabili
|
||||
### Azioni di Terze Parti Vulnerabili di Github
|
||||
|
||||
#### [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 ad artifact provenienti da diversi flussi di lavoro 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 Azione Github consente di accedere ad artifact provenienti 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 flusso di lavoro. Pertanto, se l'Artifact è vulnerabile, un attaccante potrebbe abusare di questo per compromettere altri flussi di lavoro 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 abusare di questo per compromettere altri workflow che si fidano dell'Artifact.
|
||||
|
||||
Esempio di flusso di lavoro vulnerabile:
|
||||
Esempio di workflow vulnerabile:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -340,7 +340,7 @@ path: ./script.py
|
||||
```
|
||||
---
|
||||
|
||||
## Altra Accesso Esterno
|
||||
## Altro Accesso Esterno
|
||||
|
||||
### Hijacking di Namespace Repo Cancellati
|
||||
|
||||
@@ -448,7 +448,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
```
|
||||
</details>
|
||||
|
||||
- Se il segreto è utilizzato **direttamente in un'espressione**, lo script shell generato è memorizzato **su disco** ed è accessibile.
|
||||
- Se il segreto è usato **direttamente in un'espressione**, lo script shell generato è memorizzato **su disco** ed è accessibile.
|
||||
- ```bash
|
||||
cat /home/runner/work/_temp/*
|
||||
```
|
||||
@@ -534,9 +534,9 @@ Anche se **Github** cerca di **rilevare valori segreti** nei log delle azioni e
|
||||
|
||||
## 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 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 lì hai, reso invisibile il tuo exploit su github.
|
||||
Un'organizzazione in GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualcosa" nell'Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e lì 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.
|
||||
|
||||
Reference in New Issue
Block a user