Italian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - local privilege escalation ssh pivoting

Supporta HackTricks

In questo scenario supponiamo che tu abbia compromesso un account non privilegiato all'interno di una VM in un progetto Compute Engine.

Incredibilmente, i permessi GCP del compute engine che hai compromesso possono aiutarti a escalare i privilegi localmente all'interno di una macchina. Anche se questo non sarà sempre molto utile in un ambiente cloud, è bene sapere che è possibile.

Leggi gli script

Compute Instances sono probabilmente lì per eseguire alcuni script per eseguire azioni con i loro account di servizio.

Poiché IAM è molto granulare, un account può avere privilegi di lettura/scrittura su una risorsa ma nessun privilegio di elenco.

Un grande esempio ipotetico di questo è una Compute Instance che ha il permesso di leggere/scrivere backup in un bucket di archiviazione chiamato instance82736-long-term-xyz-archive-0332893.

Eseguendo gsutil ls dalla riga di comando non restituisce nulla, poiché l'account di servizio non ha il permesso IAM storage.buckets.list. Tuttavia, se esegui gsutil ls gs://instance82736-long-term-xyz-archive-0332893 potresti trovare un backup completo del filesystem, dandoti accesso in chiaro ai dati di cui il tuo account Linux locale è privo.

Potresti essere in grado di trovare questo nome di bucket all'interno di uno script (in bash, Python, Ruby...).

Metadati personalizzati

Gli amministratori possono aggiungere metadati personalizzati a livello di istanza e progetto. Questo è semplicemente un modo per passare coppie chiave/valore arbitrarie in un'istanza, ed è comunemente usato per variabili d'ambiente e script di avvio/arresto.

Inoltre, è possibile aggiungere userdata, che è uno script che verrà eseguito ogni volta che la macchina viene avviata o riavviata e che può essere accessibile anche dall'endpoint dei metadati.

Per ulteriori informazioni controlla:

LogoCloud SSRFHackTricks

Abusare dei permessi IAM

La maggior parte dei permessi proposti di seguito sono assegnati al Compute SA predefinito, l'unico problema è che il campo di accesso predefinito impedisce al SA di usarli. Tuttavia, se il campo cloud-platform è abilitato o solo il campo compute è abilitato, sarai in grado di abusarne.

Controlla i seguenti permessi:

Cerca chiavi nel filesystem

Controlla se altri utenti hanno effettuato l'accesso in gcloud all'interno della macchina e hanno lasciato le loro credenziali nel filesystem:

sudo find / -name "gcloud"

Questi sono i file più interessanti:

  • ~/.config/gcloud/credentials.db

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

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

  • ~/.credentials.json

Altre regex per le chiavi API

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"

Riferimenti

Supporta HackTricks
PreviousGCP - Network Docker EscapeNextGCP - Persistence

Last updated