GCP - Storage Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Storage

Informações Básicas:

GCP - Storage Enum

`storage.objects.get`

Esta permissão permite que você baixe arquivos armazenados no Cloud Storage. Isso pode potencialmente permitir que você escale privilégios porque em algumas ocasiões informações sensíveis são salvas lá. Além disso, alguns serviços do GCP armazenam suas informações em buckets:

GCP Composer: Quando você cria um Ambiente Composer, o código de todos os DAGs será salvo dentro de um bucket. Essas tarefas podem conter informações interessantes dentro de seu código.
GCR (Container Registry): A imagem dos contêineres é armazenada dentro de buckets, o que significa que se você puder ler os buckets, poderá baixar as imagens e procurar por leaks e/ou código fonte.

`storage.objects.setIamPolicy`

Você pode se dar permissão para abusar de qualquer um dos cenários anteriores desta seção.

`storage.buckets.setIamPolicy`

Para um exemplo de como modificar permissões com esta permissão, consulte esta página:

GCP - Public Buckets Privilege Escalation

`storage.hmacKeys.create`

O recurso de "interoperabilidade" do Cloud Storage, projetado para interações entre nuvens como com o AWS S3, envolve a criação de chaves HMAC para Contas de Serviço e usuários. Um atacante pode explorar isso gerando uma chave HMAC para uma Conta de Serviço com privilégios elevados, assim escalando privilégios dentro do Cloud Storage. Enquanto as chaves HMAC associadas a usuários só podem ser recuperadas via console da web, tanto as chaves de acesso quanto as secretas permanecem perpetuamente acessíveis, permitindo um potencial armazenamento de acesso de backup. Por outro lado, as chaves HMAC vinculadas a Contas de Serviço são acessíveis via API, mas suas chaves de acesso e secretas não são recuperáveis após a criação, adicionando uma camada de complexidade para acesso contínuo.

# Create key
gsutil hmac create <sa-email> # You might need to execute this inside a VM instance

## If you have TROUBLES creating the HMAC key this was you can also do it contacting the API directly:
PROJECT_ID = '$PROJECT_ID'
TARGET_SERVICE_ACCOUNT = f"exam-storage-sa-read-flag-3@{PROJECT_ID}.iam.gserviceaccount.com"
ACCESS_TOKEN = "$CLOUDSDK_AUTH_ACCESS_TOKEN"
import requests
import json
key = requests.post(
f'https://www.googleapis.com/storage/v1/projects/{PROJECT_ID}/hmacKeys',
params={'access_token': ACCESS_TOKEN, 'serviceAccountEmail': TARGET_SERVICE_ACCOUNT}
).json()
#print(json.dumps(key, indent=4))
print(f'ID: {key["metadata"]["accessId"]}')
print(f'Secret: {key["secret"]}')


# Configure gsutil to use the HMAC key
gcloud config set pass_credentials_to_gsutil false
gsutil config -a

# Use it
gsutil ls gs://[BUCKET_NAME]

# Restore
gcloud config set pass_credentials_to_gsutil true

Outro script de exploração para este método pode ser encontrado aqui.

`storage.objects.create`, `storage.objects.delete` = Permissões de gravação no Storage

Para criar um novo objeto dentro de um bucket, você precisa de storage.objects.create e, de acordo com a documentação, você também precisa de storage.objects.delete para modificar um objeto existente.

Uma exploração muito comum de buckets onde você pode escrever na nuvem é no caso de o bucket estar salvando arquivos de servidor web, você pode ser capaz de armazenar novo código que será usado pela aplicação web.

Composer

Composer é Apache Airflow gerenciado dentro do GCP. Ele possui várias características interessantes:

Ele roda dentro de um cluster GKE, então o SA que o cluster usa é acessível pelo código que está rodando dentro do Composer
Todos os componentes de um ambiente de composer (código dos DAGs, plugins e dados) são armazenados dentro de um bucket GCP. Se o atacante tiver permissões de leitura e gravação sobre ele, ele poderia monitorar o bucket e sempre que um DAG for criado ou atualizado, enviar uma versão com backdoor para que o ambiente do composer obtenha a versão com backdoor do armazenamento.

Você pode encontrar uma PoC deste ataque no repositório: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

O código das Cloud Functions é armazenado no Storage e sempre que uma nova versão é criada, o código é enviado para o bucket e então o novo contêiner é construído a partir desse código. Portanto, sobrescrever o código antes que a nova versão seja construída torna possível fazer a função da nuvem executar código arbitrário.

Você pode encontrar uma PoC deste ataque no repositório: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

As versões do AppEngine geram alguns dados dentro de um bucket com o formato nome: staging.<project-id>.appspot.com. Dentro deste bucket, é possível encontrar uma pasta chamada ae que conterá uma pasta por versão do aplicativo AppEngine e dentro dessas pastas será possível encontrar o arquivo manifest.json. Este arquivo contém um json com todos os arquivos que devem ser usados para criar a versão específica. Além disso, é possível encontrar os nomes reais dos arquivos, a URL deles dentro do bucket GCP (os arquivos dentro do bucket mudaram seus nomes para seu hash sha1) e o hash sha1 de cada arquivo.

Observe que não é possível realizar uma pré-takeover deste bucket porque os usuários do GCP não estão autorizados a gerar buckets usando o nome de domínio appspot.com.

No entanto, com acesso de leitura e gravação sobre este bucket, é possível escalar privilégios para o SA anexado à versão do App Engine monitorando o bucket e sempre que uma alteração for realizada (nova versão), modificar a nova versão o mais rápido possível. Dessa forma, o contêiner que é criado a partir desse código executará o código com backdoor.

O ataque mencionado pode ser realizado de várias maneiras diferentes, todas começam monitorando o bucket staging.<project-id>.appspot.com:

Carregar o novo código completo da versão do AppEngine para um bucket diferente e disponível e preparar um arquivo manifest.json com o novo nome do bucket e hashes sha1 deles. Então, quando uma nova versão for criada dentro do bucket, você só precisa modificar o arquivo manifest.json e enviar o malicioso.
Carregar uma versão modificada do requirements.txt que usará o código de dependências maliciosas e atualizar o arquivo manifest.json com o novo nome do arquivo, URL e o hash dele.
Carregar um arquivo main.py ou app.yaml modificado que executará o código malicioso e atualizar o arquivo manifest.json com o novo nome do arquivo, URL e o hash dele.

Você pode encontrar uma PoC deste ataque no repositório: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

Google Container Registry armazena as imagens dentro de buckets, se você puder escrever nesses buckets, pode ser capaz de mover lateralmente para onde esses buckets estão sendo executados.
O bucket usado pelo GCR terá uma URL semelhante a gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (Os subdomínios de nível superior são especificados aqui).

Este serviço está obsoleto, então este ataque não é mais útil. Além disso, o Artifact Registry, o serviço que substitui este, não armazena as imagens em buckets.