Basic Github Information
Last updated
Last updated
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)
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.
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.
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, neadministrativna uloga za ljude u organizaciji je član organizacije. Po default-u, članovi organizacije imaju određeni broj dozvola.
Menadžeri za naplatu: Menadžeri za naplatu su korisnici koji mogu upravljati postavkama naplate za vašu organizaciju, kao što su informacije o plaćanju.
Menadžeri za bezbednost: 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 za bezbednost 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
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.
Podrazumevano se kreiraju uloge u repozitorijumu:
Čitanje: Preporučuje se za ne-kodere koji žele da pregledaju ili razgovaraju 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
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 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 nudi različite načine za autentifikaciju na vašem nalogu i obavljanje radnji u vaše ime.
Pristupajući github.com, možete se prijaviti koristeći svoje korisničko ime i lozinku (i 2FA potencijalno).
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
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 budnom režimu ovde.
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 treba da ima. https://github.com/settings/tokens
Oauth aplikacije mogu vas pitati za dozvole da pristupe delu vaših github informacija ili da se pretvaraju da ste vi kako bi obavili neke radnje. Uobičajen primer ove funkcionalnosti je dugme za prijavu sa github-om koje možete pronaći na nekim platformama.
Možete kreirati svoje Oauth aplikacije na https://github.com/settings/developers
Možete videti sve Oauth aplikacije koje imaju pristup vašem nalogu na https://github.com/settings/applications
Možete videti opsege za koje Oauth aplikacije mogu tražiti na 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
Neke preporuke za bezbednost:
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 navedenih opsega.
Oauth aplikacija može se koristiti kao provajder identiteta omogućavanjem "Prijavi se 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 svim 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 o tome ovde.
Github aplikacije mogu tražiti dozvole da pristupe vašim github informacijama ili da se pretvaraju da ste vi kako bi obavili specifične radnje nad specifičnim resursima. U Github aplikacijama morate navesti repozitorijume kojima će aplikacija imati pristup.
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
Možete videti sve GitHub aplikacije koje imaju pristup vašem nalogu na 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. 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
Neke preporuke za bezbednost:
GitHub aplikacija bi trebala preduzimati radnje nezavisno od korisnika (osim ako aplikacija koristi token za korisnika na serveru). Da biste zadržali token za pristup korisnika na serveru sigurnijim, možete koristiti tokene za pristup koji će isteći nakon 8 sati, i osvežiti token koji se može zameniti za novi token za pristup. Za više informacija, pogledajte "Osvežavanje tokena za pristup korisnika na serveru."
Uverite se da 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 "Prijavi se sa GitHub-om". Ali GitHub aplikacija može koristiti tok identifikacije 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 o tome ovde.
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 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).
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 odobri pokretanje Github akcije i dozvole GITHUB_TOKEN Github akcije kada se pokrene.
Github akcije obično trebaju neku vrstu tajni da bi interagovale sa github-om ili aplikacijama trećih strana. Da biste izbegli stavljanje u čistom tekstu u repozitorijum, github omogućava da ih stavite kao Tajne.
Ove tajne mogu biti konfigurirane za repozitorijum ili za celu organizaciju. Zatim, da bi Akcija mogla da pristupi tajni, morate je deklarisati kao:
Tajne informacije mogu se pristupiti samo iz Github Actions koje ih imaju deklarisane.
Jednom kada su konfigurisane u repozitorijumu ili organizacijama, korisnici Githuba više neće moći da im pristupe, samo će moći da ih promene.
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 tu akciju).
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:
Možete konfigurisati okruženje da bude pristupačno za sve grane (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.
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 runere 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 pretražujete 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 Runner prilikom njegove konfiguracije kako bi se znalo kojoj organizaciji pripada.
Ako je prilagođeni Github Runner konfiguran na mašini unutar AWS-a ili GCP-a, na primer, akcija može imati pristup metapodacima i ukrasti token servisnog naloga sa kojim mašina radi.
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.
Zla Github akcija može biti zloupotrebljena od strane napadača da:
Ukrade sve tajne kojima akcija ima pristup
Pomeranje 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.
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 naći na https://github.com/<orgname>/<reponame>/settings/branches
Nije moguće postaviti zaštitu grane na nivou organizacije. Tako da sve 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 izabrano, različite druge zaštite mogu biti na snazi:
Zahtevati broj odobrenja. Veoma je uobičajeno zahtevati da 1 ili 2 osobe 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 korisnik može 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 su dozvoljeni 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.
Kao što možete videti, č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.
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)
