GCP - local privilege escalation ssh pivoting

Soutenez HackTricks

Dans ce scénario, nous allons supposer que vous avez compromis un compte non privilégié à l'intérieur d'une VM dans un projet Compute Engine.

De manière étonnante, les autorisations GCP de la machine virtuelle que vous avez compromises peuvent vous aider à élever localement les privilèges à l'intérieur d'une machine. Même si cela n'est pas toujours très utile dans un environnement cloud, il est bon de savoir que c'est possible.

Lire les scripts

Les instances de calcul sont probablement là pour exécuter des scripts afin d'effectuer des actions avec leurs comptes de service.

Comme IAM est très granulaire, un compte peut avoir des privilèges de lecture/écriture sur une ressource mais pas de privilèges de liste.

Un script hypothétique intéressant est une instance de calcul qui a l'autorisation de lire/écrire des sauvegardes dans un bucket de stockage appelé instance82736-long-term-xyz-archive-0332893.

L'exécution de gsutil ls depuis la ligne de commande ne renvoie rien, car le compte de service manque de l'autorisation IAM storage.buckets.list. Cependant, si vous exécutez gsutil ls gs://instance82736-long-term-xyz-archive-0332893, vous pouvez trouver une sauvegarde complète du système de fichiers, vous donnant un accès en clair aux données auxquelles votre compte Linux local manque.

Vous vous pouvez trouver ce nom de bucket à l'intérieur d'un script (en bash, Python, Ruby...).

Métadonnées personnalisées

Les administrateurs peuvent ajouter des métadonnées personnalisées au niveau de l'instance et du projet. Il s'agit simplement d'une manière de passer des paires clé/valeur arbitraires dans une instance, et est couramment utilisé pour les variables d'environnement et les scripts de démarrage/arrêt.

De plus, il est possible d'ajouter des données utilisateur, qui est un script qui sera exécuté à chaque démarrage ou redémarrage de la machine et qui peut être également accédé depuis l'endpoint de métadonnées.

Pour plus d'informations, consultez :

Abus des autorisations IAM

La plupart des autorisations proposées suivantes sont attribuées au compte de service Compute par défaut, le seul problème est que la portée d'accès par défaut empêche le compte de service de les utiliser. Cependant, si la portée cloud-platform est activée ou simplement la portée compute est activée, vous pourrez les abuser.

Vérifiez les autorisations suivantes :

Recherche de clés dans le système de fichiers

Vérifiez si d'autres utilisateurs se sont connectés à gcloud à l'intérieur de la machine et ont laissé leurs informations d'identification dans le système de fichiers :

sudo find / -name "gcloud"

Voici les fichiers les plus intéressants :

  • ~/.config/gcloud/credentials.db

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

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

  • ~/.credentials.json

Plus de regex pour les clés 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"

Références

Soutenez HackTricks

Last updated