GCP - Understanding Domain-Wide Delegation
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Hierdie pos is die inleiding van https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover wat toegang bied tot meer besonderhede.
Google Workspace se Domein-Wye delegasie laat 'n identiteitsobjek, hetsy 'n eksterne app van Google Workspace Marketplace of 'n interne GCP Diensrekening, toe om data oor die Workspace namens gebruikers te bekom. Hierdie funksie, wat noodsaaklik is vir toepassings wat met Google API's of dienste wat gebruikersverpersoonliking benodig, interaksie het, verbeter doeltreffendheid en minimaliseer menslike foute deur take te outomatiseer. Deur OAuth 2.0 kan app-ontwikkelaars en administrateurs hierdie diensrekeninge toegang tot gebruikersdata gee sonder individuele gebruikers se toestemming. Google Workspace laat die skepping van twee hoofsoorte globale gedelegeerde objek identiteite toe:
GWS Toepassings: Toepassings van die Workspace Marketplace kan opgestel word as 'n gedelegeerde identiteit. Voordat dit in die mark beskikbaar gestel word, ondergaan elke Workspace-toepassing 'n hersiening deur Google om potensiële misbruik te minimaliseer. Terwyl dit nie die risiko van misbruik heeltemal uitskakel nie, verhoog dit aansienlik die moeilikheidsgraad vir sulke voorvalle om voor te kom.
GCP Diensrekening: Leer meer oor GCP Diensrekeninge hier.
So kan 'n GCP Diensrekening Google API's namens ander identiteite in Google Workspace benader:
Identiteit skep 'n JWT: Die Identiteit gebruik die diensrekening se private sleutel (deel van die JSON sleutel paar lêer) om 'n JWT te teken. Hierdie JWT bevat aansprake oor die diensrekening, die te verpersoonlik gebruiker, en die OAuth skope van toegang tot die REST API wat aangevra word.
Die Identiteit gebruik die JWT om 'n toegangstoken aan te vra: Die toepassing/gebruiker gebruik die JWT om 'n toegangstoken van Google se OAuth 2.0 diens aan te vra. Die versoek sluit ook die te verpersoonlik gebruiker in (die gebruiker se Workspace e-pos), en die skope waarvoor toegang aangevra word.
Google se OAuth 2.0 diens keer 'n toegangstoken terug: Die toegangstoken verteenwoordig die diensrekening se gesag om namens die gebruiker vir die gespesifiseerde skope op te tree. Hierdie token is tipies kortstondig en moet periodiek verfris word (volgens die toepassing se behoefte). Dit is noodsaaklik om te verstaan dat die OAuth skope wat in die JWT-token gespesifiseer is, geldigheid het en 'n impak op die resulterende toegangstoken het. Byvoorbeeld, toegangstokens wat verskeie skope besit, sal geldigheid hou vir verskeie REST API-toepassings.
Die Identiteit gebruik die toegangstoken om Google API's aan te roep: Nou met 'n relevante toegangstoken, kan die diens toegang tot die vereiste REST API verkry. Die toepassing gebruik hierdie toegangstoken in die "Authorization" kop van sy HTTP versoeke wat bestem is vir Google API's. Hierdie API's gebruik die token om die verpersoonlikte identiteit te verifieer en te bevestig dat dit die nodige magtiging het.
Google API's keer die aangevraagde data terug: As die toegangstoken geldig is en die diensrekening die toepaslike magtiging het, keer die Google API's die aangevraagde data terug. Byvoorbeeld, in die volgende prent, het ons die users.messages.list metode benut om al die Gmail boodskap-ID's wat met 'n teiken Workspace gebruiker geassosieer is, te lys.
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
