GCP - Understanding Domain-Wide Delegation
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)
Ovaj post je uvod u https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover koji se može pristupiti za više detalja.
Delegacija na nivou domena Google Workspace omogućava identitetskom objektu, bilo spoljnoj aplikaciji iz Google Workspace Marketplace-a ili internom GCP servisnom nalogu, da pristupi podacima širom Workspace-a u ime korisnika. Ova funkcija, koja je ključna za aplikacije koje komuniciraju sa Google API-ima ili uslugama koje zahtevaju impersonaciju korisnika, poboljšava efikasnost i minimizira ljudske greške automatizacijom zadataka. Korišćenjem OAuth 2.0, programeri aplikacija i administratori mogu dati ovim servisnim nalozima pristup korisničkim podacima bez pojedinačne saglasnosti korisnika. Google Workspace omogućava kreiranje dva glavna tipa globalnih delegiranih identiteta:
GWS Aplikacije: Aplikacije iz Workspace Marketplace-a mogu biti postavljene kao delegirani identitet. Pre nego što postanu dostupne na tržištu, svaka Workspace aplikacija prolazi reviziju od strane Google-a kako bi se minimizirala potencijalna zloupotreba. Iako to ne eliminiše potpuno rizik od zloupotrebe, značajno povećava težinu za takve incidente da se dogode.
GCP Servisni Nalog: Saznajte više o GCP Servisnim Nalozima ovde.
Ovako GCP Servisni Nalog može pristupiti Google API-ima u ime drugih identiteta u Google Workspace-u:
Identitet kreira JWT: Identitet koristi privatni ključ servisnog naloga (deo JSON ključa) da potpiše JWT. Ovaj JWT sadrži tvrdnje o servisnom nalogu, ciljanom korisniku koga treba impersonirati, i OAuth opsezima pristupa REST API-ju koji se zahteva.
Identitet koristi JWT da zatraži pristupni token: Aplikacija/korisnik koristi JWT da zatraži pristupni token od Google-ove OAuth 2.0 usluge. Zahtev takođe uključuje ciljanog korisnika koga treba impersonirati (email korisnika iz Workspace-a), i opsege za koje se traži pristup.
Google-ova OAuth 2.0 usluga vraća pristupni token: Pristupni token predstavlja ovlašćenje servisnog naloga da deluje u ime korisnika za određene opsege. Ovaj token je obično kratkotrajan i mora se periodično osvežavati (prema potrebama aplikacije). Važno je razumeti da opsezi OAuth navedeni u JWT tokenu imaju validnost i uticaj na rezultantni pristupni token. Na primer, pristupni tokeni koji poseduju više opsega će imati validnost za brojne REST API aplikacije.
Identitet koristi pristupni token da pozove Google API-e: Sada sa relevantnim pristupnim tokenom, servis može pristupiti potrebnom REST API-ju. Aplikacija koristi ovaj pristupni token u "Authorization" header-u svojih HTTP zahteva namenjenih Google API-ima. Ovi API-ji koriste token da verifikuju impersonirani identitet i potvrde da ima potrebna ovlašćenja.
Google API-e vraćaju tražene podatke: Ako je pristupni token validan i servisni nalog ima odgovarajuće ovlašćenje, Google API-e vraćaju tražene podatke. Na primer, na sledećoj slici, iskoristili smo users.messages.list metodu da bismo naveli sve Gmail ID-ove poruka povezane sa ciljanom Workspace korisnikom.
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)
