GCP - IAM Privesc
Last updated
Last updated
Pronađite više informacija o IAM-u u:
iam.roles.update
(iam.roles.get
)Napadač sa navedenim dozvolama će moći da ažurira ulogu koja vam je dodeljena i dodeli vam dodatne dozvole za druge resurse kao što su:
Možete pronaći skriptu za automatizaciju kreiranja, iskorišćavanja i čišćenja ranjivog okruženja ovde i Python skriptu za zloupotrebu ovih privilegija ovde. Za više informacija pogledajte originalno istraživanje.
iam.serviceAccounts.getAccessToken
(iam.serviceAccounts.get
)Napadač sa navedenim dozvolama će moći zahtevati pristupni token koji pripada Servisnom nalogu, tako da je moguće zahtevati pristupni token Servisnog naloga sa više privilegija od naših.
Možete pronaći skriptu za automatizaciju kreiranja, iskorišćavanja i čišćenja ranjivog okruženja ovde i Python skriptu za zloupotrebu ovih privilegija ovde. Za više informacija pogledajte originalno istraživanje.
iam.serviceAccountKeys.create
Napadač sa navedenim dozvolama će moći kreirati korisnički upravljani ključ za Servisni nalog, što će nam omogućiti pristup GCP-u kao taj Servisni nalog.
Možete pronaći skriptu za automatizaciju kreiranje, iskorišćavanje i čišćenje ranjivog okruženja ovde i Python skriptu za zloupotrebu ovih privilegija ovde. Za više informacija pogledajte originalno istraživanje.
Imajte na umu da iam.serviceAccountKeys.update
neće raditi za izmenu ključa servisnog naloga jer je za to takođe potrebna dozvola iam.serviceAccountKeys.create
.
iam.serviceAccounts.implicitDelegation
Ako imate dozvolu iam.serviceAccounts.implicitDelegation
na servisnom nalogu koji ima dozvolu iam.serviceAccounts.getAccessToken
na trećem servisnom nalogu, tada možete koristiti implicitDelegation da kreirate token za taj treći servisni nalog. Evo dijagrama koji će vam pomoći da razumete.
Možete pronaći skriptu za automatizaciju kreiranje, iskorišćavanje i čišćenje ranjivog okruženja ovde i Python skriptu za zloupotrebu ovih privilegija ovde. Za više informacija pogledajte originalno istraživanje.
Imajte na umu da prema dokumentaciji, delegacija radi samo za generisanje tokena koristeći metodu generateAccessToken().
iam.serviceAccounts.signBlob
Napadač sa pomenutim dozvolama će moći da potpiše proizvoljne podatke u GCP-u. Tako će biti moguće kreirati nepotpisani JWT servisnog naloga, a zatim ga poslati kao blob da bi se JWT potpisao od strane ciljanog servisnog naloga. Za više informacija pročitajte ovo.
Možete pronaći skriptu za automatizaciju kreiranje, iskorišćavanje i čišćenje ranjivog okruženja ovde i Python skriptu za zloupotrebu ovih privilegija ovde i ovde. Za više informacija pogledajte originalno istraživanje.
iam.serviceAccounts.signJwt
Napadač sa pomenutim dozvolama će moći da potpiše dobro oblikovane JSON web tokene (JWT). Razlika u odnosu na prethodnu metodu je što umesto da tražimo od Google-a da potpiše blob koji sadrži JWT, koristimo metodu signJWT koja već očekuje JWT. To olakšava upotrebu, ali možete potpisivati samo JWT umesto bilo kojih bajtova.
Možete pronaći skriptu za automatizaciju kreiranje, iskorišćavanje i čišćenje ranjivog okruženja ovde i Python skriptu za zloupotrebu ovih privilegija ovde. Za više informacija pogledajte originalno istraživanje.
iam.serviceAccounts.setIamPolicy
Napadač sa pomenutim dozvolama će moći da doda IAM politike servisnim nalozima. Možete to zloupotrebiti da biste sebi dodelili dozvole koje su vam potrebne da biste se predstavljali kao servisni nalog. U sledećem primeru dodeljujemo sebi ulogu roles/iam.serviceAccountTokenCreator
nad interesantnim servisnim nalogom:
Možete pronaći skriptu za automatizaciju kreiranja, iskorišćavanja i čišćenja ranjivog okruženja ovde.
iam.serviceAccounts.actAs
Dozvola iam.serviceAccounts.actAs je slična dozvoli iam:PassRole iz AWS-a. Neophodna je za izvršavanje zadataka, poput pokretanja instance Compute Engine, jer omogućava "delovanje kao" servisni nalog, obezbeđujući sigurno upravljanje dozvolama. Bez ove dozvole, korisnici mogu dobiti neovlašćen pristup. Dodatno, iskorišćavanje iam.serviceAccounts.actAs uključuje različite metode, pri čemu svaka zahteva određeni set dozvola, za razliku od drugih metoda koje zahtevaju samo jednu.
Impersonacija servisnog naloga može biti veoma korisna za dobijanje novih i boljih privilegija. Postoje tri načina na koja možete impersonirati drugi servisni nalog:
Autentifikacija korišćenjem RSA privatnih ključeva (pokriveno gore)
Autorizacija korišćenjem Cloud IAM politika (pokriveno ovde)
Implementacija poslova na GCP uslugama (više se odnosi na kompromitovanje korisničkog naloga)
iam.serviceAccounts.getOpenIdToken
Napadač sa pomenutim dozvolama će biti u mogućnosti da generiše OpenID JWT. Oni se koriste za potvrdu identiteta i ne nose nužno implicitnu autorizaciju za pristup resursu.
Prema ovom interesantnom postu, neophodno je navesti publiku (servis gde želite da koristite token za autentifikaciju) i dobićete JWT potpisan od strane Google-a koji pokazuje servisni nalog i publiku JWT-a.
Možete generisati OpenIDToken (ako imate pristup) sa:
Onda ga možete koristiti da pristupite usluzi sa:
Neke usluge koje podržavaju autentifikaciju putem ovakvih tokena su:
Google Cloud Endpoints (ako koristite Google OIDC)
Primer kako kreirati OpenID token u ime servisnog naloga možete pronaći ovde.