GCP - IAM Privesc

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

IAM

Pronađite više informacija o IAM u:

GCP - IAM, Principals & Org Policies Enum

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

Napadač sa pomenutim dozvolama će moći da ažurira role dodeljene vama i dodeli vam dodatne dozvole nad drugim resursima, kao što su:

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

Možete pronaći skriptu za automatizaciju kreiranja, exploit-a i čišćenja vuln okruženja ovde i python skriptu za zloupotrebu ove privilegije ovde. Za više informacija pogledajte izvorno istraživanje.

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

iam.roles.create & iam.serviceAccounts.setIamPolicy

Permisija iam.roles.create omogućava kreiranje prilagođenih uloga u projektu/organizaciji. U rukama napadača, ovo je opasno jer im omogućava da definišu nove skupove dozvola koje kasnije mogu biti dodeljene entitetima (na primer, koristeći iam.serviceAccounts.setIamPolicy dozvolu) sa ciljem eskalacije privilegija.

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

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

An attacker sa pomenutim dozvolama će moći da zahteva access token koji pripada Service Account-a, tako da je moguće zatražiti access token Service Account-a koji ima više privilegija od našeg.

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

Možete pronaći skriptu koja automatizuje creation, exploit and cleaning of a vuln environment here i python skriptu za zloupotrebu ovog privilegija here. Za više informacija pogledajte original research.

iam.serviceAccountKeys.create

Napadač sa pomenutim dozvolama će moći da create a user-managed key for a Service Account, što će nam omogućiti pristup GCP-u kao taj Service Account.

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

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

Možete pronaći skriptu za automatizaciju creation, exploit and cleaning of a vuln environment here i python skriptu za zloupotrebu ove privilegije here. Za više informacija pogledajte original research.

Imajte na umu da iam.serviceAccountKeys.update won’t work to modify the key SA, jer je za to potrebna i permisija iam.serviceAccountKeys.create.

iam.serviceAccounts.implicitDelegation

Ukoliko imate dozvolu iam.serviceAccounts.implicitDelegation nad Service Account-om koji ima dozvolu iam.serviceAccounts.getAccessToken nad trećim Service Account-om, onda možete upotrebiti implicitDelegation da kreirate token za taj treći Service Account. Evo dijagrama koji pomaže da se objasni.

Imajte na umu da prema documentation, delegacija gcloud radi samo za generisanje tokena koristeći metodu generateAccessToken(). Dakle, ovde imate kako da dobijete token koristeći API direktno:

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"]
}'

Možete pronaći skriptu za automatizaciju the creation, exploit and cleaning of a vuln environment here i python skriptu za zloupotrebu ovog privilegija here. Za više informacija pogledajte original research.

iam.serviceAccounts.signBlob

Napadač sa pomenutim privilegijama moći će da potpiše proizvoljne payloads u GCP. Dakle biće moguće kreirati nepotpisani JWT od SA i potom ga poslati kao blob da bi JWT bio potpisan od strane ciljanog SA. Za više informacija read this.

Možete pronaći skriptu za automatizaciju the creation, exploit and cleaning of a vuln environment here i python skriptu za zloupotrebu ovog privilegija here i here. Za više informacija pogledajte original research.

iam.serviceAccounts.signJwt

Napadač sa pomenutim privilegijama moći će da potpiše ispravno formirane JSON web tokene (JWTs). Razlika u odnosu na prethodni metod je što umesto da google potpiše blob koji sadrži JWT, koristimo signJWT metodu koja već očekuje JWT. To ga čini lakšim za upotrebu ali možete potpisivati samo JWT umesto proizvoljnih bajtova.

Možete pronaći skriptu za automatizaciju the creation, exploit and cleaning of a vuln environment here i python skriptu za zloupotrebu ovog privilegija here. Za više informacija pogledajte original research.

iam.serviceAccounts.setIamPolicy

Napadač sa pomenutim privilegijama moći će da dodaje IAM policies na service accounts. Možete to zloupotrebiti da dodelite sebi permisije koje su vam potrebne da se lažno predstavite kao service account. U sledećem primeru dodeljujemo sebi ulogu roles/iam.serviceAccountTokenCreator nad interesantnim 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"

You can find a script to automate the creation, exploit and cleaning of a vuln environment here.

iam.serviceAccounts.actAs

Dozvola iam.serviceAccounts.actAs je kao dozvola iam:PassRole iz AWS-a. Neophodna je za izvršavanje zadataka, kao što je pokretanje Compute Engine instance, jer omogućava da “actAs” Service Account, što obezbeđuje sigurno upravljanje privilegijama. Bez nje korisnici mogu dobiti neprimeren pristup. Dodatno, eksploatisanje iam.serviceAccounts.actAs uključuje različite metode, od kojih svaka zahteva skup dozvola, za razliku od drugih metoda koje zahtevaju samo jednu.

Service account impersonation

Impersonating a service account can be very useful to obtain new and better privileges. Postoje tri načina na koja možete impersonate another service account:

  • Authentication using RSA private keys (pokazano iznad)
  • Authorization using Cloud IAM policies (pokazano ovde)
  • Deploying jobs on GCP services (više primenljivo na kompromitaciju korisničkog naloga)

iam.serviceAccounts.getOpenIdToken

Napadač sa pomenutim dozvolama moći će da generiše OpenID JWT. Oni se koriste za potvrđivanje identiteta i ne nose nužno implicitnu autorizaciju nad resursom.

Prema ovom interesting post, neophodno je navesti audience (servis na kojem želite da koristite token za autentikaciju) i dobićete JWT potpisan od strane Google-a koji označava service account i audience JWT-a.

Možete generisati OpenIDToken (ako imate pristup) pomoću:

# 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

Zatim ga možete jednostavno koristiti za pristup servisu pomoću:

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

Neke usluge koje podržavaju autentifikaciju putem ovakvih tokena su:

Primer kako da kreirate OpenID token u ime servisnog naloga možete pronaći ovde.

Reference

Tip

Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Učite i vežbajte Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks