AIでGoogleをハックして7億円稼ぐ

 (brutecat.com)
10 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • AIに Google のAPIを絶えず 自動で突かせた 結果、3か月で50万ドルのバグバウンティ収益を上げたセキュリティ研究の事例
  • 60,000本超の Android アプリから集めた APIキー と Google の API仕様書（discovery document） を組み合わせ、外部ではあまり知られていないものまで含め 1,500超のAPI をテスト対象として確保
  • Claude ベースのAIに APIテストツール を接続し、人間のようにリクエストを送り、権限確認が抜けた アクセス制御の脆弱性 を自動で見つけるよう構成
  • Google Voice アカウント乗っ取り、YouTube 非公開動画の流出、Widevine DRM キー露出、Nest デバイス所有者の身元追跡など深刻な脆弱性を多数発見
  • ほとんどは高度な攻撃ではなく、権限チェック漏れ、認証なしAPI、実データをそのまま露出したテスト環境 といった繰り返される基本的なミスに起因

研究の出発点

  • 2025年10月、bugSWAT Mexico への招待をきっかけに Google 向け研究へ再び注力。Google のソースコードを一部のぞける点が興味を引いた
  • 過去1年間 Claude で小規模プロジェクトを作る中で、AIで Google API を大規模に自動テスト する活用余地が大きいと判断
  • 中核となる入口は discovery document — Google版 Swagger ドキュメントで、すべてのエンドポイント・パラメータ・メソッドを機械可読で記述する
    • YouTube Data API のように公開されているものもあるが、Internal People API のような内部APIにも存在
    • 一部はそのままアクセスできるが、大半は 有効なAPIキーが必要

APIキー集め

  • あるサービスで見つけたキーが、同じ GCP プロジェクトの 複数の別APIでも有効 なことが多く、キーを多く集めるほどアクセス可能な API 範囲が広がる
  • 友人の Michael と協力してキー収集を実施
    • すべてのバージョンのすべての Google アプリを含む 61,200本の Android APK をダウンロードし、展開して API キーを検索
    • Chrome Debugger API ベースの拡張機能でトラフィックを横取りし、既知の約2,800の Google Web ドメインを巡回してリアルタイムのリクエストからキーを収集
    • Google の iOS アプリ（IPA）の復号や、入手可能な Google バイナリの解析も並行して実施

  • Google のキーだけを選別

    • VRP の範囲を守るため、Cloud Marketplace API でキーに紐づくプロジェクト情報を照会し、Google 以外のキーを除外
    • 権限のないAPIにキーを使うと、返ってくるエラーに プロジェクト番号 が露出する（例: "...in project 244648151629..."）
    • この番号で照会すると company フィールドがプロジェクト所有ドメインを示すため、google.com（および nest.com・fitbit.com・wing.com などの買収企業）以外のキーは破棄

生きている Google API ドメインを探す

  • 拡張機能が記録したドメイン、キーワードベースの総当たり生成、証明書透明性ログ（certificate transparency） を組み合わせて候補ドメインを確保
  • 各ドメインにリクエストを送り、Server ヘッダーが ESF・GSE・scaffolding on HTTPServer2 のいずれかなら、生きている有効な Google API と判定

隠された仕様書までかき集める

  • 2025年7月、Google は大半の API で /$discovery/rest パスを削除したが、一部は回避可能だった

  • Visibility Label で隠されたエンドポイント

    • 特定プロジェクトでは visibility label が有効で、labels パラメータを与えたときだけ見える隠しエンドポイントにアクセス可能
    • Service Management API の仕様書をラベルなしで取得すると253KBだが、?labels=GOOGLE_INTERNAL を付けると 329KB に増え、隠された文書が大量に露出
    • ラベルは一度に1つしか受け付けず、すべてのラベル・すべてのキー・すべての API の組み合わせを試す莫大なリクエスト量が必要
  • こうして 1,500超のAPI 仕様書を確保し、過去研究で集めていた文書と合わせて AI 自動テストの準備が整った

認証の問題を解決

  • API キーで「権限」は満たせても、多くのエンドポイントは呼び出し元が誰かを確認する 認証（authentication） も別途要求する
  • Bearer トークンは GCP プロジェクトに紐づいているため API キーと混ぜると「別プロジェクト」エラーになり、既知の回避策はなかった

  • First Party Authentication（FPA）

    • 多くの API が対応する Google 独自認証方式 FPA は API キーと併用できる
    • Web リクエストにはセッション Cookie と、そこから計算した Authorization 値が含まれ、*.clients6.google.com ホストへ送られる
    • drivefrontend-pa など一部の API は、メールアドレスなどのユーザー識別子をハッシュに入れる、より完全な FPA v2 ヘッダーを要求
    • Michael が、Google がしばらく誤って流出させていた sourcemap を発見し、内部 gapix ライブラリ内の FPA v2 ヘッダー生成コードを確保

  • トークン構造と Gaia ID

    • トークン形式は <timestamp>_<hash>_<識別子キー> で、SHA1 の入力は "email:gaiaId timestamp sessionCookie origin"
    • 識別子キーは e（メール）・u（難読化 Gaia ID）・a（Workspace ドメイン）の3つだけで、他の文字はバックエンドが無視
    • Gaia は "Google Accounts and ID Administration" の略で、すべてのアカウントは 連番の unobfuscated Gaia ID（例: 131337133377）と長い難読化 ID を持つ

  • Origin ホワイトリストとキー制限

    • 多くの API は許可 Origin 一覧を持ち、非許可 origin を使うと cookie の問題のように見える SESSION_COOKIE_INVALID エラーを返す
    • キーには Server・Browser・Android・iOS の4種類の制限があり、Browser は Referer、iOS は X-Ios-Bundle-Identifier、Android は X-Android-Package と証明書フィンガープリントの一致が必要
    • キー収集時にこれらの値もあわせて保存し、総当たりを同じプログラムに統合
    • *.corp.google.com origin は制限がなく、この種の API は公開意図のない内部 API である可能性が高く、バグも多い — ある事例ではアクセス制御の脆弱性で 9,000ドル を獲得

リクエストフローの地図と自作テストツール

  • リクエストがどの段階（メソッド解決 → キー有効性 → キー制限 → 認証 → origin 検査 → label など）で拒否されるかを分類するプログラムを作り、どのキーがどの API に通るかの対応表 を確保
  • Google の API Explorer は公開 API のみ対応で非公開版も直接使えないため、FPA v2 まで対応する自作 API Explorer を約1週間かけて制作
    • 仕様書をクライアント側で解析して有効なリクエスト/レスポンス JSON を自動構成し、任意ペイロードを素早く試せる UI を提供
    • デモで使われたエンドポイントは assignedTams（技術アカウントマネージャー） を漏えいさせるアクセス制御バグで、6,000ドル を獲得

AI 自動テストの構成

  • 目標は基本的な アクセス制御の問題を AI が自動発見 し、その後に人間がより深刻な脆弱性へ発展させること
  • フロントエンドの JSON パースコードを MCP ツール として AI に接続し、人間のように API をテストさせる構成にした

  • より徹底的に、より静かに

    • 当初は AI が数回突いて早々に終わってしまうため、Ralph Wiggum loop により全エンドポイントを最低1回テストしないと終了できないよう強制
    • エンドポイントを論理的 グループに先に分類 してグループ単位でテストし、前のグループで得た発見を後のグループへ共有
    • probe_api 入力を endpoint・path・body 中心に単純化し、複雑な FPA 認証はバックエンド側で処理して AI はペイロード作成に集中
    • キーごとにレスポンスが異なる可能性があるため、すべてのキーで同一リクエストを自動送信 し、同じレスポンスはハッシュでまとめて整理
    • Method not found のような紛らわしいエラーは MISSING_REQUIRED_VISIBILITY_LABEL などに翻訳して AI の混乱を防止

  • ノイズと検証の問題を解決

    • 当初は本物のバグが90%のノイズに埋もれ、検証の難しさ と 過剰な誤検知 の2点が主要課題として浮上
    • レポートに実際のリクエストを指す operation ID を入れ、フロントエンドで「Play」により再現可能にして改ざん不能な証拠を確保
    • 1か月以上かけてシステムプロンプトを磨き、報告基準を明確化 — 他ユーザーデータへのアクセス や、本来 4xx であるべき箇所での 2xx のみを対象とし、単なる 存在列挙（existence enumeration） は脆弱性から除外
    • その後、AI は 50%以上の精度 でバグを大量発見するようになり、唯一の制約は保有 API キーの数だった

発見された主な脆弱性

  • 3か月未満の運用で 50万ドル相当 のバグを発見。以下は修正済みの代表例

  • Google Voice アカウント乗っ取り

    • gfibervoice-pa にアクセス制御がまったくなく、認証すら不要な1行の curl で、被害者の unobfuscated Gaia ID さえ分かれば電話番号・通知先アドレスなど PII を丸ごとダンプ可能
    • レスポンスから被害者の Google アカウント復旧用電話番号 まで確認可能（特定条件でのみ露出、正確な条件は Google 非公開）
    • 任意アカウントに Voice 番号を強制割り当てするエンドポイントも存在し（500エラーでも実際には番号が追加される）、SIM スワップの可能性があるエンドポイントも発見
    • P0/S0 と分類され数時間でパッチ、20,000ドル を獲得
    • パッチ直後に /btz などイントラネット専用 zhandler の露出も発見し、/flagz に到達すると実行サービスから API キーを抽出可能だった

  • AdExchange アカウント乗っ取り

    • 単一リクエストで AdExchange アカウント一覧全体 をダンプするエンドポイントを発見
    • 本番では塞がれていたアカウント用エンドポイントが、ステージング環境ではアクセス制御なしで動作 し、そのステージングが実際の本番データを参照していた
    • 任意アカウントに自分を ADMIN として追加することも可能で、2件の報告で合計 30,000ドル を獲得

  • eldar.corp.google.com

    • 内部のプライバシー評価管理用 Googler 専用サイト Eldar の API が外部に露出し、非 Googler でも内部ログへのアクセス要求など機微情報を閲覧可能
    • ブロック後も別のサンドボックスアドレスから到達可能であることを追加報告し、合計 26,674ドル を獲得

  • YouTube 非公開動画の流出

    • 動画アップロード時に生成される asset 名が Auto generated asset - <video_id> 形式のため、検索だけで 非公開動画 ID が漏えい し視聴可能
    • 30秒ごとにリクエストすれば、パートナーがアップロードした非公開動画のリアルタイムフィードを取得可能。企業が製品発表動画を事前に非公開アップロードする点を利用して、予測市場でのインサイダー賭け に悪用され得る現実的脅威
    • 12,000ドル を獲得（レポート品質も高評価）

  • Widevine DRM キー露出

    • Disney・Netflix などが使う世界最大級の DRM Widevine のパートナーポータル API が公開アクセス可能だった
    • 組織一覧全体のダンプ、特定組織の PGP・AES キーの取得と復号、任意組織に自分を追加してデバイス管理まで可能
    • 16,004.40ドル を獲得（レポート品質も高評価）

  • plx.corp.google.com

    • 社員専用の内部分析プラットフォーム PLX の基盤 DataHub API が露出し、在籍社員情報テーブルのメタデータを参照可能
    • ステージング API で setIamPolicy により データセット管理者を自己追加 でき、機密の YouTube データ（最大 2.1PB 規模のテーブルを含む）をダンプ可能
    • 1時間以内に P0/S0 と認定され、2つの脆弱性で各 12,000ドル を獲得

Translation Hub のクロステナント脆弱性

  • 大規模ドキュメント翻訳管理製品 Translation Hub で多数のアクセス制御問題を発見
  • ListOperations が OAuth トークンなしで動作し、内部サービスアカウント名・GCS バケット名・内部テーブル名が漏えい
  • 任意の Google アカウントの bearer トークンだけで、翻訳者メールアドレス・作業中の機密ファイル名 など他プロジェクトのデータを参照可能
  • UpdateProjectConfig で被害者設定を任意 GCS パスに変更すると、共有サービスアカウント権限を悪用して 非公開 GCS オブジェクトを base64 で流出 させられる
  • 3つのバグの合計で 36,500ドル を獲得

YouTube TV CMS

  • 任意動画を strike・claim・monetize できる YouTube CMS アカウント用 API で、campaign エンドポイントが呼び出し元との関係を一切検査していなかった
  • GET /v1/campaigns がスコープなしで システム内の全 campaign をグローバルダンプ し、変更・複製・削除も ID だけで可能
  • 副産物として機微な CMS アカウントのメールアドレスも漏えいし、24,000ドル を獲得（レポート品質も高評価）

Vertex AI Search for Commerce

  • 小売向け検索・推薦製品の conversationalSearchCustomizationConfig がアクセス制御なしで任意プロジェクト設定の読み書きを許可
  • 読み取りでは顧客の システムプロンプト（モデル preamble） や内部ポリシーメモ付きの分類例が露出
  • 書き込みでは顧客向け検索 AI のシステムプロンプトに プロンプトインジェクションのペイロード注入 が可能で、30,000ドル を獲得

Cloud Console GraphQL

  • インターネット非公開の内部サービスでも プロキシ経由の攻撃面 を通じて間接到達でき、Cloud Console（コードネーム Pantheon）は GraphQL で gRPC バックエンドをプロキシしていた

  • 署名検証の回避

    • 各リクエストはクエリ署名（querySignature）を検証するため改変しにくいが、ステージングの認証不要クエリは署名を検証しない ことを発見
    • introspection で 3,448 個のスキーマを収集して GitHub にアーカイブし、「query path」の概念を導入して既存の AI ファジング基盤へ GraphQL を統合

  • App Engine リクエストログ

    • GetDashboardAppStats が IAM 検証なしで（認証すら不要）任意プロジェクトの24時間分 App Engine ログを返した
    • リクエスト URL にパスワード再設定リンクやトークンが含まれ得るため、18,000ドル を獲得し CVE-2026-8934 が割り当てられた

  • Vertex Assistant

    • 5GB のフロントエンド JS を解析して隠された実験機能 Vertex Assistant を特定し、DevTools で feature flag を強制有効化
    • 関連クエリがすべて認証なしで userId だけで動作し、対象メールアドレスさえ分かれば セッション一覧・全会話履歴の参照と変更 が可能で、30,000ドル を獲得

  • Maps Platform 請求クレジット

    • ListBillingAccountCredits が権限チェックなしで動作し、ワイルドカードで多数顧客のクレジット情報を返した
    • Google 社員が承認時に記入した 顧客 PII が justification フィールドにそのまま露出 し、12,000ドル を獲得

まとめと教訓

  • 3か月間この構成で 50万ドル超 のバウンティを獲得し、公開されたものはその一部にすぎない
  • Google のバグの大半で重要なのは高度なエクスプロイトではなく 忍耐 であり、同じ壊れたパターンが至る所で繰り返される — IAM チェック漏れ、認証なし GraphQL、本番のデバッグエンドポイント、実データを指すサンドボックス
  • AI の役割は斬新さではなく、人間が最後まで扱うには広すぎる攻撃面に対して 明白なことを疲れず繰り返し検証する こと
  • 主な示唆
    • operation_id 再現システム がワークフローを生産的にした決定的要素 — ワンクリック確認がなければ AI 出力は役に立たないノイズ
    • discovery doc・GraphQL SDL・proto を確保すれば、AI は意味のあるテスト入力を把握できる
    • Google のサーバーサイドの攻撃面は非常に標準化されており、インフラ固有の差異を AI から抽象化すれば、実際の API テストにより集中できる

関連記事

1件のコメント

 
j2sus91 7 분 전

バイブコーディングの、まさに新概念の収益ですね