Last updated
Vind meer inligting oor IAM in:
iam.roles.update (iam.roles.get)'n Aanvaller met die genoemde toestemmings sal in staat wees om 'n rol wat aan jou toegewys is, by te werk en jou ekstra toestemmings te gee vir ander hulpbronne soos:
Jy kan 'n skripsie vind om die skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing outomaties te doen hier en 'n Python-skripsie om hierdie voorreg te misbruik hier. Vir meer inligting, kyk na die oorspronklike navorsing.
iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)'n Aanvaller met die genoemde toestemmings sal in staat wees om 'n toegangsteken aan te vra wat aan 'n Diensrekening behoort, sodat dit moontlik is om 'n toegangsteken van 'n Diensrekening met meer voorregte as ons s'n aan te vra.
Jy kan 'n skripsie vind om die skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing outomaties te doen hier en 'n Python-skripsie om hierdie voorreg te misbruik hier. Vir meer inligting, kyk na die oorspronklike navorsing.
iam.serviceAccountKeys.create'n Aanvaller met die genoemde toestemmings sal in staat wees om 'n gebruikersbestuurde sleutel vir 'n Diensrekening te skep, wat ons in staat sal stel om toegang tot GCP as daardie Diensrekening te verkry.
Jy kan 'n skripsie vind om die skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing outomaties te doen hier en 'n Python-skripsie om hierdie voorreg te misbruik hier. Vir meer inligting, kyk na die oorspronklike navorsing.
Let daarop dat iam.serviceAccountKeys.update nie sal werk om die sleutel te wysig van 'n SA nie, omdat die toestemmings iam.serviceAccountKeys.create ook nodig is om dit te doen.
iam.serviceAccounts.implicitDelegationAs jy die iam.serviceAccounts.implicitDelegation toestemming het op 'n Diensrekening wat die iam.serviceAccounts.getAccessToken toestemming het op 'n derde Diensrekening, kan jy die implicitDelegation gebruik om 'n token vir daardie derde Diensrekening te skep. Hier is 'n diagram om te help verduidelik.
Jy kan 'n skripsie vind om die skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing outomaties te doen hier en 'n Python-skripsie om hierdie voorreg te misbruik hier. Vir meer inligting, kyk na die oorspronklike navorsing.
Let daarop dat volgens die dokumentasie, werk die delegasie slegs om 'n token te genereer deur die generateAccessToken() metode te gebruik.
iam.serviceAccounts.signBlob'n Aanvaller met die genoemde toestemmings sal in staat wees om arbitrêre nutslading in GCP te onderteken. Dit sal dus moontlik wees om 'n onondertekende JWT van die SA te skep en dit dan as 'n blob te stuur om die JWT deur die SA wat ons teiken, te laat onderteken. Vir meer inligting lees hierdie.
Jy kan 'n skripsie vind om die skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing outomaties te doen hier en 'n Python-skripsie om hierdie voorreg te misbruik hier en hier. Vir meer inligting, kyk na die oorspronklike navorsing.
iam.serviceAccounts.signJwt'n Aanvaller met die genoemde toestemmings sal in staat wees om goedgevormde JSON-webtokens (JWT's) te onderteken. Die verskil met die vorige metode is dat in plaas daarvan om Google 'n blob te laat onderteken wat 'n JWT bevat, gebruik ons die signJWT-metode wat reeds 'n JWT verwag. Dit maak dit makliker om te gebruik, maar jy kan slegs JWT's onderteken in plaas van enige bytes.
Jy kan 'n skripsie vind om die skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing outomaties te doen hier en 'n Python-skripsie om hierdie voorreg te misbruik hier. Vir meer inligting, kyk na die oorspronklike navorsing.
iam.serviceAccounts.setIamPolicy'n Aanvaller met die genoemde toestemmings sal in staat wees om IAM-beleide by diensrekeninge toe te voeg. Jy kan dit misbruik om jouself die toestemmings te gee wat jy nodig het om die diensrekening te impersoneer. In die volgende voorbeeld gee ons onsself die roles/iam.serviceAccountTokenCreator-rol oor die interessante SA:
Jy kan 'n skripsie vind om die skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing outomaties te doen hier.
iam.serviceAccounts.actAsDie iam.serviceAccounts.actAs toestemming is soos die iam:PassRole toestemming van AWS. Dit is noodsaaklik vir die uitvoering van take, soos die inisieer van 'n Compute Engine-instantie, aangesien dit die vermoë gee om "as" 'n Diensrekening op te tree, wat verseker dat toestemmingsbestuur veilig is. Sonder dit kan gebruikers onnodige toegang verkry. Daarbenewens behels die uitbuiting van die iam.serviceAccounts.actAs verskillende metodes, elk met 'n stel toestemmings, in teenstelling met ander metodes wat net een benodig.
Die verpersoonliking van 'n diensrekening kan baie nuttig wees om nuwe en beter voorregte te verkry. Daar is drie maniere waarop jy 'n ander diensrekening kan verpersoonlik:
Outentifikasie met behulp van RSA privaat sleutels (hierbo gedek)
Magtiging met behulp van Cloud IAM-beleide (hier gedek)
Implementering van take op GCP-diens (meer van toepassing op die kompromittering van 'n gebruikersrekening)
iam.serviceAccounts.getOpenIdToken'n Aanvaller met die genoemde toestemmings sal in staat wees om 'n OpenID JWT te genereer. Hierdie word gebruik om identiteit te beweer en dra nie noodwendig enige implisiete magtiging teenoor 'n hulpbron nie.
Volgens hierdie interessante pos, is dit nodig om die gehoor (diens waar jy die token wil gebruik om te outentiseer) aan te dui en jy sal 'n JWT wat deur Google onderteken is, ontvang wat die diensrekening en die gehoor van die JWT aandui.
Jy kan 'n OpenIDToken genereer (as jy die toegang het) met:
Dan kan jy dit net gebruik om toegang tot die diens te verkry met:
Sommige dienste wat verifikasie via hierdie soort tokens ondersteun, is:
Google Cloud Endpoints (as Google OIDC gebruik word)
'n Voorbeeld van hoe om 'n OpenID-token namens 'n diensrekening te skep, kan hier gevind word.
