GCP - local privilege escalation ssh pivoting

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

In diesem Szenario gehen wir davon aus, dass Sie ein nicht privilegiertes Konto innerhalb einer VM in einem Compute Engine-Projekt kompromittiert haben.

Erstaunlicherweise können Ihnen die GCP-Berechtigungen des Compute Engine, den Sie kompromittiert haben, möglicherweise helfen, lokale Privilegien innerhalb einer Maschine zu eskalieren. Auch wenn dies in einer Cloud-Umgebung nicht immer sehr hilfreich ist, ist es gut zu wissen, dass es möglich ist.

Lesen Sie die Skripte

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

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

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

Wenn Sie gsutil ls von der Befehlszeile ausführen, wird nichts zurückgegeben, da dem Dienstkonto die IAM-Berechtigung storage.buckets.list fehlt. Wenn Sie jedoch gsutil ls gs://instance82736-long-term-xyz-archive-0332893 ausführen, finden Sie möglicherweise ein vollständiges Dateisystem-Backup, das Ihnen Zugriff auf Daten im Klartext gibt, auf die Ihr lokales Linux-Konto keinen Zugriff hat.

Sie können diesen Eimernamen möglicherweise in einem Skript (in Bash, Python, Ruby usw.) finden.

Benutzerdefinierte Metadaten

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

Darüber hinaus ist es möglich, Benutzerdaten hinzuzufügen, die ein Skript sind, das jedes Mal ausgeführt wird, wenn die Maschine gestartet oder neu gestartet wird und das auch vom Metadaten-Endpunkt aus abgerufen 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 das SA daran hindert, sie zu verwenden. Wenn jedoch der cloud-platform-Bereich aktiviert ist oder nur der compute-Bereich aktiviert ist, können Sie sie missbrauchen.

Überprüfen Sie die folgenden Berechtigungen:

Suchen Sie nach Schlüsseln im Dateisystem

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

sudo find / -name "gcloud"

Die folgenden Dateien sind besonders interessant:

  • ~/.config/gcloud/credentials.db

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

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

  • ~/.credentials.json

Weitere API-Schlüssel-Regexe

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

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Last updated