GCP - local privilege escalation ssh pivoting

Impara l'hacking di AWS da zero a eroe con htARTE (Esperto Red Team di HackTricks AWS)!

Altri modi per supportare 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 della compute engine che hai compromesso potrebbero aiutarti a escalare i privilegi localmente all'interno di una macchina. Anche se ciò non sarà sempre molto utile in un ambiente cloud, è utile sapere che è possibile.

Leggi gli script

Le Istanze di Calcolo sono probabilmente lì per eseguire alcuni script per eseguire azioni con i loro account di servizio.

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

Un ottimo esempio ipotetico di ciò è un'istanza di calcolo che ha il permesso di leggere/scrivere backup su un bucket di archiviazione chiamato instance82736-long-term-xyz-archive-0332893.

L'esecuzione di gsutil ls dalla riga di comando non restituisce nulla, poiché all'account di servizio manca 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, ottenendo accesso in chiaro ai dati a cui il tuo account Linux locale manca.

Potresti trovare questo nome del 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 acceduto anche dall'endpoint dei metadati.

Per ulteriori informazioni controlla:

Abuso dei permessi IAM

La maggior parte dei permessi proposti seguenti sono assegnati all'account di servizio di default Compute, l'unico problema è che lo scope di accesso predefinito impedisce all'account di servizio di utilizzarli. Tuttavia, se lo scope cloud-platform è abilitato o solo lo scope compute è abilitato, sarai in grado di abusarne.

Controlla i seguenti permessi:

Cerca le chiavi nel filesystem

Verifica se altri utenti hanno effettuato il login 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

Altri 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

Impara l'hacking su AWS da zero a eroe con htARTE (Esperto Red Team di HackTricks su AWS)!

Altri modi per supportare HackTricks:

Last updated