GCP <--> Workspace Pivoting
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Workspace se Domein-Wye delegasie laat 'n identiteit objek, hetsy 'n eksterne app van Google Workspace Marketplace of 'n interne GCP Diensrekening, toe om data oor die Workspace namens gebruikers te verkry.
Dit beteken basies dat diensrekeninge binne GCP projekte van 'n organisasie dalk in staat is om Workspace gebruikers van dieselfde organisasie (of selfs van 'n ander) te verpersoonlik.
For more information about how this exactly works check:
GCP - Understanding Domain-Wide DelegationAs 'n aanvaller toegang oor GCP gecompromitteer het en 'n geldige Workspace gebruiker e-pos bekend is (verkieslik super admin) van die maatskappy, kan hy alle projekte wat hy toegang het, opnoem, alle SA's van die projekte opnoem, kyk na watter diensrekeninge hy toegang het, en herhaal al hierdie stappe met elke SA wat hy kan verpersoonlik. Met 'n lys van al die diensrekeninge waartoe hy toegang het en die lys van Workspace e-posse, kan die aanvaller probeer om gebruikers met elke diensrekening te verpersoonlik.
Let daarop dat wanneer die domein wye delegasie gekonfigureer word, geen Workspace gebruiker benodig word nie, daarom weet net een geldige is genoeg en vereis vir die verpersoonliking. Tog, die privileges van die verpersoonlikte gebruiker sal gebruik word, so as dit Super Admin is, sal jy toegang tot alles hê. As dit geen toegang het nie, sal dit nutteloos wees.
This simple script will generate an OAuth token as the delegated user that you can then use to access other Google APIs with or without gcloud:
Dit is 'n hulpmiddel wat die aanval kan uitvoer volgens hierdie stappe:
Lys GCP-projekte met behulp van die Resource Manager API.
Herhaal op elke projekbron, en lys GCP-diensrekeningbronne waartoe die aanvanklike IAM-gebruiker toegang het met behulp van GetIAMPolicy.
Herhaal op elke diensrekeningrol, en vind ingeboude, basiese, en pasgemaakte rolle met serviceAccountKeys.create toestemming op die teiken diensrekeningbron. Dit moet opgemerk word dat die Editor-rol inherent hierdie toestemming het.
Skep 'n nuwe KEY_ALG_RSA_2048 privaat sleutel vir elke diensrekeningbron wat met relevante toestemming in die IAM-beleid gevind word.
Herhaal op elke nuwe diensrekening en skep 'n JWT objek daarvoor wat bestaan uit die SA privaat sleutel akkrediteer en 'n OAuth-scope. Die proses om 'n nuwe JWT objek te skep sal herhaal op al die bestaande kombinasies van OAuth scopes van die oauth_scopes.txt lys, ten einde al die delegasie moontlikhede te vind. Die lys oauth_scopes.txt word opgedateer met al die OAuth scopes wat ons gevind het om relevant te wees vir die misbruik van Workspace identiteite.
Die _make_authorization_grant_assertion metode onthul die noodsaaklikheid om 'n teiken werkruimte gebruiker te verklaar, waarna verwys word as subject, vir die generering van JWTs onder DWD. Terwyl dit mag lyk asof dit 'n spesifieke gebruiker vereis, is dit belangrik om te besef dat DWD elke identiteit binne 'n domein beïnvloed. Gevolglik, die skep van 'n JWT vir enige domein gebruiker beïnvloed al die identiteite in daardie domein, in ooreenstemming met ons kombinasie lys kontrole. Eenvoudig gestel, een geldige Workspace gebruiker is voldoende om vorentoe te beweeg.
Hierdie gebruiker kan in DeleFriend se config.yaml lêer gedefinieer word. As 'n teiken werkruimte gebruiker nie reeds bekend is nie, fasiliteer die hulpmiddel die outomatiese identifikasie van geldige werkruimte gebruikers deur domein gebruikers met rolle op GCP projekte te skandeer. Dit is belangrik om (weer) op te let dat JWTs domein-spesifiek is en nie vir elke gebruiker gegenereer word nie; daarom, die outomatiese proses teiken 'n enkele unieke identiteit per domein.
Lys en skep 'n nuwe draer toegangstoken vir elke JWT en valideer die token teen die tokeninfo API.
Gitlab het hierdie Python-skrip geskep wat twee dinge kan doen - lys die gebruiker gids en skep 'n nuwe administratiewe rekening terwyl dit 'n json met SA akkrediteer en die gebruiker om te verpersoonlik aandui. Hier is hoe jy dit sou gebruik:
Dit is moontlik om Domein Wye Delegasies in https://admin.google.com/u/1/ac/owl/domainwidedelegation** te kontroleer.**
'n Aanvaller met die vermoë om diensrekeninge in 'n GCP-projek te skep en super admin voorregte in GWS kan 'n nuwe delegasie skep wat SAs toelaat om as sommige GWS-gebruikers op te tree:
Genereer 'n Nuwe Diensrekening en Ooreenstemmende Sleutel Paar: Op GCP kan nuwe diensrekening hulpbronne interaktief via die konsole of programmaties met direkte API-oproepe en CLI-gereedskap geproduseer word. Dit vereis die rol iam.serviceAccountAdmin of enige aangepaste rol toegerus met die iam.serviceAccounts.create toestemming. Sodra die diensrekening geskep is, sal ons voortgaan om 'n verwante sleutel paar te genereer (iam.serviceAccountKeys.create toestemming).
Skep van 'n nuwe delegasie: Dit is belangrik om te verstaan dat slegs die Super Admin rol die vermoë het om globale Domein-Wye delegasie in Google Workspace op te stel en Domein-Wye delegasie kan nie programmaties opgestel word nie, dit kan slegs handmatig deur die Google Workspace konsole geskep en aangepas word.
Die skep van die reël kan onder die bladsy API kontroles → Bestuur Domein-Wye delegasie in Google Workspace Admin konsole gevind word.
Hecht OAuth skope voorreg: Wanneer 'n nuwe delegasie gekonfigureer word, vereis Google slegs 2 parameters, die Klient ID, wat die OAuth ID van die GCP Diensrekening hulpbron is, en OAuth skope wat definieer watter API-oproepe die delegasie benodig.
Die volledige lys van OAuth skope kan hier gevind word, maar hier is 'n aanbeveling: https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid
Optree namens die teiken identiteit: Op hierdie punt het ons 'n funksionerende gedelegeerde objek in GWS. Nou, met die GCP Diensrekening private sleutel, kan ons API-oproepe uitvoer (in die omvang gedefinieer in die OAuth skooparameter) om dit te aktiveer en namens enige identiteit wat in Google Workspace bestaan, op te tree. Soos ons geleer het, sal die diensrekening toegangstokens genereer volgens sy behoeftes en volgens die toestemming wat hy het vir REST API-toepassings.
Kontroleer die vorige afdeling vir 'n paar gereedskap om hierdie delegasie te gebruik.
OAuth SA ID is globaal en kan gebruik word vir kruis-organisatoriese delegasie. Daar is geen beperking geïmplementeer om kruis-globale delegasie te voorkom nie. In eenvoudige terme, diensrekeninge van verskillende GCP-organisasies kan gebruik word om domein-wye delegasie op ander Workspace-organisasies te konfigureer. Dit sou beteken dat slegs Super Admin toegang tot Workspace benodig word, en nie toegang tot dieselfde GCP-rekening nie, aangesien die teenstander diensrekeninge en private sleutels op sy persoonlik beheerde GCP-rekening kan skep.
Deur standaard het Workspace gebruikers die toestemming om nuwe projekte te skep, en wanneer 'n nuwe projek geskep word, ontvang die skepper die Eienaar rol oor dit.
Daarom kan 'n gebruiker 'n projek skep, die API's aktiveer om Workspace in sy nuwe projek te enumerate en probeer om dit te enumerate.
Om 'n gebruiker in staat te stel om Workspace te enumerate, benodig hy ook genoeg Workspace toestemming (nie elke gebruiker sal in staat wees om die gids te enumerate nie).
Kontroleer meer enumerasie in:
GCP - IAM, Principals & Org Policies EnumJy kan verdere inligting oor die gcloud vloei om aan te meld vind in:
Soos daar verduidelik, kan gcloud die omvang https://www.googleapis.com/auth/drive aanvra wat 'n gebruiker sou toelaat om toegang tot die gebruiker se drive te verkry.
As 'n aanvaller, as jy fisies die rekenaar van 'n gebruiker gecompromitteer het en die gebruiker is steeds aangemeld met sy rekening, kan jy aanmeld deur 'n token met toegang tot die drive te genereer met:
If an attacker compromises the computer of a user he could also modify the file google-cloud-sdk/lib/googlecloudsdk/core/config.py and add in the CLOUDSDK_SCOPES the scope 'https://www.googleapis.com/auth/drive':
Daarom, die volgende keer wanneer die gebruiker aanmeld, sal hy 'n token met toegang tot drive genereer wat die aanvaller kan misbruik om toegang tot die drive te verkry. Dit is duidelik dat die blaaier sal aandui dat die gegenereerde token toegang tot drive sal hê, maar aangesien die gebruiker homself die gcloud auth login sal noem, sal hy waarskynlik niks vermoed nie.
Om drive lêers te lys: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"
As 'n aanvaller volledige toegang oor GWS het, sal hy in staat wees om toegang te verkry tot groepe met privaat toegang oor GCP of selfs gebruikers, daarom is dit gewoonlik "eenvoudiger" om van GWS na GCP te beweeg net omdat gebruikers in GWS hoë privaathede oor GCP het.
Standaard kan gebruikers vrylik by Workspace groepe van die Organisasie aansluit en daardie groepe kan GCP toestemmings toegeken hê (kyk jou groepe in https://groups.google.com/).
Deur die google groups privesc te misbruik, mag jy in staat wees om op te skaal na 'n groep met een of ander soort privaat toegang tot GCP.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
