GCP - local privilege escalation ssh pivoting

Support HackTricks

neste cenário, vamos supor que você comprometeu uma conta não privilegiada dentro de uma VM em um projeto do Compute Engine.

Incrivelmente, as permissões do GCP do compute engine que você comprometeu podem ajudá-lo a escalar privilégios localmente dentro de uma máquina. Mesmo que isso nem sempre seja muito útil em um ambiente de nuvem, é bom saber que é possível.

Leia os scripts

Instâncias de Computação provavelmente estão lá para executar alguns scripts para realizar ações com suas contas de serviço.

Como o IAM é muito granular, uma conta pode ter privilégios de leitura/gravação sobre um recurso, mas sem privilégios de listagem.

Um grande exemplo hipotético disso é uma Instância de Computação que tem permissão para ler/gravar backups em um bucket de armazenamento chamado instance82736-long-term-xyz-archive-0332893.

Executar gsutil ls a partir da linha de comando não retorna nada, pois a conta de serviço não possui a permissão IAM storage.buckets.list. No entanto, se você executar gsutil ls gs://instance82736-long-term-xyz-archive-0332893, pode encontrar um backup completo do sistema de arquivos, dando acesso em texto claro a dados que sua conta local do Linux não possui.

Você pode ser capaz de encontrar o nome desse bucket dentro de um script (em bash, Python, Ruby...).

Metadados Personalizados

Os administradores podem adicionar metadados personalizados no nível da instância e nível do projeto. Isso é simplesmente uma maneira de passar pares de chave/valor arbitrários para uma instância, e é comumente usado para variáveis de ambiente e scripts de inicialização/desligamento.

Além disso, é possível adicionar userdata, que é um script que será executado toda vez que a máquina for iniciada ou reiniciada e que pode ser acessado a partir do endpoint de metadados também.

Para mais informações, confira:

Abusando permissões IAM

A maioria das permissões propostas a seguir são dadas à SA de Computação padrão, o único problema é que o escopo de acesso padrão impede a SA de usá-las. No entanto, se o escopo cloud-platform estiver habilitado ou apenas o escopo compute estiver habilitado, você poderá abusar delas.

Verifique as seguintes permissões:

Procure por Chaves no sistema de arquivos

Verifique se outros usuários fizeram login no gcloud dentro da caixa e deixaram suas credenciais no sistema de arquivos:

sudo find / -name "gcloud"

Estes são os arquivos mais interessantes:

  • ~/.config/gcloud/credentials.db

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

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

  • ~/.credentials.json

Mais regexes de chaves de 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"

Referências

Suporte ao HackTricks

Last updated