GCP - Basiese Inligting

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!
• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

Hulpbron hiërargie

Google Cloud gebruik ’n Hulpbron hiërargie wat konseptueel soortgelyk is aan dié van ’n tradisionele lêerstelsel. Dit bied ’n logiese ouer/kind werksvloei met spesifieke aanhegpunte vir beleide en toestemmings.

Op ’n hoë vlak lyk dit soos volg:

Organization
--> Folders
--> Projects
--> Resources

’n Virtuele masjien (genoem ’n Compute Instance) is ’n hulpbron. ’n Hulpbron woon in ’n projek, waarskynlik langs ander Compute Instances, stoor emmers, ens.

Projek Migrasie

Dit is moontlik om ’n projek sonder enige organisasie na ’n organisasie met die toestemmings roles/resourcemanager.projectCreator en roles/resourcemanager.projectMover te migreer. As die projek binne ’n ander organisasie is, is dit nodig om GCP-ondersteuning te kontak om eerstens uit die organisasie te beweeg. Vir meer inligting, kyk na hierdie.

Organisasie Beleide

Laat jou toe om sentrale beheer oor jou organisasie se wolkhulpbronne te hê:

• Sentrale beheer om beperkings te konfigureer oor hoe jou organisasie se hulpbronne gebruik kan word.
• Definieer en stel grenslyne vas vir jou ontwikkelingspan om binne nakomingsgrense te bly.
• Help projek eienaars en hul spanne om vinnig te beweeg sonder om bekommerd te wees oor die oortreding van nakomings.

Hierdie beleide kan geskep word om die hele organisasie, vouer(s) of projek(te) te affekteer. Afstammelinge van die geteikende hulpbron hiërargie node erf die organisasie beleid.

Om ’n organisasie beleid te definieer, kies jy ’n beperking, wat ’n spesifieke tipe beperking teenoor ’n Google Cloud diens of ’n groep Google Cloud dienste is. Jy konfigureer daardie beperking met jou gewenste beperkings.

Algemene gebruiksgevalle

• Beperk hulpbrondeling gebaseer op domein.
• Beperk die gebruik van Identiteit en Toegang Bestuur diens rekeninge.
• Beperk die fisiese ligging van nuut geskepte hulpbronne.
• Deaktiveer diensrekening skepping.

Daar is baie meer beperkings wat jou fyn beheer oor jou organisasie se hulpbronne gee. Vir meer inligting, sien die lys van alle Organisasie Beleid Diens beperkings.

Standaard Organisasie Beleide

IAM Rolle

Hierdie is soos IAM beleide in AWS aangesien elke rol ’n stel toestemmings bevat.

Echter, anders as in AWS, is daar geen gesentraliseerde repo van rolle nie. In plaas daarvan, gee hulpbronne X toegang rolle aan Y prinsipes, en die enigste manier om uit te vind wie toegang tot ’n hulpbron het, is om die get-iam-policy metode oor daardie hulpbron te gebruik.
Dit kan ’n probleem wees omdat dit beteken dat die enigste manier om uit te vind watter toestemmings ’n prinsipe het, is om elke hulpbron te vra wie dit toestemming gee, en ’n gebruiker mag nie toestemming hê om toestemming van alle hulpbronne te kry nie.

Daar is drie tipes rolle in IAM:

• Basiese/Primitive rolle, wat die Eienaar, Redigeerder, en Kykers rolle insluit wat voor die bekendstelling van IAM bestaan het.
• Vooraf gedefinieerde rolle, wat fyn toegang bied vir ’n spesifieke diens en deur Google Cloud bestuur word. Daar is baie vooraf gedefinieerde rolle, jy kan almal daarvan met die voorregte wat hulle het hier sien.
• Pasgemaakte rolle, wat fyn toegang bied volgens ’n gebruiker-gespesifiseerde lys van toestemmings.

Daar is duisende toestemmings in GCP. Om te kyk of ’n rol ’n toestemming het, kan jy hier die toestemming soek en sien watter rolle dit het.

Jy kan ook hier vooraf gedefinieerde rolle soek wat deur elke produk aangebied word. Let daarop dat sommige rolle nie aan gebruikers geheg kan word nie en slegs aan SA’s omdat sommige toestemmings wat hulle bevat.
Boonop, let daarop dat toestemmings slegs in werking sal tree as hulle aan die relevante diens geheg is.

Of kyk of ’n pasgemaakte rol ’n spesifieke toestemming hier kan gebruik.

GCP - IAM, Principals & Org Policies Enum

Gebruikers

In GCP-konsol is daar geen Gebruikers of Groepe bestuur nie, dit word in Google Workspace gedoen. Alhoewel jy ’n ander identiteitsverskaffer in Google Workspace kan sinkroniseer.

Jy kan Workspaces gebruikers en groepe in https://admin.google.com benader.

MFA kan gedwonge word vir Workspaces gebruikers, egter, ’n aanvaller kan ’n token gebruik om GCP via cli te benader wat nie deur MFA beskerm sal word nie (dit sal slegs deur MFA beskerm word wanneer die gebruiker aanmeld om dit te genereer: gcloud auth login).

Groepe

Wanneer ’n organisasie geskep word, word verskeie groepe sterk aanbeveel om geskep te word. As jy enige van hulle bestuur, mag jy al die of ’n belangrike deel van die organisasie gecompromitteer het:

Standaard Wagwoord Beleid

• Handhaaf sterk wagwoorde
• Tussen 8 en 100 karakters
• Geen hergebruik
• Geen vervaldatum
• As mense toegang tot Workspace deur ’n derdeparty verskaffer, word hierdie vereistes nie toegepas nie.

Diensrekeninge

Dit is die prinsipes wat hulpbronne kan he geheg en toegang het om maklik met GCP te interaksie. Byvoorbeeld, dit is moontlik om die auth token van ’n Diensrekening geheg aan ’n VM in die metadata te benader.
Dit is moontlik om ’n paar konflikte te ondervind wanneer jy beide IAM en toegang skope gebruik. Byvoorbeeld, jou diensrekening mag die IAM rol van compute.instanceAdmin hê, maar die instansie wat jy gecompromitteer het, is beperk met die skopbeperking van https://www.googleapis.com/auth/compute.readonly. Dit sal jou verhinder om enige veranderinge te maak met die OAuth token wat outomaties aan jou instansie toegeken word.

Dit is soortgelyk aan IAM rolle van AWS. Maar nie soos in AWS nie, kan enige diensrekening aan enige diens geheg word (dit hoef nie via ’n beleid toegelaat te word nie).

Verskeie van die diensrekeninge wat jy sal vind, is eintlik outomaties gegenereer deur GCP wanneer jy ’n diens begin gebruik, soos:

PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com

Dit is egter ook moontlik om aangepaste diensrekeninge te skep en aan hulpbronne te koppel, wat soos volg sal lyk:

SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com

Sleutels & Tokens

Daar is 2 hoof maniere om GCP as ’n diensrekening te benader:

• Via OAuth tokens: Dit is tokens wat jy sal ontvang van plekke soos metadata eindpunte of deur http versoeke te steel en hulle is beperk deur die toegang skope.
• Sleutels: Dit is publieke en private sleutelpare wat jou sal toelaat om versoeke as die diensrekening te teken en selfs OAuth tokens te genereer om aksies as die diensrekening uit te voer. Hierdie sleutels is gevaarlik omdat dit meer ingewikkeld is om te beperk en te beheer, daarom beveel GCP aan om hulle nie te genereer nie.
• Let daarop dat elke keer as ’n SA geskep word, GCP ’n sleutel vir die diensrekening genereer wat die gebruiker nie kan toegang nie (en nie in die webtoepassing gelys sal word nie). Volgens hierdie draad word hierdie sleutel intern deur GCP gebruik om metadata eindpunte toegang te gee om die toeganklike OAuth tokens te genereer.

Toegang skope

Toegang skope is aangewend op gegenereerde OAuth tokens om toegang tot die GCP API eindpunte te verkry. Hulle beperk die toestemmings van die OAuth token.
Dit beteken dat as ’n token aan ’n Eienaar van ’n hulpbron behoort, maar nie die in die token skoop het om daardie hulpbron te benader nie, die token nie gebruik kan word om (mis)bruik van daardie voorregte te maak nie.

Google beveel eintlik aan dat toegang skope nie gebruik word nie en heeltemal op IAM staatgemaak word. Die webbestuursportaal handhaaf dit eintlik, maar toegang skope kan steeds op instansies toegepas word deur middel van pasgemaakte diensrekeninge programmaties.

Jy kan sien watter skope toegeken is deur te vra:

curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}

Die vorige scopes is diegene wat per ongeluk gegenereer is met gcloud om toegang tot data te verkry. Dit is omdat wanneer jy gcloud gebruik, jy eers ’n OAuth-token skep, en dit dan gebruik om die eindpunte te kontak.

Die belangrikste scope van hulle is waarskynlik cloud-platform, wat basies beteken dat dit moontlik is om toegang tot enige diens in GCP te verkry.

Jy kan ’n lys van alle moontlike scopes hier vind.

As jy gcloud blaaierskredensies het, is dit moontlik om ’n token met ander scopes te verkry, deur iets soos te doen:

# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
gcloud auth application-default print-access-token

# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"

Terraform IAM Beleide, Bindings en Lidmaatskappe

Soos gedefinieer deur terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam gebruik maak van terraform met GCP, is daar verskillende maniere om ’n prinsiep toegang tot ’n hulpbron te gee:

• Lidmaatskappe: Jy stel prinsipes as lede van rolle sonder beperkings oor die rol of die prinsipes. Jy kan ’n gebruiker as ’n lid van ’n rol stel en dan ’n groep as ’n lid van dieselfde rol stel en ook daardie prinsipes (gebruiker en groep) as lede van ander rolle stel.
• Bindings: Verskeie prinsipes kan aan ’n rol gebind word. Daardie prinsipes kan steeds aan ander rolle gebind of lede daarvan wees. As ’n prinsiep wat nie aan die rol gebind is nie, as lid van ’n gebinde rol gestel word, sal die volgende keer wanneer die binding toegepas word, die lidmaatskap verdwyn.
• Beleide: ’n beleid is geauthoritief, dit dui rolle en prinsipes aan en dan, kan daardie prinsipes nie meer rolle hê nie en daardie rolle kan nie meer prinsipes hê nie tensy daardie beleid gewysig word (nie eers in ander beleide, bindings of lidmaatskappe nie). Daarom, wanneer ’n rol of prinsiep in ’n beleid gespesifiseer word, is al sy voorregte beperk deur daardie beleid. Dit kan natuurlik omseil word as die prinsiep die opsie gegee word om die beleid of voorregte-eskalasie toestemmings te wysig (soos om ’n nuwe prinsiep te skep en hom aan ’n nuwe rol te bind).

Verwysings

• https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/
• https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

• Kyk na die subskripsie planne!
• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
• Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.