Unit 42가 공개한 Google Vertex AI SDK 버킷 스쿼팅 'Pickle in the Middle' 분석. 무권한 크로스 테넌트 RCE로 이어지는 Pickle 역직렬화 체인과 패치 타임라인, 탐지 관점을 다룬다.
댓글은 익명으로 작성되며, 삭제 비밀번호를 설정하면 본인만 삭제할 수 있습니다. 비밀번호를 설정하지 않은 댓글은 누구나 삭제할 수 있습니다.
피해자 프로젝트에 대한 접근 권한이 전혀 없는 외부 공격자가, 피해자가 업로드하는 머신러닝 모델을 중간에 가로채 악성 코드를 심은 페이로드로 교체할 수 있다. 이것이 2026년 3월 Palo Alto Networks Unit 42 연구원 Ori Hadad가 Google Cloud에 제출한 버그 리포트의 핵심이었다. Google은 보고 5일 만에 최고 심각도를 부여하고 패치를 우선 처리했다. Unit 42는 이 공격 체인을 "Pickle in the Middle"로 명명했고, 2026년 6월 16일 기술 보고서로 공개했다. 별도 CVE 번호는 부여되지 않았다.
| 항목 | 내용 |
|---|---|
| 공개 | Unit 42 "Pickle in the Middle" (2026-06-16) |
| 공격 벡터 | 크로스 테넌트, 피해자 계정 접근 불필요 |
| 영향 버전 | google-cloud-aiplatform < 1.148.0 (테스트 확인 1.139.0·1.140.0) |
| 패치 | v1.144.0 부분 → v1.148.0 완전 (2026-04-15) |
| 야생 악용 | 미확인 (Unit 42·Google 발표 기준) |
| CVE | 미부여 |
Vertex AI Python SDK는 모델을 업로드할 때 중간 스테이징 버킷이 필요하다. 개발자가 별도 설정을 하지 않으면 SDK가 자동으로 버킷명을 결정하는데, 생성 공식이 {project-id}-vertex-staging-{region} 형태였다.
두 가지 결함이 결합됐다. 첫째, 이름이 예측 가능하다. GCP 프로젝트 ID는 GCS 버킷명·서비스 계정 이메일 등 공개 리소스에서 노출되는 경우가 많다. 공격자가 피해자의 프로젝트 ID와 리전을 알면 {project-id}-vertex-staging-{region} 공식으로 정확한 버킷명을 미리 계산할 수 있었다.
둘째, SDK가 버킷 소유권을 검증하지 않았다. 해당 이름의 버킷이 GCS에 존재하는지만 확인하고, 그 버킷이 자신의 프로젝트 소유인지는 따지지 않았다. 공격자가 동일한 이름의 버킷을 자신의 GCP 계정에 미리 생성해 두면, 피해자 SDK는 이를 자신의 버킷으로 착각하고 모델을 올렸다.
Unit 42는 이 기법을 "버킷 스쿼팅(Bucket Squatting)"으로 명명했다. 도메인 스쿼팅의 클라우드 스토리지 버전이다.
Unit 42의 분석에 따르면, 단순 모델 탈취를 넘어 원격 코드 실행(RCE)으로 이어지는 체인은 다음 구조로 작동한다.
공격자는 버킷에 Cloud Storage 이벤트 트리거를 심어둔다. 피해자가 모델을 업로드하면 약 800밀리초 이내에 트리거가 발동되고, 1,400밀리초 시점에 파일이 악성 버전으로 교체된다.
Pickle 역직렬화가 RCE의 경로가 되는 이유: Python ML 모델 저장에는 joblib·pickle이 널리 쓰인다. 두 형식 모두 역직렬화 시점에 파일 내 __reduce__ 메서드를 자동 실행하는 특성이 있다. 공격자가 이 메서드에 임의 코드를 정의해 두면, Vertex AI 서비스 에이전트가 파일을 로드하는 순간 그 코드가 에이전트 권한으로 실행된다. RCE가 실행되는 주체가 Vertex AI 서비스 에이전트이기 때문에, 탈취되는 것은 공격자 자신의 권한이 아닌 피해자 테넌트의 서비스 계정 토큰이다.
Unit 42의 PoC에서 확인된 취득 가능한 권한 범위는 상당했다. 서비스 계정 토큰이 cloud-platform 스코프로 발급됐는데, 이는 GCP에서 가장 넓은 권한 범위다. 이를 통해 다음이 가능했다.
Unit 42와 Google의 공식 발표 기준, 야생 악용(exploitation in the wild)은 발견되지 않았다. CISA KEV 등재도 이루어지지 않았다.
동일한 루트 원인(버킷명 예측 + 소유권 미검증)으로 Gemini Enterprise와 Cloud Run("MountSquat")에서도 함께 발견됐다. Focal Security의 분석에 따르면, 버킷 스쿼팅은 특정 벤더의 문제가 아니라 클라우드 스토리지 설계에서 반복 등장하는 구조적 패턴이다.
공격자는 피해자 SDK가 자신의 버킷에 파일을 올릴 수 있도록 IAM 정책을 열어둬야 한다. 이 흔적이 탐지 기점이 된다.
Cloud Audit Logs: 피해자의 SDK가 storage.objects.create 이벤트를 생성할 때, 해당 버킷의 resourceName에 포함된 프로젝트 번호가 자신의 프로젝트와 일치하지 않는다. 이 프로젝트 번호 불일치가 공격 발생 여부를 가리는 핵심 지표가 된다.
버킷 선점 조기 탐지: storage.buckets.create 이벤트를 모니터링해, 피해자 프로젝트의 예상 버킷명 패턴({project-id}-vertex-staging-*)을 다른 프로젝트가 선점하는 시도를 감지할 수 있다. Google Cloud의 Security Command Center에서 이상 버킷 생성 규칙을 설정하면 조기 경보가 가능하다.
v1.148.0 이후 SDK는 타 프로젝트 버킷으로의 업로드 시도를 에러로 차단하므로, 버킷 스쿼팅 공격 시도 자체가 SDK 로그에 에러로 남는다.
ATT&CK 매핑 (추정 — 공식 매핑 없음):
cloud-platform 스코프 서비스 계정 토큰 재활용국내에서도 통신·의료·게임·플랫폼 등 여러 분야의 기업이 Vertex AI를 운영 환경에 도입하고 있다. Google Cloud가 공개한 한국 고객 사례만 봐도 ML 파이프라인이 실서비스에 폭넓게 들어와 있음을 알 수 있다.
문제는 기본 설정이다. SDK의 staging_bucket 파라미터를 별도로 지정하지 않으면 {project-id}-vertex-staging-{region} 공식이 그대로 적용되므로, 기본 설정 상태의 파이프라인은 버킷명이 외부에서 예측 가능한 구조를 유지한다. google-cloud-aiplatform이 v1.148.0 미만이라면, 버킷 소유권 검증이 없는 상태로 모델 업로드가 이루어진다.
"Pickle in the Middle"이 보여준 것은 피해자 계정에 대한 어떤 접근도 없이 ML 인프라에 침투할 수 있다는 점이다. 클라우드 네이티브 ML 파이프라인에서 SDK 기본값을 그대로 신뢰하는 구조가 얼마나 넓은 공격 표면을 만드는지를 이 취약점이 구체적으로 증명했다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.