GCP - Storage Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Grundinformationen:
GCP - Storage Enumstorage.objects.get
Diese Berechtigung erlaubt es Ihnen, Dateien, die in Cloud Storage gespeichert sind, herunterzuladen. Dies kann potenziell dazu führen, dass Sie Privilegien eskalieren, da in einigen Fällen sensible Informationen dort gespeichert sind. Darüber hinaus speichern einige GCP-Dienste ihre Informationen in Buckets:
GCP Composer: Wenn Sie eine Composer-Umgebung erstellen, wird der Code aller DAGs in einem Bucket gespeichert. Diese Aufgaben könnten interessante Informationen in ihrem Code enthalten.
GCR (Container Registry): Das Bild der Container wird in Buckets gespeichert, was bedeutet, dass Sie, wenn Sie die Buckets lesen können, die Bilder herunterladen und nach Leaks und/oder Quellcode suchen können.
storage.objects.setIamPolicy
Sie können sich die Berechtigung geben, jede der vorherigen Szenarien in diesem Abschnitt auszunutzen.
storage.buckets.setIamPolicy
Für ein Beispiel, wie man Berechtigungen mit dieser Berechtigung ändert, überprüfen Sie diese Seite:
GCP - Public Buckets Privilege Escalationstorage.hmacKeys.create
Die "Interoperabilitäts"-Funktion von Cloud Storage, die für Cross-Cloud-Interaktionen wie mit AWS S3 konzipiert ist, umfasst die Erstellung von HMAC-Schlüsseln für Dienstkonten und Benutzer. Ein Angreifer kann dies ausnutzen, indem er einen HMAC-Schlüssel für ein Dienstkonto mit erhöhten Berechtigungen generiert, wodurch er die Privilegien innerhalb von Cloud Storage eskaliert. Während HMAC-Schlüssel, die mit Benutzern verbunden sind, nur über die Webkonsole abgerufen werden können, bleiben sowohl die Zugriffs- als auch die geheimen Schlüssel dauerhaft zugänglich, was potenziellen Backup-Zugriffsspeicher ermöglicht. Im Gegensatz dazu sind HMAC-Schlüssel, die mit Dienstkonten verknüpft sind, über die API zugänglich, aber ihre Zugriffs- und geheimen Schlüssel sind nach der Erstellung nicht abrufbar, was eine zusätzliche Komplexität für den kontinuierlichen Zugriff hinzufügt.
Ein weiteres Exploit-Skript für diese Methode finden Sie hier.
storage.objects.create
, storage.objects.delete
= Speicher SchreibberechtigungenUm ein neues Objekt in einem Bucket zu erstellen, benötigen Sie storage.objects.create
und, gemäß den Dokumenten, benötigen Sie auch storage.objects.delete
, um ein bestehendes Objekt zu ändern.
Eine sehr häufige Ausnutzung von Buckets, in die Sie in der Cloud schreiben können, ist der Fall, dass der Bucket Webserver-Dateien speichert. Sie könnten in der Lage sein, neuen Code zu speichern, der von der Webanwendung verwendet wird.
Composer ist Apache Airflow, das innerhalb von GCP verwaltet wird. Es hat mehrere interessante Funktionen:
Es läuft innerhalb eines GKE-Clusters, sodass der SA, den der Cluster verwendet, von dem Code, der innerhalb von Composer ausgeführt wird, zugänglich ist.
Alle Komponenten einer Composer-Umgebung (Code der DAGs, Plugins und Daten) werden in einem GCP-Bucket gespeichert. Wenn der Angreifer Lese- und Schreibberechtigungen dafür hat, könnte er den Bucket überwachen und wann immer ein DAG erstellt oder aktualisiert wird, eine mit einem Hintertür versehenen Version einreichen, sodass die Composer-Umgebung die hintertürbehaftete Version aus dem Speicher erhält.
Sie finden einen PoC dieses Angriffs im Repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs
Der Code von Cloud Functions wird im Storage gespeichert, und wann immer eine neue Version erstellt wird, wird der Code in den Bucket hochgeladen und dann wird der neue Container aus diesem Code erstellt. Daher ist es möglich, den Code zu überschreiben, bevor die neue Version erstellt wird, um die Cloud-Funktion dazu zu bringen, beliebigen Code auszuführen.
Sie finden einen PoC dieses Angriffs im Repo: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions
AppEngine-Versionen generieren einige Daten in einem Bucket im Formatname: staging.<project-id>.appspot.com
. In diesem Bucket ist es möglich, einen Ordner namens ae
zu finden, der einen Ordner pro Version der AppEngine-App enthält, und in diesen Ordnern ist es möglich, die Datei manifest.json
zu finden. Diese Datei enthält ein JSON mit allen Dateien, die verwendet werden müssen, um die spezifische Version zu erstellen. Darüber hinaus ist es möglich, die echten Namen der Dateien, die URL zu ihnen im GCP-Bucket (die Dateien im Bucket haben ihren Namen in ihren sha1-Hash geändert) und den sha1-Hash jeder Datei zu finden.
Beachten Sie, dass es nicht möglich ist, diesen Bucket im Voraus zu übernehmen, da GCP-Benutzer nicht autorisiert sind, Buckets mit dem Domainnamen appspot.com zu erstellen.
Mit Lese- und Schreibzugriff auf diesen Bucket ist es jedoch möglich, die Berechtigungen für den SA, der an der App Engine-Version angehängt ist, zu eskalieren, indem der Bucket überwacht wird und jedes Mal, wenn eine Änderung vorgenommen wird (neue Version), die neue Version so schnell wie möglich geändert wird. Auf diese Weise wird der Container, der aus diesem Code erstellt wird, den hintertürbehafteten Code ausführen.
Der erwähnte Angriff kann auf viele verschiedene Arten durchgeführt werden, alle beginnen mit der Überwachung des Buckets staging.<project-id>.appspot.com
:
Laden Sie den vollständigen neuen Code der AppEngine-Version in einen anderen und verfügbaren Bucket hoch und bereiten Sie eine manifest.json
-Datei mit dem neuen Bucket-Namen und den sha1-Hashes vor. Wenn dann eine neue Version im Bucket erstellt wird, müssen Sie nur die manifest.json
-Datei ändern und die bösartige hochladen.
Laden Sie eine modifizierte Version von requirements.txt
hoch, die den bösartigen Abhängigkeitscode verwendet und die manifest.json
-Datei mit dem neuen Dateinamen, der URL und dem Hash aktualisiert.
Laden Sie eine modifizierte main.py
- oder app.yaml
-Datei hoch, die den bösartigen Code ausführt und die manifest.json
-Datei mit dem neuen Dateinamen, der URL und dem Hash aktualisiert.
Sie finden einen PoC dieses Angriffs im Repo: https://github.com/carlospolop/Monitor-Backdoor-AppEngine
Google Container Registry speichert die Images in Buckets. Wenn Sie diese Buckets beschreiben können, könnten Sie in der Lage sein, seitlich zu dem Ort zu wechseln, an dem diese Buckets ausgeführt werden.
Der von GCR verwendete Bucket hat eine URL, die ähnlich ist wie gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com
(Die obersten Subdomains sind hier angegeben).
Dieser Dienst ist veraltet, daher ist dieser Angriff nicht mehr nützlich. Darüber hinaus speichert Artifact Registry, der Dienst, der diesen ersetzt, die Images nicht in Buckets.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)