GCP - Understanding Domain-Wide Delegation

unga mkono HackTricks

Chapisho hili 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 Uteuzi wa Utekelezaji wa Kikoa

Uteuzi wa Utekelezaji wa Kikoa wa Google Workspace huruhusu kitu cha kitambulisho, iwe ni programu ya nje kutoka Soko la Google Workspace au akaunti ya huduma ya GCP ya ndani, kufikia data kote kwenye Workspace kwa niaba ya watumiaji. Kipengele hiki, ambacho ni muhimu kwa programu zinazoshirikiana na APIs za Google au huduma zinazohitaji uigaji wa mtumiaji, huongeza ufanisi na kupunguza makosa ya kibinadamu kwa kiotomatiki majukumu. Kwa kutumia OAuth 2.0, watengenezaji wa programu na wasimamizi wanaweza kutoa upatikanaji wa akaunti hizi za huduma kwa data ya mtumiaji bila ridhaa ya mtumiaji binafsi. Google Workspace inaruhusu uundaji wa aina mbili kuu za vitambulisho vya vitu vilivyoteuliwa kimataifa:

  • Programu za GWS: Programu kutoka Soko la Workspace inaweza kuwekwa kama kitambulisho kilichoteuliwa. Kabla ya kuwa inapatikana kwenye soko, kila programu ya Workspace inapitia ukaguzi na Google ili kupunguza matumizi mabaya yanayowezekana. Ingawa hii haiondoi kabisa hatari ya unyanyasaji, inaongeza sana ugumu kwa matukio kama hayo kutokea.

  • Akaunti ya Huduma ya GCP: Jifunze zaidi kuhusu Akaunti za Huduma za GCP hapa.

Uteuzi wa Utekelezaji wa Kikoa: Chini ya Mfumo

Hivi ndivyo Akaunti ya Huduma ya GCP inaweza kupata APIs za Google kwa niaba ya vitambulisho vingine katika Google Workspace:

  1. Kitambulisho hujenga JWT: Kitambulisho hutumia ufunguo wa kibinafsi wa akaunti ya huduma (sehemu ya faili ya jozi ya JSON) kusaini JWT. JWT hii ina madai kuhusu akaunti ya huduma, mtumiaji lengwa wa kuigwa, na ruhusa za OAuth za kupata API ya REST inayotakiwa.

  2. Kitambulisho hutumia JWT kuomba tokeni ya upatikanaji: Programu/mtumiaji hutumia JWT kuomba tokeni ya upatikanaji kutoka kwa huduma ya OAuth 2.0 ya Google. Ombi pia linajumuisha mtumiaji lengwa wa kuigwa (barua pepe ya Workspace ya mtumiaji), na ruhusa ambazo upatikanaji unahitajika.

  3. Huduma ya OAuth 2.0 ya Google hurudisha tokeni ya upatikanaji: Tokeni ya upatikanaji inawakilisha mamlaka ya akaunti ya huduma kutenda kwa niaba ya mtumiaji kwa ruhusa zilizotajwa. Kadi hii kawaida ni ya muda mfupi na lazima ibadilishwe mara kwa mara (kulingana na mahitaji ya programu). Ni muhimu kuelewa kuwa ruhusa za OAuth zilizotajwa katika kadi ya JWT zina halali na athari kwenye tokeni ya upatikanaji inayopatikana. Kwa mfano, tokeni za upatikanaji zenye ruhusa nyingi zitakuwa na halali kwa maombi mengi ya API ya REST.

  4. Kitambulisho hutumia tokeni ya upatikanaji kupiga simu kwa APIs za Google: Sasa na tokeni ya upatikanaji inayofaa, huduma inaweza kupata API ya REST inayohitajika. Programu hutumia tokeni hii ya upatikanaji kwenye kichwa cha "Uthibitishaji" cha maombi yake ya HTTP yanayoelekea kwa APIs za Google. APIs hizi hutumia kadi hiyo kuthibitisha kitambulisho kilichojiigiza na kuthibitisha kuwa ina idhini inayohitajika.

  5. API za Google hurudisha data iliyohitajika: Ikiwa tokeni ya upatikanaji ni halali na akaunti ya huduma ina idhini inayofaa, APIs za Google hurudisha data iliyohitajika. Kwa mfano, kwenye picha ifuatayo, tumetumia njia ya users.messages.list kuorodhesha vitambulisho vyote vya barua pepe za Gmail zinazohusiana na mtumiaji wa Workspace aliyelengwa.

unga mkono HackTricks

Last updated