Español - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

GCP - local privilege escalation ssh pivoting

Apoya a HackTricks

en este escenario vamos a suponer que has comprometido una cuenta no privilegiada dentro de una VM en un proyecto de Compute Engine.

Sorprendentemente, los permisos de GCP del compute engine que has comprometido pueden ayudarte a escalar privilegios localmente dentro de una máquina. Incluso si eso no siempre será muy útil en un entorno de nube, es bueno saber que es posible.

Lee los scripts

Las Instancias de Cómputo probablemente estén ahí para ejecutar algunos scripts para realizar acciones con sus cuentas de servicio.

Como IAM es muy granular, una cuenta puede tener privilegios de lectura/escritura sobre un recurso pero sin privilegios de listado.

Un gran ejemplo hipotético de esto es una Instancia de Cómputo que tiene permiso para leer/escribir copias de seguridad en un bucket de almacenamiento llamado instance82736-long-term-xyz-archive-0332893.

Ejecutar gsutil ls desde la línea de comandos no devuelve nada, ya que la cuenta de servicio carece del permiso IAM storage.buckets.list. Sin embargo, si ejecutas gsutil ls gs://instance82736-long-term-xyz-archive-0332893 puedes encontrar una copia de seguridad completa del sistema de archivos, dándote acceso en texto claro a datos que tu cuenta local de Linux no tiene.

Es posible que puedas encontrar este nombre de bucket dentro de un script (en bash, Python, Ruby...).

Metadatos personalizados

Los administradores pueden agregar metadatos personalizados a nivel de instancia y proyecto. Esta es simplemente una forma de pasar pares clave/valor arbitrarios a una instancia, y se utiliza comúnmente para variables de entorno y scripts de inicio/apagado.

Además, es posible agregar userdata, que es un script que será ejecutado cada vez que la máquina se inicie o reinicie y que puede ser accedido desde el punto final de metadatos también.

Para más información consulta:

Abusando de los permisos IAM

La mayoría de los siguientes permisos propuestos son otorgados al SA de Cómputo por defecto, el único problema es que el alcance de acceso por defecto impide que el SA los use. Sin embargo, si el alcance cloud-platform está habilitado o solo el alcance compute está habilitado, podrás abusar de ellos.

Revisa los siguientes permisos:

Busca claves en el sistema de archivos

Verifica si otros usuarios han iniciado sesión en gcloud dentro de la caja y han dejado sus credenciales en el sistema de archivos:

sudo find / -name "gcloud"

Estos son los archivos más interesantes:

  • ~/.config/gcloud/credentials.db

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

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

  • ~/.credentials.json

Más expresiones regulares de claves 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"

Referencias

Apoya a HackTricks
PreviousGCP - Network Docker EscapeNextGCP - Persistence

Last updated