Afrikaans - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP <--> Workspace Pivoting

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Vanaf GCP na GWS

Basiese domeinwye delegasie

Google Workspace se Domeinwye delegasie maak dit vir 'n identiteitsobjek, of 'n eksterne toepassing van Google Workspace Marketplace of 'n interne GCP-diensrekening, moontlik om data regoor die Workspace namens gebruikers te benader.

Dit beteken basies dat diensrekeninge binne GCP-projekte van 'n organisasie moontlik kan optree as Workspace-gebruikers van dieselfde organisasie (of selfs van 'n ander een).

Vir meer inligting oor hoe dit presies werk, kyk na:

GCP - Understanding Domain-Wide Delegation

Kompromitteer bestaande delegasie

As 'n aanvaller toegang tot GCP gekompromitteer het en 'n geldige Workspace-gebruiker se e-posadres ken (verkieslik super-admin) van die maatskappy, kan hy alle projekte opnoem waarop hy toegang het, alle diensrekeninge van die projekte opnoem, nagaan aan watter diensrekeninge hy toegang het, en herhaal al hierdie stappe met elke DR wat hy kan optree. Met 'n lys van al die diensrekeninge waarop hy toegang het en die lys van Workspace-e-posse, kan die aanvaller probeer om elke gebruiker met elke diensrekening te impersoneer.

Let daarop dat wanneer die domeinwye delegasie gekonfigureer word, geen Workspace-gebruiker benodig word nie, daarom is net een geldige een genoeg en nodig vir die impersoneering. Die privileges van die geïmpersoneerde gebruiker sal egter gebruik word, dus as dit 'n Super Admin is, sal jy alles kan benader. As dit geen toegang het nie, sal dit nutteloos wees.

GCP Genereer Delegasie-token

Hierdie eenvoudige skripsie sal 'n OAuth-token genereer as die gedelegeerde gebruiker wat jy dan kan gebruik om ander Google-API's mee te benader met of sonder gcloud:

# Impersonate indicated user
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>

# Impersonate indicated user and add additional scopes
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file> --scopes "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"

DeleFriend

Dit is 'n instrument wat die aanval kan uitvoer deur hierdie stappe te volg:

  1. Enumerate GCP Projekte deur die gebruik van die Resource Manager API.

  2. Itereer op elke projekbron, en enumerate GCP Diensrekeningbronne waartoe die aanvanklike IAM-gebruiker toegang het deur GetIAMPolicy te gebruik.

  3. Itereer op elke diensrekeningrol, en vind ingeboude, basiese, en aangepaste rolle met serviceAccountKeys.create toestemming op die teiken diensrekeningbron. Dit moet genoteer word dat die Editor rol hierdie toestemming inherent besit.

  4. Skep 'n nuwe KEY_ALG_RSA_2048 privaatsleutel vir elke diensrekeningbron wat gevind is met die relevante toestemming in die IAM-beleid.

  5. Itereer op elke nuwe diensrekening en skep 'n JWT objek daarvoor wat saamgestel is uit die SA privaatsleutelgelde en 'n OAuth-skoop. Die proses om 'n nuwe JWT objek te skep sal itereer op al die bestaande kombinasies van OAuth-skopes van oauth_scopes.txt lys, om al die delegasiemoontlikhede te vind. Die lys oauth_scopes.txt word opgedateer met al die OAuth-skopes wat ons gevind het as relevant vir die misbruik van Workspace-identiteite.

  6. Die _make_authorization_grant_assertion metode onthul die noodsaaklikheid om 'n teiken werkspasiegebruiker te verklaar, verwys as onderwerp, vir die genereer van JWT's onder DWD. Alhoewel dit mag lyk asof 'n spesifieke gebruiker benodig word, is dit belangrik om te besef dat DWD elke identiteit binne 'n domein beïnvloed. Gevolglik, die skep van 'n JWT vir enige domeingebruiker beïnvloed alle identiteite in daardie domein, konsekwent met ons kombinasie-opnoemtoets. Eenvoudig gestel, een geldige Workspace-gebruiker is voldoende om voort te gaan. Hierdie gebruiker kan in DeleFriend se config.yaml lêer gedefinieer word. As 'n teiken werkspasiegebruiker nie reeds bekend is nie, fasiliteer die instrument die outomatiese identifikasie van geldige werkspasiegebruikers deur domeingebruikers met rolle op GCP-projekte te skandeer. Dit is belangrik om te let (weereens) dat JWT's domeinspesifiek is en nie vir elke gebruiker gegenereer word nie; dus, teiken die outomatiese proses 'n enkele unieke identiteit per domein.

  7. Enumerate en skep 'n nuwe draer-toegangsteken vir elke JWT en valideer die teken teen die tokeninfo API.

Gitlab se Python-skrip

Gitlab het hierdie Python-skrip geskep wat twee dinge kan doen - die gebruikersgids lys en 'n nuwe administratiewe rekening skep terwyl 'n json met SA-gelde en die gebruiker om te impersoneer aangedui word. Hier is hoe jy dit sou gebruik:

# Install requirements
pip install --upgrade --user oauth2client

# Validate access only
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com

# List the directory
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--list

# Create a new admin account
./gcp_delegation.py --keyfile ./credentials.json \
--impersonate steve.admin@target-org.com \
--domain target-org.com \
--account pwned

Skep 'n nuwe delegasie (Volharding)

Dit is moontlik om Domeinwye Delegasies te kontroleer in https://admin.google.com/u/1/ac/owl/domainwidedelegation.

'n Aanvaller met die vermoë om diensrekeninge in 'n GCP-projek te skep en **super-admin-voorregte vir GWS te hê, kan 'n nuwe delegasie skep wat SAs toelaat om sommige GWS-gebruikers te impersoneer:

  1. Die Skep van 'n Nuwe Diensrekening en Ooreenstemmende Sleutelpaar: Op GCP kan nuwe diensrekeningbronne óf interaktief via die konsole geproduseer word óf programmaties deur direkte API-oproepe en CLI-hulpmiddels te gebruik. 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 sleutelpaar te genereer (iam.serviceAccountKeys.create toestemming).

  2. Die Skep van 'n nuwe delegasie: Dit is belangrik om te verstaan dat slegs die Super Admin-rol die vermoë besit om globale Domeinwye delegasie in Google Workspace op te stel en Domeinwye delegasie kan nie programmaties opgestel word nie, Dit kan slegs handmatig deur die Google Workspace konsole geskep en aangepas word.

  • Die skepping van die reël kan gevind word onder die bladsy API-beheer → Bestuur Domeinwye delegasie in die Google Workspace Admin-konsole.

  1. Die Koppel van OAuth-skope-voorreg: Wanneer 'n nuwe delegasie gekonfigureer word, vereis Google slegs 2 parameters, die Kliënt-ID, wat die OAuth-ID van die GCP Diensrekening-bron is, en OAuth-skope wat definieer watter API-oproepe die delegasie benodig.

  • Die volledige lys van OAuth-skope kan hier gevind word hier, 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

  1. Optrede namens die teikenidentiteit: Op hierdie punt het ons 'n funksionerende gedelegeerde objek in GWS. Nou kan ons, deur die gebruik van die GCP Diensrekening privaatsleutel, API-oproepe uitvoer (binne die omvang wat in die OAuth-skop-parameter gedefinieer is) 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 hulpmiddels om hierdie delegasie te gebruik.

Kruis-organisatoriese delegasie

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 kan diensrekeninge van verskillende GCP-organisasies gebruik word om domeinwye delegasie op ander Workspace-organisasies te konfigureer. Dit sou daartoe lei dat daar slegs Super Admin-toegang tot Workspace benodig word, en nie toegang tot dieselfde GCP-rekening nie, aangesien die teenstander diensrekeninge en privaatsleutels op sy persoonlik beheerde GCP-rekening kan skep.

Die Skep van 'n Projek om Workspace op te som

Standaard het Workspace-gebruikers die toestemming om nuwe projekte te skep, en wanneer 'n nuwe projek geskep word, kry die skepper die Eienaar-rol daaroor.

Daarom kan 'n gebruiker 'n projek skep, die API's aktiveer om Workspace in sy nuwe projek op te som en probeer om dit te opsom.

Om 'n gebruiker in staat te stel om Workspace op te som, benodig hy ook genoeg Workspace-toestemmings (nie elke gebruiker sal in staat wees om die gids op te som nie).

# Create project
gcloud projects create <uniq-projec-name> --name=proj-name
# Set project
gcloud config set project <uniq-projec-name>
# Enable svcs
gcloud services enable admin.googleapis.com
gcloud services enable cloudidentity.googleapis.com
# Get org ID
gcloud organizations list
# Get currents email user groups (at least you can check the groups and members of the groups you belong to)
gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
gcloud identity groups memberships list --group-email=g<group-email>

# FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
gcloud beta identity groups preview --customer <org-cust-id>

Kyk meer opsporing in:

GCP - IAM, Principals & Org Policies Enum

Misbruik van Gcloud

Jy kan meer inligting vind oor die gcloud vloei om in te teken in:

GCP - Non-svc Persistance

Soos daar verduidelik is, kan gcloud die omvang https://www.googleapis.com/auth/drive aanvra wat 'n gebruiker in staat sou stel om toegang tot die gebruiker se aandrywing te verkry. As 'n aanvaller, as jy fisies die rekenaar van 'n gebruiker gekompromiteer het en die gebruiker is nog steeds ingeteken met sy rekening, kan jy inlog deur 'n token te genereer met toegang tot die aandrywing met behulp van:

gcloud auth login --enable-gdrive-access

Indien 'n aanvaller die rekenaar van 'n gebruiker kompromitteer, kan hy ook die lêer google-cloud-sdk/lib/googlecloudsdk/core/config.py wysig en die omvang CLOUDSDK_SCOPES die omvang 'https://www.googleapis.com/auth/drive' byvoeg:

Daarom, die volgende keer as die gebruiker inteken, sal hy 'n token met toegang tot drive skep wat die aanvaller kan misbruik om toegang tot die aandryf te verkry. Duidelik sal die webblaaier aandui dat die gegenereerde token toegang tot die aandryf sal hê, maar aangesien die gebruiker self die gcloud auth login sal aanroep, sal hy waarskynlik niks vermoed nie.

Om aandryf lêers te lys: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

Van GWS na GCP

Toegang tot bevoorregte GCP-gebruikers

Indien 'n aanvaller volledige toegang tot GWS het, sal hy in staat wees om toegang te verkry tot groepe met bevoorregte toegang tot GCP of selfs gebruikers, daarom is die beweging van GWS na GCP gewoonlik meer "eenvoudig" net omdat gebruikers in GWS hoë voorregte oor GCP het.

Google Groups Bevoorregte Eskalasie

Standaard kan gebruikers vrylik by Workspace-groepe van die Organisasie aansluit en daardie groepe mag GCP-toestemmings toegewys hê (kontroleer jou groepe by https://groups.google.com/).

Deur die google groups privesc te misbruik, kan jy moontlik eskaleer na 'n groep met 'n soort bevoorregte toegang tot GCP.

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousGCP - Storage EnumNextGCP - Understanding Domain-Wide Delegation

Last updated