GCP - local privilege escalation ssh pivoting

Aprenda hacking AWS do zero ao avançado com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Neste cenário, vamos supor que você comprometeu uma conta sem privilégios dentro de uma VM em um projeto Compute Engine.

Surpreendentemente, as permissões do GCP da instância de computação que você comprometeu podem ajudá-lo a escalar privilégios localmente dentro de uma máquina. Mesmo que 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 é granular, uma conta pode ter privilégios de leitura/escrita sobre um recurso, mas sem privilégios de listagem.

Um ótimo exemplo hipotético disso é uma Instância de Computação que tem permissão para ler/escrever 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 está sem 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-lhe acesso em texto simples a dados que sua conta Linux local não possui.

Você pode encontrar esse nome de bucket dentro de um script (em bash, Python, Ruby...).

Metadados personalizados

Os administradores podem adicionar metadados personalizados no nível da instância e do projeto. Isso é simplesmente uma forma 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, consulte:

Abusando das permissões do 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ê será capaz de 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 máquina 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/[CONTA]/adc.json

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

  • ~/.credentials.json

Mais expressões regulares 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

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Última actualización