구글을 AI로 해킹해서 7억원 벌기

▲ 이미지 출처: GeekNews

2026년 6월, 보안 연구자 아르빈 시브람(Arvin Shivram, 핸들명 Brutecat)이 자신의 블로그에 글 한 편을 올렸다. 제목은 “Hacking Google with A.I. for $500,000“. 3개월 동안 Claude AI를 자동화 도구로 삼아 구글 내부 API 1,500개 이상을 체계적으로 탐사한 끝에 50만 달러(약 7억원)어치의 취약점을 Google의 공식 버그 바운티 프로그램(VRP)에 보고했다는 기록이다. 발견된 취약점의 스펙트럼은 충격적이다. 인증 없이 타인의 전화번호를 가로챌 수 있는 Google Voice API부터, 넷플릭스·아마존 프라임이 사용하는 Widevine DRM 파트너 포털, 수 페타바이트 규모의 YouTube 내부 데이터에 접근 가능한 스테이징 환경까지 포함됐다.

배경: Google VRP와 AI 보안의 교차점

구글의 취약점 보상 프로그램(VRP)은 2010년 시작 이래 2025년까지 누적 8,160만 달러를 747명의 연구자에게 지급했다. 2025년 한 해만 1,710만 달러로 역대 최고 기록을 세웠고, 개별 최고 보상금은 25만 달러에 달했다. 같은 해 구글은 AI 취약점만을 다루는 별도 AI VRP도 운영해 도쿄 행사 단 하나에서만 70건 이상의 보고서와 40만 달러 이상을 집행했다. 시브람의 사례가 특별한 이유는 수익 총액이 아니다. AI가 기존 수동 방식의 속도와 규모 한계를 어떻게 돌파하는지, 그 메커니즘을 최초로 공개적으로 해부했다는 점이다.

데이터 수집: 6만 1,200개 APK와 2,800개 도메인

시브람의 작업은 데이터 수집 단계부터 자동화됐다. 그는 APK Mirror에서 구글 앱 61,200개의 APK 파일을 긁어 역공학으로 내장된 API 키를 추출했다. 동시에 Chrome Debugger API를 활용한 브라우저 확장을 구축해 2,800개 이상의 구글 웹 도메인에서 실시간 네트워크 트래픽을 가로채 추가 키를 수집했다. iOS 바이너리와 Cloud Marketplace API 필터링까지 포함하면 최종적으로 3,600개의 API 키가 모였다. 구글이 제공하는 머신 리더블 API 명세서인 discovery document(구글판 Swagger 문서)를 통해 1,500개 이상의 API 엔드포인트 목록이 확보됐다. 여기에는 외부에 공개되지 않은 내부 API도 포함됐다. 일부 API는 GOOGLE_INTERNAL 가시성 레이블을 달고 있었는데, 이 레이블 자체가 역설적으로 숨겨진 엔드포인트의 존재를 드러냈다.

AI 엔진: Claude MCP 툴과 1개월의 프롬프트 정제

핵심 자동화 엔진은 Claude AI에 세 가지 MCP(Model Context Protocol) 툴을 붙인 구조였다. probe_api(엔드포인트 직접 호출), report_vulnerability(취약점 자동 기록), confirm_testing_complete(테스트 완료 확인)가 그것이다. Claude는 이 툴들을 통해 1,500개 API를 3,600개 키 전체로 순열 조합해 자율적으로 탐사했다. 시브람은 시스템 프롬프트를 약 1개월에 걸쳐 반복 정제했고, 최종적으로 취약점 탐지 정확도 50% 이상을 달성했다. 그룹 기반 엔드포인트 분류, 다중 키 병렬 프로빙, 표준화된 오류 메시지 파싱이 주요 개선 포인트였다. 단순한 스크립트 자동화가 아니라 AI 에이전트가 맥락을 이해하고 판단하며 탐사하는 구조다.

발견된 취약점과 보상금: 카테고리별 해부

연구를 통해 확인된 주요 취약점과 VRP 보상금은 다음과 같다. 가장 심각한 케이스는 Google Voice/Fiber API였다. gfibervoice-pa.googleapis.com 엔드포인트는 Gaia ID(구글 내부 사용자 식별자)만 있으면 인증 없이 타인의 전화번호·보이스메일 PIN·복구 번호까지 반환했다. 임의 번호 배정도 가능해 SIM 스왑 공격으로 이어질 수 있었다. 구글은 보고 후 수 시간 안에 패치했고 보상금은 2만 달러였다. Vertex AI Translation Hub는 3만 6,500달러로 단일 최고 보상금을 받았다. 인증되지 않은 ListOperations 호출이 서비스 계정명과 GCS 버킷명을 유출했고, 다른 프로젝트의 번역가 그룹·편집 작업(PII 포함)에 크로스 테넌트 읽기가 가능했다. 로고 업로드 기능을 통해 비공개 GCS 오브젝트 탈취도 성공했다.

AdExchange 스테이징 환경은 3만 달러짜리 케이스였다. 스테이징 도메인 test-adexchangebuyer-googleapis.sandbox.google.com이 프로덕션 데이터를 그대로 가리키고 있었고 접근 통제가 전무했다. 모든 AdExchange 계정 목록 조회, 사용자 권한 수정, 임의 구글 계정을 관리자로 추가하는 것까지 가능했다. Vertex AI Commerce(3만 달러)에서는 권한 없는 사용자가 다른 프로젝트의 대화형 검색 설정과 내부 정책 노트를 읽을 수 있었고, 쓰기 권한까지 확보돼 고객사 AI 검색에 프롬프트 인젝션이 가능한 상태였다. Cloud Console GraphQL 세 건은 합산 6만 달러에 달했다. App Engine 로그 유출(CVE-2026-8934, 1만 8,000달러), Vertex AI 어시스턴트 세션 접근(3만 달러), Google Maps 청구·PII 유출(1만 2,000달러)이 각각 보고됐다. YouTube Content ID API(1만 2,000달러)는 자산명 형식 “Auto generated asset – <video_id>”를 통해 미공개·비공개 영상 ID를 검색 가능했다. PLX/DataHub 스테이징(1만 2,000달러)은 수 페타바이트 규모의 YouTube Analytics 테이블 1,592개에 접근 가능했고 IAM 정책으로 자신을 소유자로 추가할 수 있었다. Nest 기기 익명화 해제는 순차적 Nest ID로 Gaia ID를 조회한 뒤, 별도의 Play Books 라이선스 API와 체이닝해 이메일 주소까지 역산하는 공격 경로였다.

패턴 분석: 반복되는 기본 실수들

시브람이 블로그에서 강조한 핵심은 이것이다. 발견된 취약점 대부분은 정교한 제로데이가 아니라 “반복되는 기본 실수”에서 비롯됐다. 구체적으로 세 가지 패턴이 반복됐다. 첫째, 누락된 권한 검사. API 엔드포인트 자체는 존재하지만 호출자가 누구인지 검증하지 않는다. Google Voice, YouTube TV CMS, Cloud Console GraphQL이 이 패턴이었다. 둘째, 스테이징 환경이 프로덕션 데이터를 가리키는 구조. 테스트 도메인에 접근 통제 없이 실제 운영 데이터가 연결된 경우가 AdExchange와 PLX/DataHub에서 발견됐다. 셋째, 테넌트 간 격리 실패. SaaS 구조에서 프로젝트 A가 프로젝트 B의 데이터를 읽거나 쓸 수 있는 상태가 Vertex AI Translation Hub와 Vertex AI Commerce에서 확인됐다. 이 세 패턴은 구글만의 문제가 아니다. 중소 서비스, 스타트업, SaaS 플랫폼에서 오히려 더 빈번하게 발생하는 구조적 문제다.

중소기업에 대한 시사점

• API 키 하드코딩 즉시 제거 — 안드로이드·iOS 앱, 웹 프론트엔드 코드에 박힌 API 키는 61,200개 APK를 자동 스캔하는 도구 앞에서 즉시 노출된다. 키는 환경변수나 서버사이드 프록시를 통해 관리해야 한다.
• 스테이징 환경 격리 점검 — 개발·테스트 서버가 프로덕션 DB나 API에 직접 연결돼 있지 않은지 확인하라. 스테이징이 실제 운영 데이터를 바라보는 구조는 VRP 3만 달러 케이스처럼 즉각적인 위협이 된다.
• API 엔드포인트 권한 감사 — 내부용으로 만든 API가 외부에서 인증 없이 호출 가능한 상태인지 정기적으로 점검하라. discovery document 유형의 API 명세서가 외부에 노출되면 공격자의 지도가 된다.
• 멀티테넌트 격리 검증 — SaaS 또는 멀티 프로젝트 구조라면 프로젝트 간 데이터 읽기·쓰기 격리를 명시적으로 검증하라. ORM이나 프레임워크의 기본 설정이 항상 안전하지는 않다.
• 방어자도 AI로 선제 탐색 — 공격자가 Claude 같은 AI를 써서 자동화한다면, 방어자도 같은 도구로 자신의 API를 먼저 탐색해야 한다. 자체 버그바운티 또는 AI 기반 DAST(동적 애플리케이션 보안 테스트) 도입을 고려할 시점이다.