GCP - Storage Privesc

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks

Storage

Informações básicas:

GCP - Storage Enum

storage.objects.get

Essa 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 Composer Environment o código de todos os DAGs será salvo dentro de um bucket. Essas tarefas podem conter informações interessantes dentro do seu código.
  • GCR (Container Registry): A imagem dos containers é armazenada dentro de buckets, o que significa que se você conseguir ler os buckets será capaz de baixar as imagens e buscar por leaks e/ou código-fonte.

storage.objects.setIamPolicy

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

# Add binding
gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Remove binding
gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role="<ROLE>" \
--project=<PROJECT_ID>

# Change Policy
gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

storage.buckets.setIamPolicy

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

# Add binding
gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Remove binding
gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
--role=<ROLE> \
--project=<MY_PROJECT>

# Change policy
gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
--project=<PROJECT_ID> <<'POLICY'
{
"bindings": [
{
"role": "<ROLE>",
"members": [
"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
]
}
]
}
POLICY

GCP - Public Buckets Privilege Escalation

storage.hmacKeys.create

O recurso “interoperability” do Cloud Storage, projetado para interações cross-cloud como com AWS S3, envolve a criação de HMAC keys para Service Accounts e usuários. Um atacante pode explorar isso gerando uma HMAC key para um Service Account com privilégios elevados, assim escalando privilégios dentro do Cloud Storage. Enquanto as HMAC keys associadas a usuários só são recuperáveis via o web console, tanto as access e secret keys permanecem perpetuamente acessíveis, permitindo possível armazenamento de backup do acesso. Por outro lado, HMAC keys vinculadas a Service Accounts são acessíveis via API, mas suas access e secret keys não podem ser recuperadas 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"storage-sa@{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

Another exploit script for this method can be found aqui.

storage.objects.create, storage.objects.delete = Storage Permissões de escrita

In order to create a new object inside a bucket you need storage.objects.create and, according to a documentação, you need also storage.objects.delete to modify an existent object.

Uma exploração muito common de buckets onde você pode write na cloud é quando o bucket está salvando web server files; você pode ser capaz de store new code que será usado pela aplicação web.

Composer

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

  • Ele roda dentro de um GKE cluster, então a SA que o cluster usa é acessível pelo código executado dentro do Composer
  • Todos os componentes de um composer environment (código dos DAGs, plugins e dados) são armazenados dentro de um bucket GCP. Se o atacante tem permissões de leitura e escrita sobre ele, ele poderia monitorar o bucket e sempre que um DAG for criado ou atualizado, submeter uma versão backdoored para que o ambiente do Composer obtenha do Storage a versão backdoored.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs

Cloud Functions

  • O código do 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 container é build a partir desse código. Portanto, sobrescrever o código antes da nova versão ser construída possibilita fazer a cloud function executar código arbitrário.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions

App Engine

AppEngine versions generate some data inside a bucket with the format name: staging.<project-id>.appspot.com. Inside this bucket, it’s possible to find a folder called ae that will contain a folder per version of the AppEngine app and inside these folders it’ll be possible to find the manifest.json file. This file contains a json with all the files that must be used to create the specific version. Moreover, it’s possible to find the real names of the files, the URL to them inside the GCP bucket (the files inside the bucket changed their name for their sha1 hash) and the sha1 hash of each file.

Nota que não é possível pre-takeover este bucket porque usuários GCP não estão autorizados a gerar buckets usando o domínio appspot.com.

No entanto, com acesso de leitura & escrita sobre este bucket, é possível escalar privilégios para a SA anexada à 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 container que é criado a partir desse código irá executar o código backdoored.

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

  • Faça upload do código completo da nova versão do AppEngine para um bucket diferente e disponível e prepare um manifest.json com o novo nome do bucket e os hashes sha1 deles. Então, quando uma nova versão for criada dentro do bucket, você só precisa modificar o manifest.json e enviar o malicioso.
  • Envie uma versão modificada do requirements.txt que vai usar as dependências maliciosas e atualize o manifest.json com o novo filename, URL e o hash dele.
  • Faça upload de um main.py ou app.yaml modificado que executará o código malicioso e atualize o manifest.json com o novo filename, URL e o hash dele.

You can find a PoC of this attack in the repo: https://github.com/carlospolop/Monitor-Backdoor-AppEngine

GCR

  • Google Container Registry armazena as imagens dentro de buckets; se você pode write those buckets você pode ser capaz de move laterally to where those buckets are being run.
  • O bucket usado pelo GCR terá uma URL similar a gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com (Os subdomínios de topo são especificados aqui).

Tip

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

Referências

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks