GWS - Admin Directory Sync
PreviousGWS - Workspace Sync Attacks (GCPW, GCDS, GPS, Directory Sync with AD & EntraID)NextGCDS - Google Cloud Directory Sync
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)
Die hoof verskil tussen hierdie manier om gebruikers met GCDS te sinkroniseer is dat GCDS handmatig gedoen word met 'n paar binaries wat jy moet aflaai en uitvoer terwyl Admin Directory Sync serverloos deur Google bestuur word in https://admin.google.com/ac/sync/externaldirectories.
Op die oomblik van hierdie skrywe is hierdie diens in beta en dit ondersteun 2 tipes sinkronisasie: Van Active Directory en van Azure Entra ID:
Active Directory: Om dit op te stel moet jy toegang aan Google gee tot jou Active Directory omgewing. En aangesien Google slegs toegang het tot GCP-netwerke (via VPC connectors) moet jy 'n connector skep en dan jou AD beskikbaar maak vanaf daardie connector deur dit in VM's in die GCP-netwerk te hê of Cloud VPN of Cloud Interconnect te gebruik. Dan moet jy ook akkrediteer van 'n rekening met lees toegang oor die gids en sertifikaat om via LDAPS te kontak.
Azure Entra ID: Om dit te konfigureer is dit net nodig om in Azure aan te meld met 'n gebruiker met lees toegang oor die Entra ID subskripsie in 'n pop-up wat deur Google gewys word, en Google sal die token met lees toegang oor Entra ID hou.
Sodra dit korrek geconfigureer is, sal albei opsies toelaat om gebruikers en groepe na Workspace te sinkroniseer, maar dit sal nie toelaat om gebruikers en groepe van Workspace na AD of EntraID te configureer nie.
Ander opsies wat dit tydens hierdie sinkronisasie sal toelaat is:
Stuur 'n e-pos aan die nuwe gebruikers om in te log
Outomaties hul e-posadres verander na die een wat deur Workspace gebruik word. So as Workspace @hacktricks.xyz gebruik en EntraID gebruikers @carloshacktricks.onmicrosoft.com gebruik, sal @hacktricks.xyz gebruik word vir die gebruikers wat in die rekening geskep is.
Kies die groepe wat die gebruikers bevat wat gesinkroniseer sal word.
Kies om groepe te sinkroniseer en in Workspace te skep (of dui aan om alle groepe te sinkroniseer).
As jy daarin slaag om 'n AD of EntraID te kompromitteer, sal jy totale beheer oor die gebruikers & groepe hê wat gesinkroniseer gaan word met Google Workspace. Let egter daarop dat die wagwoorde wat die gebruikers in Workspace mag gebruik die dieselfde kan wees of nie.
Wanneer die sinkronisasie plaasvind, kan dit alle gebruikers van AD of net diegene van 'n spesifieke OU of net die gebruikers wat lede van spesifieke groepe in EntraID is sinkroniseer. Dit beteken dat om 'n gesinkroniseerde gebruiker aan te val (of 'n nuwe een te skep wat gesinkroniseer word) jy eers moet uitvind watter gebruikers gesinkroniseer word.
Gebruikers mag die wagwoord hergebruik of nie van AD of EntraID, maar dit beteken dat jy die wagwoorde van die gebruikers moet kompromitteer om in te log.
As jy toegang het tot die e-posse van die gebruikers, kan jy die Workspace wagwoord van 'n bestaande gebruiker verander, of 'n nuwe gebruiker skep, wag totdat dit gesinkroniseer word en die rekening opstel.
Sodra jy toegang tot die gebruiker binne Workspace het, kan daar 'n paar toestemmings standaard gegee word.
Jy moet ook eers uitvind watter groepe gesinkroniseer word. Alhoewel daar die moontlikheid is dat ALLES die groepe gesinkroniseer word (aangesien Workspace dit toelaat).
Let daarop dat selfs al word die groepe en lidmaatskappe in Workspace ingevoer, die gebruikers wat nie in die gebruikers sinkronisasie gesinkroniseer word nie, sal nie geskep word tydens groepe sinkronisasie nie, selfs al is hulle lede van enige van die gesinkroniseerde groepe.
As jy weet watter groepe van Azure toegangsregte in Workspace of GCP toegeken word, kan jy eenvoudig 'n gecompromitteerde gebruiker (of nuut geskep) in daardie groep voeg en daardie toestemmings verkry.
Daar is 'n ander opsie om bestaande bevoorregte groepe in Workspace te misbruik. Byvoorbeeld, die groep gcp-organization-admins@<workspace.email> het gewoonlik hoë voorregte oor GCP.
As die sinkronisasie van, byvoorbeeld EntraID, na Workspace geconfigureer is om die domein van die ingevoerde objek met die e-pos van Workspace te vervang, sal dit moontlik wees vir 'n aanvaller om die groep gcp-organization-admins@<entraid.email> in EntraID te skep, 'n gebruiker in hierdie groep toe te voeg, en wag totdat die sinkronisasie van al die groepe plaasvind.
Die gebruiker sal in die groep gcp-organization-admins@<workspace.email> bygevoeg word, wat voorregte in GCP verhoog.
Let daarop dat Workspace akkrediteer met lees slegs toegang oor AD of EntraID benodig om gebruikers en groepe te sinkroniseer. Daarom is dit nie moontlik om Google Workspace te misbruik om enige verandering in AD of EntraID te maak nie. So dit is nie moontlik op hierdie oomblik nie.
Ek weet ook nie waar Google die AD akkrediteer of EntraID token stoor nie en jy kan dit nie herstel deur die sinkronisasie te herconfigureer nie (dit verskyn nie in die webvorm nie, jy moet dit weer gee). Maar, vanaf die web kan dit moontlik wees om die huidige funksionaliteit te misbruik om gebruikers en groepe te lys.
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
