mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-25 04:15:49 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -12,7 +12,7 @@ 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** (om die genoem impakte te veroorsaak)
|
||||
- Laastens, 'n afdeling oor **post-exploitatie tegnieke om 'n aksie van binne te misbruik** (want die genoem impakte)
|
||||
|
||||
## Impakte Opsomming
|
||||
|
||||
@@ -20,7 +20,7 @@ Vir 'n inleiding oor [**Github Actions kyk na die basiese inligting**](../basic-
|
||||
|
||||
As jy **arbitraire kode in GitHub Actions** binne 'n **repository** 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.
|
||||
- **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.
|
||||
@@ -81,7 +81,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> Let daarop dat jy in verskeie gevalle **github gebruikers tokens binne Github Actions omgewings of in die geheime** sal vind. Hierdie tokens kan jou meer voorregte oor die repository en organisasie gee.
|
||||
> Let daarop dat jy in verskeie gevalle **github gebruikers tokens binne Github Actions omgewings of in die geheime** sal kan vind. Hierdie tokens kan jou meer voorregte oor die repository en organisasie gee.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -143,7 +143,7 @@ Dit is moontlik om die toestemmings wat aan 'n Github Token gegee is in ander ge
|
||||
> [!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.
|
||||
>
|
||||
> 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) kontroleer.
|
||||
|
||||
### Uitvoering vanaf Repo Skepping
|
||||
|
||||
@@ -151,9 +151,9 @@ In die geval dat lede van 'n organisasie **nuwe repos kan skep** en jy kan githu
|
||||
|
||||
### Uitvoering vanaf 'n Nuwe Tak
|
||||
|
||||
As jy **'n nuwe tak in 'n repository kan skep 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 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 uitvoerbaar maak **handmatig,** wanneer 'n **PR geskep word** of wanneer **enige kode gepush word** (afhangende van hoe luidrugtig jy wil wees):
|
||||
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
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
@@ -170,33 +170,33 @@ branches:
|
||||
## Forked 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 aksies swak geconfigureer is, kan 'n aanvaller in staat wees om hulle te kompromitteer.
|
||||
> Daar is verskillende triggers wat 'n aanvaller kan toelaat om 'n **Github Action van 'n ander repository** te **uitvoer**. As daardie triggerbare aksies swak geconfigureer is, kan 'n aanvaller in staat wees om hulle te kompromitteer.
|
||||
|
||||
### `pull_request`
|
||||
|
||||
Die werksvloei-trigger **`pull_request`** sal die werksvloei elke keer uitvoer wanneer 'n pull request ontvang word met 'n paar uitsonderings: standaard, as dit die **eerste keer** is dat jy **saamwerk**, sal 'n **onderhouer** die **uitvoering** van die werksvloei moet **goedkeur**:
|
||||
Die werksvloei-trigger **`pull_request`** sal die werksvloei uitvoer elke keer as 'n pull request ontvang word met 'n paar uitsonderings: standaard, as dit die **eerste keer** is dat jy **saamwerk**, sal 'n **onderhouer** die **uitvoering** van die werksvloei moet **goedkeur**:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> Aangesien die **standaard beperking** vir **eerste keer** bydraers is, kan jy **bydra tot die regstelling van 'n geldige fout/typo** en dan **ander PRs stuur om jou nuwe `pull_request` voorregte te misbruik**.
|
||||
> Aangesien die **standaard beperking** vir **eerste keer** bydraers is, kan jy bydrae **deur 'n geldige fout/typo te herstel** en dan **ander PRs stuur om jou nuwe `pull_request` voorregte te misbruik**.
|
||||
>
|
||||
> **Ek het dit getoets en dit werk nie**: ~~‘n Ander 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**: ~~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 **verhoed dit standaard skryfrechten** en **toegang tot geheime** tot die teikengebruikersrepo soos genoem in die [**dokumentasie**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
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):
|
||||
|
||||
> Met die uitsondering van `GITHUB_TOKEN`, **word geheime nie aan die hardloper oorgedra** wanneer 'n werksvloei van 'n **forked** repository geaktiveer word nie. Die **`GITHUB_TOKEN` het slegs leesregte** in pull requests **van 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**.
|
||||
|
||||
'n Aanvaller kan die definisie van die Github Action wysig om arbitrêre dinge uit te voer en arbitrêre aksies by te voeg. Hy sal egter nie in staat wees om geheime te steel of die repo te oorskryf nie weens die genoem beperkings.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Ja, as die aanvaller die github action in die PR verander wat geaktiveer sal word, sal sy Github Action die een wees wat gebruik word en nie die een van die oorspronklike repo nie!**
|
||||
> **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**.
|
||||
|
||||
### **`pull_request_target`**
|
||||
|
||||
Die werksvloei-trigger **`pull_request_target`** het **skryfrechten** tot die teikengebruikersrepo en **toegang tot geheime** (en vra nie vir toestemming nie).
|
||||
Die werksvloei-trigger **`pull_request_target`** het **skryfrechten** tot die teikrepository 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/).
|
||||
@@ -207,9 +207,9 @@ En hierdie een sal **toegang tot geheime** 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 werksvloei van 'n ander een uit te voer wanneer dit `voltooi`, `gevraag` of `in_progress` is.
|
||||
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 uit te voer nadat die aparte "Toets Hardloop" werksvloei voltooi is:
|
||||
In hierdie voorbeeld is 'n werksvloei geconfigureer om te loop nadat die aparte "Toets Loop" werksvloei voltooi is:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -217,9 +217,9 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Moreover, according to the docs: Die werksvloei wat deur die `workflow_run` gebeurtenis begin is, kan **toegang tot geheime hê en tokens skryf, selfs al was die vorige werksvloei nie**.
|
||||
Boonop, volgens die dokumentasie: Die werksvloei wat deur die `workflow_run` gebeurtenis begin is, kan **toegang tot geheime hê en tokens skryf, selfs al was die vorige werksvloei nie**.
|
||||
|
||||
Hierdie tipe werksvloei kan aangeval word as dit **afhang** van 'n **werksvloei** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** geaktiveer kan word. 'n Paar kwesbare voorbeelde kan [**hierdie blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)** gevind word.** Die eerste een bestaan uit die **`workflow_run`** geaktiveerde werksvloei wat die aanvallerskode aflaai: `${{ github.event.pull_request.head.sha }}`\
|
||||
Hierdie tipe werksvloei kan aangeval word as dit **afhang** van 'n **werksvloei** wat deur 'n eksterne gebruiker via **`pull_request`** of **`pull_request_target`** geaktiveer kan word. 'n Paar kwesbare voorbeelde kan [**in hierdie blog gevind word**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Die eerste een bestaan uit die **`workflow_run`** geaktiveerde werksvloei wat die aanvaller se kode aflaai: `${{ github.event.pull_request.head.sha }}`\
|
||||
Die tweede een bestaan uit **die oordrag** van 'n **artefak** van die **onbetroubare** kode na die **`workflow_run`** werksvloei en die gebruik van die inhoud van hierdie artefak op 'n manier wat dit **kwesbaar maak vir RCE**.
|
||||
|
||||
### `workflow_call`
|
||||
@@ -230,18 +230,18 @@ TODO: Kontroleer of wanneer dit vanaf 'n pull_request uitgevoer word, die gebrui
|
||||
|
||||
## Misbruik van Geforkte Uitvoering
|
||||
|
||||
Ons het al die maniere genoem hoe 'n eksterne aanvaller 'n github werksvloei kan laat uitvoer, kom ons kyk nou na hoe hierdie uitvoerings, as dit sleg geconfigureer is, misbruik kan word:
|
||||
Ons het al die maniere genoem waarop 'n eksterne aanvaller 'n github werksvloei kan laat uitvoer, kom ons kyk nou na hoe hierdie uitvoerings, as dit sleg geconfigureer is, misbruik kan word:
|
||||
|
||||
### Onbetroubare checkout uitvoering
|
||||
|
||||
In die geval van **`pull_request`,** sal die werksvloei in die **konsep 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 **`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 '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**.
|
||||
|
||||
> [!CAUTION]
|
||||
> egter, as die **aksie** 'n **duidelike PR checkout** het wat **die kode van die PR** sal **kry** (en nie van die basis nie), sal dit die aanvallers beheerde kode gebruik. Byvoorbeeld (kyk na lyn 12 waar die PR kode afgelaai word):
|
||||
> 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. Slegs as 'n voorbeeld verskaf.
|
||||
<pre class="language-yaml"><code class="lang-yaml"># ONVEILIG. Verskaf net 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 werksgeleenthede te konfigureer om veilig uitgevoer te word 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 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).
|
||||
|
||||
### Konteks Skrip Injekties <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
@@ -282,13 +282,13 @@ Let daarop dat daar sekere [**github kontekste**](https://docs.github.com/en/act
|
||||
gh-actions-context-script-injections.md
|
||||
{{#endref}}
|
||||
|
||||
### **GITHUB_ENV Skrip Injekie** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
### **GITHUB_ENV Skrip Injektion** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
|
||||
|
||||
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 injekteer 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 inplant 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 geupload artefak vertrou om sy inhoud binne die **`GITHUB_ENV`** env veranderlike te stoor. 'n Aanvaller kan iets soos dit oplaai om dit te kompromitteer:
|
||||
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:
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -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 **afhangklikhede van hierdie gebruiker repos** gebruik, 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/)
|
||||
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/)
|
||||
|
||||
---
|
||||
|
||||
@@ -360,7 +360,7 @@ As ander repositories **afhangklikhede van hierdie gebruiker repos** gebruik, sa
|
||||
|
||||
### Cache Poisoning
|
||||
|
||||
'n Cache word tussen **workflow-uitvoerings in dieselfde tak** gehandhaaf. Dit beteken dat as 'n aanvaller **kompromitteer** 'n **pakket** wat dan in die cache gestoor word en **afgelaai** en uitgevoer word deur 'n **meer bevoorregte** workflow, hy ook daardie workflow sal kan **kompromitteer**.
|
||||
'n Cache word tussen **workflow-runs in dieselfde tak** gehandhaaf. Dit beteken dat as 'n aanvaller **kompromitteer** 'n **pakket** wat dan in die cache gestoor word en **afgelaai** en uitgevoer word deur 'n **meer bevoorregte** workflow, hy ook daardie workflow sal kan **kompromitteer**.
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
@@ -392,13 +392,13 @@ Kyk na die volgende bladsye:
|
||||
|
||||
### Toegang tot geheime <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
|
||||
As jy inhoud in 'n skrif inspuit, is dit interessant om te weet hoe jy toegang tot geheime kan kry:
|
||||
As jy inhoud in 'n skrip inspuit, is dit interessant om te weet hoe jy toegang tot geheime kan kry:
|
||||
|
||||
- As die geheim of token op 'n **omgewing veranderlike** gestel is, kan dit direk deur die omgewing met **`printenv`** aangespreek word.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Lys geheime in Github Action-uitvoer</summary>
|
||||
<summary>Lys geheime in Github Action-uitset</summary>
|
||||
```yaml
|
||||
name: list_env
|
||||
on:
|
||||
@@ -456,7 +456,7 @@ cat /home/runner/work/_temp/*
|
||||
- ```bash
|
||||
ps axe | grep node
|
||||
```
|
||||
- Vir 'n **aangepaste aksie** kan die risiko verskil, afhangende van hoe 'n program die geheim wat dit van die **argument** verkry het, gebruik:
|
||||
- Vir 'n **aangepaste aksie** kan die risiko wissel, afhangende van hoe 'n program die geheim wat dit van die **argument** verkry het, gebruik:
|
||||
|
||||
```yaml
|
||||
uses: fakeaction/publish@v3
|
||||
@@ -468,7 +468,7 @@ 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** (kwetsbare 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 gelyktydig 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:
|
||||
```bash
|
||||
@@ -515,14 +515,14 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
```
|
||||
</details>
|
||||
|
||||
Soos jy in die vorige kode kon sien, is die Github registrasie gehos in **`ghcr.io`**.
|
||||
Soos wat jy in die vorige kode kon sien, is die Github registrasie gehost in **`ghcr.io`**.
|
||||
|
||||
'n Gebruiker met leesregte oor die repo sal dan in staat wees om die Docker Image af te laai met 'n persoonlike toegangsteken:
|
||||
```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 **gelekte geheime in die Docker beeld lae soek:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
@@ -530,13 +530,13 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
|
||||
|
||||
### Sensitiewe inligting in Github Actions logs
|
||||
|
||||
Selfs al probeer **Github** om **geheime waardes** in die aksies logs te **detecteer** en **te vermy om** hulle te wys, sal **ander sensitiewe data** wat in die uitvoering van die aksie gegenereer kon gewees het, nie versteek wees nie. Byvoorbeeld, 'n JWT wat met 'n geheime waarde onderteken is, sal nie versteek wees nie tensy dit [spesifiek gekonfigureer](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) is.
|
||||
Selfs al probeer **Github** om **geheime waardes** in die aksies logs te **ontdek** en **te vermy om** hulle te wys, sal **ander sensitiewe data** wat in die uitvoering van die aksie gegenereer kon gewees het nie versteek wees nie. Byvoorbeeld, 'n JWT wat met 'n geheime waarde onderteken is, sal nie versteek wees nie tensy dit [spesifiek gekonfigureer](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret) is.
|
||||
|
||||
## Bedek jou Spore
|
||||
|
||||
(Techniek 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 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 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)
|
||||
|
||||
'n Organisasie in GitHub is baie proaktief in die verslagdoening van rekeninge aan GitHub. Al wat jy moet doen is om “n paar goed” 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 onsigbaar gemaak op github.
|
||||
|
||||
> [!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