▲

Google API 키는 비밀이 아니었다. 그러나 Gemini가 규칙을 바꿨다

 (trufflesecurity.com)
1P by GN⁺ 9시간전 | ★ favorite | 댓글 1개
  • Google이 10년 넘게 API 키는 비밀이 아니며 공개해도 안전하다고 안내해 왔으나, Gemini API 활성화 이후 동일 키가 민감한 인증 수단으로 변함
  • 기존에 Google Maps, Firebase 등에서 사용되던 공개 키가 Gemini API 접근 권한을 자동으로 얻게 되어, 공개된 키로 개인 데이터 접근 및 요금 청구 가능
  • Truffle Security는 2,863개의 실사용 Google API 키가 인터넷에 노출되어 있으며, 이 중 일부는 Google 자체 서비스의 키도 포함됨을 확인
  • Google은 문제를 인정하고 누출 키 차단, Gemini 전용 기본 설정, 노출 알림 기능을 도입 중이나, 기존 키의 소급 점검은 미완료 상태
  • 이번 사례는 AI 기능 통합으로 인한 기존 자격 증명의 권한 확장 위험을 보여주며, 개발자들은 즉시 Gemini API 활성화 여부와 키 노출 상태 점검이 필요함

핵심 문제

  • Google Cloud는 AIza... 형식의 단일 API 키 구조를 사용하며, 이는 공개 식별용과 민감 인증용 두 목적을 동시에 수행
    • 과거 Google은 개발자에게 API 키를 클라이언트 코드에 직접 포함해도 안전하다고 명시
    • Firebase 보안 체크리스트에서도 “API 키는 비밀이 아니다”라고 안내
  • 그러나 Gemini API가 활성화되면, 기존 프로젝트의 모든 API 키가 자동으로 Gemini 엔드포인트 접근 권한을 얻게 됨
    • 경고, 확인 절차, 이메일 알림 없이 권한이 확장됨
  • 이로 인해 두 가지 문제가 발생
    • 권한의 소급 확장(Retroactive Privilege Expansion): 과거 공개된 Maps 키가 Gemini 접근 자격으로 변함
    • 불안전한 기본값(Insecure Defaults): 새 키 생성 시 기본 설정이 “Unrestricted”로 되어 있어, Gemini 포함 모든 API 접근 가능
  • 결과적으로 수천 개의 청구용 토큰이 실제 인증 자격으로 변해 인터넷에 노출된 상태

공격 가능 시나리오

  • 공격자는 웹사이트의 소스코드에서 AIza... 키를 복사해 단순한 curl 요청으로 Gemini API에 접근 가능
  • 공격자는 이를 통해
    • 비공개 데이터 접근 (/files/, /cachedContents/ 엔드포인트)
    • Gemini API 사용 요금 부과
    • 쿼터 소진으로 서비스 중단 유발
  • 공격자는 피해자의 인프라를 침입하지 않고, 공개 웹페이지에서 키만 추출해 공격 수행 가능

공개된 키의 규모

  • Truffle Security는 Common Crawl 2025년 11월 데이터셋(약 700TiB) 을 분석해 2,863개의 활성 Google API 키를 발견
    • 이 키들은 원래 Google Maps 등 공개 서비스용으로 사용되었으나, Gemini API 접근 권한을 보유
  • 피해 대상에는 금융기관, 보안기업, 글로벌 리크루팅사, 그리고 Google 자체가 포함
    • Google조차 동일한 구조적 위험에 노출되어 있었음

Google 내부 키 사례

  • Truffle Security는 Google 제품 웹사이트의 공개 소스코드에 포함된 키로 Gemini API 접근을 시연
    • 해당 키는 2023년 2월 이전부터 공개되어 있었으며, 원래는 단순 프로젝트 식별용으로 사용
    • /models 엔드포인트 호출 시 정상 응답(200 OK) 을 반환, 민감 API 접근 가능 확인
  • 즉, 과거 무해했던 키가 개발자 개입 없이 민감 권한을 획득한 사례

취약점 보고 및 대응 타임라인

  • 2025년 11월 21일: Google VDP에 보고
  • 11월 25일: Google은 “의도된 동작”으로 판단
  • 12월 1일~2일: Truffle Security가 Google 내부 키 사례 제시 후, Google이 버그로 재분류 및 심각도 상향
  • 12월 12일: Google이 누출 키 탐지 파이프라인 확장 및 Gemini 접근 제한 조치 시작
  • 2026년 1월 13일: Google이 취약점을 “단일 서비스 권한 상승(Single-Service Privilege Escalation, READ)” 으로 분류
  • 2월 2일: 근본 원인 수정 작업 진행 중 확인

Google의 후속 조치

  • Google은 공식 문서에서 다음과 같은 보안 강화 계획을 발표
    • Scoped defaults: AI Studio에서 생성된 새 키는 Gemini 전용 접근만 허용
    • Leaked key blocking: 누출된 키의 Gemini API 접근 자동 차단
    • Proactive notification: 누출 키 탐지 시 사용자에게 즉시 알림 발송
  • 일부 개선은 이미 진행 중이나, 기존 노출 키의 소급 점검 및 사용자 통보는 미완료

개발자 점검 가이드

  • 1단계: 모든 GCP 프로젝트에서 Generative Language API 활성화 여부 확인
  • 2단계: 활성화된 경우, API 키 설정에서 ‘Unrestricted’ 또는 Gemini 포함 키 식별
  • 3단계: 해당 키가 공개 코드나 웹페이지에 포함되어 있는지 확인
    • 노출된 키는 즉시 회전(rotating) 필요
  • 보너스: TruffleHog 도구를 사용해 Gemini 접근 가능한 실사용 키 자동 탐지 가능
    • 명령 예시: trufflehog filesystem /path/to/your/code --only-verified

결론

  • 이번 사례는 AI 기능 추가로 인해 기존 공개 자격 증명이 민감 권한을 얻게 되는 구조적 위험을 보여줌
  • Google은 문제를 인식하고 대응 중이나, 안전한 기본값과 키 분리 설계의 중요성이 다시 부각됨
  • 개발자와 기업은 Gemini API 활성화 여부 및 키 노출 상태를 즉시 점검해야 함
▲
GN⁺ 9시간전  [-]
Hacker News 의견들

  • Google AI Studio 문서가 오픈 프록시를 통해 앱을 배포하도록 권장하고 있음
    이 방식은 API 키가 프록시 뒤에 있으니 안전하다고 착각하게 만들지만, 실제로는 AI 과금 남용이 가능해짐
    AI 기능이 전혀 없는 앱조차도 키 범위가 수동으로 제한되지 않으면 고비용 모델에 노출됨
    이런 취약한 앱들은 Google, Twitter, Hacker News 검색만으로도 쉽게 찾을 수 있음
    관련 분석은 이 글에 정리되어 있음

  • Google이 유출된 키를 차단한다고 하지만, 애초에 그 키들을 비밀로 취급하지 않았음
    Gemini 출시 이전에 생성된 모든 키가 Gemini에 접근하지 못하도록 막는 게 이상적이었음
    만약 유출 탐지 시스템이 오탐을 낸다면, 정상적인 Gemini 키까지 차단될 위험이 있음

    • 이 문제는 단순히 차단으로 해결될 수준이 아님
      최소한 Generative Language API 권한을 모든 기존 키에서 제거해야 하지만, 그마저도 완전한 해결책은 아님
      결국 모든 키에서 해당 권한을 일괄 제거해야 할 수도 있음
      이는 수많은 애플리케이션을 깨뜨릴 것이며, Google이 문제를 인정하지 않으려는 이유가 됨
      더 심각한 건 키가 캐시된 컨텍스트와 업로드 데이터까지 노출한다는 점임

  • 예전 안드로이드 이미지에 하드코딩된 Google 키들이 실제로 Gemini에 사용 가능했음을 발견했음
    일부는 이미 많은 사람이 사용 중이라 속도 제한이 걸렸지만, 몇몇은 여전히 작동했음
    두 달 전쯤 이 키들이 유출된 것으로 간주되어 모두 비활성화되었음

  • 오래전에 생성된 키들이 원래는 Firebase나 Firestore 같은 제한된 서비스용이었음
    그런데 Gemini 출시 후, 기존 키에도 Gemini 접근이 자동으로 활성화되어 악용이 쉬워졌음
    APK 파일에 포함된 공개 키가 그대로 Gemini 접근 키가 되어버린 셈임

    • Gemini API는 기본적으로 비활성 상태이지만, 프로젝트 단위로 활성화되면 문제가 생김
      예를 들어 개발자 X가 Maps용 키를 만들고, 다른 개발자 Y가 같은 프로젝트에서 Gemini를 켜면
      X의 키가 Gemini 접근 권한을 얻게 됨
      따라서 프로젝트 재사용을 피하고, 서비스별로 분리된 GCP 프로젝트를 써야 함

  • 이렇게 명백한 보안 결함이 왜 사전에 걸러지지 않았는지 의문임
    Google 같은 대기업이라면 표준화된 테스트나 스펙이 있어야 하는데 말임

    • Google은 예전의 Google이 아님
      조직이 커지고 복잡해질수록 이런 감시 사각지대가 오히려 늘어남
    • 이런 기본적인 보안 검증을 인터뷰 항목으로 넣자는 제안도 있었지만,
      그들은 여전히 이진 트리 뒤집기 문제에만 몰두했음
    • Google의 진짜 전문성은 광고 판매에 있음
    • 보안은 여전히 개발자들이 가장 신경 안 쓰는 마지막 프런티어임
    • 거대한 조직에서는 왼손이 오른손이 뭘 하는지 모르는 경우가 많음

  • 이 사태는 과거 SSN(사회보장번호) 남용 사례를 떠올리게 함
    원래는 단순 식별용 번호였는데, 어느 순간 인증 키로 쓰이기 시작하면서 문제가 커졌던 것처럼
    빠르고 싸게 구현하려다 결국 비용은 사용자에게 전가되는 구조임

  • Google이 아직 이 문제를 완전히 해결하지 못한 것처럼 보임
    Gemini를 서둘러 출시하려다 생긴 대형 실수이며,
    문제를 고치려면 기존 키를 비활성화해야 해서 고객 워크플로우가 망가질 가능성이 큼
    Google 입장에서도 매우 치명적인 이미지 손상임

  • 이건 일종의 권한 역확장(Retroactive Privilege Expansion) 문제임
    예전 Maps 키를 웹사이트에 공개해뒀는데, 팀의 다른 개발자가 Gemini를 켜면
    그 공개 키가 곧바로 Gemini 접근 자격이 되어버림
    결과적으로 누구나 그 키로 파일 업로드나 캐시 데이터에 접근할 수 있게 됨

    • 새 기능은 기존 키가 아니라 명시적으로 옵트인한 새 키에만 적용했어야 함
      예전 문서에 따라 공개 키를 사용한 사용자들이 피해를 보고 있음
    • 물론 Maps 키를 공개하는 건 원래 위험함
      공격자가 그 키를 훔쳐 과금 폭탄을 일으킬 수 있음

  • 쉽게 설명하자면, 수천 개의 기존 API 키가 단순 과금 토큰에서
    갑자기 Gemini 접근 자격으로 바뀌어버린 상황임
    Maps API 키는 원래 사용자에게 지도 서비스를 제공하면서 내 카드로 결제되도록 설계된 것임
    문제는 이런 키들이 이제 Gemini에도 접근할 수 있게 되었다는 점임
    내부용 프로젝트를 따로 만들어 키를 분리했어야 했는데,
    빠르게 배포하려다 LLM이 생성한 코드를 그대로 쓰고, 문제가 생기자 Google 탓을 하는 구조임

    • 하지만 실제 문제는 Maps 키가 이제 Gemini의 민감한 콘텐츠까지 접근할 수 있다는 점임

  • 이 문제를 분석한 보안 회사의 이전 연구도 인상적이었음
    예를 들어 “Anyone can Access Deleted and Private Repository Data on GitHub” 글처럼
    삭제된 GitHub 저장소 데이터 접근 취약점을 밝혀낸 사례가 있음
    이번에도 그들의 분석이 큰 도움이 되었음

답변달기