Osnovne informacije o Github-u

Reading time: 15 minutes

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

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.

Štaviše, korisnik može biti deo različitih timova sa različitim ulogama u preduzeću, organizaciji ili repozitorijumu.

I konačno, repozitorijumi mogu imati posebne mehanizme zaštite.

Privilegije

Uloge u preduzeću

  • 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, 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.

Uloge u organizaciji

U organizaciji korisnici mogu imati različite uloge:

  • 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, ne-administrativna 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.

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

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

Postavke ovde konfigurirane će ukazivati na sledeće dozvole članova organizacije:

  • Biti administrator, pisac, čitalac ili bez dozvole nad svim repozitorijumima organizacije.
  • Ako članovi mogu kreirati privatne, interne ili javne repozitorijume.
  • Ako je moguće fork-ovati repozitorijume.
  • Ako je moguće pozvati spoljne saradnike.
  • Ako se mogu objaviti javne ili privatne stranice.
  • Dozvole koje administratori imaju nad repozitorijumima.
  • Ako članovi mogu kreirati nove timove.

Uloge u repozitorijumu

Po defaultu, uloge u repozitorijumu su kreirane:

  • Č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.

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 svoje uloge na https://github.com/organizations/<org_name>/settings/roles

Timovi

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.

Korisnici

Korisnici organizacije mogu biti navedeni na https://github.com/orgs/<org_name>/people.

U informacijama o svakom korisniku možete videti timove čiji je korisnik član, i repozitorijume kojima korisnik ima pristup.

Github autentifikacija

Github nudi različite načine za autentifikaciju na vašem nalogu i obavljanje radnji u vaše ime.

Web pristup

Pristupajući github.com, možete se prijaviti koristeći svoje korisničko ime i lozinku (i 2FA potencijalno).

SSH ključevi

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

GPG ključevi

Ne možete imiti korisnika 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 here.

Lični pristupni tokeni

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

Oauth aplikacije

Oauth aplikacije mogu vas pitati za dozvole da pristupite delu vaših github informacija ili da imitirate vas da obavite neke radnje. Uobičajen primer ove funkcionalnosti je dugme prijave sa github-om koje možete pronaći na nekim platformama.

Neke preporuke za bezbednost:

  • OAuth aplikacija uvek treba da deluje 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.
  • Nemojte praviti OAuth aplikaciju ako želite da vaša aplikacija deluje na jednom repozitorijumu. Sa repo Oauth opsegom, Oauth aplikacije mogu delovati na svim repozitorijumima autentifikovanog korisnika.
  • Nemojte praviti 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 more.

Github aplikacije

Github aplikacije mogu tražiti dozvole da pristupite vašim github informacijama ili da imitirate vas da obavite specifične radnje nad specifičnim resursima. U Github aplikacijama morate navesti repozitorijume kojima će aplikacija imati pristup.

Neke preporuke za bezbednost:

  • GitHub aplikacija treba da preduzima radnje nezavisno od korisnika (osim ako aplikacija koristi user-to-server token). Da biste zadržali korisničke pristupne tokene 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 korisničkih pristupnih tokena."
  • Uverite se da se GitHub aplikacija integriše sa specifičnim repozitorijumima.
  • GitHub aplikacija treba da poveže sa ličnim nalogom ili organizacijom.
  • Ne očekujte da GitHub aplikacija zna i radi sve što korisnik može.
  • Nemojte koristiti GitHub aplikaciju ako vam je potrebna samo usluga "Prijava sa GitHub-om". Ali GitHub aplikacija može koristiti tokene za identifikaciju korisnika 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."
  • Više ovde more.

Github Actions

Ovo nije način za autentifikaciju u 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 akcije

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 izgraditi docker kontejner ili proveriti da PR ne sadrži tajne).

Konfiguracija

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

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

Takođe je moguće konfigurisati ko treba da dobije odobrenje za pokretanje Github akcije i dozvole GITHUB_TOKEN Github akcije kada se pokrene.

Git tajne

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

Primer korišćenja Bash

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

warning

Tajne informacije mogu se pristupiti samo iz Github Actions koje ih imaju deklarisane.

Kada su konfigurisane u repozitorijumu ili organizacijama, korisnici Githuba više neće moći da im pristupe, samo će moći da promene.

Dakle, jedini način da se ukradu github tajne je da se pristupi mašini koja izvršava Github Action (u toj situaciji ćete moći da pristupite samo tajnama deklarisanim za Action).

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

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 recenzija pre izvršavanja akcije koristeći okruženje ili čekati neko vreme pre nego što dozvoli da se implementacije nastave.

Git Action Runner

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.

Nekoliko organizacija će dozvoliti pokretanje Github akcija u infrastrukturi treće strane jer obično bude jeftinije.

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

Način da saznate koje Github akcije se izvršavaju u ne-github infrastrukturi je da potražite runs-on: self-hosted u yaml konfiguraciji Github akcije.

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.

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

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

Zla Github akcija može biti zloupotrebljena od strane napadača da:

  • 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

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.

Zaštite grana repozitorijuma mogu se pronaći na https://github.com/<orgname>/<reponame>/settings/branches

note

Nije moguće postaviti zaštitu grane na nivou organizacije. Tako da sve one moraju biti deklarisane na svakom repozitorijumu.

Različite zaštite mogu se primeniti na granu (kao na master):

  • 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 commitovi poslati. Ako ne, korisnik može odobriti legitiman kod, a zatim dodati zli kod i spojiti ga.
  • Zahtevati recenzije od vlasnika koda. Najmanje 1 vlasnik koda repozitorijuma treba da odobri PR (tako da "slučajni" korisnici ne mogu da ga odobre)
  • Ograničiti ko može da odbaci recenzije pull zahteva. Možete odrediti ljude ili timove koji mogu da odbace recenzije pull zahteva.
  • Dozvoliti određenim akterima da zaobiđu zahteve pull zahteva. 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 tajnih podataka 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 commitove. Commitovi moraju biti potpisani.
  • Zahtevati linearnu istoriju. Sprečava spajanje commitova da budu poslati na odgovarajuće grane.
  • Uključiti administratore. Ako ovo nije postavljeno, administratori mogu zaobići restrikcije.
  • Ograničiti ko može da šalje na odgovarajuće grane. Ograničiti ko može da pošalje PR.

note

Kao što vidite, čak i ako uspete 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

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