GCP <--> Workspace Pivoting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Delegacija na nivou domena Google Workspace omogućava identitetskom objektu, bilo spoljnoj aplikaciji iz Google Workspace Marketplace ili unutrašnjem GCP servisnom nalogu, da pristupi podacima širom Workspace-a u ime korisnika.
To u suštini znači da servisni nalozi unutar GCP projekata organizacije mogu biti u mogućnosti da imituju korisnike Workspace-a iste organizacije (ili čak iz druge).
Za više informacija o tome kako ovo tačno funkcioniše, pogledajte:
GCP - Understanding Domain-Wide DelegationAko napadač kompromituje neki pristup preko GCP i zna validnu email adresu korisnika Workspace-a (poželjno super admin), mogao bi da enumeriše sve projekte kojima ima pristup, enumeriše sve SA projekata, proveri kojima servisnim nalozima ima pristup, i ponovi sve ove korake sa svakim SA koji može da imituje. Sa listom svih servisnih naloga kojima ima pristup i listom Workspace emailova, napadač bi mogao da pokuša da imitira korisnika sa svakim servisnim nalogom.
Napomena: kada se konfiguriše delegacija na nivou domena, nije potreban nijedan korisnik Workspace-a, stoga samo znajte da jedan validan korisnik je dovoljan i potreban za imitaciju. Međutim, privilegije imitiranog korisnika će biti korišćene, tako da ako je to Super Admin, moći ćete da pristupite svemu. Ako nema nikakav pristup, ovo će biti beskorisno.
Ovaj jednostavni skript će generisati OAuth token kao delegirani korisnik koji možete koristiti za pristup drugim Google API-ima sa ili bez gcloud:
Ovo je alat koji može izvršiti napad prateći ove korake:
Enumerate GCP Projects koristeći Resource Manager API.
Iterirati na svaki projekat resursa, i enumerate GCP Service account resources kojima inicijalni IAM korisnik ima pristup koristeći GetIAMPolicy.
Iterirati na svaku ulogu servisnog naloga, i pronaći ugrađene, osnovne i prilagođene uloge sa serviceAccountKeys.create dozvolom na ciljanom resursu servisnog naloga. Treba napomenuti da Editor uloga inherentno poseduje ovu dozvolu.
Kreirati novi KEY_ALG_RSA_2048 privatni ključ za svaki resurs servisnog naloga koji je pronađen sa relevantnom dozvolom u IAM politici.
Iterirati na svakom novom servisnom nalogu i kreirati JWT objekat za njega koji se sastoji od SA privatnih ključnih kredencijala i OAuth opsega. Proces kreiranja novog JWT objekta će iterirati na sve postojeće kombinacije OAuth opsega iz oauth_scopes.txt liste, kako bi pronašao sve mogućnosti delegacije. Lista oauth_scopes.txt se ažurira sa svim OAuth opsezima za koje smo smatrali da su relevantni za zloupotrebu identiteta Workspace-a.
Metod _make_authorization_grant_assertion otkriva potrebu da se deklarira target workspace user, nazvan subject, za generisanje JWT-ova pod DWD. Iako se može činiti da zahteva specifičnog korisnika, važno je shvatiti da DWD utiče na svaki identitet unutar domena. Shodno tome, kreiranje JWT-a za bilo kog korisnika domena utiče na sve identitete u tom domenu, u skladu sa našim proverama kombinacija. Jednostavno rečeno, jedan validan Workspace korisnik je dovoljan za nastavak.
Ovaj korisnik može biti definisan u DeleFriend-ovom config.yaml fajlu. Ako ciljani korisnik Workspace-a nije već poznat, alat olakšava automatsku identifikaciju validnih korisnika Workspace-a skeniranjem korisnika domena sa ulogama na GCP projektima. Ključno je napomenuti (ponovo) da su JWT-ovi specifični za domen i ne generišu se za svakog korisnika; stoga, automatski proces cilja jedinstveni identitet po domenu.
Enumerate and create a new bearer access token za svaki JWT i validirati token protiv tokeninfo API.
Gitlab je kreirao ovaj Python skript koji može uraditi dve stvari - listati korisnički direktorijum i kreirati novi administratorski nalog dok ukazuje na json sa SA kredencijalima i korisnikom koga treba imitirati. Evo kako biste ga koristili:
Moguće je proveriti delegacije na nivou domena u https://admin.google.com/u/1/ac/owl/domainwidedelegation.
Napadač sa sposobnošću da kreira servisne naloge u GCP projektu i super admin privilegijom za GWS može kreirati novu delegaciju koja omogućava SA da se predstavljaju kao neki GWS korisnici:
Generisanje novog servisnog naloga i odgovarajućeg para ključeva: Na GCP-u, novi resursi servisnog naloga mogu se proizvoditi ili interaktivno putem konzole ili programatski koristeći direktne API pozive i CLI alate. To zahteva ulogu iam.serviceAccountAdmin ili bilo koju prilagođenu ulogu opremljenu sa iam.serviceAccounts.create dozvolom. Kada se servisni nalog kreira, nastavićemo sa generisanjem odgovarajućeg para ključeva (iam.serviceAccountKeys.create dozvola).
Kreiranje nove delegacije: Važno je razumeti da samo Super Admin uloga ima sposobnost da postavi globalnu delegaciju na nivou domena u Google Workspace i delegacija na nivou domena ne može biti postavljena programatski, može se samo kreirati i prilagoditi ručno putem Google Workspace konzole.
Kreiranje pravila može se naći na stranici API kontrole → Upravljanje delegacijom na nivou domena u Google Workspace Admin konzoli.
Priključivanje privilegije OAuth opsega: Kada se konfiguriše nova delegacija, Google zahteva samo 2 parametra, Client ID, koji je OAuth ID resursa GCP Servisnog naloga, i OAuth opsege koje definišu koje API pozive delegacija zahteva.
Puna lista OAuth opsega može se naći ovde, ali evo preporuke: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Delovanje u ime ciljne identiteta: U ovom trenutku, imamo funkcionalni delegirani objekat u GWS. Sada, koristeći privatni ključ GCP Servisnog naloga, možemo izvršiti API pozive (u opsegu definisanom u parametru OAuth opsega) da ga aktiviramo i delujemo u ime bilo kojeg identiteta koji postoji u Google Workspace. Kao što smo saznali, servisni nalog će generisati pristupne tokene prema svojim potrebama i u skladu sa dozvolama koje ima za REST API aplikacije.
Proverite prethodni odeljak za neke alate za korišćenje ove delegacije.
OAuth SA ID je globalan i može se koristiti za cross-organizational delegaciju. Nije implementirana nijedna restrikcija koja bi sprečila cross-global delegaciju. U jednostavnim terminima, servisni nalozi iz različitih GCP organizacija mogu se koristiti za konfiguraciju delegacije na nivou domena u drugim Workspace organizacijama. To bi rezultiralo samo potrebom za Super Admin pristupom Workspace-u, a ne pristupom istom GCP nalogu, jer protivnik može kreirati Servisne Naloge i privatne ključeve na svom lično kontrolisanom GCP nalogu.
Po defaultu korisnici Workspace-a imaju dozvolu da kreiraju nove projekte, a kada se novi projekat kreira, kreator dobija ulogu Vlasnika nad njim.
Stoga, korisnik može kreirati projekat, omogućiti API-je za enumeraciju Workspace-a u svom novom projektu i pokušati da enumerira.
Da bi korisnik mogao da enumerira Workspace, takođe mu je potrebna dovoljna Workspace dozvola (neće svaki korisnik moći da enumerira direktorijum).
Proverite više enumeracije u:
GCP - IAM, Principals & Org Policies EnumMožete pronaći dodatne informacije o gcloud toku za prijavu u:
Kao što je objašnjeno tamo, gcloud može zatražiti opseg https://www.googleapis.com/auth/drive koji bi omogućio korisniku pristup disku korisnika.
Kao napadač, ako ste fizički kompromitovali računar korisnika i korisnik je još uvek prijavljen sa svojim nalogom, mogli biste se prijaviti generišući token sa pristupom disku koristeći:
Ako napadač kompromituje računar korisnika, mogao bi takođe da izmeni datoteku google-cloud-sdk/lib/googlecloudsdk/core/config.py i doda u CLOUDSDK_SCOPES opseg 'https://www.googleapis.com/auth/drive':
Stoga, sledeći put kada se korisnik prijavi, kreiraće token sa pristupom drive-u koji bi napadač mogao da zloupotrebi za pristup drive-u. Očigledno, pretraživač će ukazati da generisani token ima pristup drive-u, ali kako će se korisnik sam prijaviti koristeći gcloud auth login, verovatno neće posumnjati u ništa.
Da biste nabrojali datoteke na drive-u: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
Ako napadač ima potpun pristup GWS-u, moći će da pristupi grupama sa privilegovanim pristupom GCP-u ili čak korisnicima, stoga prelazak sa GWS-a na GCP je obično "jednostavniji" samo zato što korisnici u GWS-u imaju visoke privilegije nad GCP-om.
Podrazumevano, korisnici mogu slobodno da se pridružuju Workspace grupama Organizacije i te grupe mogu imati dodeljene GCP dozvole (proverite svoje grupe na https://groups.google.com/).
Zloupotrebom google groups privesc mogli biste biti u mogućnosti da se eskalirate u grupu sa nekim oblikom privilegovanog pristupa GCP-u.
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)
