Abusing Github Actions
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Informazioni di Base
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:
Avere permessi per creare l'azione
Abusare dei trigger pull request correlati
Abusare di altre tecniche di accesso esterno
Pivoting da un repository già compromesso
Infine, una sezione sulle tecniche di post-exploitation per abusare di un'azione dall'interno (causando gli impatti menzionati)
Riassunto degli Impatti
Per un'introduzione su Github Actions controlla le informazioni di base.
Nel caso tu possa eseguire azioni Github arbitrarie/iniettare codice in un repository, potresti essere in grado di:
Rubare i segreti da quel repo/organizzazione.
Se puoi solo iniettare, puoi rubare tutto ciò che è già presente nel workflow.
Abusare dei privilegi del repo per accedere ad altre piattaforme come AWS e GCP.
Eseguire codice in custom workers (se vengono utilizzati custom workers) e provare a pivotare da lì.
Sovrascrivere il codice del repository.
Questo dipende dai privilegi del
GITHUB_TOKEN
(se presente).Compromettere deployments e altri artifacts.
Se il codice sta distribuendo o memorizzando qualcosa, potresti modificarlo e ottenere ulteriori accessi.
GITHUB_TOKEN
Questo "segreto" (proveniente da ${{ secrets.GITHUB_TOKEN }}
e ${{ github.token }}
) viene fornito quando l'amministratore abilita questa opzione:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F109713985-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FSeBtjKurjq2uRti4Bnzw%252Fuploads%252Fgit-blob-321c885ffd9caf24732687dc5af975a2321e623d%252Fimage%2520%2886%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=661f2c5d&sv=1)
Questo token è lo stesso che utilizzerà una Github Application, quindi può accedere agli stessi endpoint: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps
Github dovrebbe rilasciare un flow 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
Nota che il token scade dopo il completamento del job.
Questi token appaiono così: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7
Alcune cose interessanti che puoi fare con questo token:
Nota che in diverse occasioni potrai trovare token utente github all'interno degli envs di Github Actions o nei secrets. Questi token possono darti più privilegi sul repository e sull'organizzazione.
È possibile controllare i permessi dati a un Github Token nei repository di altri utenti controllando i log delle azioni:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F109713985-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FSeBtjKurjq2uRti4Bnzw%252Fuploads%252Fgit-blob-ee3d116e8ab59b805b891841f778211d307bec1b%252Fimage%2520%28286%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=20715cf2&sv=1)
Esecuzione Consentita
Questo sarebbe il modo più semplice per compromettere le Github actions, poiché questo caso suppone che tu abbia accesso per creare un nuovo repo nell'organizzazione, o abbia privilegi di scrittura su un repository.
Se ti trovi in questo scenario, puoi semplicemente controllare le tecniche di Post Exploitation.
Esecuzione dalla Creazione del Repo
Nel caso in cui i membri di un'organizzazione possano creare nuovi repo e tu possa eseguire github actions, puoi creare un nuovo repo e rubare i secrets impostati a livello di organizzazione.
Esecuzione da un Nuovo Branch
Se puoi creare un nuovo branch in un repository che già contiene una Github Action configurata, puoi modificarla, caricare il contenuto e poi eseguire quell'azione dal nuovo branch. In questo modo puoi esfiltrare i secrets a livello di repository e di organizzazione (ma devi sapere come sono chiamati).
Puoi rendere l'azione modificata eseguibile manualmente, quando viene creato un PR o quando viene caricato del codice (a seconda di quanto vuoi essere rumoroso):
Esecuzione Forked
Ci sono diversi trigger che potrebbero permettere a un attaccante di eseguire una Github Action di un altro repository. Se queste azioni attivabili sono configurate male, un attaccante potrebbe essere in grado di comprometterle.
pull_request
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, un maintainer dovrà approvare l'esecuzione del workflow:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F109713985-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FSeBtjKurjq2uRti4Bnzw%252Fuploads%252Fgit-blob-e8609ada1672308138cf7f2f4488cfd599c1a938%252Fimage%2520%28184%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=f7f7640f&sv=1)
Poiché la limitazione predefinita è per i collaboratori alla prima volta, potresti contribuire correggendo un bug/errore valido e poi inviare altre PR per abusare dei tuoi nuovi privilegi 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 impedisce i permessi di scrittura e l'accesso ai secrets al repository di destinazione come menzionato nei docs:
Con l'eccezione di
GITHUB_TOKEN
, i secrets non vengono passati al runner quando un workflow è attivato da un repository forked. IlGITHUB_TOKEN
ha permessi di sola lettura nelle pull request da repository forked.
Un attaccante potrebbe modificare la definizione della Github Action per eseguire cose arbitrarie e aggiungere azioni arbitrarie. Tuttavia, non sarà in grado di rubare secrets o sovrascrivere il repository a causa delle limitazioni menzionate.
Sì, se l'attaccante cambia nella PR la github action che verrà attivata, la sua Github Action sarà quella utilizzata e non quella del repository originale!
Poiché l'attaccante controlla anche il codice eseguito, anche se non ci sono secrets o permessi di scrittura sul GITHUB_TOKEN
, un attaccante potrebbe ad esempio caricare artefatti dannosi.
pull_request_target
pull_request_target
Il trigger del workflow pull_request_target
ha permessi di scrittura sul repository di destinazione e accesso ai secrets (e non chiede permesso).
Nota che il trigger del workflow pull_request_target
viene eseguito nel contesto base e non in quello dato dalla PR (per non eseguire codice non attendibile). Per ulteriori informazioni su pull_request_target
controlla i docs.
Inoltre, per ulteriori informazioni su questo uso specifico pericoloso, controlla questo post sul blog di github.
Potrebbe sembrare che poiché il workflow eseguito è quello definito nel base e non nella PR sia sicuro usare pull_request_target
, ma ci sono alcuni casi in cui non lo è.
E questo avrà accesso ai secrets.
workflow_run
workflow_run
Il trigger workflow_run consente di eseguire un workflow da un altro quando è completed
, requested
o in_progress
.
In questo esempio, un workflow è configurato per essere eseguito dopo che il workflow separato "Run Tests" è completato:
Inoltre, secondo la documentazione: Il workflow avviato dall'evento workflow_run
è in grado di accedere ai segreti e scrivere token, anche se il workflow precedente non lo era.
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. Il primo consiste nel workflow attivato da workflow_run
che scarica il codice dell'attaccante: ${{ github.event.pull_request.head.sha }}
Il secondo consiste nel passare un artifact dal codice non fidato al workflow workflow_run
e utilizzare il contenuto di questo artifact in modo che sia vulnerabile a RCE.
workflow_call
workflow_call
TODO
TODO: Verificare se quando eseguito da un pull_request il codice utilizzato/scaricato è quello dell'origine o del PR forkato
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 mal configurate, potrebbero essere abusate:
Esecuzione di checkout non fidato
Nel caso di pull_request
, il workflow verrà eseguito nel contesto del PR (quindi eseguirà il codice del PR malevolo), ma qualcuno deve autorizzarlo prima e verrà eseguito con alcune limitazioni.
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
verrà eseguito il codice del repository originale, quindi l'attaccante non può controllare il codice eseguito.
Tuttavia, se l'azione ha un checkout PR esplicito che prenderà il codice dal PR (e non dalla base), utilizzerà il codice controllato dall'attaccante. Ad esempio (controlla la linea 12 dove viene scaricato il codice del PR):
Il codice potenzialmente non fidato viene eseguito durante npm install
o npm build
poiché gli script di build e i pacchetti referenziati sono controllati dall'autore del PR.
Un github dork per cercare azioni vulnerabili è: event.pull_request pull_request_target extension:yml
tuttavia, ci sono diversi modi per configurare i job in modo sicuro anche se l'azione è configurata in modo insicuro (come l'uso di condizionali su chi è l'attore che genera il PR).
Iniezioni di Script nel Contesto
Nota che ci sono alcuni contesti di GitHub i cui valori sono controllati dall'utente che crea il PR. Se l'azione di GitHub utilizza quei dati per eseguire qualcosa, potrebbe portare a esecuzione arbitraria di codice:
Gh Actions - Context Script InjectionsIniezione di Script in GITHUB_ENV
Dalla documentazione: Puoi rendere una variabile d'ambiente disponibile per qualsiasi passaggio successivo in un job di workflow definendo o aggiornando la variabile d'ambiente e scrivendola nel file di ambiente GITHUB_ENV
.
Se un attaccante potesse iniettare qualsiasi valore all'interno di questa variabile env, potrebbe iniettare variabili env che potrebbero eseguire codice nei passaggi successivi come LD_PRELOAD o NODE_OPTIONS.
Ad esempio (questo e questo), immagina un workflow che si fida di un artifact caricato per memorizzare il suo contenuto all'interno della variabile env GITHUB_ENV
. Un attaccante potrebbe caricare qualcosa del genere per comprometterlo:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F109713985-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FSeBtjKurjq2uRti4Bnzw%252Fuploads%252Fgit-blob-e4a09fa61b7bbbe0f9e90bf6ca86661b5029c218%252Fimage%2520%28261%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=a281e188&sv=1)
Azioni di Terze Parti di GitHub Vulnerabili
Come menzionato in questo post del blog, questa azione di GitHub consente di accedere agli artifact di 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 successivamente 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:
Questo potrebbe essere attaccato con questo workflow:
Altri Accessi Esterni
Hijacking di un Namespace Eliminato
Se un account cambia il suo 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 eliminato.
Quindi, se un'azione sta usando un repository da un account inesistente, è ancora possibile che un attaccante possa creare quell'account e compromettere l'azione.
Se altri repository stavano usando dipendenze da questi repository 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/
Repo Pivoting
In questa sezione parleremo di tecniche che permetterebbero di pivotare da un repository a un altro supponendo di avere qualche tipo di accesso al primo (controlla la sezione precedente).
Cache Poisoning
Una cache è mantenuta tra esecuzioni di workflow nello stesso branch. Ciò significa che se un attaccante compromette un pacchetto che viene poi memorizzato nella cache e scaricato ed eseguito da un workflow più privilegiato, sarà in grado di compromettere anche quel workflow.
GH Actions - Cache PoisoningArtifact Poisoning
I workflow potrebbero usare artifact da altri workflow e persino repository, se un attaccante riesce a compromettere la GitHub Action che carica un artifact che viene poi utilizzato da un altro workflow, potrebbe compromettere gli altri workflow:
Gh Actions - Artifact PoisoningPost Exploitation da un'Azione
Accesso a AWS e GCP tramite OIDC
Controlla le seguenti pagine:
AWS - Federation AbuseGCP - Federation AbuseAccesso ai segreti
Se stai iniettando contenuto in uno script, è interessante sapere come puoi accedere ai segreti:
Se il segreto o il token è impostato come variabile d'ambiente, può essere direttamente accessibile tramite l'ambiente usando
printenv
.
Se il segreto è usato direttamente in un'espressione, lo script shell generato è memorizzato su disco ed è accessibile.
cat /home/runner/work/_temp/*
Per una custom action, il rischio può variare a seconda di come un programma utilizza il segreto ottenuto dall'argomento:
Abusare dei runner self-hosted
Il modo per trovare quali Github Actions vengono eseguite in infrastrutture non-Github è cercare runs-on: self-hosted
nel file di configurazione yaml di Github Action.
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.
Nei runner self-hosted è anche possibile ottenere i **segreti dal processo _Runner.Listener_** che conterrà tutti i segreti dei workflow in qualsiasi fase scaricando la sua memoria:
Consulta questo post per maggiori informazioni.
Registro delle Immagini Docker di Github
È possibile creare azioni Github che costruiscono e memorizzano un'immagine Docker all'interno di Github. Un esempio può essere trovato nel seguente espandibile:
Last updated