- Google Cloud Vertex AI SDK for Python에 버킷 스쿼팅(Bucket Squatting) 취약점이 존재하여, 피해 프로젝트에 대한 접근 권한이 없는 공격자가 모델 업로드 과정을 가로채고 조작할 수 있다.
- Palo Alto Networks Unit 42가 이 공격 기법을 Pickle in the Middle이라 명명하고 Google 버그 바운티 프로그램을 통해 제보했으며, 야외 악용 사례는 현재까지 확인되지 않았다.
- 성공 시 Google의 관리형 서빙 인프라 내부에서 임의 코드가 실행될 수 있어, 모델 아티팩트 무결성 검증과 pickle 대체 포맷 도입이 핵심 대응으로 부상한다.
클라우드 AI 서비스의 신뢰 경계가 SDK 내부의 암묵적 가정 한 줄로 무너지면 곧장 공급망 침투로 이어질 수 있다는 점이 이번 사안의 본질적 시사점이다.
머신러닝 워크로드가 빠르게 클라우드 네이티브 환경으로 이동하면서, 학습과 서빙 사이의 모델 업로드 경로가 새로운 공급망 위협 면(surface)으로 부상하고 있다. 특히 Google Cloud의 Vertex AI는 모델 레지스트리와 스토리지(GCS, Google Cloud Storage) 결합을 통해 업로드 자동화를 제공하는데, 바로 이 자동화 지점에 보안 사각지대가 존재할 수 있다는 분석이 나왔다.
들어가며: Vertex AI 모델 업로드 경로가 새 위협 면이 된 이유
공급망 공격의 최신 무대는 클라우드 AI 인프라
전통적인 소프트웨어 공급망 공격은 패키지 저장소나 CI/CD 파이프라인에 집중되어 왔다. 그러나 모델 학습과 배포가 Managed Service 위주로 전환되면서, 공격자의 시선은 SDK 호출과 클라우드 스토리지의 상호작용 패턴으로 옮겨가고 있다. Vertex AI SDK가 모델을 업로드할 때 사용하는 임시 경로와 권한 모델이 충분히 견고하지 않으면, 모델 아티팩트 자체가 침투 벡터가 될 수 있다.
Unit 42가 명명한 Pickle in the Middle의 의미
Palo Alto Networks Unit 42의 연구진은 이번 취약점을 분석하며 Pickle in the Middle이라는 공격 명칭을 제안했다. 이는 pickle 기반 직렬화 모델 파일이 업로드 구간의 중개 지점에서 변조될 수 있음을 함축적으로 표현한 용어로, 클라우드 AI 보안 커뮤니티에서 새로운 공격 분류 체계로 자리 잡을 가능성도 있다.
취약점 개요: Google Vertex AI SDK for Python의 버킷 스쿼팅 결함
버킷 스쿼팅이란 무엇인가
버킷 스쿼팅(Bucket Squatting)은 클라우드 스토리지의 버킷 이름이 전역적으로 고유해야 한다는 특성을 악용한 기법이다. 예측 가능한 버킷 명명 규칙을 역추적하여, 정식 사용자보다 먼저 동일 이름의 버킷을 선점하고, 이후 피해자의 트래픽이나 업로드 흐름을 자신에게로 우회시키는 방식으로 동작한다.
피해 프로젝트 권한 없이 모델 업로드를 가로채는 흐름
취약한 SDK는 모델 업로드 시 특정 GCS 버킷 경로를 사용자가 명시적으로 소유하지 않아도 암묵적으로 신뢰하는 경로가 포함될 수 있다. 이때 공격자가 동일 경로의 버킷을 사전에 생성해 두면, SDK가 의도치 않은 위치로 모델을 전송하게 되며, 공격자는 그 과정을 가로채 자신의 pickle 페이로드로 치환할 기회를 얻는다.
공격 메커니즘 심층 분석: Pickle in the Middle 단계별 해부
1단계: 대상 GCS 버킷 선점 및 경로 예측
공격자는 먼저 Vertex AI가 내부적으로 활용하는 버킷 명명 규칙과 디렉터리 패턴을 분석한다. 공개 문서, SDK 소스, 그리고 과거 트래픽 노출 사례를 결합해 예측 가능한 경로를 추출한 뒤, 자신의 GCP 계정에서 동일 이름의 버킷을 미리 생성한다. 이 시점에서는 피해 프로젝트와의 직접적 연결이 없으므로 침해 흔적이 남지 않을 수 있다.
2단계: 악성 pickle 페이로드 삽입
버킷 선점이 완료되면, 공격자는 피해자가 업로드할 위치에 pickle 포맷의 악성 모델 파일을 미리 배치할 수 있다. pickle은 Python 객체 직렬화 표준으로, 역직렬화 과정에서 __reduce__ 등을 통해 임의 코드가 실행될 수 있어 정상 모델과 외형상 구분이 어려운 악성 페이로드로 둔갑할 가능성이 있다.
3단계: Google 서빙 인프라 내부에서 임의 코드 실행
피해자의 SDK가 모델을 업로드하고 Vertex AI 서빙 노드가 해당 pickle을 로드하는 순간, 페이로드가 트리거되어 서빙 컨테이너 내부에서 임의 코드가 실행된다. 공격자는 이 권한을 활용해 인접 메타데이터, 다른 버킷, 혹은 동일 프로젝트 내 다른 리소스로 횡적 이동할 수 있으며, 침해의 정당성을 입증하기 위한 감사 로그 조작까지 가능해질 수 있다.
영향 범위와 위험도 평가
실제 야외 악용 사례는 없지만 잠재 영향이 큰 이유
Unit 42와 Google 측 모두 현재까지 야외(wild) 환경에서 실제 악용이 확인되지 않았다고 밝혔다. 그러나 pickle 역직렬화 취약점의 특성과, 공격이 성공할 경우 Google의 관리형 서빙 인프라 내부에서 코드가 실행된다는 점에서, 영향력이 큰 사안으로 분류된다. 특히 관리형 ML 서비스는 사용자가 호스트 OS를 직접 통제하지 못하기 때문에 사고 대응과 포렌식이 매우 제한적이다.
영향받는 구성 요건과 점검 체크리스트
아래 표는 영향을 받는 구성과 권장 점검 항목을 요약한 것이다.
- 영향 가능 구성: Vertex AI SDK for Python을 통해 모델 업로드를 수행하고, SDK가 내부적으로 추론 가능한 GCS 경로를 사용하는 모든 프로젝트
- 권장 점검 항목 1: SDK 버전 확인 및 최신 패치 적용 여부
- 권장 점검 항목 2: 프로젝트 IAM 정책에서 최소 권한 원칙 준수 여부
- 권장 점검 항목 3: 모델 아티팩트의 무결성 검증(해시, 서명) 정책 존재 여부
- 권장 점검 항목 4: pickle 기반 직렬화를 SafeTensors, ONNX 등 대체 포맷으로 전환했는지 여부
탐지·완화·패치 가이드
즉시 적용 가능한 SDK 업그레이드 및 IAM 점검
우선 Vertex AI SDK for Python을 최신 버전으로 업그레이드하여 버킷 스쿼팅 관련 패치를 적용해야 한다. 동시에 프로젝트 IAM에서 service account에 부여된 roles/storage.objectAdmin과 같은 광범위 권한을 좁히고, 업로드 대상 버킷을 명시적으로 지정하는 정책을 강화할 필요가 있다.
모델 아티팩트 무결성 검증과 pickle 대체 포맷 도입
장기적으로는 pickle 사용을 줄이는 것이 가장 효과적인 완화책이다. Hugging Face의 SafeTensors나 ONNX와 같이 임의 코드 실행이 불가능한 포맷으로 전환하고, 업로드 단계에서 SHA-256 해시와 클라우드 KMS 기반 서명 검증을 거치는 파이프라인을 설계해야 한다. 이러한 절차는 Pickle in the Middle 시나리오에서 페이로드 치환 시도를 차단하는 데 결정적 역할을 한다.
버그 바운티 및 위협 인텔리전스 활용 방안
이번 사례는 외부 연구자의 책임 있는 공개(responsible disclosure)가 어떻게 클라우드 AI 보안을 강화하는지를 잘 보여준다. 보안팀은 Google, AWS, Microsoft Azure의 버그 바운티 프로그램과 Unit 42, Mandiant 같은 위협 인텔리전스 제공자의 보고서를 정기적으로 모니터링하고, 신규 SDK 릴리스 노트에서 보안 관련 변경 사항을 별도로 트래킹하는 체계를 갖춰야 한다.
공급망 전 구간에 걸친 보안 모델링 재설계 필요성
단일 SDK 취약점 차원의 대응을 넘어, 모델 학습-패키징-업로드-서빙 전 구간에 대한 위협 모델링을 재수행할 필요가 있다. 특히 Managed AI 서비스는 사용자가 통제하지 않는 신뢰 경계를 포함하므로, zero-trust 원칙에 기반한 검증 단계를 명시적으로 추가하고, 사고 발생 시 공급망 침해를 전제로 한 포렌식 절차를 미리 마련해 두는 것이 바람직해 보인다.
핵심 정리
- 버킷 스쿼팅은 예측 가능한 스토리지 명명 규칙을 악용해 업로드 흐름을 가로채는 기법으로, Vertex AI SDK의 모델 업로드 경로가 직접적인 표적이 되었다.
- Pickle in the Middle 공격은 선점-삽입-실행의 3단계로 구성되며, 성공 시 Google 서빙 인프라 내부에서 임의 코드 실행으로 이어질 수 있다.
- SDK 업그레이드와 IAM 최소 권한 적용에 그치지 않고, pickle 대체 포맷과 아티팩트 서명 검증을 포함한 공급망 보안 모델 재설계가 요구된다.