GCP - Kuelewa Delegation ya Domain-Wide

Reading time: 4 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Post hii ni utangulizi wa https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover ambayo inaweza kupatikana kwa maelezo zaidi.

Kuelewa Delegation ya Domain-Wide

Delegation ya Domain-Wide ya Google Workspace inaruhusu kitu cha utambulisho, iwe ni programu ya nje kutoka Google Workspace Marketplace au GCP Service Account ya ndani, kupata data katika Workspace kwa niaba ya watumiaji. Kipengele hiki, ambacho ni muhimu kwa programu zinazoshirikiana na Google APIs au huduma zinazohitaji uigaji wa mtumiaji, kinaboresha ufanisi na kupunguza makosa ya kibinadamu kwa kuendesha kazi kwa otomatiki. Kwa kutumia OAuth 2.0, waendelezaji wa programu na wasimamizi wanaweza kuwapa hizi service accounts ufikiaji wa data za watumiaji bila idhini ya mtumiaji binafsi.

Google Workspace inaruhusu uundaji wa aina mbili kuu za utambulisho wa kimataifa wa delegated object:

  • Programu za GWS: Programu kutoka Marketplace ya Workspace zinaweza kuwekwa kama utambulisho wa delegated. Kabla ya kupatikana katika soko, kila programu ya Workspace hupitia ukaguzi na Google ili kupunguza matumizi mabaya yanayoweza kutokea. Ingawa hii haiondoi kabisa hatari ya matumizi mabaya, inafanya kuwa ngumu zaidi kwa matukio kama hayo kutokea.
  • GCP Service Account: Jifunze zaidi kuhusu GCP Service Accounts hapa.

Delegation ya Domain-Wide: Chini ya Mfuniko

Hivi ndivyo GCP Service Account inaweza kupata Google APIs kwa niaba ya utambulisho mwingine katika Google Workspace:

  1. Utambulisho unaunda JWT: Utambulisho unatumia funguo za siri za service account (sehemu ya faili ya jozi ya funguo za JSON) kusaini JWT. Hii JWT ina madai kuhusu service account, mtumiaji wa lengo wa kuigizwa, na OAuth scopes za ufikiaji wa REST API inayohitajika.
  2. Utambulisho unatumia JWT kuomba token ya ufikiaji: Programu/mtumiaji anatumia JWT kuomba token ya ufikiaji kutoka huduma ya OAuth 2.0 ya Google. Ombi pia linajumuisha mtumiaji wa lengo wa kuigizwa (barua pepe ya mtumiaji wa Workspace), na scopes ambazo ufikiaji unahitajika.
  3. Huduma ya OAuth 2.0 ya Google inarudisha token ya ufikiaji: Token ya ufikiaji inawakilisha mamlaka ya service account ya kutenda kwa niaba ya mtumiaji kwa ajili ya scopes zilizotajwa. Token hii kwa kawaida ina muda mfupi wa matumizi na inahitaji kusasishwa mara kwa mara (kulingana na mahitaji ya programu). Ni muhimu kuelewa kwamba OAuth scopes zilizotajwa katika token ya JWT zina uhalali na zinaathiri token ya ufikiaji inayopatikana. Kwa mfano, token za ufikiaji zenye scopes nyingi zitakuwa na uhalali kwa programu nyingi za REST API.
  4. Utambulisho unatumia token ya ufikiaji kuita Google APIs: Sasa ikiwa na token ya ufikiaji inayofaa, huduma inaweza kupata REST API inayohitajika. Programu inatumia token hii ya ufikiaji katika kichwa cha "Authorization" cha maombi yake ya HTTP yanayoelekezwa kwa Google APIs. APIs hizi zinatumia token kuthibitisha utambulisho wa kuigizwa na kuthibitisha kuwa ina idhini inayohitajika.
  5. Google APIs inarudisha data iliyohitajika: Ikiwa token ya ufikiaji ni halali na service account ina idhini inayofaa, Google APIs inarudisha data iliyohitajika. Kwa mfano, katika picha ifuatayo, tumetumia mbinu ya users.messages.list kuorodhesha IDs za ujumbe wa Gmail zinazohusiana na mtumiaji wa lengo wa Workspace.

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks