German - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - Storage Privesc

Support HackTricks

Storage

Grundinformationen:

GCP - Storage Enum

storage.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 Escalation

storage.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, 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.

# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance

## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"exam-storage-sa-read-flag-3@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')


# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

# Restore
gcloud config set pass_credentials_to_gsutil true

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

storage.objects.create, storage.objects.delete = Speicher Schreibberechtigungen

Um 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

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ür-Version aus dem Speicher erhält.

Sie finden einen PoC dieses Angriffs im Repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • 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

App Engine

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 auf 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ür-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

GCR

  • Google Container Registry speichert die Images in Buckets. Wenn Sie diese Buckets schreiben 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.

Referenzen

Unterstützen Sie HackTricks
PreviousGCP - Sourcerepos PrivescNextGCP - Workflows Privesc

Last updated