2026년 6월 현재, 한 보안 연구원이 Claude 기반 AI에 API 테스트 도구를 연결해 Google의 1,500개 이상 API를 자동으로 두드려 3개월 만에 50만 달러의 버그 바운티를 벌었다. 대부분 취약점은 정교한 익스플로잇이 아니라 권한 검사 누락, 인증 없는 API, 실제 데이터를 그대로 노출한 테스트 환경 같은 반복되는 기본 실수에서 비롯됐다. 이 글은 그 워크플로와 발견된 사례, 그리고 일반 개발자도 배울 수 있는 교훈을 정리한다.
한 사람이 3개월에 7억? — 사건 개요
brutecat.com이 공개한 사례는 단순하다. AI가 사람처럼 API를 찔러보고, 응답에서 권한 제어 누락을 자동으로 걸러내며, 사람이 그중 심각한 취약점을 골라 보고서로 다듬는다. 연구원 본인은 이 방식을 "AI의 역할은 참신함이 아니라, 사람이 끝까지 다루기엔 너무 넓은 표면에서 명백한 것을 지치지 않고 반복 검증하는 것" 이라고 표현한다.
| 항목 | 수치 |
|------|------|
| 연구 기간 | 약 3개월 (2025년 10월~2026년 1월) |
| 누적 바운티 | 500,000 USD 이상 (한화 약 7억 원) |
| 테스트 대상 API | 1,500개+ (Google 공개 + 내부 discovery) |
| 분석한 Android 앱 | 61,200개 APK |
| 수집한 API 키 | 60,000개 앱에서 추출 |
| AI 자동 발견 정확도 | 50%+ (소음 제외 후) |
| 발견한 주요 사례 | 9건 이상 (P0/S0 포함) |
어떻게 시작했나 — 61,200개 APK 속 API 키 모으기
진입점은 Google의 discovery document(Google판 Swagger)다. 모든 엔드포인트·파라미터·메서드를 기계가 읽을 수 있게 기술한 문서인데, YouTube Data API처럼 공개된 것도 있지만 Internal People API 같은 내부 API에도 존재한다. 문제는 대부분이 유효한 API 키를 요구한다는 점이다.
API 키 수집은 4단계로 진행됐다.
- 1단계: 모든 버전의 모든 Google 앱을 포함한 61,200개 Android APK 내려받아 압축 해제 후 API 키 grep
- 2단계: Chrome Debugger API 기반 확장 프로그램으로 트래픽 가로채, 2,800여 개 Google 웹 도메인 방문하며 실시간 키 수집
- 3단계: Google iOS 앱(IPA) 복호화와 입수 가능한 바이너리 분석 병행
- 4단계: Cloud Marketplace API로 키에 연결된 GCP 프로젝트 정보를 조회해 google.com / nest.com / fitbit.com / wing.com 외 키는 폐기
한 서비스에서 찾은 키가 같은 GCP 프로젝트의 여러 다른 API에 활성화되는 경우가 많아, 키를 많이 모을수록 접근 가능한 API 범위가 선형으로 늘어난다. 연구원은 친구 Michael과 협력해 60,000개 앱에서 추출한 키를 권한 없는 API에 대입하며 살아있는 키를 분류했다.
1,500개 API 명세서 확보 — 숨겨진 엔드포인트까지
2025년 7월 Google이 대부분 API에서 /$discovery/rest 경로를 제거했지만 일부는 우회가 가능했다. 그리고 특정 프로젝트는 visibility label이 켜져 있어 labels 파라미터를 줘야만 보이는 숨겨진 엔드포인트가 존재한다.
# 라벨 없이 받으면 253KB
curl "https://servicemanagement.googleapis.com/v1/services//projectSettings/"
# ?labels=GOOGLE_INTERNAL을 붙이면 329KB
curl "https://servicemanagement.googleapis.com/v1/services//projectSettings/?labels=GOOGLE_INTERNAL"
이 라벨은 한 번에 하나만 받을 수 있어, 모든 라벨 × 모든 키 × 모든 API 조합을 시험하는 막대한 요청량이 필요했다. 그래야 1,500개+ API 명세서를 확보하고, 과거 연구에서 모아둔 문서와 합쳐 AI 자동 테스트 준비가 완료된다.
FPA 토큰과 Origin 제한 풀기
API 키로 "권한"은 해결됐지만 다수 엔드포인트는 호출자가 누구인지 확인하는 인증(authentication)을 별도로 요구한다. Bearer 토큰은 GCP 프로젝트에 묶여 있어 API 키와 섞으면 "서로 다른 프로젝트" 오류가 발생하고, 알려진 우회법이 없다. 다행히 다수 API가 Google 독자 인증인 First Party Authentication(FPA)을 지원한다.
Michael이 Google이 한동안 실수로 유출한 sourcemap을 발견, 내부 gapix 라이브러리에서 FPA v2 헤더 생성 코드를 확보했다. 토큰 구조는 email:gaiaId timestamp sessionCookie origin이다. 식별자 키는 e(이메일)·u(난독화 Gaia ID)·a(Workspace 도메인) 단 3개뿐이고 다른 글자는 백엔드가 무시한다.
마지막으로 Origin 화이트리스트와 키 제한이 남는다. 다수 API는 허용 Origin 목록을 두며, 비허용 origin 사용 시 SESSION_COOKIE_INVALID 오류를 반환한다. 키에는 Server·Browser·Android·iOS 네 가지 제한이 있어, Browser는 Referer, iOS는 X-Ios-Bundle-Identifier, Android는 X-Android-Package와 인증서 지문이 일치해야 한다. 키 수집 시 이 값들도 함께 저장해 무차별 대입을 동일 프로그램에 통합했다. 단 *.corp.google.com origin은 제한이 없어, 이런 API는 공개 의도가 아닌 내부 API일 가능성이 높고 버그도 많다 — 한 사례는 접근 제어 취약점으로 9,000 USD를 받았다.
AI가 50% 정확도로 버그를 대량 발견한 구성
요청은 어디서 막히는지 분류하는 프로그램을 먼저 만들었다. 메서드 해석 → 키 유효성 → 키 제한 → 인증 → origin 검사 → label 검사 등 6단계에서 거부 여부를 매핑하고, 어떤 키가 어떤 API에 통하는지 대응표를 확보했다. Google의 API Explorer는 공개 API만 지원하므로, FPA v2까지 지원하는 자체 API Explorer를 약 일주일 만에 만들었다.
그 위에 AI 레이어를 얹었다.
- 프론트엔드의 JSON 파싱 코드를 MCP 도구로 AI에 연결
- AI는 페이로드 작성에만 집중, 복잡한 FPA 인증은 백엔드가 처리
- 엔드포인트를 논리적 그룹으로 분류해 그룹 단위로 테스트
- Ralph Wiggum loop로 모든 엔드포인트를 최소 1회 테스트
- 키마다 응답이 다를 수 있어 동일 요청을 모든 키에 자동 전송
- "Method not found" 같은 헷갈리는 오류를
MISSING_REQUIRED_VISIBILITY_LABEL등으로 번역 - 같은 응답은 해시로 묶어 정리
발견된 주요 취약점 — 9건만 소개
3개월간 500,000 USD 이상의 바운티를 확보했고, 게재된 것은 그중 일부다.
| 서비스 | 취약점 | 보상 |
|--------|--------|------|
| Google Voice | gfibervoice-pa에 접근 제어 없음, Gaia ID만으로 PII 전체 덤프 | 20,000 USD |
| AdExchange | 스테이징 환경에서 임의 계정에 ADMIN 추가 가능 | 30,000 USD |
| Eldar (eldar.corp.google.com) | Googler 전용 평가 관리 API가 외부 노출 | 26,674 USD |
| YouTube 비공개 영상 | asset 이름 패턴으로 비공개 영상 ID 유출 | 12,000 USD |
| Widevine DRM | 파트너 포털 API 공개, 조직 키 조회·복호화 | 16,004 USD |
| PLX 내부 분석 | DataHub API에서 setIamPolicy로 admin 자가 추가, 2.1PB 테이블 노출 | 24,000 USD |
| Translation Hub | ListOperations 인증 없이 작동, 타 프로젝트 데이터 조회 | 36,500 USD |
| YouTube TV CMS | GET /v1/campaigns가 스코핑 없이 전역 덤프 | 24,000 USD |
| Vertex AI Search Commerce | 시스템 프롬프트 노출 및 프롬프트 인젝션 | 30,000 USD |
개발자도 배울 수 있는 5가지 교훈
이 사례에서 일반 백엔드/API 개발자가 가져갈 수 있는 교훈은 다음과 같다.
- IAM 체크 누락은 가장 흔한 버그다. 정교한 익스플로잇보다 "인증 없는 엔드포인트"가 더 큰 보상을 받는다.
- 스테이징이 프로덕션을 가리키면 취약점이다. AdExchange 사례처럼 테스트 환경이 실 데이터를 노출하는 패턴이 반복된다.
- discovery doc / GraphQL SDL을 점검하라.
?labels=GOOGLE_INTERNAL같은 우회 경로가 있을 수 있다. - operation_id 재현 시스템이 핵심이다. 보고서에 operation ID를 넣어 프론트엔드에서 "Play"로 재현 가능하게 만들면 잡음을 90%에서 50% 미만으로 줄일 수 있다.
- AI는 표면을 넓히는 도구다. 사람이 끝까지 다루기엔 너무 넓은 API 범위에서 명백한 것을 반복 검증하는 역할에 최적화되어 있다.
마무리 — 반복되는 깨진 패턴
3개월간 이 설정으로 500,000 USD 이상의 바운티를 확보했고, 그중 일부는 1시간 내에 P0/S0로 인정받았다. 대부분의 Google 버그는 인내가 핵심이며, 동일한 깨진 패턴이 도처에 반복된다. IAM 체크 누락, 인증 없는 GraphQL, 프로덕션의 디버그 엔드포인트, 실제 데이터를 가리키는 샌드박스. AI의 역할은 이 명백한 것들을 지치지 않고 반복 검증하는 것이고, 사람이 그중 심각한 사례를 골라내는 구조가 가장 효과적이었다. 2026년 6월 기준으로 AI 기반 자동 API 퍼징은 더 이상 실험이 아니라, 보안 연구의 표준 워크플로가 되어가고 있다.
'자동화&툴 리뷰' 카테고리의 다른 글
| 취약점 보고서는 더 이상 특별하지 않다 — 2026년 LLM 시대 보안 분류학 (0) | 2026.06.25 |
|---|---|
| F3 - 미래를 위한 오픈소스 데이터 파일 형식, Parquet 이후의 차세대 컬럼 포맷 (0) | 2026.06.25 |
| X 외국어 글 자동 번역 — "번역 보기" 안 눌러도 되는 오픈소스 크롬 확장 (0) | 2026.06.24 |
| NotionTalk: 카카오톡에서 바로 쓰는 Notion 비서 — MCP 한 번 연결로 끝 (1) | 2026.06.24 |
| bigset - 세상의 모든 데이터를 가지고 있다면? 한 문장으로 만드는 라이브 데이터셋 (0) | 2026.06.24 |