GCP - Cloudfunctions Privesc
cloudfunctions
Mehr Informationen über Cloud Functions:
cloudfunctions.functions.create
, cloudfunctions.functions.sourceCodeSet
, iam.serviceAccounts.actAs
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
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.
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
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)
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
cloudfunctions.functions.setIamPolicy
, iam.serviceAccounts.actAs
Gib dir eine der vorherigen .update
oder .create
Berechtigungen, um zu eskalieren.
cloudfunctions.functions.update
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
Last updated