Osnovne informacije o Github

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Osnovna struktura

Osnovna struktura Github okruženja velike kompanije je da poseduje enterprise koji poseduje više organizacija, a svaka od njih može sadržati više repositories i više timova. Manje kompanije mogu imati samo jednu organizaciju i bez enterprise-a.

Iz ugla korisnika, jedan user može biti član različitih enterprise-a i organizacija. Unutar njih korisnik može imati različite enterprise, organization i repository uloge.

Pored toga, korisnik može biti deo različitih timova sa različitim enterprise, organization ili repository ulogama.

I na kraju, repositories mogu imati posebne mehanizme zaštite.

Privilegije

Enterprise uloge

  • Enterprise owner: Osobe sa ovom ulogom mogu upravljati administratorima, upravljati organizacijama unutar enterprise-a, upravljati enterprise podešavanjima, i nametati politiku preko organizacija. Međutim, oni ne mogu pristupiti organization podešavanjima ili sadržaju osim ako im nije dodeljena organization owner uloga ili direktan pristup repository-ju koji poseduje organizacija.
  • Enterprise members: Članovi organizacija koje poseduje vaše enterprise su takođe automatski članovi enterprise-a.

Organization uloge

U organizaciji korisnici mogu imati različite uloge:

  • Organization owners: Organization owners imaju potpun administrativni pristup vašoj organizaciji. Ovu ulogu treba ograničiti, ali na najmanje dve osobe u vašoj organizaciji.
  • Organization members: Podrazumevana, ne-administrativna uloga za ljude u organizaciji je organization member. Po default-u, organization members imaju niz dozvola.
  • Billing managers: Billing managers su korisnici koji mogu upravljati billing podešavanjima vaše organizacije, kao što su podaci o plaćanju.
  • Security Managers: To je uloga koju organization owners mogu dodeliti bilo kojem timu u organizaciji. Kada se primeni, daje svakom članu tima dozvole da upravljaju security alerts i podešavanjima kroz vašu organizaciju, kao i read dozvole za sve repositories u organizaciji.
  • Ako vaša organizacija ima security tim, možete koristiti security manager ulogu da članovima tima date najmanje potrebne pristupe organizaciji.
  • Github App managers: Da biste dozvolili dodatnim korisnicima da upravljaju GitHub Apps koje poseduje organizacija, owner im može dodeliti GitHub App manager dozvole.
  • Outside collaborators: Outside collaborator je osoba koja ima pristup jednom ili više organization repositories ali nije eksplicitno član organizacije.

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

Privilegije članova

U https://github.com/organizations/<org_name>/settings/member_privileges možete videti dozvole koje korisnici imaju samo zato što su deo organizacije.

Podešavanja ovde indiciraju sledeće dozvole članova organizacije:

  • Biti admin, writer, reader ili bez dozvole nad svim organization repos.
  • Da li članovi mogu kreirati private, internal ili public repositories.
  • Da li je moguće fork-ovati repositories.
  • Da li je moguće pozivati outside collaborators.
  • Da li se public ili private sajtovi mogu objavljivati.
  • Dozvole koje admini imaju nad repositories.
  • Da li članovi mogu kreirati nove timove.

Repository uloge

Po default-u repository uloge su kreirane:

  • Read: Preporučeno za non-code contributors koji žele da pregledaju ili diskutujutu o projektu
  • Triage: Preporučeno za contribute-ere koji treba da proaktivno upravljaju issues i pull requests bez write pristupa
  • Write: Preporučeno za contribute-ere koji aktivno push-uju u projekat
  • Maintain: Preporučeno za project menadžere koji treba da upravljaju repository-jem bez pristupa osetljivim ili destruktivnim akcijama
  • Admin: Preporučeno za osobe kojima treba potpun pristup projektu, uključujući osetljive i destruktivne akcije kao što su upravljanje bezbednošću ili brisanje repository-ja

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

Takođe možete kreirati sopstvene uloge u https://github.com/organizations/<org_name>/settings/roles

Timovi

Možete listati 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 parent timu.

Korisnici

Korisnici organizacije mogu biti listani u https://github.com/orgs/<org_name>/people.

U informacijama za svakog korisnika možete videti timove čiji je korisnik član, i repos koje korisnik ima pristup.

Github autentifikacija

Github nudi različite načine da se autentifikujete na svoj nalog i izvršavate akcije u vaše ime.

Web pristup

Pristupanjem github.com možete se prijaviti koristeći username i password (i potencijalno 2FA).

SSH Keys

Možete konfigurisati svoj nalog sa jednim ili više public keys koji omogućavaju povezanom private key-ju da izvršava akcije u vaše ime. https://github.com/settings/keys

GPG Keys

Ne možete podsvesno predstavljati korisnika pomoću ovih ključeva, ali ako ih ne koristite može se desiti da budete otkriveni zbog slanja commits bez potpisa. Saznajte više o vigilant mode ovde.

Personal Access Tokens

Možete generisati personal access token da date aplikaciji pristup vašem nalogu. Prilikom kreiranja personal access token-a user mora navesti dozvole koje će token imati. https://github.com/settings/tokens

Oauth Applications

Oauth applications mogu tražiti dozvole za pristup delu vaših github informacija ili da vas impersoniraju kako bi izvršili neke akcije. Uobičajen primer ove funkcionalnosti je login with github dugme koje možete pronaći na nekim platformama.

Neke bezbednosne preporuke:

  • An OAuth App bi uvek trebao delovati kao autentifikovani GitHub user kroz ceo GitHub (na primer, pri slanju user notifikacija) i imati pristup samo specificiranim scopes..
  • An OAuth App može biti korišćen kao identity provider omogućavanjem “Login with GitHub” za autentifikovanog korisnika.
  • Ne pravite OAuth App ako želite da vaša aplikacija deluje samo na jednom repository-ju. Sa repo OAuth scope-om, OAuth Apps mogu delovati na svim_** repositorijima autentifikovanog korisnika**.
  • Ne pravite OAuth App da deluje kao aplikacija za vaš tim ili kompaniju. OAuth Apps se autentifikuju kao pojedinačni korisnik, tako da ako jedna osoba kreira OAuth App za kompaniju, i potom napusti kompaniju, niko drugi neće imati pristup njemu.
  • Više u ovde.

Github Applications

Github applications mogu tražiti dozvole da pristupe vašim github informacijama ili da vas impersoniraju kako bi izvršili specifične akcije nad specifičnim resursima. U Github Apps morate specificirati repositories kojima app će imati pristup.

Neke bezbednosne preporuke:

  • GitHub App bi trebao preduzimati akcije nezavisno od korisnika (osim ako app ne koristi user-to-server token). Da biste zadržali user-to-server access tokene bezbednijim, možete koristiti access tokene koji će isteći nakon 8 sati, i refresh token koji se može zameniti za novi access token. Za više informacija, pogledajte “Refreshing user-to-server access tokens”.
  • Uverite se da se GitHub App integriše sa specifičnim repositories.
  • GitHub App bi trebalo da bude povezan sa personal account ili organizacijom.
  • Ne očekujte da GitHub App zna i radi sve što korisnik može.
  • Ne koristite GitHub App ako vam je potreban samo “Login with GitHub” servis. Ali GitHub App može koristiti user identification flow da prijavi korisnike i uradi druge stvari.
  • Ne pravite GitHub App ako samo želite da delujete kao GitHub user i radite sve što taj user može.
  • Ako koristite svoju aplikaciju sa GitHub Actions i želite da modifikujete workflow fajlove, morate se autentifikovati u ime korisnika sa OAuth token-om koji uključuje workflow scope. Korisnik mora imati admin ili write dozvolu na repository-ju koji sadrži workflow fajl. Za više informacija, pogledajte “Understanding scopes for OAuth apps”.
  • Više u ovde.

Github Actions

Ovo nije način za autentifikaciju u github, ali maliciozna Github Action može dobiti neautorizovan pristup github-u i u zavisnosti od privilegija datih Action-u, može biti izvršeno nekoliko različitih napada. Pogledajte ispod za više informacija.

Git Actions

Git actions omogućavaju automatizaciju izvršavanja koda kada se dogodi događaj. Obično se izvršeni kod nekako odnosi na kod iz repository-ja (na primer, pravljenje docker containera ili provera da PR ne sadrži tajne).

Konfiguracija

U https://github.com/organizations/<org_name>/settings/actions moguće je proveriti konfiguraciju github actions za organizaciju.

Moguće je potpuno zabraniti korišćenje github actions, dozvoliti sve github actions, ili dozvoliti samo određene actions.

Takođe je moguće konfigurisati ko treba odobrenje da pokrene Github Action i dozvole GITHUB_TOKEN-a Github Action-a kada se pokrene.

Git Secrets

Github Action obično treba neki vid secrets da bi komunicirao sa github-om ili third party aplikacijama. Da biste izbegli stavljanje u plain-text u repo, github dozvoljava da ih stavite kao Secrets.

Ovi secrets se mogu konfigurisati za repo ili za celu organizaciju. Zatim, da bi Action imao pristup secret-u potrebno je da ga deklarišete ovako:

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 }}

Primer korišćenja Bash 

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Warning

Secrets su dostupne samo iz Github Actions koje su ih deklarisale.

Kada su konfigurisane u repo ili u organizations korisnici github-a neće moći ponovo da im pristupe, moći će samo da ih promene.

Stoga, jedini način da ukradete github secrets je da imate pristup mašini koja izvršava Github Action (u tom scenariju moći ćete pristupiti samo secrets deklarisanim za tu Action).

Git Environments

Github omogućava kreiranje environments u kojima možete sačuvati secrets. Zatim možete dati github action pristup secrets unutar environment-a pomoću nečega poput:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Možete konfigurisati okruženje da mu se pristupa sa svih grana (zadato), samo sa zaštićenih grana ili da odredite koje grane mogu pristupiti njemu.
Dodatno, zaštite okruženja uključuju:

  • Required reviewers: blokira job-ove koji ciljaju okruženje dok se ne odobre. Omogućite Prevent self-review da biste primenili pravi princip četiri oka pri samom odobrenju.
  • Deployment branches and tags: ograničite koje grane/tags mogu deploy-ovati u okruženje. Preporučljivo je izabrati konkretne grane/tags i osigurati da su te grane zaštićene. Napomena: opcija “Protected branches only” odnosi se na klasične branch protections i možda neće raditi kako se očekuje ako koristite rulesets.
  • Wait timer: odložite deploy-ove za konfigurabilni period.

Takođe, moguće je podesiti broj potrebnih review-eva pre nego što se izvrši action koristeći okruženje, ili sačekati određeno vreme pre nego što se dozvole deploy-evi da nastave.

Git Action Runner

Github Action može biti izvršen unutar github okruženja ili može biti izvršen u infrastrukturi treće strane koju je korisnik konfigurisao.

Neke organizacije dozvoljavaju pokretanje Github Actions u infrastrukturi treće strane jer je to često jeftinije.

Možete izlistati self-hosted runners organizacije na https://github.com/organizations/<org_name>/settings/actions/runners

Način da se pronađe koje se Github Actions izvršavaju van github infrastrukture je pretraga za runs-on: self-hosted u konfiguracionom yaml-u Github Action-a.

Nije moguće pokrenuti Github Action organizacije unutar self-hosted mašine druge organizacije jer se prilikom konfiguracije Runner-a generiše jedinstveni token koji zna kojoj organizaciji runner pripada.

Ako je custom Github Runner konfigurisana na mašini unutar AWS ili GCP, na primer, Action može imati pristup metadata endpoint-u i ukrasti token servisnog naloga pod kojim mašina radi.

Git Action Compromise

Ako su sve actions (ili neki maliciozni action) dozvoljeni, korisnik bi mogao iskoristiti Github action koji je maliciozan i koji će kompromitovati container u kojem se izvršava.

Caution

Maliciozan run Github Action-a može biti zloupotrebljen od strane napadača da:

  • Ukrade sve secrets kojima Action ima pristup
  • Krene lateralno ako se Action izvršava unutar infrastrukture treće strane gde se SA token koji pokreće mašinu može dohvatiti (verovatno preko metadata servisa)
  • Zloupotrebi token koji koristi workflow da ukrade kod repozitorijuma u kojem se Action izvršava ili čak izmeni taj kod.

Zaštita grana

Branch protections su dizajnirane da ne daju potpuni kontrolu nad repozitorijumom korisnicima. Cilj je postaviti više nivoa zaštite pre nego što će neko moći da upiše kod u određenu granu.

Zaštite grana repozitorijuma se nalaze na https://github.com/<orgname>/<reponame>/settings/branches

Note

Nije moguće postaviti branch protection na nivou organizacije. Dakle, sve moraju biti deklarisane u svakom repo-u.

Različite zaštite mogu biti primenjene na granu (npr. master):

  • Možete zahtevati PR pre merge-a (tako da ne možete direktno merge-ovati kod u granu). Ako je ovo izabrano, mogu biti aktivne i druge zaštite:
  • Zahtevati broj odobrenja. Vrlo je uobičajeno zahtevati 1 ili 2 osobe da odobre vaš PR kako pojedinačni korisnik ne bi mogao direktno da merge-uje kod.
  • Odbaciti odobrenja kada se potisnu novi commit-ovi. Ako se ovo ne uključi, korisnik može odobriti legitiman kod, a zatim dodati maliciozni kod i merge-ovati ga.
  • Zahtevati odobrenje najnovijeg reviewable push-a. Osigurava da svaki novi commit nakon odobrenja (uključujući push-eve drugih saradnika) ponovo pokreće review tako da napadač ne može da doda promene posle odobrenja i merge-uje.
  • Zahtevati odobrenja od Code Owners. Najmanje 1 code owner repoa mora odobriti PR (tako da “nasumični” korisnici ne mogu odobriti).
  • Ograničiti ko može odbaciti pull request review-e. Možete specificirati ljude ili timove koji imaju dozvolu da odbace review-e.
  • Dozvoliti određenim akterima da zaobiđu zahteve za pull request-om. Ovi korisnici će moći da zaobiđu prethodna ograničenja.
  • Zahtevati da status checks prođu pre merge-a. Neki checks moraju proći pre nego što se može merge-ovati commit (npr. GitHub App koji izveštava rezultate SAST-a). Savet: vezujte required checks za specifičan GitHub App; u suprotnom bilo koji app bi mogao falsifikovati check preko Checks API, i mnogi botovi prihvataju skip direktive (npr. “@bot-name skip”).
  • Zahtevati rešavanje konverzacija pre merge-a. Svi komentari na kod moraju biti rešeni pre nego što PR može biti merge-ovan.
  • Zahtevati signed commits. Commit-ovi moraju biti potpisani.
  • Zahtevati linear history. Sprečava da se merge commits šalju u matching grane.
  • Include administrators. Ako ovo nije uključeno, administratori mogu zaobići restrikcije.
  • Restrict who can push to matching branches. Ograničite ko može poslati PR.

Note

Kao što vidite, čak i ako uspete da dobijete kredencijale nekog korisnika, repo-i mogu biti zaštićeni i sprečiti vas da push-ujete kod u master, na primer, kako biste kompromitovali CI/CD pipeline.

Zaštita tag-ova

Tag-ovi (npr. latest, stable) su po defaultu mutabilni. Da biste primenili princip četiri oka pri ažuriranju tag-ova, zaštitite tag-ove i povežite zaštite kroz environment-e i grane:

  1. Na pravilu za zaštitu taga, omogućite Require deployments to succeed i zahtevajte uspešan deployment u zaštićeno okruženje (npr. prod).
  2. U ciljnom okruženju, ograničite Deployment branches and tags na release granu (npr. main) i po želji konfigurišite Required reviewers sa Prevent self-review.
  3. Na release grani, podesite branch protections da Require a pull request, postavite approvals ≥ 1, i omogućite i Dismiss approvals when new commits are pushed i Require approval of the most recent reviewable push.

Ovaj lanac sprečava jednog saradnika da ponovo tag-uje ili force-publish-uje release-ove izmjenom workflow YAML-a, jer su deployment gate-ovi sprovedeni izvan workflow-a.

References

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks