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

구글을 AI로 해킹해서 7억 원을 벌기까지\n\nAI에게 구글 API를 자동으로 테스트하도록 학습시키고, 끊임없이 취약점을 분석하게 만든 결과 단 3개월 만에 무려 50만 달러(한화 약 7억 원)의 버그 바운티(보안 포상금)를 획득한 놀라운 연구 사례가 공개되었습니다.\n\n이번 연구는 정교한 제로데이 취약점 공격이 아니었습니다. 대규모 안드로이드 앱에서 수집한 API 키와 구글의 공식 API 명세서를 분석한 뒤, Claude 기반 AI가 사람처럼 API를 호출하여 권한 검증 누락(BOLA/IDOR) 등 기본적이지만 치명적인 실수를 찾아내도록 자동화한 것이 핵심입니다. 구글 보이스 계정 탈취부터 유튜브 비공개 영상 노출까지, 발견된 취약점의 디테일과 AI 시스템 설계 방식을 생생하게 전해드립니다.\n\n---\n\n## 1. 연구의 출발점과 접근 전략\n\n이번 대규모 프로젝트는 2025년 10월 'bugSWAT Mexico' 행사에 초청받은 것을 계기로 시작되었습니다. 연구진은 구글의 소스 코드 일부를 분석할 수 있는 권한을 얻은 뒤 큰 흥미를 느꼈고, 지난 1년간 Claude를 사용해 소규모 개발 프로젝트를 진행한 경험을 바탕으로 \"AI를 활용해 구글 API 전체를 대규모로 테스트하면 어떨까?\"라는 가설을 세웠습니다.\n\n자동화 테스트를 위한 핵심 진입점은 바로 구글의 '디스커버리 문서(Discovery Document)'였습니다. 이는 구글의 모든 API 엔드포인트, 파라미터, 메서드 형식을 기계가 읽을 수 있도록 기술한 일종의 '구글 전용 Swagger 문서'입니다. YouTube Data API 같은 공개 문서뿐만 아니라, 내부 전용 'Internal People API' 같은 비공개 API 문서도 이 방식으로 관리되고 있었습니다. 이 명세서들을 확보하면 AI가 정확히 어떤 구조로 요청을 보내야 하는지 쉽게 파악할 수 있습니다.\n\n---\n\n## 2. 대규모 API 키 및 타겟 도메인 수집\n\n구글 API를 호출하려면 유효한 API 키가 필요합니다. 하나의 서비스에서 유출된 키가 구글 클라우드 플랫폼(GCP) 내의 다른 여러 API에서도 기본적으로 연동되어 사용 가능한 경우가 많기 때문입니다. 연구진은 키를 긁어모으기 위해 다음과 같은 치밀한 과정을 거쳤습니다.\n\n- 안드로이드 앱 분석: 총 61,200개의 구글 관련 안드로이드 APK 파일의 압축을 해제하여 소스 코드 내에 하드코딩된 API 키를 대량으로 수집했습니다.\n- 실시간 트래픽 캡처: 크롬 디버거 API 기반의 브라우저 확장 프로그램을 개발하여, 알려진 2,800여 개의 구글 웹 도메인을 방문할 때 오가는 실시간 요청에서 API 키를 갈취했습니다.\n- iOS 앱 및 바이너리 복호화: 구글의 iOS 앱(IPA) 파일과 기타 바이너리를 역공학 분석하여 추가 키를 확보했습니다.\n\n이렇게 수집한 수만 개의 키 중에서 구글 공식 프로젝트의 키만 필터링하기 위해 'Cloud Marketplace API'를 활용했습니다. 유효하지 않은 API에 요청을 보낼 때 반환되는 에러 메시지 속 프로젝트 번호(project 244648151629 등)를 파악한 후, 도메인 소유주가 google.com 혹은 인수 합병된 자회사(nest.com, fitbit.com, wing.com 등)인 키들만 남기고 나머지는 모두 폐기했습니다.\n\n또한, 수집된 도메인 중 실제로 살아있는 구글 API 서버를 구별하기 위해 HTTP 응답 헤더 중 Server 헤더가 ESF, GSE, scaffolding on HTTPServer2 중 하나로 끝나는 도메인을 실시간으로 매핑했습니다.\n\n---\n\n## 3. 숨겨진 API 명세서(Discovery Document) 우회 확보\n\n구글은 보안 강화를 위해 2025년 7월경 대부분의 API에서 /$discovery/rest 경로로 명세서를 직접 조회하는 길을 막아버렸습니다. 하지만 연구진은 다음과 같은 두 가지 우회 기법으로 숨겨진 API 명세서를 확보했습니다.\n\n- Visibility Label(공개 라벨) 악용: 특정 구글 내부 프로젝트는 외부 노출을 막기 위해 라벨이 걸려 있습니다. 예를 들어 Service Management API 명세서를 일반 경로로 받으면 크기가 253KB에 불과하지만, 쿼리 파라미터에 ?labels=GOOGLE_INTERNAL을 붙여 요청하자 용량이 329KB로 늘어나며 수많은 숨겨진 엔드포인트가 드러났습니다.\n- 조합 무차별 대입: 모든 가능성 있는 내부 라벨, 확보한 API 키, 모든 API 목록을 일일이 조합해 수백만 번의 요청을 보낸 끝에 1,500개 이상의 정밀한 API 명세서를 확보하는 데 성공했습니다.\n\n---\n\n## 4. 까다로운 구글 인증(FPA) 장벽 넘기\n\nAPI 키를 확보했더라도 상당수 API는 호출자가 누구인지 검증하는 추가 인증을 요구합니다. 베어러(Bearer) 토큰을 무작위로 사용하면 GCP 프로젝트 간 충돌 에러가 발생하여 사용할 수 없었습니다. 이때 연구진은 구글이 자체적으로 사용하는 내부 인증 체계인 FPA(First Party Authentication)에 주목했습니다.\n\n웹 브라우저의 세션 쿠키와 이를 기반으로 연산된 Authorization 헤더는 구글 내부 API 전송을 위해 활성화되어 있었습니다. 특히 구글이 예전에 실수로 노출한 소스맵 파일에서 내부용 인증 헤더 생성 라이브러리인 gapix의 코드가 발견되었습니다. 이 덕분에 연구진은 FPA v2 인증 헤더를 임의로 생성할 수 있게 되었습니다.\n\n구글의 모든 계정은 고유의 난독화되지 않은 Gaia ID(순차적 숫자 형식)를 가지고 있었는데, FPA v2의 토큰 구조(timestamp_hash_identifier)에 이 Gaia ID와 이메일 등을 삽입하여 정상적인 인증 통과를 유도했습니다. 또한, 특정 API가 내부 개발자 전용 도메인(*.corp.google.com)에서의 접근만 허용하도록 설정된 것을 발견하고 이를 우회하여 대규모 내부 취약점을 확인했습니다.\n\n---\n\n## 5. AI 자동 테스트 시스템의 구축과 노이즈 필터링\n\n준비가 완료된 후, 연구진은 약 일주일간의 튜닝을 거쳐 자체 제작한 API Explorer 도구를 Claude 모델과 연결했습니다. Claude가 사람 보안 연구원처럼 API를 탐색하고 취약점을 파악하도록 만들기 위해 아래와 같은 엄격한 최적화를 수행했습니다.\n\n- 랄프 위검 루프(Ralph Wiggum Loop) 설계: AI가 단순히 \"몇 번 찔러보고 끝났다\"고 판단하는 조기 종료 현상을 막기 위해, 모든 엔드포인트를 최소 1회 이상 완벽히 테스트하기 전까지는 절대 종료되지 않도록 제어 루프를 강제했습니다.\n- 인증 무관화 및 데이터 해싱: AI가 API의 복잡한 FPA v2 암호화 연산에 신경 쓰지 않고 오직 논리적인 취약점 페이로드를 작성하는 데만 집중할 수 있도록 복잡한 헤더 연산은 백엔드 프로그램에 위임했습니다. 동일한 키로 반복 검증 시 발생하는 수많은 중복 에러 응답은 해시값으로 압축 정리하여 AI의 인지 부하를 줄였습니다.\n- 오탐율 낮추기: 초기에는 보고되는 탐지 결과의 90%가 단순 노이즈(오탐)였습니다. 한 달간의 프롬프트 엔지니어링 끝에, 타인의 개인 데이터에 무단 접근 가능한 경우(BOLA)와 성공적인 조작(2xx 응답) 등 명확한 버그의 기준을 정해주자 AI의 버그 발견 정확도가 50% 이상으로 급격히 개선되었습니다.\n- 재현 검증용 Operation ID 제공: 발견된 취약점 리포트에 실제 발생했던 요청 패킷 추적 아이디(Operation ID)를 포함시켜, 사람이 UI에서 'Play' 버튼 한 번만 누르면 즉시 버그가 재현되도록 신뢰도를 확보했습니다.\n\n---\n\n## 6. 발견된 주요 취약점 및 버그 바운티 수령 현황\n\n이렇게 구축된 AI 시스템은 가동된 지 3개월 만에 총 50만 달러가 넘는 보안 포상금을 휩쓸었습니다. 다음은 구글이 즉각 패치한 대표적인 심각한 취약점 사례들입니다.\n\n| 취약점 대상 API | 발견된 문제의 핵심 | 포상금 (USD) |\n| --- | --- | --- |\n| Translation Hub | 아무 구글 계정 토큰으로 타 프로젝트의 기밀 파일 경로 조회 및 공유 서비스 계정을 악용해 비공개 GCS 버킷 내의 원본 파일을 추출하는 취약점 | $36,500 |\n| AdExchange 계정 탈취 | 스테이징 환경의 관리자 생성 API가 접근 제어 없이 실제 프로덕션 데이터를 직접 바라보고 있어, 요청 단 한 번으로 임의 계정에 자신을 관리자(Admin)로 무단 등록 가능 | $30,000 |\n| Vertex Assistant | 숨겨진 비공개 AI 비서 서비스의 특정 쿼리가 인증 없이 대상자의 이메일 주소만 있으면 대화 이력 및 민감 세션을 통째로 읽어올 수 있었던 결함 | $30,000 |\n| Vertex AI Search | 권한 검증 누락으로 인해 고객의 기업용 프롬프트와 사내 분류 예시를 무단 조회하고, AI의 시스템 프롬프트(Preamble)에 프롬프트 인젝션 페이로드를 주입할 수 있는 취약점 | $30,000 |\n| Eldar (구글 내부 사이트) | 구글 직원들만 접근해야 하는 개인정보 영향 평가 시스템이 외부에 공개되어 수많은 내부 데이터 조회 및 허가 요청 권한 노출 | $26,674 |\n| YouTube TV CMS | 임의의 영상을 차단(strike), 소유권 주장(claim), 수익화(monetize) 처리할 수 있는 파트너 전용 엔드포인트의 전역 권한 검사 누락 및 민감 이메일 유출 | $24,000 |\n| Google Voice | 인증도 필요 없는 한 줄의 curl 명령만으로 타인의 Gaia ID 기준 개인정보(PII) 전체를 다운로드하고 임의 계정에 포워딩 번호를 강제 등록하는 초민감 취약점 | $20,000 |\n| App Engine (CVE-2026-8934) | 인증 절차 없이 타 프로젝트의 24시간 치밀한 요청 로그(비밀번호 재설정 토큰 링크 등 포함)를 전체 조회할 수 있는 취약점 | $18,000 |\n| Widevine DRM 키 노출 | 넷플릭스, 디즈니 등이 사용하는 암호화 키 관리 도구의 파트너 포털에 권한 없이 로그인하여 PGP·AES 복호화 키를 통째로 가져올 수 있던 결함 | $16,004.40 |\n| YouTube 비공개 영상 유출 | 에셋 명명 규칙의 패턴(Auto generated asset - <video_id>)을 활용한 검색 API 취약점으로, 미공개 예정인 기업의 신제품 발표 영상 등 비공개 영상을 사전 유출할 수 있던 위협 | $12,000 |\n\n``chart\n{\"title\":\"주요 취약점별 버그 바운티 수령액\",\"unit\":\"달러($)\",\"data\":[{\"label\":\"Translation Hub\",\"value\":36500},{\"label\":\"AdExchange 탈취\",\"value\":30000},{\"label\":\"Vertex Assistant\",\"value\":30000},{\"label\":\"Vertex AI Search\",\"value\":30000},{\"label\":\"Eldar 내부망\",\"value\":26674},{\"label\":\"YouTube TV CMS\",\"value\":24000},{\"label\":\"Google Voice 탈취\",\"value\":20000},{\"label\":\"App Engine 로그\",\"value\":18000},{\"label\":\"Widevine DRM 키\",\"value\":16004},{\"label\":\"YouTube 비공개영상\",\"value\":12000}]}\n``\n\n---\n\n## 7. 마무리와 핵심 교훈\n\n이 대규모 프로젝트는 우리에게 매우 중요한 교훈을 남깁니다.\n\n첫째, 구글과 같은 거대 빅테크 기업에서 발견되는 치명적인 취약점조차도 엄청나게 복잡하고 정교한 수학적 해킹 공격이 아니라 \"권한 검증 누락\", \"잘못 설정된 스테이징 환경\", \"디버그 도메인의 무단 노출\" 같은 너무나 기본적이고 반복적인 실수에서 시작된다는 점입니다.\n\n둘째, 이 과정에서 AI의 역할은 '창의성'이 아니라 '지치지 않는 끈기'였습니다. 사람이 일일이 수천 개의 엔드포인트를 매번 수십 개의 API 키와 대조해 가며 테스트하는 것은 불가능에 가깝습니다. 하지만 AI는 지치지 않고 수백만 번의 반복 검증을 통해 아주 미세한 권한 틈새를 기어코 잡아냈습니다.\n\n셋째, AI 보안 테스트가 제대로 기능하기 위해서는 '사람이 즉각 재현하고 검증할 수 있는 일원화된 워크플로(Operation ID)'와 'AI가 정확한 형식을 이해할 수 있도록 구조화된 명세서(Discovery Doc)'가 선제적으로 구축되어 있어야 합니다. 이 시스템 인프라를 마련하는 것이 보안 자동화의 성패를 가르는 결정적인 차이였습니다.