GCP - Understanding Domain-Wide Delegation

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

• Ako želite da vidite svoju kompaniju reklamiranu na HackTricks-u ili da preuzmete HackTricks u PDF formatu proverite PLANOVE ZA PRIJAVU!

• Nabavite zvanični PEASS & HackTricks swag

• Otkrijte Porodicu PEASS, našu kolekciju ekskluzivnih NFT-ova

• Pridružite se 💬 Discord grupi ili telegram grupi ili me pratite na Twitter-u 🐦 @carlospolopm.

• Podelite svoje hakovanje trikove slanjem PR-ova na HackTricks i HackTricks Cloud github repozitorijume.

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 gde možete pronaći više detalja.

Razumevanje Delegacije na Nivou Domena

Delegacija na nivou domena u Google Workspace-u omogućava objektu identiteta, bilo da je to spoljni aplikacija sa Google Workspace Marketplace-a ili interni GCP Service Account, da pristupi podacima širom Workspace-a u ime korisnika. Ova funkcija, koja je ključna za aplikacije koje interaguju sa Google API-jima ili uslugama koje zahtevaju impersonaciju korisnika, poboljšava efikasnost i minimizira ljudske greške automatizacijom zadataka. Korišćenjem OAuth 2.0, razvojni 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 objekata identiteta:

• GWS Aplikacije: Aplikacije sa Workspace Marketplace-a mogu biti postavljene kao delegirani identitet. Pre nego što postanu dostupne na tržištu, svaka aplikacija Workspace-a prolazi kroz pregled od strane Google-a kako bi se minimizirala mogućnost zloupotrebe. Iako ovo ne eliminiše potpuno rizik od zloupotrebe, značajno povećava težinu za takve incidente da se dese.

• GCP Service Account: Saznajte više o GCP Service Accounts ovde.

Delegacija na Nivou Domena: Iznutra

Ovako GCP Service Account može pristupiti Google API-jima u ime drugih identiteta u Google Workspace-u:

1. Identitet kreira JWT: Identitet koristi privatni ključ servisnog naloga (deo JSON ključnog para fajla) da potpiše JWT. Ovaj JWT sadrži tvrdnje o servisnom nalogu, ciljanom korisniku za impersonaciju i OAuth opsege pristupa REST API-ju koji se zahteva.

2. Identitet koristi JWT za zahtevanje pristupnog tokena: Aplikacija/korisnik koristi JWT za zahtevanje pristupnog tokena od Google-ovog OAuth 2.0 servisa. Zahtev takođe uključuje ciljanog korisnika za impersonaciju (email korisnika Workspace-a) i opsege za koje se zahteva pristup.

3. Google-ov OAuth 2.0 servis 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 osvežavati periodično (prema potrebi aplikacije). Važno je razumeti da OAuth opsezi navedeni u JWT tokenu imaju važnost i uticaj na rezultantni pristupni token. Na primer, pristupni tokeni koji poseduju više opsega će biti važeći za brojne REST API aplikacije.

4. Identitet koristi pristupni token za pozivanje Google API-ja: Sada sa relevantnim pristupnim tokenom, servis može pristupiti potrebnom REST API-ju. Aplikacija koristi ovaj pristupni token u "Authorization" zaglavlju svojih HTTP zahteva namenjenih Google API-jima. Ovi API-ji koriste token za proveru impersoniranog identiteta i potvrdu da ima neophodnu autorizaciju.

5. Google API-ji vraćaju tražene podatke: Ako je pristupni token validan i servisni nalog ima odgovarajuću autorizaciju, Google API-ji vraćaju tražene podatke. Na primer, u sledećoj slici, iskoristili smo users.messages.list metod da bismo naveli sve Gmail ID poruka povezanih sa ciljanim korisnikom Workspace-a.