Serbian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP <--> Workspace Pivoting

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

Od GCP-a do GWS-a

Osnove Delegacije na Nivou Domena

Delegacija na nivou domena u Google Workspace-u omogućava objektu identiteta, bilo da je to spoljni aplikacija sa Google Workspace Marketplace-a ili interni GCP Servisni Nalog, da pristupi podacima širom Workspace-a u ime korisnika.

Ovo u osnovi znači da servisni nalozi unutar GCP projekata organizacije mogu impersonirati korisnike Workspace-a iste organizacije (ili čak iz druge).

Za više informacija o tome kako tačno funkcioniše, pogledajte:

GCP - Understanding Domain-Wide Delegation

Kompromitovanje postojeće delegacije

Ako napadač kompromituje neki pristup preko GCP-a i zna validan email korisnika Workspace-a (po mogućstvu super admina) kompanije, mogao bi enumerisati sve projekte do kojih ima pristup, enumerisati sve servisne naloge projekata, proveriti na koje servisne naloge ima pristup, i ponoviti sve ove korake sa svakim SA-om kojeg može impersonirati. Sa listom svih servisnih naloga do kojih ima pristup i listom emailova Workspace-a, napadač bi mogao pokušati da impersonira korisnika sa svakim servisnim nalogom.

Imajte na umu da prilikom konfigurisanja delegacije na nivou domena nije potreban korisnik Workspace-a, stoga je dovoljno znati jednog validnog i potrebnog korisnika za impersonaciju. Međutim, privilegije impersoniranog korisnika će biti korišćene, pa ako je to Super Admin, bićete u mogućnosti pristupiti svemu. Ako nema nikakav pristup, ovo će biti beskorisno.

GCP Generisanje Delegacionog Tokena

Ovaj jednostavan skript će generisati OAuth token kao delegirani korisnik koji zatim možete koristiti za pristup drugim Google API-ima sa ili bez 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

Ovo je alat koji može izvršiti napad prateći ove korake:

  1. Nabrajanje GCP projekata korišćenjem Resource Manager API-ja.

  2. Iteriranje kroz svaki resurs projekta, i nabrajanje resursa GCP servisnih naloga kojima početni IAM korisnik ima pristup korišćenjem GetIAMPolicy.

  3. Iteriranje kroz svaku ulogu servisnog naloga, i pronalaženje ugrađenih, osnovnih i prilagođenih uloga sa dozvolom serviceAccountKeys.create na ciljnom resursu servisnog naloga. Treba napomenuti da uloga Editor inherentno poseduje ovu dozvolu.

  4. Kreiranje novog KEY_ALG_RSA_2048 privatnog ključa za svaki resurs servisnog naloga koji je pronađen sa relevantnom dozvolom u IAM politici.

  5. Iteriranje kroz svaki novi servisni nalog i kreiranje JWT objekta za njega koji se sastoji od kredencijala privatnog ključa SA i OAuth opsega. Proces kreiranja novog JWT objekta će iterirati kroz sve postojeće kombinacije OAuth opsega iz liste oauth_scopes.txt, kako bi pronašao sve mogućnosti delegacije. Lista oauth_scopes.txt je ažurirana sa svim OAuth opsezima koje smo smatrali relevantnim za zloupotrebu identiteta Workspace-a.

  6. Metoda _make_authorization_grant_assertion otkriva potrebu za deklarisanjem ciljnog korisnika Workspace-a, nazvanog subject, za generisanje JWT-ova pod DWD. Iako se može činiti da je potreban određeni korisnik, važno je shvatiti da DWD utiče na svaki identitet unutar domena. Stoga, kreiranje JWT-a za bilo kog korisnika domena utiče na sve identitete u tom domenu, u skladu sa našom proverom kombinacija. Jednostavno rečeno, jedan važeći Workspace korisnik je dovoljan za nastavak. Ovaj korisnik može biti definisan u config.yaml fajlu DeleFriend-a. Ako ciljni korisnik Workspace-a već nije poznat, alat omogućava automatsko identifikovanje validnih korisnika Workspace-a skeniranjem korisnika domena sa ulogama na GCP projektima. Važno je napomenuti (ponovo) da su JWT-ovi specifični za domen i ne generišu se za svakog korisnika; stoga, automatski proces cilja na jedan jedinstveni identitet po domenu.

  7. Nabrajanje i kreiranje novog bearer pristupnog tokena za svaki JWT i validacija tokena protiv tokeninfo API-ja.

Gitlab-ov Python skript

Gitlab je kreirao ovu Python skriptu koja može obaviti dve stvari - izlistati korisnički direktorijum i kreirati novi administratorski nalog dok pokazuje json sa SA kredencijalima i korisnikom za impersonaciju. Evo kako biste je koristili:

# 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

Kreiranje nove delegacije (Održivost)

Moguće je proveriti Delegacije na nivou domena na https://admin.google.com/u/1/ac/owl/domainwidedelegation.

Napadač sa sposobnošću kreiranja servisnih naloga u GCP projektu i super admin privilegijom u GWS može kreirati novu delegaciju koja omogućava servisnim nalozima da se predstavljaju kao neki GWS korisnici:

  1. Generisanje novog servisnog naloga i odgovarajućeg para ključeva: Na GCP-u, nove resurse servisnih naloga možemo proizvesti interaktivno putem konzole ili programski korišćenjem direktnih API poziva i CLI alata. Ovo zahteva ulogu iam.serviceAccountAdmin ili bilo koju prilagođenu ulogu opremljenu sa dozvolom iam.serviceAccounts.create. Kada je servisni nalog kreiran, nastavljamo sa generisanjem povezanog para ključeva (dozvola iam.serviceAccountKeys.create).

  2. Kreiranje nove delegacije: Važno je razumeti da samo uloga Super Admin poseduje sposobnost postavljanja globalne Delegacije na nivou domena u Google Workspace-u i Delegacija na nivou domena ne može biti postavljena programski, Može biti samo kreirana i prilagođena ručno putem Google Workspace konzole.

  • Pravilo za kreiranje može se pronaći na stranici API kontrole → Upravljanje Delegacijom na nivou domena u Google Workspace Admin konzoli.

  1. Povezivanje privilegija OAuth opsega: Prilikom konfigurisanja nove delegacije, Google zahteva samo 2 parametra, Client ID, koji je OAuth ID GCP Servisnog naloga resursa, i OAuth opsege koji definišu koje API pozive delegacija zahteva.

  • Puna lista OAuth opsega može se pronaći ovde, ali evo preporuke: 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. Delovanje u ime ciljnog identiteta: U ovom trenutku, imamo funkcionalni delegirani objekat u GWS. Sada, korišćenjem privatnog ključa GCP Servisnog naloga, možemo izvršiti API pozive (u opsegu definisanom u OAuth opsegu parametra) da ga pokrenemo i delujemo u ime bilo kog identiteta koji postoji u Google Workspace-u. Kako smo saznali, servisni nalog će generisati pristupne tokene prema svojim potrebama i prema dozvolama koje ima za REST API aplikacije.

  • Proverite prethodni odeljak za neke alate za korišćenje ove delegacije.

Delegacija preko organizacija

OAuth SA ID je globalan i može se koristiti za delegaciju preko organizacija. Nije implementirana nikakva restrikcija koja sprečava prekograničnu delegaciju. Jednostavno rečeno, servisni nalozi iz različitih GCP organizacija mogu se koristiti za konfigurisanje delegacije na nivou domena u drugim Workspace organizacijama. To bi rezultiralo u tome da je potrebno samo Super Admin pristup Workspace-u, a ne pristup istom GCP nalogu, jer napadač može kreirati Servisne naloge i privatne ključeve na svom lično kontrolisanom GCP nalogu.

Kreiranje projekta radi enumeracije Workspace-a

Podrazumevano, Workspace korisnici imaju dozvolu da kreiraju nove projekte, i kada se novi projekat kreira, kreator dobija ulogu Vlasnika nad njim.

Stoga, korisnik može kreirati projekat, omogućiti API-je radi enumeracije Workspace-a u svom novom projektu i pokušati je enumerisati.

Da bi korisnik mogao da enumeriše Workspace, takođe mu je potrebno dovoljno Workspace privilegija (neće svaki korisnik moći da enumeriše direktorijum).

# 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>

Proverite više enumeracije u:

GCP - IAM, Principals & Org Policies Enum

Zloupotreba Gcloud-a

Možete pronaći dodatne informacije o gcloud toku za prijavljivanje u:

GCP - Non-svc Persistance

Kao što je objašnjeno tamo, gcloud može zatražiti opseg https://www.googleapis.com/auth/drive što bi omogućilo korisniku pristup drajvu korisnika. Kao napadač, ako ste fizički kompromitovali računar korisnika i korisnik je i dalje prijavljen na svoj nalog, možete se prijaviti generisanjem tokena sa pristupom drajvu korišćenjem:

gcloud auth login --enable-gdrive-access

Ako napadač kompromituje računar korisnika, takođe može izmeniti datoteku google-cloud-sdk/lib/googlecloudsdk/core/config.py i dodati u CLOUDSDK_SCOPES opseg 'https://www.googleapis.com/auth/drive':

Stoga, sledeći put kada se korisnik prijavi, kreiraće token sa pristupom drajvu koji napadač može zloupotrebiti da pristupi drajvu. Očigledno je da će pretraživač naznačiti da će generisani token imati pristup drajvu, ali kako će korisnik sam pozvati gcloud auth login, verovatno neće posumnjati ništa.

Za listanje drajv fajlova: curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"

Od GWS do GCP

Pristup privilegovanim GCP korisnicima

Ako napadač ima potpuni pristup nad GWS-om, moći će da pristupi grupama sa privilegovanim pristupom nad GCP-om ili čak korisnicima, stoga prelazak sa GWS-a na GCP je obično "jednostavniji" jer korisnici u GWS-u imaju visoke privilegije nad GCP-om.

Eskalacija privilegija Google grupa

Podrazumevano, korisnici mogu slobodno pristupiti Workspace grupama Organizacije i te grupe mogu imati dodeljene GCP dozvole (proverite svoje grupe na https://groups.google.com/).

Zloupotrebom google grupne eskalacije privilegija možda ćete moći da pređete na grupu sa nekom vrstom privilegovanog pristupa GCP-u.

Reference

Naučite hakovanje AWS-a od nule do heroja sa htARTE (HackTricks AWS Red Team Expert)!

Drugi načini podrške HackTricks-u:

PreviousGCP - Storage EnumNextGCP - Understanding Domain-Wide Delegation

Last updated