mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-24 20:10:16 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## Basiese Inligting
|
||||
|
||||
In hierdie bladsy sal jy vind:
|
||||
Op hierdie bladsy sal jy vind:
|
||||
|
||||
- 'n **opsomming van al die impakte** van 'n aanvaller wat daarin slaag om toegang tot 'n Github Action te verkry
|
||||
- Verskillende maniere om **toegang tot 'n aksie** te verkry:
|
||||
@@ -12,19 +12,19 @@ In hierdie bladsy sal jy vind:
|
||||
- Misbruik van **pull request** verwante triggers
|
||||
- Misbruik van **ander eksterne toegang** tegnieke
|
||||
- **Pivoting** vanaf 'n reeds gecompromitteerde repo
|
||||
- Laastens, 'n afdeling oor **post-exploitatie tegnieke om 'n aksie van binne te misbruik** (want die genoem impakte)
|
||||
- Laastens, 'n afdeling oor **post-exploitatie tegnieke om 'n aksie van binne te misbruik** (om die genoem impakte te veroorsaak)
|
||||
|
||||
## Impakte Opsomming
|
||||
## Opsomming van Impakte
|
||||
|
||||
Vir 'n inleiding oor [**Github Actions kyk na die basiese inligting**](../basic-github-information.md#github-actions).
|
||||
|
||||
As jy **arbitraire kode in GitHub Actions** binne 'n **repository** kan **uitvoer**, mag jy in staat wees om:
|
||||
As jy **arbitraire kode in GitHub Actions** binne 'n **repo** kan **uitvoer**, mag jy in staat wees om:
|
||||
|
||||
- **Geheime** wat aan die pyplyn gekoppel is te **steel** en die **privileges van die pyplyn te misbruik** om ongeoorloofde toegang tot eksterne platforms, soos AWS en GCP, te verkry.
|
||||
- **Ontplooiings** en ander **artefakte** te **kompromitteer**.
|
||||
- As die pyplyn bates ontplooi of stoor, kan jy die finale produk verander, wat 'n voorsieningskettingaanval moontlik maak.
|
||||
- **Kode in pasgemaakte werkers** uit te voer om rekenaarkrag te misbruik en na ander stelsels te pivot.
|
||||
- **Repository kode te oorskryf**, afhangende van die toestemmings wat met die `GITHUB_TOKEN` geassosieer is.
|
||||
- **Repo-kode te oorskryf**, afhangende van die toestemmings wat met die `GITHUB_TOKEN` geassosieer is.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
@@ -35,11 +35,11 @@ Hierdie "**geheim**" (kom van `${{ secrets.GITHUB_TOKEN }}` en `${{ github.token
|
||||
Hierdie token is dieselfde een wat 'n **Github Toepassing sal gebruik**, sodat dit toegang tot dieselfde eindpunte kan hê: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
|
||||
> [!WARNING]
|
||||
> Github moet 'n [**vloei**](https://github.com/github/roadmap/issues/74) vrystel wat **kruis-repository** toegang binne GitHub toelaat, sodat 'n repo ander interne repos met die `GITHUB_TOKEN` kan benader.
|
||||
> Github moet 'n [**vloei**](https://github.com/github/roadmap/issues/74) vrystel wat **kruis-repo** toegang binne GitHub toelaat, sodat 'n repo ander interne repos met die `GITHUB_TOKEN` kan benader.
|
||||
|
||||
Jy kan die moontlike **toestemmings** van hierdie token sien in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
|
||||
|
||||
Let daarop dat die token **verval nadat die werk voltooi is**.\
|
||||
Let daarop dat die token **verval nadat die taak voltooi is**.\
|
||||
Hierdie tokens lyk soos volg: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
|
||||
|
||||
Sommige interessante dinge wat jy met hierdie token kan doen:
|
||||
@@ -56,7 +56,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
|
||||
-d "{\"commit_title\":\"commit_title\"}"
|
||||
```
|
||||
{{#endtab }}
|
||||
{{#tab name="Goedkeur PR" }}
|
||||
{{#tab name="Approve PR" }}
|
||||
```bash
|
||||
# Approve a PR
|
||||
curl -X POST \
|
||||
@@ -85,7 +85,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
|
||||
<details>
|
||||
|
||||
<summary>lys geheime in Github Action uitvoer</summary>
|
||||
<summary>lys geheime in Github Action-uitset</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -141,17 +141,17 @@ Dit is moontlik om die toestemmings wat aan 'n Github Token gegee is in ander ge
|
||||
## Toegelate Uitvoering
|
||||
|
||||
> [!NOTE]
|
||||
> Dit sou die maklikste manier wees om Github aksies te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om **'n nuwe repo in die organisasie te skep**, of **skryfregte oor 'n repository** het.
|
||||
> Dit sou die maklikste manier wees om Github aksies te kompromitteer, aangesien hierdie geval veronderstel dat jy toegang het om **nuwe repo in die organisasie te skep**, of **skryfregte oor 'n repository** het.
|
||||
>
|
||||
> As jy in hierdie scenario is, kan jy net die [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action) kontroleer.
|
||||
> As jy in hierdie scenario is, kan jy net die [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action) kontroleer.
|
||||
|
||||
### Uitvoering vanaf Repo Skepping
|
||||
|
||||
In die geval dat lede van 'n organisasie **nuwe repos kan skep** en jy kan github aksies uitvoer, kan jy **'n nuwe repo skep en die geheime wat op organisasievlak gestel is, steel**.
|
||||
In die geval dat lede van 'n organisasie **nuwe repos** kan **skep** en jy kan github aksies uitvoer, kan jy **nuwe repo skep en die geheime wat op organisasievlak gestel is, steel**.
|
||||
|
||||
### Uitvoering vanaf 'n Nuwe Tak
|
||||
|
||||
As jy **'n nuwe tak in 'n repository wat reeds 'n Github Action** geconfigureer het, kan jy dit **wysig**, die inhoud **oplaai**, en dan **daardie aksie vanaf die nuwe tak uitvoer**. Op hierdie manier kan jy **repository en organisasievlak geheime** **uitvoer** (maar jy moet weet hoe hulle genoem word).
|
||||
As jy **n nuwe tak in 'n repository wat reeds 'n Github Action** geconfigureer het, kan **skep**, kan jy dit **wysig**, die inhoud **oplaai**, en dan **daardie aksie vanaf die nuwe tak uitvoer**. Op hierdie manier kan jy **repository en organisasievlak geheime** **uitvoer** (maar jy moet weet hoe hulle genoem word).
|
||||
|
||||
Jy kan die gewysigde aksie **handmatig** uitvoerbaar maak, wanneer 'n **PR geskep word** of wanneer **enige kode gepush word** (afhangende van hoe luidrugtig jy wil wees):
|
||||
```yaml
|
||||
@@ -183,7 +183,7 @@ Die werksvloei-trigger **`pull_request`** sal die werksvloei uitvoer elke keer a
|
||||
>
|
||||
> **Ek het dit getoets en dit werk nie**: ~~Nog 'n opsie sou wees om 'n rekening te skep met die naam van iemand wat by die projek bygedra het en sy rekening te verwyder.~~
|
||||
|
||||
Boonop **voorkom dit standaard skryfrechten** en **toegang tot geheime** tot die teikrepository soos genoem in die [**dokumentasie**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
Boonop, standaard **voorkom skryfrechten** en **geheime toegang** tot die teikengebruikersrepo soos genoem in die [**dokumentasie**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> Met die uitsondering van `GITHUB_TOKEN`, **word geheime nie aan die hardeware oorgedra** wanneer 'n werksvloei geaktiveer word vanaf 'n **forked** repository. Die **`GITHUB_TOKEN` het lees-slegs regte** in pull requests **van forked repositories**.
|
||||
|
||||
@@ -192,11 +192,11 @@ Boonop **voorkom dit standaard skryfrechten** en **toegang tot geheime** tot die
|
||||
> [!CAUTION]
|
||||
> **Ja, as die aanvaller in die PR die github action wat geaktiveer sal word, verander, sal sy Github Action die een wees wat gebruik word en nie die een van die oorspronklike repo nie!**
|
||||
|
||||
Aangesien die aanvaller ook die kode wat uitgevoer word, beheer, selfs al is daar geen geheime of skryfrechten op die `GITHUB_TOKEN` nie, kan 'n aanvaller byvoorbeeld **kwaadaardige artefakte oplaai**.
|
||||
Aangesien die aanvaller ook die kode wat uitgevoer word, beheer, selfs al is daar geen geheime of skryfrechten op die `GITHUB_TOKEN` nie, kan 'n aanvaller byvoorbeeld **kwaadwillige artefakte oplaai**.
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
Die werksvloei-trigger **`pull_request_target`** het **skryfrechten** tot die teikrepository en **toegang tot geheime** (en vra nie vir toestemming nie).
|
||||
Die werksvloei-trigger **`pull_request_target`** het **skryfrechten** tot die teikengebruikersrepo en **toegang tot geheime** (en vra nie vir toestemming nie).
|
||||
|
||||
Let daarop dat die werksvloei-trigger **`pull_request_target`** **in die basis konteks** loop en nie in die een gegee deur die PR nie (om **nie onbetroubare kode uit te voer**). Vir meer inligting oor `pull_request_target` [**kyk die dokumentasie**](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 hierdie [**github blog pos**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
@@ -209,7 +209,7 @@ En hierdie een sal **toegang tot geheime** hê.
|
||||
|
||||
Die [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger laat toe om 'n werksvloei van 'n ander een te laat loop wanneer dit `voltooi`, `gevraag` of `in_progress` is.
|
||||
|
||||
In hierdie voorbeeld is 'n werksvloei geconfigureer om te loop nadat die aparte "Toets Loop" werksvloei voltooi is:
|
||||
In hierdie voorbeeld is 'n werksvloei geconfigureer om te loop nadat die aparte "Toetse Loop" werksvloei voltooi is:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -234,14 +234,14 @@ Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n github werksvloei
|
||||
|
||||
### Onbetroubare checkout uitvoering
|
||||
|
||||
In die geval van **`pull_request`,** sal die werksvloei in die **konteks van die PR** uitgevoer word (so dit sal die **kwaadaardige PR se kode** uitvoer), maar iemand moet dit **eers goedkeur** en dit sal met 'n paar [beperkings](./#pull_request) loop.
|
||||
In die geval van **`pull_request`,** sal die werksvloei in die **konteks van die PR** uitgevoer word (so dit sal die **kwesbare PR se kode** uitvoer), maar iemand moet dit **eers goedkeur** en dit sal met 'n paar [beperkings](#pull_request) loop.
|
||||
|
||||
In die geval van 'n werksvloei wat **`pull_request_target` of `workflow_run`** gebruik wat afhang van 'n werksvloei wat vanaf **`pull_request_target` of `pull_request`** geaktiveer kan word, sal die kode van die oorspronklike repo uitgevoer word, so die **aanvaller kan nie die uitgevoerde kode beheer nie**.
|
||||
In die geval van 'n werksvloei wat **`pull_request_target` of `workflow_run`** gebruik wat afhang van 'n werksvloei wat geaktiveer kan word vanaf **`pull_request_target` of `pull_request`** sal die kode van die oorspronklike repo uitgevoer word, so die **aanvaller kan nie die uitgevoerde kode beheer nie**.
|
||||
|
||||
> [!CAUTION]
|
||||
> egter, as die **aksie** 'n **duidelike PR checkout** het wat **die kode van die PR** (en nie van die basis nie) sal **kry**, sal dit die aanvaller se beheerde kode gebruik. Byvoorbeeld (kyk na lyn 12 waar die PR kode afgelaai word):
|
||||
|
||||
<pre class="language-yaml"><code class="lang-yaml"># ONVEILIG. Verskaf net as 'n voorbeeld.
|
||||
<pre class="language-yaml"><code class="lang-yaml"># ONBEVEILIG. Verskaf slegs as 'n voorbeeld.
|
||||
on:
|
||||
pull_request_target
|
||||
|
||||
@@ -272,7 +272,7 @@ Dankie!
|
||||
Die potensieel **onbetroubare kode word tydens `npm install` of `npm build`** uitgevoer aangesien die bou skripte en verwysde **pakkette deur die outeur van die PR** beheer word.
|
||||
|
||||
> [!WARNING]
|
||||
> 'n github dork om vir kwesbare aksies te soek is: `event.pull_request pull_request_target extension:yml` egter, daar is verskillende maniere om die werksvloei veilig uit te voer selfs al is die aksie onveilig geconfigureer (soos om voorwaardes te gebruik oor wie die akteur is wat die PR genereer).
|
||||
> 'n github dork om vir kwesbare aksies te soek is: `event.pull_request pull_request_target extension:yml` egter, daar is verskillende maniere om die werksgeleenthede veilig uit te voer selfs al is die aksie onveilig geconfigureer (soos om voorwaardes te gebruik oor wie die akteur is wat die PR genereer).
|
||||
|
||||
### Konteks Skrip Injekties <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
@@ -286,7 +286,7 @@ gh-actions-context-script-injections.md
|
||||
|
||||
Volgens die dokumentasie: Jy kan 'n **omgewing veranderlike beskikbaar maak vir enige daaropvolgende stappe** in 'n werksvloei taak deur die omgewing veranderlike te definieer of op te dateer en dit na die **`GITHUB_ENV`** omgewing lêer te skryf.
|
||||
|
||||
As 'n aanvaller **enige waarde** binne hierdie **env** veranderlike kan **injekteer**, kan hy env veranderlikes inplant wat kode in daaropvolgende stappe kan uitvoer soos **LD_PRELOAD** of **NODE_OPTIONS**.
|
||||
As 'n aanvaller **enige waarde** binne hierdie **env** veranderlike kan **injekteer**, kan hy env veranderlikes inbring wat kode in daaropvolgende stappe kan uitvoer soos **LD_PRELOAD** of **NODE_OPTIONS**.
|
||||
|
||||
Byvoorbeeld ([**hierdie**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) en [**hierdie**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), stel jou voor 'n werksvloei wat 'n geuploade artefak vertrou om sy inhoud binne die **`GITHUB_ENV`** env veranderlike te stoor. 'n Aanvaller kan iets soos dit oplaai om dit te kompromitteer:
|
||||
|
||||
@@ -349,7 +349,7 @@ As 'n rekening sy naam verander, kan 'n ander gebruiker 'n rekening met daardie
|
||||
> [!CAUTION]
|
||||
> So as 'n aksie 'n repo van 'n nie-bestaande rekening gebruik, is dit steeds moontlik dat 'n aanvaller daardie rekening kan skep en die aksie kan kompromitteer.
|
||||
|
||||
As ander repositories **afhang van hierdie gebruiker se repos**, sal 'n aanvaller in staat wees om hulle te 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/)
|
||||
As ander repositories **afhang van hierdie gebruiker se repos**, sal 'n aanvaller in staat wees om hulle te hijack. Hier is 'n meer volledige verduideliking: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
|
||||
|
||||
---
|
||||
|
||||
@@ -456,7 +456,7 @@ cat /home/runner/work/_temp/*
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- Vir 'n **aangepaste aksie** kan die risiko wissel, afhangende van hoe 'n program die geheim wat dit van die **argument** verkry het, gebruik:
|
||||
- Vir 'n **aangepaste aksie** kan die risiko verskil, afhangende van hoe 'n program die geheim wat dit van die **argument** verkry het, gebruik:
|
||||
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
@@ -468,14 +468,14 @@ key: ${{ secrets.PUBLISH_KEY }}
|
||||
|
||||
Die manier om te vind watter **Github Actions in nie-github infrastruktuur** uitgevoer word, is om te soek na **`runs-on: self-hosted`** in die Github Action konfigurasie yaml.
|
||||
|
||||
**Self-gehoste** lopers mag toegang hê tot **ekstra sensitiewe inligting**, na ander **netwerkstelsels** (kwesbare eindpunte in die netwerk? metadata diens?) of, selfs al is dit geïsoleer en vernietig, kan **meer as een aksie gelyktydig uitgevoer word** en die kwaadwillige een kan die **geheime** van die ander steel.
|
||||
**Self-gehoste** lopers mag toegang hê tot **ekstra sensitiewe inligting**, na ander **netwerkstelsels** (kwesbare eindpunte in die netwerk? metadata diens?) of, selfs al is dit geïsoleer en vernietig, kan **meer as een aksie terselfdertyd uitgevoer word** en die kwaadwillige een kan die **geheime** van die ander steel.
|
||||
|
||||
In self-gehoste lopers is dit ook moontlik om die **geheime van die \_Runner.Listener**\_\*\* proses\*\* te verkry wat al die geheime van die werksvloei op enige stap sal bevat deur sy geheue te dump:
|
||||
In self-gehoste lopers is dit ook moontlik om die **geheime van die \_Runner.Listener**\_\*\* proses\*\* te verkry, wat al die geheime van die werksvloei op enige stap sal bevat deur sy geheue te dump:
|
||||
```bash
|
||||
sudo apt-get install -y gdb
|
||||
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
|
||||
```
|
||||
Kontroleer [**hierdie pos vir meer inligting**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
|
||||
Kontrollere [**hierdie pos vir meer inligting**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
|
||||
|
||||
### Github Docker Beeld Registrasie
|
||||
|
||||
@@ -484,7 +484,7 @@ Dit is moontlik om Github aksies te maak wat **'n Docker beeld binne Github bou
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Github Aksie Bou & Stoot Docker Beeld</summary>
|
||||
<summary>Github Aksie Bou & Stoot Docker Beeld</summary>
|
||||
```yaml
|
||||
[...]
|
||||
|
||||
@@ -525,7 +525,7 @@ docker pull ghcr.io/<org-name>/<repo_name>:<tag>
|
||||
Dan kan die gebruiker **gelekte geheime in die Docker beeld lae soek:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### Sensitiewe inligting in Github Actions logs
|
||||
@@ -534,9 +534,9 @@ Selfs al probeer **Github** om **geheime waardes** in die aksies logs te **ontde
|
||||
|
||||
## Bedek jou Spore
|
||||
|
||||
(Tegniek van [**hier**](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 teiken GitHub rekening. In GitHub kan ons **nie 'n PR van die internet verwyder** nie, maar daar is 'n draai. Vir GitHub rekeninge wat deur Github **gesuspend** is, word al hul **PRs outomaties verwyder** en van die internet verwyder. So om jou aktiwiteit te verberg, moet jy jou **GitHub rekening gesuspendeer kry of jou rekening geflag** kry. Dit sal **al jou aktiwiteite** op GitHub van die internet verberg (basies al jou eksploit PR verwyder)
|
||||
(Tegniek van [**hier**](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 teiken GitHub rekening. In GitHub kan ons **nie 'n PR van die internet verwyder** nie, maar daar is 'n draai. Vir GitHub rekeninge wat **gesuspend** is deur Github, word al hul **PRs outomaties verwyder** en van die internet verwyder. So om jou aktiwiteit te verberg, moet jy jou **GitHub rekening gesuspend of jou rekening geflag** kry. Dit sal **al jou aktiwiteite** op GitHub van die internet verberg (basies al jou eksploit PR verwyder)
|
||||
|
||||
'n Organisasie in GitHub is baie proaktief in die verslagdoening van rekeninge aan GitHub. Alles wat jy moet doen, is om "iets" in 'n Issue te deel en hulle sal seker maak jou rekening word binne 12 uur gesuspend :p en daar het jy, jou eksploit onsigbaar gemaak op github.
|
||||
'n Organisasie in GitHub is baie proaktief in die verslagdoening van rekeninge aan GitHub. Alles wat jy moet doen, is om "iets" in 'n Issue te deel en hulle sal seker maak jou rekening word binne 12 uur gesuspend :p en daar het jy, jou eksploit op github onsigbaar gemaak.
|
||||
|
||||
> [!WARNING]
|
||||
> Die enigste manier vir 'n organisasie om uit te vind dat hulle geteiken is, is om GitHub logs van SIEM te kontroleer, aangesien die PR van die GitHub UI verwyder sal word.
|
||||
|
||||
Reference in New Issue
Block a user