GCP, soos enige ander wolk, het 'n paar beginsels: gebruikers, groepe en diensrekeninge, en 'n paar hulpbronne soos rekenaar enjin, wolk funksies…
Dan, via rolle, word toestemmings aan daardie beginsels oor die hulpbronne toegeken. Dit is die manier om die toestemmings wat 'n beginsel oor 'n hulpbron in GCP het, te spesifiseer.
Daar is sekere toestemmings wat 'n gebruiker sal toelaat om nog meer toestemmings op die hulpbron of derdeparty hulpbronne te verkry, en dit word privilege escalatie genoem (ook, die benutting van die kwesbaarhede om meer toestemmings te verkry).

Daarom wil ek GCP privilege escalatie tegnieke in 2 groepe verdeel:

Privesc na 'n beginsel: Dit sal jou toelaat om 'n ander beginsel na te volg, en dus soos dit op te tree met al sy toestemmings. bv.: Misbruik getAccessToken om 'n diensrekening na te volg.
Privesc op die hulpbron: Dit sal jou toelaat om meer toestemmings oor die spesifieke hulpbron te verkry. bv.: jy kan setIamPolicy toestemming oor cloudfunctions misbruik om jou toe te laat om die funksie te aktiveer.
Let daarop dat sommige hulpbronstoestemmings jou ook sal toelaat om 'n arbitrêre diensrekening aan die hulpbron te heg. Dit beteken dat jy in staat sal wees om 'n hulpbron met 'n SA te begin, in die hulpbron in te gaan, en die SA-token te steel. Daarom sal dit jou toelaat om na 'n beginsel te eskaleer via 'n hulpbron eskalatie. Dit het al in verskeie hulpbronne gebeur, maar nou is dit minder gereeld (maar kan steeds gebeur).

Dit is duidelik dat die mees interessante privilege escalatie tegnieke die van die tweede groep is omdat dit jou sal toelaat om meer voorregte buite die hulpbronne wat jy reeds oor sommige voorregte het, te verkry. Let egter daarop dat eskalering in hulpbronne jou ook toegang kan gee tot sensitiewe inligting of selfs tot ander beginsels (miskien deur 'n geheim te lees wat 'n token van 'n SA bevat).

Warning

Dit is ook belangrik om daarop te let dat in GCP Diensrekeninge beide beginsels en toestemmings is, so die eskalering van voorregte in 'n SA sal jou ook toelaat om dit na te volg.

Note

Die toestemmings tussen hakies dui die toestemmings aan wat nodig is om die kwesbaarheid met gcloud te benut. Dit mag nie nodig wees as dit deur die API benut word nie.

Permissions for Privilege Escalation Methodology

Dit is hoe ek toets vir spesifieke toestemmings om spesifieke aksies binne GCP uit te voer.

Laai die github repo https://github.com/carlospolop/gcp_privesc_scripts af
Voeg in tests/ die nuwe skrip by

Bypassing access scopes

Tokens van SA wat uit die GCP metadata diens gelek het, het toegangskope. Dit is beperkings op die toestemmings wat die token het. Byvoorbeeld, as die token die https://www.googleapis.com/auth/cloud-platform skaal het, sal dit volledige toegang tot al GCP dienste hê. As die token egter die https://www.googleapis.com/auth/cloud-platform.read-only skaal het, sal dit slegs lees-alleen toegang tot al GCP dienste hê, selfs al het die SA meer toestemmings in IAM.

Daar is geen direkte manier om hierdie toestemmings te omseil nie, maar jy kan altyd probeer om nuwe geloofsbriewe in die gecompromitteerde gasheer te soek, die dienssleutel te vind om 'n OAuth-token sonder beperking te genereer of na 'n ander VM met minder beperking te spring.

Wanneer toegangskope gebruik word, sal die OAuth-token wat vir die rekenaarinstansie (VM) gegenereer word, 'n skaal beperking ingesluit hê. Jy mag egter in staat wees om hierdie beperking te omseil en die toestemmings wat die gecompromitteerde rekening het, te benut.

Die beste manier om hierdie beperking te omseil, is om of nuwe geloofsbriewe in die gecompromitteerde gasheer te vind, om die dienssleutel te vind om 'n OAuth-token sonder beperking te genereer of om 'n ander VM met 'n SA met minder beperking te kompromitteer.

Kontroleer SA met sleutels wat gegenereer is met:

for i in $(gcloud iam service-accounts list --format="table[no-heading](email)"); do
echo "Looking for keys for $i:"
gcloud iam service-accounts keys list --iam-account $i
done

Privilege Escalation Techniques

Die manier om jou bevoegdhede in AWS te verhoog, is om genoeg toestemmings te hê om op een of ander manier toegang te verkry tot ander diensrekening/gebruiker/groep bevoegdhede. Kettingverhogings totdat jy admin toegang oor die organisasie het.

Warning

GCP het honderde (indien nie duisende nie) toestemmings wat aan 'n entiteit toegeken kan word. In hierdie boek kan jy alle toestemmings wat ek ken vind wat jy kan misbruik om bevoegdhede te verhoog, maar as jy 'n pad weet wat hier nie genoem word nie, deel dit asseblief.

Die subbladsye van hierdie afdeling is georden volgens dienste. Jy kan op elke diens verskillende maniere vind om bevoegdhede op die dienste te verhoog.

Abusing GCP to escalate privileges locally

As jy binne 'n masjien in GCP is, mag jy in staat wees om toestemmings te misbruik om bevoegdhede selfs plaaslik te verhoog:

{{#ref}} gcp-local-privilege-escalation-ssh-pivoting.md {{#endref}}

README.md

GCP - Privilege Escalation

Introduction to GCP Privilege Escalation

Permissions for Privilege Escalation Methodology

Bypassing access scopes

Privilege Escalation Techniques

Abusing GCP to escalate privileges locally

References