YouTubeユーザーのメールアドレス漏えい脆弱性で1万ドルの報奨金を受領

 (brutecat.com)
1 ポイント 投稿者 GN⁺ 2025-02-13 | 1件のコメント | WhatsAppで共有
  • YouTubeチャンネルの内部Googleアカウント識別子である obfuscated Gaia ID が露出し、これをPixel Recorder共有APIでメールアドレスに結び付けられるため、Googleアカウントのプライバシー問題となっていた
  • ライブチャットのブロックメニューのInnertubeリクエストは、実際にブロックしなくても対象チャンネルの Gaia ID を含む moderateLiveChatEndpoint パラメータを返していた
  • リクエストパラメータのチャンネルIDを差し替えると、ライブチャットメッセージのない Topic Channel にまで対象を広げられ、特定の参加者に限られた問題ではなかった
  • Pixel Recorderの WriteShareList は共有対象の obfuscated Gaia ID を受け取り、レスポンスに メールアドレス を含んでおり、さらに250万文字の録音タイトルで通知メール送信も防げた
  • Googleは2024年9月15日に報告を受けた後、2025年2月9日に2つの脆弱性の修正を確認し、合計 $10,633 の報奨金を支払った

YouTubeのブロック機能で露出したGaia ID

  • GoogleのInternal People APIステージングdiscoveryドキュメントから、BlockedTarget オブジェクトが obfuscated Gaia ID と fallbackName を使うことが確認された
    • profileId はブロック対象ユーザーの obfuscated Gaia ID
    • fallbackName はブロックされるユーザーの表示名
  • GoogleアカウントのヘルプにはYouTubeでアカウントをブロックできる案内があり、実際にYouTubeライブ配信でユーザーをブロックすると、そのユーザーは myaccount.google.com/blocklist に表示された
  • ブロックリストにはチャンネル名 Mega Prime が fallbackName として、107183641464576740691 が profile ID として表示された
  • YouTubeチャンネルが基盤となるGoogleアカウントを露出させるべきではないという前提のもと、過去にもGaia IDをメールアドレスへ変換するバグがあったため、追加の経路を探し始めた

ライブチャットメニューから全チャンネルへ拡大

  • YouTubeライブチャットで三点メニューを開くだけで、/youtubei/v1/live_chat/get_item_context_menu リクエストが発生した
  • レスポンスには /youtubei/v1/live_chat/moderate へつながる moderateLiveChatEndpoint と params 値が含まれていた
  • この params はGoogleでよく使われる base64エンコードされたprotobuf で、デコードするとブロック対象ユーザーのGaia IDが入っていた
    • 例のレスポンスには 113907466537670370590 とチャンネル関連の識別子が含まれていた
    • 実際にブロックを実行しなくても対象のGaia IDを取得できた
  • get_item_context_menu リクエストパラメータをデコードすると、ブロックしようとしているチャンネルの channel ID、ライブ配信動画ID、ライブ配信投稿者IDが含まれていた
  • リクエストパラメータ内のチャンネルIDを別の値に差し替えて試した結果、YouTubeが自動生成した Topic Channel のGaia ID 103261974221829892167 も取得できた
    • Topic Channelは YouTubeが自動生成 するもので、ライブチャットメッセージがないことを前提にテストされた

Pixel Recorderがメール変換経路になった

  • 古いGoogle製品でGaia IDをメールアドレスに変換できるバグやロジック欠陥を探す中で、nathanとともに Pixel Recorder を調査した
  • Pixelスマートフォンでテスト録音を作成してGoogleアカウントに同期し、その後Webの recorder.google.com エンドポイントを使用した
  • 録音をテスト用メールアドレスに共有する際、WriteShareList リクエストは共有対象リストに obfuscated Gaia ID を含んでいた
  • pixelrecorder-pa.clients6.google.com の PlaybackService/WriteShareList レスポンスは、その共有対象のメールアドレスを返した
    • テストレスポンスには vrptest2@gmail.com が含まれていた
    • YouTubeブロック実験で得た 107183641464576740691 Gaia ID を入れた場合でも redacted@gmail.com が返された
  • これにより、YouTubeで得たGaia IDをPixel Recorder共有APIに入れてメールアドレスを突き止める攻撃チェーンが可能になった

通知メールを防いだ250万文字の録音タイトル

  • Pixel Recorderで録音を被害者と共有すると被害者に通知メールが送信されるため、攻撃の影響度が下がる可能性があった
  • 共有ポップアップには通知を無効化するオプションがなく、req2proto でリクエストprotobufを解析しても通知無効化フィールドは見つからなかった
  • WriteShareListRequest 構造には次のフィールドがあった
    • recording_id
    • delete_obfuscated_gaia_ids
    • update_shared_users
    • sharing_message
  • ユーザーを同時に追加・削除してもメールは送信され続けた
  • 通知メールの件名に録音タイトルが含まれる点を利用し、録音タイトルを極端に長くすればメール送信が失敗する可能性があると判断した
  • UpdateRecordingTitle エンドポイントで録音タイトルを 250万文字 に変更するPythonスクリプトを作成してテストしたところ、サーバー側にはタイトル長の制限がなかった
  • タイトルを250万文字に設定した後で別のテストユーザーに共有したところ、通知メールは送信されなかった

最終PoCと対応スケジュール

  • 完成した攻撃チェーンは3段階で構成されていた
    • YouTube Innertube /get_item_context_menu エンドポイントで対象チャンネルの obfuscated Gaia ID を取得する
    • 非常に長いタイトルを持つPixel Recorder録音を対象と共有し、Gaia IDをメールアドレスへ変換する
    • Pixel Recorder録音の共有対象からそのユーザーを削除して後始末する
  • PoC動画は YouTube動画 で提供されている

Googleの報奨金と修正タイムライン

  • 2024-09-15: ベンダーへ報告を送信
  • 2024-09-16: ベンダーがレポートをtriageし、Nice catch! という返答を受けた
  • 2024-10-03: パネルが既存追跡バグの重複として扱い、初期のYouTube obfuscated Gaia ID露出に対する不完全なパッチを実施
  • 2024-10-03: Pixel Recorder自体も脆弱性であることをベンダーに再説明
    • obfuscated Gaia ID はGoogle MapsやGoogle Playレビュー投稿者でも露出し得た
    • YouTubeチャンネルの obfuscated Gaia ID を再び漏えいさせる回避手法も提供された
  • 2024-11-05: パネルが $3,133 の報奨金を支給
    • 根拠は悪用可能性が中程度
    • 高影響のabuse-related methodologyに分類
  • 2024-12-03: 製品チームが追加報奨の検討のためレポートをパネルへ差し戻し、2025-02-03の公開日程を調整
  • 2024-12-12: パネルが $7,500 の追加報奨金を支給
    • 根拠は悪用可能性が高い
    • 高影響のabuse-related methodologyに分類
    • 攻撃チェーンの複雑さのため、基本金額から1段階引き下げて適用
  • 2025-01-29: ベンダーが公開日程を2025-02-02まで延長するよう要請
  • 2025-02-09: 攻撃チェーンの2つの部分がどちらも修正済みであることを確認
    • 最初の報告から 147日 が経過した時点
  • 2025-02-12: レポート公開

関連記事

1件のコメント

 
GN⁺ 2025-02-13
Hacker Newsのコメント

  • タイトルが紛らわしかった。記事を最後まで読んでいない人のために言うと、漏えいしたメールによって費用がかかったのではなく、時間と機転を費やしてバグ報奨金1万ドルを受け取ったという話

    • 最初は、ユーザーのメールを漏えいさせるサービスをユーザー1人あたり1万ドルで提供するという意味かと思った
    • 自分も1万ドルのサービスとして提供しているという意味だと思った
    • クリック狙いのタイトルかもしれない
    • 最初は、何らかのハッシュを総当たりするための計算コストの話かと思った

  • 責任ある開示、動機、報酬についての雑音は多いが、これが中央集権的な永続的アイデンティティに反対するもう一つの根拠だという話はあまり見ない
    あるサービスがReal Identity™ひとつにだけ結び付けられていると最もうまく機能すると主張するたびに、企業はユーザーを実際に保護することには抽象的にしか関心がなく、それすらたまにしかないのだと思わされる
    YouTubeでやり取りする誰もが、即座に個人特定へ3、4段階近づけると想像してみると、このバグの実際の影響はその程度だと思う。修正されてよかったが、この種のバグが近いうちになくなるとは思えない。こうした設計が爆発寸前の地雷原だと企業や大企業に気づかせるには、何が必要なのだろう

    • 抽象論としては同意する。こうしたアカウントには、ある程度の匿名性と使い捨て可能性が認められるべきだ。どうせどこかのデータベースの1行にすぎないのだから
      ただし、多くの人は実際のお金でこうした企業と取引している。たとえばYouTube Premiumの購読者やコンテンツ制作者などがそうだ。実務上は、その使い捨て可能なアカウントのどこかに、現実の身元識別子を保存せざるを得ない。詐欺リスクと銀行業務の現実のために、実際の身元と住所を企業に渡すことになり、企業もそれを保存する
      ランダムなアプリやWebサイトには個人を識別できる情報を渡さないが、自分が取引する相手は必然的に現実の自分を知っており、理論上はそのデータが漏れ得る地点になる
    • 法的な結果がないから気にしないのだ
      医療サービス提供者が医療データを漏えいさせたら、完全に叩きのめされるだろう

  • 「動作するエクスプロイトのPOCです: この動画はYouTubeの利用規約違反により削除されました」だなんて笑える

    • 元記事の作者は、概念実証のために実在するユーザーのメールアドレスを公開していた。再アップロードされた動画ではメールアドレスにぼかしが入っている
    • 最初は自分にもそう見えたが、記事を開き直したら動画が見えるようだ。たった今復旧したのかは分からない

  • このスレッドの3つ目ごとのコメントが「Googleはこのバグに対して支払いが少なすぎる」という話なので、脆弱性の価値評価について基本的な話をすると、次のようになる。
    サーバー側の脆弱性は、業者同士が競合しないため価値が低い。サーバー側の脆弱性には、実質的にグレーマーケットがない。Googleが即座に潰せて、発見された瞬間に半減期がほとんどなく、悪用すれば対象側で信頼できるテレメトリが発生するようなバグに、第三者が値段を付けるのは難しい。
    逆に、Android/Chromeのフルチェーンのようなバグが数十万ドルで売れるのは、Googleが成熟したグレーマーケットと競合しているからだ。ある業者がそのバグを入手して、欧州の一国にある複数の機関、場合によっては6か所に売ることができる。
    とはいえ、バウンティとグレーマーケットはリンゴとオレンジの比較だ。Googleが必要としているのは信頼性の高いエクスプロイトではなく「書ける」という証拠だけで、保守費用も不要なので、グレーマーケットよりはるかに少なく支払う。市場全体の総額は複数の段階に分かれ、リスク条件も付くが、Googleは割り引かれていても魅力的な一時金を提示できる。
    攻撃者は既存の事業プロセスに合う脆弱性を買う。一般に、ある新しい脆弱性でできる格好いいことや稼ぎ方を投機的に想像するわけではない。決済情報の収集、ボットネット用に数千台を確保することは既存の事業プロセスだ。Googleアカウントの実名露出はビジネスになり得るか？ 可能かもしれない。既に存在するか？ おそらくない。
    バウンティの支払額は、たいていそのバグがどれほど賢いか、興味深いかについての国民投票ではない。ただしここでは少しそういう面もあり、サーバー側のWebバグに1万ドルというのは異例に高く感じる。
    こうしたバグを見つけて生計を立てる人にとっての事業戦略は、数多く見つけることに熟達することだ。1つの信頼性の高いエクスプロイトに何か月も費やすiOSエクスプロイト開発とは違う。
    最近のキャリアでやっていた脆弱性研究が、他の多くの作業よりこちらに近かったので、かなり自信はある。それでもHNにはこうしたバウンティ作業をフルタイムでやっている人がいるので、そういう人が訂正してくれるならうれしい。

    • ほとんどの他分野では、作った物の闇市場価値を基準に報酬を受け取るわけではない。
      この分析を他のものに当てはめると、新しいカーオーディオや自転車の上限価格は約100ドルになり、著作権のあるあらゆる財の価格はネットワークで転送するコストに制限されることになる。
      Googleが支払った金額を、この作業に費やした時間と、前回のバウンティ以降に失敗したすべてのエクスプロイト試行時間で割るほうが有用だと思う。
      この分野の大多数は、努力に対して米国の最低賃金未満しか稼げず、年間6桁ドルの機会費用を払っているように思う。
      その数字は、Googleがエンドユーザーのセキュリティとプライバシーをどれほど価値あるものと見ているかを正確に示している。同じ人々の個人情報を盗ませるために他のエンジニアへ何桁も多く支払うより、はるかに低い数字だ。
    • このHNスレッドの大半がバウンティ額の話なのは嫌だが、自然なことでもある。ここにコメントしている多くの人はソフトウェア業界で働いており、非常に高額なバウンティを普通のものにしたいと思っている。
      彼らにとっては追加の収入源だからだ。ソフトウェアエンジニアが高報酬の職業であってほしいと望むのと同じように、バグバウンティも高くなってほしいと思っている。労働者が自分の職業の賃金をもっと要求するのは自然で、どんな正当化もその本能を変えることはない。
    • 「攻撃者は既存の事業プロセスに合う脆弱性を買う」というが、こういうものにも市場はあるのでは？ たとえば「うちの怪しい会社／政府を批判しているこのアカウントの背後にいる人物が誰なのかを突き止め、無力化しよう」といった形だ。
      攻撃者市場での価値とは別の誘因もある。オンライン有名人をストーキングする暴力的な人物は、こうしたゼロデイエクスプロイト市場では収益性の高い顧客ではないかもしれないが、企業が不注意に対象者の身元を暴力的なストーカーにさらし得るなら、その脆弱性は依然として責任と倫理上のリスクだ。
      個人的には、セキュリティへの注意が不完全なまま膨大な量のコードを量産するLeetCodeパフォーマンスアーティストたちに巨額の金を払っているなら、悪いことが起こる前に彼らの数多くのミスを見つけて直すのを助ける人たちにも、きちんと払うべきだと思う。
    • 法執行機関がサーバー側のバグを悪用することは、はるかにグレーゾーンが大きいか、実際に違法である可能性がある。一方で、特定対象のデバイス、つまり携帯電話やノートPCを悪用できるようにする裁判所命令を得る標準手続きは、法執行機関や情報機関に既に存在している。

  • 「必要な攻撃チェーンの複雑さのため、基本額から1段階引き下げ適用」とあるが、これはよくあることなのか？
    脆弱性プログラムにはいくつか参加しただけだが、多くはページソースにユーザーのメールアドレスが露出しているような、呆れるほど単純だが深刻な欠陥だと、むしろ報酬が少なかった。

    • 逆に、Web脆弱性としては相対的に複雑だったので減点されたのだと理解した。
    • これは逆のように思う。実質的にバグを2つ見つけたようなものなので、基本額から引き上げるべきだ。

  • 「少し前にGoogleで研究対象を探していて、Internal People API (Staging) discoveryドキュメントを掘っていた」とあるが、これは単に公開されていてよいものなのか: https://staging-people-pa.sandbox.googleapis.com/$discovery/...

    • 内部の.proto定義から自動変換されたスキーマファイルにすぎない。Googleは曖昧さによるセキュリティではなく、実際の暗号技術に依存している。
      さらに、discoveryエンドポイントは公開ドキュメント化されており[0]、外部ユーザー向けに作られたものだ。内部の人間はdiscoveryエンドポイントを読まず、コード検索で.protoファイルを直接見るはずだ。
      Googleで働いた経験からすると、APIを公開にさらすには官僚的手続きと何週間も戦わなければならなかった。偶然公開されたAWS S3バケットのようなものではない。チームはこれが公開であることを知っており、公開するために官僚制を突破したはずだ。
      [0]: https://developers.google.com/discovery/v1/getting_started

  • 投稿のタイムラインを見ると、2024-09-15に企業へ報告し、2025-01-29に企業が2025-02-12までの公開延期を求め、2025-02-09にエクスプロイトの両側がどちらも修正されたことを確認し、2025-02-12に公開したとのこと。
    つまり136日間修正されず、Googleが延長を求めたということではないか。修正まで147日、公開まで150日である。
    Google Project Zeroが他社に与える修正前の公開期限と比べると、「このバグには90日の公開期限が適用されます。90日の期限前にユーザーへ修正が提供された場合、このバグレポートは修正提供の30日後に公開されます。そうでなければ期限日に公開されます」としている。
    「パッチが期限満了後14日以内に出ると予想される場合、Project Zeroは延長を提供できます……ただし14日の猶予期間は30日のパッチ適用期間と重なるため、猶予期間内に修正された脆弱性も、元の90日期限から遅くとも120日目には公開されます」
    「14日以内に修正が用意できないと判断した場合、元の90日期限を公開時点として使います。つまり開発者が14日の猶予期間内に修正を配布すると約束した場合にのみ、14日の猶予延長を付与します」
    https://googleprojectzero.blogspot.com/p/vulnerability-discl...

    • この比較が有用だとは思わない。これはGoogleソフトウェアにおけるGoogleのバグであり、Project Zeroが見つけるのは通常、多くの人が使うソフトウェアのバグなので、修正の緊急性がより高いのだと理解している。

  • 「そのparamsはbase64でエンコードされたprotobufにすぎず、Google全体でよく使われるエンコード形式だ」とは。立派なバイナリメッセージ形式をbase64エンコードしてJSONの塊に押し込む担当Google開発者に一杯おごるべきだ。
    未来の姿を見たいなら、靴底に「worse is better」と刻まれたブーツがエンジニアの顔を永遠に踏みつける様子を想像すればいい。

    • これはどこにでもあり、最悪だ。ときどき、インターネット回線上を行き交う実際のprotobufバイトよりも、JSON内でbase64として表現されたprotobufバイトの量のほうが多いのではないかと考えてしまい、自分に一杯おごる。
    • 内部的にはprotobufフィールド内のbase64 protobufだろう。
      JSON部分は自動変換だ。
    • base64でエンコードされたprotocol bufferのJSON文字列とは、どの会社がやったのか知らなくても、どの会社がやったのか分かる。

  • メールシステムを壊してメールが送られないようにしたのが画竜点睛だ。Googleのように数多くの製品を作る巨大企業では、セキュリティがまがい物のように感じられる。
    コードの一行一行が潜在的な脆弱性だとすれば、数百万行ではもはや必然だ。シンプルに保つこと、たとえばrecorderサイトを廃止すること以外に方法はなさそうだが、それでも簡単ではない。

    • Googleが成功したものの、Googleのシステム全体の中で存続させ安全に保ち続けるほどには成功していない製品を多く終了させる、もう一つの理由かもしれない。
    • 残念ながらGoogleのユーザー数を考えると、どんな廃止でも苦痛の叫びと「スペースバーでコンピューターを暖めることに依存している」といった反発を招くだろう。https://killedbygoogle.com/を見ればよい。
    • セキュリティが「本物」のように感じられる例と、それがどう役立つのかを挙げてほしい。
      ほとんどのソフトウェア製品は非常に複雑なソフトウェアスタックに依存しており、使っているすべてのライブラリとOSを100%信頼するなら、それは間違った姿勢だと思う。プロセッサにもMeltdownのようなバグがあった。セキュリティは終わりのない戦いであり、勝ったかどうかは決して分からず、負けた場合だけたまに分かる。
    • 本質的には、コード行数に基づいてセキュリティ脆弱性の数を計算するドレイク方程式[1]のようなものを提案しているわけだ。この方程式にはほかにどんな要素が入るだろうか。
      [1] https://en.wikipedia.org/wiki/Drake_equation
    • 要するに、セキュリティはまがい物だということだ。どんなアプリも真に安全ではない。アプリのセキュリティに数百万ドルを費やしても、人間のユーザー1人のたった一つのミスで突破され得る。

  • 私もタイトルをGPU計算コスト1万ドルのような意味に誤解した。古いGoogle製品を一つ選んですぐに穴を見つけたのを見ると、こういうバグはさらに数十個、あるいは数百個ありそうだ。

    • 「古いGoogle製品を一つ選んですぐに穴を見つけた」というふうには動かない。おそらく筆者は価値のあるものを見つけるまで、複数の製品を数週間または数か月掘り下げた可能性が高い。
    • 私もYouTuberのメールアドレスを1万ドルで売るという意味に誤解した。