GCP - Storage Privesc

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks

Storage

Grundlegende Informationen:

GCP - Storage Enum

storage.objects.get

Diese Berechtigung erlaubt es dir, Dateien herunterzuladen, die in Cloud Storage gespeichert sind. Dies kann dir potenziell ermöglichen, Privilegien zu eskalieren, da in einigen Fällen sensible Informationen dort gespeichert werden. Außerdem speichern einige GCP-Dienste ihre Informationen in buckets:

  • GCP Composer: Wenn du eine Composer Environment erstellst, wird der Code aller DAGs in einem bucket gespeichert. Diese Tasks können interessante Informationen in ihrem Code enthalten.
  • GCR (Container Registry): Die images der Container werden in buckets gespeichert, was bedeutet, dass du, wenn du die buckets lesen kannst, die images herunterladen und nach leaks und/oder Quellcode durchsuchen kannst.

storage.objects.setIamPolicy

Damit kannst du dir die Berechtigung geben, jede der vorherigen Szenarien in diesem Abschnitt zu missbrauchen.

# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

storage.buckets.setIamPolicy

Ein Beispiel, wie man Berechtigungen mit dieser Berechtigung ändert, findest du auf dieser Seite:

# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

Die “interoperability”-Funktion von Cloud Storage, konzipiert für Cross-Cloud-Interaktionen wie mit AWS S3, umfasst die Erstellung von HMAC-Keys für Service Accounts und Benutzer. Ein Angreifer kann dies ausnutzen, indem er einen HMAC-Key für einen Service Account mit erhöhten Rechten erzeugt, und so Privilegien innerhalb von Cloud Storage eskaliert. Während HMAC-Keys, die mit Benutzern verknüpft sind, nur über die Webkonsole abrufbar sind, bleiben sowohl die access and secret keys dauerhaft zugänglich, was das Speichern eines Backup-Zugriffs ermöglicht. Im Gegensatz dazu sind mit Service Accounts verknüpfte HMAC-Keys über die API zugänglich, aber ihre access and secret keys sind nach der Erstellung nicht abrufbar, was eine zusätzliche Komplexitätsebene für dauerhaften Zugriff schafft.

# 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"storage-sa@{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 ist here zu finden.

storage.objects.create, storage.objects.delete = Storage Write-Berechtigungen

Um ein neues Objekt innerhalb eines bucket zu erstellen benötigt man storage.objects.create und, laut the docs, benötigt man außerdem storage.objects.delete, um ein bestehendes Objekt zu modifizieren.

Eine sehr häufige exploitation von buckets, in die man in der Cloud schreiben kann, ist der Fall, dass der bucket Webserver-Dateien speichert — dann kann man möglicherweise neuen Code ablegen, der von der Webanwendung verwendet wird.

Composer

Composer ist Apache Airflow, verwaltet innerhalb von GCP. Es hat mehrere interessante Eigenschaften:

  • Es läuft innerhalb eines GKE cluster, daher ist das SA, das der Cluster verwendet, für den Code innerhalb von Composer zugänglich.
  • Alle Komponenten einer composer-Umgebung (Code der DAGs, Plugins und Daten) werden in einem GCP bucket gespeichert. Wenn ein Angreifer Lese- und Schreibzugriff darauf hat, könnte er den bucket überwachen und immer wenn ein DAG erstellt oder aktualisiert wird, eine hintertürte Version einreichen, sodass die Composer-Umgebung die hintertürte Version aus dem Storage holt.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • Cloud Functions-Code wird in Storage gespeichert und jedes Mal, wenn eine neue Version erstellt wird, wird der Code in den bucket gepusht und daraus das neue Container-Image gebaut. Daher ist es möglich, durch Überschreiben des Codes bevor die neue Version gebaut wird, die Cloud Function dazu zu bringen, beliebigen Code auszuführen.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngine-Versionen erzeugen Daten innerhalb eines buckets mit dem Format: staging.<project-id>.appspot.com. Innerhalb dieses buckets findet man einen Ordner namens ae, der einen Ordner pro Version der AppEngine-App enthält, und in diesen Ordnern findet man die Datei manifest.json. Diese Datei enthält ein JSON mit allen Dateien, die verwendet werden müssen, um die spezifische Version zu erstellen. Außerdem lassen sich die echten Dateinamen, die URL zu ihnen im GCP bucket (die Dateien im bucket haben ihren Namen durch ihren sha1-Hash ersetzt) und der sha1-Hash jeder Datei finden.

Note that it’s not possible to pre-takeover this bucket because GCP users aren’t authorized to generate buckets using the domain name appspot.com.

Mit Lese- & Schreibzugriff auf diesen bucket ist es jedoch möglich, Rechte auf das SA zu eskalieren, das an die App Engine-Version gebunden ist, indem man den bucket überwacht und bei jeder Änderung (neue Version) die neue Version so schnell wie möglich modifiziert. Auf diese Weise führt der aus diesem Code erstellte Container den hintertürten Code aus.

Der beschriebene Angriff kann auf viele verschiedene Arten durchgeführt werden. Alle beginnen mit dem Überwachen des staging.<project-id>.appspot.com buckets:

  • Lade den kompletten neuen Code der AppEngine-Version in einen anderen verfügbaren bucket hoch und bereite eine manifest.json-Datei mit dem neuen Bucket-Namen und den sha1-Hashes der Dateien vor. Wenn dann eine neue Version im bucket erstellt wird, musst du nur die manifest.json ändern und die bösartige Version hochladen.
  • Lade eine modifizierte requirements.txt hoch, die bösartige Abhängigkeiten verwendet, und aktualisiere die manifest.json mit dem neuen Dateinamen, der URL und dem Hash.
  • Lade eine modifizierte main.py oder app.yaml-Datei hoch, die den bösartigen Code ausführt, und aktualisiere die manifest.json mit dem neuen Dateinamen, der URL und dem Hash.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry speichert die Images in buckets. Wenn du in diese buckets schreiben kannst, könntest du lateral dorthin gelangen, wo diese Images ausgeführt werden.
  • Der von GCR verwendete bucket hat eine URL ähnlich gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (Die Top-Level-Subdomains sind here angegeben).

Tip

Dieser Dienst ist veraltet, daher ist dieser Angriff nicht mehr nützlich. Außerdem speichert Artifact Registry, der Dienst, der ihn ersetzt, die Images nicht in buckets.

Referenzen

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstütze HackTricks