German - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - local privilege escalation ssh pivoting

Support HackTricks

In diesem Szenario nehmen wir an, dass du ein nicht privilegiertes Konto innerhalb einer VM in einem Compute Engine-Projekt kompromittiert hast.

Erstaunlicherweise können die GCP-Berechtigungen der Compute Engine, die du kompromittiert hast, dir helfen, lokal Privilegien innerhalb einer Maschine zu eskalieren. Auch wenn das in einer Cloud-Umgebung nicht immer sehr hilfreich ist, ist es gut zu wissen, dass es möglich ist.

Skripte lesen

Compute-Instanzen sind wahrscheinlich da, um einige Skripte auszuführen, um Aktionen mit ihren Dienstkonten durchzuführen.

Da IAM sehr granular ist, kann ein Konto Lese-/Schreibberechtigungen für eine Ressource haben, aber keine Listenberechtigungen.

Ein großartiges hypothetisches Beispiel dafür ist eine Compute-Instanz, die die Berechtigung hat, Backups in einen Speicher-Bucket namens instance82736-long-term-xyz-archive-0332893 zu lesen/schreiben.

Wenn du gsutil ls von der Kommandozeile ausführst, wird nichts zurückgegeben, da dem Dienstkonto die IAM-Berechtigung storage.buckets.list fehlt. Wenn du jedoch gsutil ls gs://instance82736-long-term-xyz-archive-0332893 ausführst, findest du möglicherweise ein vollständiges Dateisystem-Backup, das dir unverschlüsselten Zugriff auf Daten gibt, auf die dein lokales Linux-Konto keinen Zugriff hat.

Du kannst diesen Bucket-Namen möglicherweise in einem Skript (in Bash, Python, Ruby...) finden.

Benutzerdefinierte Metadaten

Administratoren können benutzerdefinierte Metadaten auf Instanz- und Projektebene hinzufügen. Dies ist einfach eine Möglichkeit, willkürliche Schlüssel/Wert-Paare in eine Instanz zu übergeben, und wird häufig für Umgebungsvariablen und Start-/Herunterfahrskripte verwendet.

Darüber hinaus ist es möglich, Benutzerdaten hinzuzufügen, was ein Skript ist, das jedes Mal ausgeführt wird, wenn die Maschine gestartet oder neu gestartet wird und das auch vom Metadaten-Endpunkt aus zugegriffen werden kann.

Für weitere Informationen siehe:

Missbrauch von IAM-Berechtigungen

Die meisten der folgenden vorgeschlagenen Berechtigungen werden dem Standard-Compute-SA erteilt, das einzige Problem ist, dass der Standardzugriffsbereich den SA daran hindert, sie zu verwenden. Wenn jedoch der cloud-platform Bereich aktiviert ist oder nur der compute Bereich aktiviert ist, wirst du in der Lage sein, sie auszunutzen.

Überprüfe die folgenden Berechtigungen:

Suche nach Schlüsseln im Dateisystem

Überprüfe, ob andere Benutzer sich in gcloud innerhalb der Box angemeldet haben und ihre Anmeldeinformationen im Dateisystem hinterlassen haben:

sudo find / -name "gcloud"

Dies sind die interessantesten Dateien:

  • ~/.config/gcloud/credentials.db

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json

  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto

  • ~/.credentials.json

Weitere API-Schlüssel Regexes

TARGET_DIR="/path/to/whatever"

# Service account keys
grep -Pzr "(?s){[^{}]*?service_account[^{}]*?private_key.*?}" \
"$TARGET_DIR"

# Legacy GCP creds
grep -Pzr "(?s){[^{}]*?client_id[^{}]*?client_secret.*?}" \
"$TARGET_DIR"

# Google API keys
grep -Pr "AIza[a-zA-Z0-9\\-_]{35}" \
"$TARGET_DIR"

# Google OAuth tokens
grep -Pr "ya29\.[a-zA-Z0-9_-]{100,200}" \
"$TARGET_DIR"

# Generic SSH keys
grep -Pzr "(?s)-----BEGIN[ A-Z]*?PRIVATE KEY[a-zA-Z0-9/\+=\n-]*?END[ A-Z]*?PRIVATE KEY-----" \
"$TARGET_DIR"

# Signed storage URLs
grep -Pir "storage.googleapis.com.*?Goog-Signature=[a-f0-9]+" \
"$TARGET_DIR"

# Signed policy documents in HTML
grep -Pzr '(?s)<form action.*?googleapis.com.*?name="signature" value=".*?">' \
"$TARGET_DIR"

Referenzen

Unterstütze HackTricks
PreviousGCP - Network Docker EscapeNextGCP - Persistence

Last updated