Claude에 API 테스트 도구를 붙여 구글의 내부 API를 자동으로 찔러본 결과, 단 3개월 만에 50만 달러(약 7억 원)의 버그 바운티를 받은 실전 사례를 원문 기준으로 분석합니다. 어떻게 가능했는지, 그리고 우리 서비스도 같은 함정에 빠져 있는 건 아닌지 함께 짚어볼게요.
AI 버그 바운티로 7억을 벌었다는데, 정교한 0day였을까요?
보안 리포트를 보다 보면 늘 기대하게 되는 장면이 있어요. 메모리 커럽션, 정교한 익스플로잇 체인, 며칠 밤을 새운 리버스 엔지니어링 같은 거요. 그런데 이번에 화제가 된 사례는 정반대였습니다. 거의 대부분이 “권한 검사를 깜빡한 API” 한 줄짜리 실수에서 터졌거든요.
한 보안 연구자가 2025년 10월부터 약 3개월간 구글을 대상으로 진행한 연구인데, 핵심은 사람이 일일이 찌른 게 아니라 Claude 기반 AI에게 API 테스트를 시켰다는 점이에요. 최근 보안 업계에서 이 글이 크게 회자됐는데, 저도 원문을 끝까지 읽으면서 “이건 자동화의 방향성 자체가 바뀌는 신호”라는 생각이 들더라고요. 단순 요약을 넘어, 실제 수치와 방법론을 하나씩 뜯어보겠습니다.
⚡ 이 글의 핵심만 먼저 보기 (Key Takeaways)
- 총 수익: 약 3개월 만에 50만 달러(약 7억 원)의 구글 버그 바운티 획득
- 수집 규모: 61,200개 Android APK에서 API 키 3,600개를 긁어모으고, 1,500개 이상의 API 명세서를 확보
- 핵심 도구: Claude에 API 테스트용 MCP 도구를 연결해 권한 검사 누락(접근 제어 취약점)을 자동으로 탐색
- 가장 충격적인 점: 대부분이 0day가 아니라 인증 없는 API·테스트 환경의 실데이터 노출 같은 반복되는 기본 실수
- 최대 단일 보상: Translation Hub 취약점 묶음이 $36,500으로 가장 컸음
- 실무 액션: 우리 서비스의 스테이징·내부 API가 프로덕션 데이터를 보고 있지 않은지 지금 점검할 것
📌 목차
- 50만 달러는 어떻게 가능했나 — 전체 그림
- 출발점: API 키 6만 개와 숨겨진 명세서 사냥
- 인증의 벽 넘기: FPA v2 리버스 엔지니어링
- Claude를 자동 해커로 만든 5단계 셋업
- 실제로 터진 취약점 케이스 분석
- 진짜 교훈: 반복되는 기본 실수
- 이런 분들께 적극 추천합니다
- 자주 묻는 질문 (FAQ)
1. 50만 달러는 어떻게 가능했나 — 전체 그림
먼저 큰 그림부터요. 이 연구는 2025년 10월 bugSWAT Mexico 초청을 계기로 다시 불붙었고, 약 3개월간의 집중 테스트 끝에 총 50만 달러의 보상으로 이어졌어요. 출발점은 화려한 기술이 아니라 단순한 가정 하나였습니다. “구글에는 외부에 잘 알려지지 않은 API가 엄청나게 많고, 그중 일부는 권한 검사가 비어 있을 것이다.”
문제는 그 “엄청나게 많은 API”를 사람이 다 못 본다는 거예요. 그래서 등장한 게 AI입니다. 키를 모으고, 살아있는 API 도메인을 찾고, 명세서를 확보한 뒤, Claude에게 사람처럼 요청을 보내며 접근 제어 구멍을 찾게 한 거죠.
① Scale over depth — 깊이보다 규모로 승부한 전략
이 연구의 본질은 “한 방의 천재적 익스플로잇”이 아니라 지치지 않는 반복이에요. 1,500개 API × 수천 개 키 × 여러 인증 조합을 사람이 손으로 돌리면 평생 걸리지만, AI는 밤새 묵묵히 돌릴 수 있거든요.
💡 실제 활용 시나리오 예시:
보안팀이 수백 개 마이크로서비스를 운영 중이라면, 사람 펜테스터가 전수 점검하는 데만 몇 주가 걸려요. 여기에 AI 에이전트를 붙여 “모든 엔드포인트에 인증 없이 요청 → 2xx + 민감 데이터 응답만 보고”로 1차 스크리닝을 돌리면, 사람은 진짜 의심 케이스만 검증하면 됩니다.
2. 출발점: API 키 6만 개와 숨겨진 명세서 사냥
공격 표면을 넓히는 게 첫 단계였어요. 핵심 진입점은 discovery document, 쉽게 말해 구글판 Swagger 문서입니다. 모든 엔드포인트·파라미터·메서드를 기계가 읽을 수 있게 기술해 둔 거라, AI 자동 테스트의 입력으로 완벽했죠.
① 61,200 APKs — 앱을 통째로 분해해 키 줍기
친구 Michael과 협력해 모든 버전의 모든 구글 안드로이드 앱 61,200개 APK를 내려받아 압축을 풀고 API 키를 검색했어요. 여기에 Chrome Debugger API 기반 확장으로 실시간 트래픽에서 키를 가로채고, iOS 앱(IPA) 복호화까지 병행해 총 3,600개 키를 확보했습니다. 한 서비스에서 찾은 키가 같은 GCP 프로젝트의 다른 API에도 살아있는 경우가 많아서, 키를 많이 모을수록 접근 범위가 폭발적으로 넓어졌어요.
② Visibility Label — labels 파라미터로 숨은 API 캐내기
2025년 7월 구글이 대부분 API에서 /$discovery/rest 경로를 막았지만, 우회로가 있었어요. 일부 프로젝트는 visibility label이 켜져 있어서 ?labels=GOOGLE_INTERNAL을 붙여야만 숨은 엔드포인트가 보였거든요. 실제로 Service Management API 명세서가 라벨 없이는 253KB였는데, 라벨을 붙이자 329KB로 늘면서 숨겨진 문서가 대량으로 노출됐습니다.
💡 실제 활용 시나리오 예시:
“우리 내부 API는 문서를 공개 안 했으니 안전해”라고 믿는 팀이 많아요. 하지만 이 사례처럼 인증서 투명성 로그(CT log)와 키워드 브루트포스만으로도 숨은 도메인이 드러납니다. 보안은 “안 알려줬다”가 아니라 “권한으로 막혔다”여야 합니다.
3. 인증의 벽 넘기: FPA v2 리버스 엔지니어링
API 키로 “권한”은 해결됐지만, 많은 엔드포인트는 “호출자가 누구인지” 확인하는 인증(authentication)도 따로 요구했어요. 여기서 막혔다면 연구는 절반에서 끝났을 텐데, 돌파구가 있었습니다.
① First Party Authentication — 구글 독자 인증의 구조
구글의 웹 요청은 세션 쿠키와 그로부터 계산한 Authorization 값을 함께 *.clients6.google.com으로 보냅니다. 이게 FPA(First Party Authentication)예요. 일부 API는 이메일 등 사용자 식별자까지 해시에 넣는 더 완전한 FPA v2를 요구했는데, 결정적으로 Michael이 구글이 한동안 실수로 유출한 sourcemap에서 내부 gapix 라이브러리의 FPA v2 헤더 생성 코드를 찾아냈습니다.
② Gaia ID — 순차적 숫자가 만든 추적의 단서
토큰 형식은 <timestamp>_<hash>_<식별자키>이고, SHA-1 입력은 “email:gaiaId timestamp sessionCookie origin”이에요. 여기서 중요한 게 Gaia ID입니다. 모든 구글 계정은 순차적인(예: 131337133377) unobfuscated Gaia ID를 가지는데, 이 “순차적”이라는 성질이 나중에 Nest 기기 소유자 신원 추적의 핵심 단서가 됐어요.
💡 실제 활용 시나리오 예시:
식별자를 1, 2, 3처럼 순차 정수로 발급하면 enumeration(연속 추측)에 그대로 노출돼요. 신규 서비스를 설계한다면 사용자 ID는 UUID나 난독화된 값으로 발급하고, 순차 내부 ID는 절대 외부 응답에 노출하지 않는 게 기본 중의 기본입니다.
4. Claude를 자동 해커로 만든 5단계 셋업
저는 이 챕터가 가장 흥미로웠어요. AI에게 그냥 “취약점 찾아”라고 던지면 절대 안 됩니다. 처음엔 거대한 컨텍스트를 한 번에 던졌더니 AI가 중간에 멈춰버렸거든요. 그래서 단계적으로 구조를 잡았습니다.
① 그룹 분류 + Ralph Wiggum 루프
엔드포인트를 기능별로 묶어 컨텍스트 부담을 줄이고, AI가 “다 했어요”라고 거짓 종료하지 못하도록 confirm_testing_complete() 검증을 강제했어요. 일명 Ralph Wiggum 루프인데, AI가 끝났다고 우겨도 실제로 모든 케이스를 돌렸는지 확인하고서야 종료되게 한 거죠.
② 멀티 키 프로빙 + 표준 에러 분류
같은 요청을 모든 API 키로 돌리며 응답을 중복 제거(dedup)하고, 구글의 난해한 오류 메시지를 standardErrorType으로 표준화했어요. 이게 핵심인데, 에러를 일관되게 분류해야 AI가 “권한 없음”과 “데이터 노출”을 구분할 수 있거든요.
# AI에게 가르친 판단 기준 (의역)
1) 순차 ID 추측 → 테스트 기법일 뿐, 취약점 아님
2) 존재 여부 노출(enumeration) ≠ 데이터 노출
3) 2xx 응답 + 기밀 데이터 → 진짜 취약점
4) 확인 즉시 보고 (confirm_testing_complete)💡 실제 활용 시나리오 예시:
AI 에이전트로 반복 작업을 자동화할 때 가장 큰 적은 “그럴듯한 거짓 보고”예요. 출력 스키마를 강제하고(여기선 표준 에러 타입), 완료 조건을 코드로 검증하게 하면 false positive가 확 줄어듭니다. 사내 QA 자동화에도 그대로 적용 가능한 패턴이에요.
참고로 이런 “AI에 도구를 붙여 자동화”하는 흐름이 궁금하다면 Claude Code 확장 완벽 정리: 스킬·플러그인·MCP 3종 글도 함께 보면 그림이 잘 그려져요.
5. 실제로 터진 취약점 케이스 분석
이제 AI가 실제로 찾아낸 것들을 볼게요. 보상 금액과 함께 보면 “아, 이게 이렇게 큰일이구나” 싶어집니다.
| 취약점 | 핵심 원인 | 보상 |
|---|---|---|
| Google Voice 계정 탈취 | 인증 없는 엔드포인트가 전화번호·복구 연락처 노출 | $20,000 |
| AdExchange 권한 상승 | 스테이징이 프로덕션 데이터를 가리킴 | $30,000 |
| Widevine DRM 키 노출 | PGP·서명 키와 파트너 명부 접근 | $16,004.40 |
| YouTube 비공개 영상 유출 | Content ID가 미공개 영상 식별자 누출 | $12,000 |
| Translation Hub | 인증 없는 ListOperations + 교차 테넌트 쓰기 | $36,500 |
| Vertex AI Search 프롬프트 인젝션 | 설정 API에 읽기·쓰기 권한 검사 누락 | $30,000 |
① Nest 기기 소유자 추적 — 조합의 무서움
단일 버그보다 무서운 건 조합이에요. Nest 인증 프록시에서 순차 unobfuscated Gaia ID를 enumeration하고, 여기에 Play Books 라이선스 관리 기능을 엮어 이메일까지 역추적했습니다. 결국 “이 Nest 기기 주인은 누구”라는 신원 매칭이 가능해진 거죠.
② 스테이징의 배신 — test 환경이 진짜 데이터를 봤다
AdExchange는 test-adexchangebuyer-googleapis.sandbox.google.com이라는 스테이징이 프로덕션 데이터를 가리켰고, PLX/DataHub에서는 스테이징의 setIamPolicy가 인증 없이 열려 1,592개 이상의 유튜브 분석 테이블(페타바이트급)을 노출했어요. “테스트니까 괜찮아”가 가장 위험한 말이었던 셈입니다.
💡 실제 활용 시나리오 예시:
많은 회사가 스테이징 DB를 프로덕션 스냅샷으로 채우면서 접근 제어는 느슨하게 둬요. 실데이터를 쓸 거면 프로덕션과 동일한 인증·권한을 적용하거나, 아예 마스킹된 합성 데이터를 쓰는 게 맞습니다. 이 사례만으로도 사내 스테이징 정책을 다시 볼 이유가 충분해요.
6. 진짜 교훈: 반복되는 기본 실수
50만 달러짜리 결론이 허무할 정도로 단순해요. 거의 모든 취약점이 세 가지 기본 실수로 수렴했거든요.
- 권한 검사 누락: 인증은 받아놓고 “이 사용자가 이 데이터를 볼 자격이 있나”를 안 봄
- 인증 없는 API: 내부용이라 믿고 아예 인증을 안 건 엔드포인트
- 테스트 환경의 실데이터 노출: 스테이징이 프로덕션을 그대로 바라봄
여기서 핵심이 있어요. AI가 한 일은 “새로운 공격 기법 발명”이 아니라 지치지 않고 전수 검사한 것뿐이에요. 즉, AI 버그 바운티의 위력은 창의성이 아니라 규모와 끈기에서 나옵니다. 공격자가 이미 이 무기를 들었다면, 방어자도 같은 무기로 우리 표면을 먼저 훑어봐야 한다는 뜻이고요.
💡 실제 활용 시나리오 예시:
다음 스프린트에 “접근 제어 회귀 테스트”를 넣어보세요. 권한 없는 토큰으로 모든 주요 엔드포인트를 호출했을 때 401/403이 아니라 200이 나오면 즉시 실패하는 자동 테스트요. 이 단순한 게이트 하나가 위 케이스의 70% 이상을 사전에 잡습니다.
7. 이런 분들께 적극 추천합니다
- API를 다수 운영하며 접근 제어(IDOR/BOLA)가 늘 불안한 백엔드 개발자
- 스테이징·내부 환경의 보안 정책을 책임지는 DevOps·SRE 담당자
- AI 에이전트로 보안 테스트·QA 자동화를 실험해보고 싶은 분
- 버그 바운티에 입문하려는데 “뭘 어디서부터”가 막막한 주니어 보안 연구자
- AI가 실제 업무를 어디까지 자동화하는지 사례로 확인하고 싶은 기획자·PM
- 사내 API 거버넌스·문서 노출 정책을 점검해야 하는 아키텍트
8. 자주 묻는 질문 (FAQ)
Q. AI만 있으면 누구나 이렇게 버그 바운티로 돈을 벌 수 있나요?
A. 그렇게 단순하진 않아요. AI는 전수 테스트와 패턴 탐색을 대신해줄 뿐, 키 수집·인증 우회·결과 검증 같은 핵심 판단은 연구자의 깊은 도메인 지식에서 나왔습니다. 다만 진입 장벽이 크게 낮아진 건 분명해요. AI에게 “무엇을 시키고, 어떻게 검증할지”를 설계하는 능력이 새로운 핵심 역량이 됩니다.
Q. 우리 서비스도 같은 위험에 노출돼 있을까요?
A. 안타깝게도 가능성이 높아요. 이 사례의 취약점은 특별한 게 아니라 어디서나 흔한 “권한 검사 누락”이었거든요. 권한 없는 토큰으로 주요 API를 호출하는 회귀 테스트를 추가하고, 스테이징이 프로덕션 데이터를 보지 않게 분리하는 것부터 시작하면 위험을 크게 줄일 수 있습니다.
Q. 이렇게 구글을 테스트해도 법적으로 괜찮은 건가요?
A. 이 연구는 구글의 공식 취약점 보상 프로그램(VRP) 범위 안에서 진행됐기 때문에 합법이에요. 실제로 연구자는 비-구글 키를 폐기하며 범위를 철저히 지켰습니다. 허가 범위(scope) 밖을 건드리면 그건 범죄가 됩니다. 반드시 공식 프로그램 규정을 먼저 확인하세요.
✍️ 글을 마치며
이번 사례의 진짜 메시지는 “AI가 천재 해커가 됐다”가 아니라, 지루한 전수 검사를 지치지 않고 해내는 존재가 생겼다는 거예요. 그리고 그 앞에서 무너진 건 정교한 방어선이 아니라 권한 검사 한 줄을 깜빡한 기본 실수였습니다.
저는 당장 “권한 없는 토큰으로 모든 주요 엔드포인트를 호출했을 때 200이 나오면 실패하는” 회귀 테스트를 만들어볼 것 같아요. 공격자가 AI로 우리 표면을 훑기 전에, 우리가 먼저 같은 방식으로 훑는 게 가장 현실적인 방어니까요.
여러분은 어떤 부분이 가장 인상적이셨나요? 댓글로 자유롭게 의견 남겨주세요! 😊