gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-25 04:15:49 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/github-security/abusing-github-actions

Browse Source
This commit is contained in:
Translator
2025-09-29 23:28:16 +00:00
parent 096f908055
commit 12b99a361b
2 changed files with 347 additions and 116 deletions
Download Patch File Download Diff File Expand all files Collapse all files

236
src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
View File

@@ -4,55 +4,55 @@
## Gereedskap
Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare eenhede op te spoor:
Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare eenes op te spoor:
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Kyk ook na die checklist by [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
## Basiese Inligting
Op hierdie blad sal jy vind:
Op hierdie bladsy sal jy vind:
- 'n **opsomming van al die gevolge** wat 'n aanvaller kan hê indien hy toegang tot 'n Github Action kry
- Verskillende maniere om **toegang tot 'n action** te kry:
- Om **permissions** te hê om die action te skep
- Misbruik van **pull request** verwante triggers
- Misbruik van **ander eksterne toegang** tegnieke
- **Pivoting** vanuit 'n reeds gekompromitteerde repo
- Laastens, 'n afdeling oor **post-exploitation techniques to abuse an action from inside** (om die genoemde gevolge te veroorsaak)
- 'n **opsomming van al die impakte** van 'n aanvaller wat daarin slaag om toegang tot 'n Github Action te kry
- Verskillende maniere om **toegang tot 'n action te kry**:
- Om die **regte** te hê om die action te skep
- Misbruik van **pull request**-verwante triggers
- Misbruik van ander **eksterne toegang** tegnieke
- **Pivoting** van 'n reeds gekompromitteerde repo
- Laastens, 'n afdeling oor **post-exploitation techniques om 'n action van binne te misbruik** (om die genoemde impakte te veroorsaak)
## Opsomming van Gevolge
## Opsomming van impakte
For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
Vir 'n inleiding oor [**Github Actions: kyk na die basiese inligting**](../basic-github-information.md#github-actions).
Indien jy kan **execute arbitrary code in GitHub Actions** binne 'n **repository**, mag jy in staat wees om:
As jy daarin kan slaag om **arbitrêre kode in GitHub Actions uit te voer** binne 'n **repository**, mag jy die volgende kan doen:
- **Steal secrets** wat aan die pipeline gekoppel is en **abuse the pipeline's privileges** om ongemagtigde toegang tot eksterne platforms soos AWS en GCP te verkry.
- **Compromise deployments** en ander **artifacts**.
- As die pipeline assets ontplooi of stoor, kan jy die finale produk verander, wat 'n supply chain attack moontlik maak.
- **Execute code in custom workers** om rekenkrag te misbruik en na ander stelsels te pivot.
- **Overwrite repository code**, afhangende van die permissions geassosieer met die `GITHUB_TOKEN`.
- **Steel secrets** wat aan die pipeline gemonteer is en **misbruik die pipeline se voorregte** om ongemagtigde toegang tot eksterne platforms, soos AWS en GCP, te kry.
- **Benadeel deployments** en ander **artefakte**.
- As die pipeline assets deploy of stoor, kan jy die finale produk verander, wat 'n supply chain attack moontlik maak.
- **Voer kode uit in custom workers** om rekenkrag te misbruik en na ander stelsels te pivot.
- **Oorskryf repository-kode**, afhangende van die regte geassosieer met die `GITHUB_TOKEN`.
## GITHUB_TOKEN
Hierdie "**secret**" (afkomstig van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token }}`) word gegee wanneer die admin hierdie opsie aktiveer:
Hierdie "**secret**" (komende van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token }}`) word gegee wanneer die admin hierdie opsie aanskakel:
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
Hierdie token is dieselfde een wat 'n **Github Application** sal gebruik, dus kan dit toegang hê tot dieselfde endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
Hierdie token is dieselfde een wat 'n **Github Application sal gebruik**, so dit kan toegang tot dieselfde endpoints kry: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
> [!WARNING]
> Github behoort 'n [**flow**](https://github.com/github/roadmap/issues/74) vry te stel wat **allows cross-repository** toegang binne GitHub moontlik maak, sodat 'n repo ander interne repos kan bereik met die `GITHUB_TOKEN`.
> Github behoort 'n [**flow**](https://github.com/github/roadmap/issues/74) vry te stel wat **cross-repository** toegang binne GitHub toelaat, sodat 'n repo ander interne repos met die `GITHUB_TOKEN` kan toegang.
Jy kan die moontlike **permissions** van hierdie token sien by: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
Neem kennis dat die token **expires after the job has completed**.\
Sulke tokens lyk soos: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Let daarop dat die token **verval nadat die job voltooi is**.\
Hierdie tokens lyk soos: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Sommige interessante dinge wat jy met hierdie token kan doen:
Party interessante dinge wat jy met hierdie token kan doen:
{{#tabs }}
{{#tab name="Merge PR" }}
@@ -91,7 +91,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
{{#endtabs }}
> [!CAUTION]
> Let wel dat jy in verskeie gevalle **github user tokens inside Github Actions envs or in the secrets** kan vind. Hierdie tokens kan jou meer regte oor die repository en organisasie gee.
> Neem kennis dat jy in verskeie gevalle **github user tokens binne Github Actions envs of in die secrets** kan vind. Hierdie tokens kan jou meer voorregte oor die repository en organisasie gee.
<details>
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
Dit is moontlik om die permissies wat aan 'n Github Token in ander gebruikers repositories gegee is te kontroleer deur **die logs van die actions te kontroleer**:
Dit is moontlik om die permissies wat aan 'n Github Token in ander gebruikers se repositories gegee is, te kontroleer deur **die logs** van die actions na te gaan:
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
## Toegestane uitvoering
## Toegestane Uitvoering
> [!NOTE]
> Dit sou die maklikste manier wees om Github actions te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om **create a new repo in the organization**, of dat jy **write privileges over a repository** het.
> Dit sou die maklikste manier wees om Github actions te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om **'n nuwe repo in die organisasie te skep**, of **skryfregte oor 'n repository** te hê.
>
> As jy in hierdie scenario is, kan jy net die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) nagaan.
> As jy in hierdie scenario is, kan jy net die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) raadpleeg.
### Uitvoering vanaf repo-skepping
### Uitvoering vanaf Repo-skepping
Indien lede van 'n organisasie die vermoë het om **create new repos** en jy Github Actions kan uitvoer, kan jy **create a new repo and steal the secrets set at organization level**.
As lede van 'n organisasie **nuwe repos kan skep** en jy kan github actions uitvoer, kan jy **'n nuwe repo skep en die secrets wat op organisasievlak gestel is steel**.
### Uitvoering vanaf 'n nuwe branch
Indien jy kan **create a new branch in a repository that already contains a Github Action** wat reeds gekonfigureer is, kan jy dit **modify**, die inhoud **upload**, en dan daardie action **execute that action from the new branch**. Op hierdie manier kan jy **exfiltrate repository and organization level secrets** (maar jy moet weet hoe hulle genoem word).
As jy **'n nuwe branch in 'n repository wat reeds 'n Github Action bevat** kan skep, kan jy dit **wysig**, die inhoud **oplaai**, en dan daardie action **uitvoer vanaf die nuwe branch**. Op hierdie manier kan jy **exfiltrate repository and organization level secrets** (maar jy moet weet hoe hulle genoem word).
> [!WARNING]
> Enige beperking wat slegs binne die workflow YAML geïmplementeer is (byvoorbeeld, `on: push: branches: [main]`, job conditionals, of manual gates) kan deur medewerkers gewysig word. Sonder eksterne afdwinging (branch protections, protected environments, and protected tags), kan 'n bydraer 'n workflow herlei om op hul branch te loop en gemonteerde secrets/permissions misbruik.
> Enige beperking wat slegs binne die workflow YAML geïmplementeer is (byvoorbeeld, `on: push: branches: [main]`, job conditionals, of manual gates) kan deur medewerkers gewysig word. Sonder eksterne afdwinging (branch protections, protected environments, and protected tags), kan 'n bijdrager 'n workflow herrigting gee om op hul branch te loop en gemonteerde secrets/permissions misbruik.
Jy kan die gemodifiseerde action uitvoerbaar maak **manually,** wanneer 'n **PR is created** of wanneer **some code is pushed** (afhangend van hoe luidrugtig jy wil wees):
Jy kan die gewijzigde action uitvoerbaar maak **manueel,** wanneer 'n **PR is created** of wanneer **some code is pushed** (afhangend van hoe luidrugtig jy wil wees):
```yaml
on:
workflow_dispatch: # Launch manually
@@ -183,46 +183,46 @@ branches:
## Gevorkte Uitvoering
> [!NOTE]
> Daar is verskillende triggers wat 'n aanvaller kan toelaat om 'n Github Action van 'n ander repository uit te voer. As daardie triggerbare actions swak gekonfigureer is, kan 'n aanvaller dit kompromitteer.
> Daar is verskillende triggers wat 'n aanvaller kan toelaat om 'n **Github Action van 'n ander repository uit te voer**. As daardie triggerbare actions swak gekonfigureer is, kan 'n aanvaller dit compromise.
### `pull_request`
Die workflow-trigger **`pull_request`** sal die workflow elke keer uitvoer wanneer 'n pull request ontvang word, met 'n paar uitsonderings: standaard, as dit die **eerste keer** is dat jy **bydra**, sal 'n **maintainer** die **uitvoering** van die workflow moet **goedkeur**:
Die workflow-trigger **`pull_request`** sal die workflow elke keer uitvoer as 'n pull request ontvang word met sommige uitsonderings: standaard, as dit die **eerste keer** is dat jy **collaborating**, sal 'n **maintainer** die **run** van die workflow moet **approve**:
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
> [!NOTE]
> Aangesien die **standaardbeperking** vir **eerstetydse** bydraers is, kan jy 'n bydrae lewer deur 'n geldige fout/tipografiese fout te **regmaak** en dan **ander PRs stuur om jou nuwe `pull_request`-privilegies te misbruik**.
> Aangesien die **default limitation** vir **first-time** contributors geld, kan jy bydra deur 'n geldige bug/typo reg te stel en dan ander PRs stuur om jou nuwe `pull_request` privileges te abuse.
>
> **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.~~
> **Ek het dit getoets en dit werk nie**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
Boonop verhoed dit standaard **skryfpermissies** en **toegang tot secrets** tot die teiken repository soos in die [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) vermeld:
Boonop verhoed dit standaard **write permissions** en **secrets access** tot die teiken repository soos in die [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories) genoem:
> Met die uitsondering van `GITHUB_TOKEN`, **word secrets nie aan die runner oorgedra nie** wanneer 'n workflow vanaf 'n **forked** repository getrig word. Die **`GITHUB_TOKEN` het net lees-regte** in pull requests **van forked repositories**.
> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**.
'n Aanvaller kan die definisie van die Github Action wysig om arbitrêre dinge uit te voer en arbitrêre actions by te voeg. Hy sal egter weens die genoemde beperkings nie in staat wees om secrets te steel of die repo oor te skryf nie.
'n Aanvaller kan die definisie van die Github Action wysig om arbitrêre dinge uit te voer en arbitrêre actions by te voeg. Hy sal egter nie in staat wees om secrets te steel of die repo oor te skryf nie weens die genoemde beperkings.
> [!CAUTION]
> **Ja, as die aanvaller die github action in die PR verander wat getrig sal word, sal sy Github Action gebruik word en nie dié van die oorspronklike repo nie!**
> **Ja, as die aanvaller in die PR die github action verander wat ge-trigger 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, kan hy byvoorbeeld selfs al is daar geen secrets of skryfpermissies op die `GITHUB_TOKEN` nie, **malafide artifacts oplaai**.
Aangesien die aanvaller ook die kode wat uitgevoer word beheer, selfs al is daar geen secrets of write permissions op die `GITHUB_TOKEN` nie, kan 'n aanvaller byvoorbeeld **upload malicious artifacts**.
### **`pull_request_target`**
Die workflow-trigger **`pull_request_target`** het **skryfpermissie** op die teiken repository en **toegang tot secrets** (en vra nie toestemming nie).
Die workflow-trigger **`pull_request_target`** het **write permission** tot die teiken repository en **access to secrets** (en vra nie toestemming nie).
Let daarop dat die workflow-trigger **`pull_request_target`** **in die base-konteks loop** en nie in daardie wat deur die PR gegee word nie (om **nie onbetroubare kode uit te voer** nie). Vir meer inligting oor `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Boonop, vir meer inligting oor hierdie spesifieke gevaarlike gebruik kyk na hierdie [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
Neem kennis dat die workflow-trigger **`pull_request_target`** **in die base context loop** en nie in dié wat deur die PR verskaf word nie (om **nie onbetroubare kode uit te voer nie**). Vir meer inligting oor `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Boonop, vir meer inligting oor hierdie spesifieke gevaarlike gebruik, kyk na hierdie [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
Dit mag lyk asof dit veilig is om **`pull_request_target`** te gebruik omdat die **uitgevoerde workflow** dié is wat in die **base** gedefinieer is en nie in die PR nie, maar daar is 'n **paar gevalle waar dit nie so is nie**.
Dit mag lyk asofs dit veilig is om **`pull_request_target`** te gebruik omdat die **uitgevoerde workflow** dié is wat in die **base** gedefinieer is en **nie in die PR nie**, maar daar is 'n **paar gevalle waar dit nie so is nie**.
En hierdie een sal **toegang tot secrets** hê.
En hierdie een sal **access to secrets** hê.
### `workflow_run`
Die [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger maak dit moontlik om 'n workflow vanaf 'n ander een uit te voer wanneer dit `completed`, `requested` of `in_progress` is.
Die [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger laat toe dat 'n workflow vanaf 'n ander een loop wanneer dit `completed`, `requested` of `in_progress` is.
In hierdie voorbeeld is 'n workflow gekonfigureer om uit te voer nadat die aparte "Run Tests" workflow voltooi het:
In hierdie voorbeeld is 'n workflow gekonfigureer om te loop nadat die aparte "Run Tests" workflow voltooi is:
```yaml
on:
workflow_run:
@@ -230,26 +230,26 @@ workflows: [Run Tests]
types:
- completed
```
Boonop, volgens die docs: Die workflow wat deur die `workflow_run` event begin is, kan **toegang tot secrets kry en write tokens skryf, selfs al het die vorige workflow dit nie gekry nie**.
Boonop, volgens die docs: Die workflow wat deur die `workflow_run` event begin is, kan **access secrets and write tokens, even if the previous workflow was not**.
Hierdie tipe workflow kan aangeval word as dit **afhanklik** is van 'n **workflow** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** **getrigger** kan word. 'n Paar kwesbare voorbeelde kan in [**dié blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability) gevind word. Die eerste behels die deur die **`workflow_run`** getriggerde workflow wat die aanvaller se kode aflaai: `${{ github.event.pull_request.head.sha }}`\
Die tweede behels die deurgee van 'n **artifact** van die **untrusted** kode aan die **`workflow_run`** workflow en die gebruik van die inhoud van hierdie artifact op 'n wyse wat dit **vulnerable to RCE** maak.
Hierdie tipe workflow kan aangeval word as dit **afhanklik** is van 'n **workflow** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** **getrigger** kan word. 'n Paar kwesbare voorbeelde kan [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Die eerste een bestaan uit die deur **`workflow_run`** getriggerde workflow wat die aanvallers se code aflaai: `${{ github.event.pull_request.head.sha }}`\
Die tweede een bestaan uit **passing** 'n **artifact** van die **untrusted** code na die **`workflow_run`** workflow en die gebruik van die inhoud van hierdie artifact op 'n wyse wat dit **vulnerable to RCE** maak.
### `workflow_call`
TODO
TODO: Kyk of wanneer dit vanaf `pull_request` uitgevoer word, die gebruikte/afgelaaide kode dié van die origin is of dié van die geforkte PR
TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
## Abusing Forked Execution
## Misbruik van geforkte uitvoering
Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n GitHub workflow kan laat uitvoer; kom ons kyk nou hoe hierdie uitvoerings, as hulle sleg gekonfigureer is, misbruik kan word:
Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n github workflow kan laat uitvoer, kom ons kyk nou hoe hierdie uitvoerings, as hulle swak gekonfigureer is, misbruik kan word:
### Untrusted checkout execution
In die geval van **`pull_request`**, gaan die workflow in die **context of the PR** uitgevoer word (dus sal dit die **malicious PRs code** uitvoer), maar iemand moet dit eers **authorize** en dit sal met 'n paar [limitations](#pull_request) hardloop.
In die geval van **`pull_request`,** sal die workflow in die **konteks van die PR** uitgevoer word (dus sal dit die **malicious PRs code** uitvoer), maar iemand moet dit eers **authorize it first** en dit sal met sekere [limitations](#pull_request) loop.
In die geval van 'n workflow wat **`pull_request_target` or `workflow_run`** gebruik en afhanklik is van 'n workflow wat vanaf **`pull_request_target` or `pull_request`** getrigger kan word, sal die kode van die oorspronklike repo uitgevoer word, so die **attacker cannot control the executed code**.
In die geval van 'n workflow wat **`pull_request_target` or `workflow_run`** gebruik en wat afhang van 'n workflow wat vanaf **`pull_request_target` or `pull_request`** getrigger kan word, sal die code van die oorspronklike repo uitgevoer word, so die **attacker cannot control the executed code**.
> [!CAUTION]
> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded):
@@ -282,14 +282,14 @@ message: |
Thank you!
</code></pre>
Die potensieel **onbetroubare kode word tydens `npm install` of `npm build` uitgevoer** aangesien die build-skrifte en verwysde **packages deur die outeur van die PR beheer word**.
Die potensieel **untrusted code is being run during `npm install` or `npm build`** aangesien die build scripts en verwysde **packages are controlled by the author of the PR**.
> [!WARNING]
> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR).
### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
Neem kennis dat daar sekere [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) is waarvan die waardes deur die **user** wat die PR skep **beheer** word. As die github action daardie **data gebruik om enige iets uit te voer**, kan dit lei tot **arbitrary code execution:**
Neem kennis dat daar sekere [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) is wie se waardes deur die **user** wat die PR skep **controlled** word. As die github action daardie **data to execute anything** gebruik, kan dit lei tot **arbitrary code execution:**
{{#ref}}
gh-actions-context-script-injections.md
@@ -297,11 +297,11 @@ gh-actions-context-script-injections.md
### **GITHUB_ENV Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
Volgens die docs: Jy kan 'n **environment variable beskikbaar maak vir enige daaropvolgende stappe** in 'n workflow job deur die environment variable te definieer of by te werk en dit te skryf na die **`GITHUB_ENV`** environment file.
Volgens die docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file.
As 'n aanvaller enige waarde in hierdie **env** variable kan injekteer, kan hy env variables injekteer wat kode kan laat uitvoer in volgende stappe, soos **LD_PRELOAD** of **NODE_OPTIONS**.
As 'n aanvaller enige waarde kon **inject any value** binne hierdie **env** variable, kan hy env-variabeles inject wat kode in volgende stappe kan laat uitvoer soos **LD_PRELOAD** of **NODE_OPTIONS**.
Byvoorbeeld ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stel 'n workflow wat 'n opgelaaide artifact vertrou om sy inhoud in die **`GITHUB_ENV`** env variable te stoor. 'n Aanvaller kan iets soos dit oplaai om dit te kompromitteer:
Byvoorbeeld ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine 'n workflow wat 'n opgelaaide artifact vertrou om sy inhoud in die **`GITHUB_ENV`** env variable te stoor. 'n aanvaller kon iets soos hierdie oplaai om dit te kompromitteer:
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
@@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
Dit is 'n probleem omdat die `github.actor` veld die gebruiker bevat wat die jongste event wat die workflow getrigger het, veroorsaak het. En daar is verskeie maniere om die `dependabot[bot]` gebruiker 'n PR te laat wysig. Byvoorbeeld:
Dit is ’n probleem omdat die `github.actor`-veld die gebruiker bevat wat die jongste gebeurtenis veroorsaak het wat die workflow geaktiveer het. En daar is verskeie maniere om die `dependabot[bot]` gebruiker ’n PR te laat wysig. Byvoorbeeld:
- Fork die victim repository
- Add die malicious payload aan jou copy
- Enable Dependabot op jou fork deur 'n outdated dependency by te voeg. Dependabot sal 'n branch skep wat die dependency met malicious code regstel.
- Open 'n Pull Request na die victim repository vanaf daardie branch (die PR sal deur die user geskep word so niks sal nog gebeur nie)
- Dan gaan die attacker terug na die initial PR wat Dependabot in sy fork oopgemaak het en voer `@dependabot recreate` uit
- Dan voer Dependabot sekere aksies uit in daardie branch wat die PR oor die victim repo verander het, wat `dependabot[bot]` die actor maak van die jongste event wat die workflow getrigger het (en gevolglik loop die workflow).
- Fork die repository van die slagoffer
- Voeg die malicious payload by jou kopie
- Enable Dependabot op jou fork deur ’n outdated dependency by te voeg. Dependabot sal ’n branch skep wat die dependency regstel met malicious code.
- Open a Pull Request na die repository van die slagoffer vanaf daardie branch (die PR sal deur die gebruiker geskep word, so niks sal nog gebeur nie)
- Then, attacker gaan terug na die aanvanklike PR wat Dependabot in sy fork oopgemaak het en voer `@dependabot recreate` uit
- Then, Dependabot voer sekere aksies in daardie branch uit wat die PR oor die slagoffer-repo wysig, wat `dependabot[bot]` die actor maak van die jongste gebeurtenis wat die workflow geaktiveer het (en daarom hardloop die workflow).
Verder, wat as in plaas van merge die Github Action 'n command injection sou hê soos in:
Verder, wat as in plaas van merging die GitHub Action ’n command injection sou hê soos in:
```yaml
on: pull_request_target
jobs:
@@ -336,22 +336,22 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}
```
Wel, die oorspronklike blogpos stel twee opsies voor om hierdie gedrag te misbruik; die tweede is:
Die oorspronklike blogpos stel twee opsies voor om hierdie gedrag te misbruik; die tweede is:
- Fork die slagoffer repository en skakel Dependabot in met some outdated dependency.
- Fork die slagoffer repository en aktiveer Dependabot met 'n verouderde dependency.
- Skep 'n nuwe branch met die kwaadwillige shell injection code.
- Verander die standaardbranch van die repo na daardie een
- Verander die standaard branch van die repo na daardie een.
- Skep 'n PR vanaf hierdie branch na die slagoffer repository.
- Voer `@dependabot merge` uit in die PR wat Dependabot in his fork oopgemaak het.
- Dependabot sal sy veranderinge in die standaardbranch van jou geforkte repository saamvoeg, die PR in die slagoffer repository opdateer, en nou die `dependabot[bot]` die actor maak van die latest event wat die workflow getrigger het en 'n kwaadwillige branch name gebruik.
- Voer `@dependabot merge` uit in die PR wat Dependabot in sy fork oopgemaak het.
- Dependabot sal sy veranderings in die standaard-branch van jou geforkte repository mergen, die PR in die slagoffer-repository bywerk en sodoende maak dat `dependabot[bot]` die akteur word van die jongste gebeurtenis wat die workflow ge-trigger het, en 'n kwaadwillige branch-naam gebruik.
### Vulnerable Third Party Github Actions
### Kwetsbare Derdeparty GitHub Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
Soos genoem in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), laat hierdie Github Action toe om toegang te verkry tot artifacts van verskillende workflows en selfs repositories.
As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories.
Die probleem is dat as die **`path`** parameter nie gestel is nie, die artifact in die huidige gids uitgepak word en dit lêers kan oor-skryf wat later gebruik of selfs in die workflow uitgevoer kan word. Daarom, as die Artifact kwesbaar is, kan 'n aanvaller dit misbruik om ander workflows wat die Artifact vertrou, te kompromiteer.
Die probleem is dat as die **`path`** parameter nie gestel is nie, die artifact in die huidige gids uitgepak word en dit lêers kan oor skryf wat later gebruik of selfs in die workflow uitgevoer kan word. Dus, as die Artifact kwesbaar is, kan 'n aanvaller dit misbruik om ander workflows wat die Artifact vertrou, te kompromitteer.
Example of vulnerable workflow:
```yaml
@@ -376,7 +376,7 @@ with:
name: artifact
path: ./script.py
```
Dit kan aangeval word met hierdie workflow:
Hierdie kan aangeval word met hierdie workflow:
```yaml
name: "some workflow"
on: pull_request
@@ -395,25 +395,25 @@ path: ./script.py
## Ander Eksterne Toegang
### Verwyderde Namespace Repo Kaping
### Verwyderde Namespace Repo-oorname
If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
As 'n account sy naam verander, kan 'n ander gebruiker daardie naam ná 'n rukkie registreer. As 'n repository **voor die naamsverandering minder as 100 stars** gehad het, sal Github die nuwe geregistreerde gebruiker met dieselfde naam toelaat om 'n **repository met dieselfde naam** as die verwyderde een te skep.
> [!CAUTION]
> Dus, as 'n action 'n repo van 'n nie‑bestaanbare account gebruik, is dit steeds moontlik dat 'n attacker daardie account kan skep en die action kan kompromitteer.
> Dus, as 'n action 'n repo van 'n nie‑bestaan­de account gebruik, is dit steeds moontlik dat 'n attacker daardie account kan skep en die action kan kompromitteer.
If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
As ander repositories **dependencies from this user repos** gebruik het, sal 'n attacker dit kan kap. Hier is 'n meer volledige verduideliking: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
---
## Repo Pivoting
> [!NOTE]
> In hierdie afdeling sal ons praat oor tegnieke wat toelaat om **pivot from one repo to another** mits ons 'n soort toegang tot die eerste het (kyk die vorige afdeling).
> In hierdie afdeling sal ons praat oor tegnieke wat toelaat om **van een repo na 'n ander te pivot** op voorwaarde dat ons enige vorm van toegang op die eerste het (sien die vorige afdeling).
### Cache Poisoning
Daar word 'n cache onderhou tussen **wokflow runs in the same branch**. Dit beteken dat as 'n attacker 'n **package** kompromitteer wat dan in die cache gestoor word en deur 'n **more privileged** workflow **downloaded** en uitgevoer word, hy daardie workflow ook sal kan **compromise**.
Daar word 'n cache onderhou tussen **workflow runs in the same branch**. Dit beteken dat as 'n attacker 'n **package** kompromitteer wat dan in die cache gestoor word en deur 'n **meer bevoorregte** workflow **downloaded** en uitgevoer word, hy daardie workflow ook kan kompromitteer.
{{#ref}}
gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
### Artifact Poisoning
Workflows kan **artifacts from other workflows and even repos** gebruik. As 'n attacker daarin slaag om die Github Action wat **uploads an artifact** te **compromise**, en daardie artifact later deur 'n ander workflow gebruik word, kan hy **compromise the other workflows**:
Workflows kan **artifacts from other workflows and even repos** gebruik; as 'n attacker daarin slaag om die Github Action wat 'n **artifact upload** te kompromitteer — wat later deur 'n ander workflow gebruik word — kan hy die ander workflows ook **kompromitteer**:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -433,7 +433,7 @@ gh-actions-artifact-poisoning.md
### Github Action Policies Bypass
Soos in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) bespreek, selfs al het 'n repository of organization 'n policy wat die gebruik van sekere actions beperk, kan 'n attacker net die action binne die workflow download (`git clone`) en dit as 'n local action verwys. Aangesien die policies nie op local paths van toepassing is nie, sal die action sonder enige beperking uitgevoer word.
Soos in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass) bespreek, selfs al het 'n repository of organisasie 'n beleid wat die gebruik van sekere actions beperk, kan 'n attacker eenvoudig die action binne die workflow download (`git clone`) en dit as 'n local action verwys. Aangesien die beleidsreëls nie lokale paths raak nie, **sal die action sonder enige beperking uitgevoer word.**
Example:
```yaml
@@ -456,7 +456,7 @@ path: gha-hazmat
- run: ls tmp/checkout
```
### Toegang tot AWS en GCP via OIDC
### Toegang tot AWS, Azure en GCP via OIDC
Kyk na die volgende bladsye:
@@ -464,19 +464,23 @@ Kyk na die volgende bladsye:
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
{{#endref}}
{{#ref}}
../../../pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md
{{#endref}}
{{#ref}}
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
{{#endref}}
### Toegang tot geheime <a href="#accessing-secrets" id="accessing-secrets"></a>
### Toegang tot secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
As jy inhoud in 'n script inspuit, is dit nuttig om te weet hoe jy toegang tot geheime kan kry:
As jy inhoud in 'n script injekteer, is dit nuttig om te weet hoe jy toegang tot secrets kan kry:
- As die geheim of token op 'n **omgewingsveranderlike** gestel is, kan dit direk via die omgewing met **`printenv`** verkry word.
- As die secret of token op 'n **environment variable** gestel is, kan dit direk deur die omgewing geraadpleeg word met **`printenv`**.
<details>
<summary>Lys geheime in Github Action-uitset</summary>
<summary>Lys secrets in die Github Action-uitset</summary>
```yaml
name: list_env
on:
@@ -503,7 +507,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
<details>
<summary>Kry reverse shell met secrets</summary>
<summary>Kry reverse shell with secrets</summary>
```yaml
name: revshell
on:
@@ -526,15 +530,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
- As die secret gebruik word **direk in 'n uitdrukking**, word die gegenereerde shell-skrip **op-disk** gestoor en is dit toeganklik.
- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible.
- ```bash
cat /home/runner/work/_temp/*
```
- Vir JavaScript actions word die secrets deur environment variables gestuur
- For a JavaScript actions the secrets and sent through environment variables
- ```bash
ps axe | grep node
```
- Vir 'n **custom action**, kan die risiko wissel afhangend van hoe 'n program die secret gebruik wat dit vanaf die **argument** bekom het:
- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
```yaml
uses: fakeaction/publish@v3
@@ -542,7 +546,7 @@ with:
key: ${{ secrets.PUBLISH_KEY }}
```
- Som alle secrets op via die secrets context (collaborator level). 'n Contributor met write access kan 'n workflow op enige branch wysig om alle repository/org/environment secrets te dump. Gebruik dubbele base64 om GitHub’s log masking te omseil en decodeer plaaslik:
- Enumerate all secrets via the secrets context (collaborator level). A contributor with write access can modify a workflow on any branch to dump all repository/org/environment secrets. Use double base64 to evade GitHub’s log masking and decode locally:
```yaml
name: Steal secrets
@@ -558,31 +562,31 @@ run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
```
Dekodeer plaaslik:
Decode locally:
```bash
echo "ZXdv...Zz09" | base64 -d | base64 -d
```
Wenk: vir stealth tydens toetsing, enkripteer voor druk (openssl is preinstalled on GitHub-hosted runners).
Tip: for stealth during testing, encrypt before printing (openssl is preinstalled on GitHub-hosted runners).
### Misbruik van Self-hosted runners
Die manier om te vind watter **Github Actions in non-github infrastructure uitgevoer word** is om te soek na **`runs-on: self-hosted`** in die Github Action configuration yaml.
Die manier om te vind watter **Github Actions are being executed in non-github infrastructure** is om te soek na **`runs-on: self-hosted`** in die Github Action-konfigurasie yaml.
**Self-hosted** runners mag toegang hê tot **ekstra sensitiewe inligting**, tot ander **netwerkstelsels** (kwesbare endpunte in die netwerk? metadata service?) of, selfs as dit geïsoleer en vernietig word, **kan meer as een action terselfdertyd uitgevoer word** en die kwaadwillige een kan die **secrets** van die ander steel.
**Self-hosted** runners mag toegang hê tot **extra sensitive information**, tot ander **network systems** (vulnerable endpoints in the network? metadata service?) of, selfs as dit geïsoleer en vernietig word, kan **more than one action might be run at the same time** en die kwaadwillige een kan **steal the secrets** van die ander.
In self-hosted runners is dit ook moontlik om die **secrets from the \_Runner.Listener**\_\*\* process\*\* wat al die secrets van die workflows by enige stap sal bevat deur sy geheue te dump:
In self-hosted runners is dit ook moontlik om die **secrets from the \_Runner.Listener**\_\*\* process\*\* te bekom, wat alle geheime van die workflows by enige stap sal bevat deur sy geheue te dump:
```bash
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**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
Kyk na [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Github Docker Images Registry
### Github Docker Beelde-register
Dit is moontlik om Github actions te maak wat **'n Docker image binne Github bou en stoor**.\
'n Voorbeeld kan in die volgende inklapbare gedeelte gevind word:
Dit is moontlik om Github actions te skep wat **'n Docker image binne Github bou en stoor**.\
'n Voorbeeld kan gevind word in die volgende uitklapbare:
<details>
@@ -617,31 +621,31 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
```
</details>
Soos jy in die vorige kode kon sien, word die Github-register gehuisves op **`ghcr.io`**.
Soos jy in die vorige kode kon sien, is die Github registry gehost op **`ghcr.io`**.
'n Gebruiker met leesregte op die repo sal dan die Docker Image kan aflaai met behulp van 'n personal access token:
'n Gebruiker met leesregte oor die repo sal dan in staat wees om die Docker Image af te laai met 'n personal access token:
```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 **leaked secrets in die Docker image layers:**
Dan kan die gebruiker soek na **leaked secrets in the Docker image layers:**
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
{{#endref}}
### Sensitiewe inligting in Github Actions logs
### Gevoelige inligting in Github Actions logs
Selfs al probeer **Github** geheime waardes in die Github Actions logs opspoor en dit nie wys nie, sal **ander sensitiewe data** wat tydens die uitvoering van die action gegenereer is nie weggesteek word nie. Byvoorbeeld, 'n JWT wat met 'n geheime waarde onderteken is, sal nie weggesteek word nie tensy dit [spesifiek gekonfigureer](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) is.
Selfs al probeer **Github** **geheime waardes opspoor** in die actions logs en **dit nie wys nie**, sal **ander sensitiewe data** wat tydens die uitvoering van die action gegenereer is nie versteek word nie. Byvoorbeeld sal 'n JWT wat met 'n geheime waarde onderteken is, nie versteek word nie, tensy dit [spesifiek geconfigureer is](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
## Covering your Tracks
## Jou spore verberg
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Eerstens, enige PR wat ingedien word is duidelik sigbaar vir die publiek in Github en vir die geteikende GitHub-rekening. In GitHub kan ons standaard nie 'n PR van die internet verwyder nie, maar daar is 'n kink in die kabel. Vir Github-rekeninge wat deur Github **geskort** is, word al hul **PRs outomaties uitgevee** en van die internet verwyder. Dus, om jou aktiwiteit te verberg, moet jy óf jou **GitHub account suspended or get your account flagged**. Dit sou **al jou aktiwiteite** op GitHub van die internet verberg (basies al jou exploit PRs verwyder).
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Eerstens is enige PR wat opgestel word duidelik sigbaar vir die publiek op Github en vir die geteikende GitHub-rekening. In GitHub, standaard kan ons **nie 'n PR van die internet verwyder nie**, maar daar is 'n draai. Vir Github-rekeninge wat deur Github **geskort** is, word al hul **PRs outomaties uitgevee** en van die internet verwyder. Dus, om jou aktiwiteit te verberg, moet jy óf jou **GitHub account suspended kry of jou rekening laat flagged word**. Dit sal **al jou aktiwiteite** op GitHub van die internet verberg (basies al jou exploit PR verwyder).
'n Organisasie op GitHub is baie proaktief in die rapporteer van rekeninge aan GitHub. Alles wat jy hoef te doen is om “some stuff” in 'n Issue te deel en hulle sal seker maak jou rekening binne 12 uur geskors is :p en daar het jy dit — jou exploit onsigbaar op github gemaak.
'n Organisasie op GitHub is baie proaktief daarin om rekeninge by GitHub aan te meld. Alles wat jy hoef te doen is om “some stuff” in 'n Issue te deel en hulle sal sorg dat jou rekening binne 12 uur geskors word :p en daar het jy dit — jou exploit onsigbaar op github gemaak.
> [!WARNING]
> Die enigste manier vir 'n organisasie om uit te vind dat hulle geteiken is, is om GitHub logs van SIEM na te gaan aangesien die PR vanaf die GitHub UI verwyder sou wees.
> Die enigste manier vir 'n organisasie om te agterkom dat hulle geteiken is, is om GitHub-logs in SIEM na te gaan aangesien die PR vanaf die GitHub UI verwyder sal word.
## Verwysings