- Googleアカウントの検索フォームを迂回し、特定のユーザー名に紐づく電話番号が存在するか確認可能
- JavaScript無効化環境でも、BotGuardトークンを意図的に挿入することで、IP制限を回避する攻撃手法を実装可能
- オランダなど一部の国では電話番号フォーマットの特性上、100万未満の組み合わせしか存在せず、現実的にプロキシとIPv6ローテーションによる大規模総当たりが可能
- Googleアカウントの表示名をLooker Studioを使って、被害者の任意の操作なしに容易に露出させられる
- この脆弱性はGoogleに報告され修正済みであり、実際の攻撃チェーンでは自動化により非常に短時間で電話番号を特定可能
概要
この記事は、Googleアカウントの電話番号を総当たり（ブルートフォース）攻撃で突き止める方法、その過程、そして防御側の対応までを詳しく扱った実例である。一般に、アカウント検索／復旧フォームはJavaScript環境とボット対策の仕組みを用いて悪用を防いでいる。しかし、JSが無効な環境＋特定のパターンではこの仕組みを迂回できることを示している。
調査の背景と手法
- Googleのアカウントユーザー名を探すフォームがJavaScriptなしで動作することを発見
- このフォームは、特定の名前（表示名）と連動した電話番号の存在有無をHTTPリクエスト2回で確認する
- 1回目のリクエスト：電話番号ベースでess値（セッショントークン）を取得
- 2回目のリクエスト：essと名前（GivenName/FamilyName）パラメータでアカウント存在有無を判定
- アカウントが存在すれば
usernamerecovery/challengeへリダイレクト、存在しなければnoaccountsfoundへリダイレクトで応答
IP制限の回避（プロキシ、IPv6活用）
- 当初はIPごとのレート制限とCAPTCHAにより総当たりは不可能だった
- オランダの携帯番号では100万通りの組み合わせ（先頭桁が決まっている）であり、プロキシ使用時には現実的で、
- AWS/Vultrなどクラウドの**/64 IPv6ブロック**を活用して、リクエストごとに異なるアドレスへローテーション可能で、サーバー側もIPv6をサポートしている
BotGuardトークンの回避
- JSフォームではBotGuardトークンが必要
- No-JSフォームで
bgresponse=js_disabledパラメータの代わりに、JSフォームから収集したトークンを挿入すると無制限に送信可能 - マルチスレッドツールを作成し、大量の電話番号を投入して迅速に存在するアカウントを検出可能
誤検知の除外（フィルタリング）
- 同じ名前／番号末尾2桁の条件で複数人が引っかかる可能性がある
- ランダムな姓（last name）を入力して再テストすることで、誤検知かどうかを自動的にフィルタリングするロジックを追加
国別の電話番号フォーマットと名前情報の収集
- 復旧フォームは電話番号のマスキング形式のみを一部提供
- 各国の電話番号パターン（national format）はGoogleのlibphonenumbers情報を調査することで把握可能
- 被害者の表示名は、Looker Studioの所有権変更機能を悪用することで、ユーザー操作なしに確認可能
最適化と自動化
- libphonenumbersで各国のPrefix／長さ／有効性検証ルールの辞書を生成
- GoベースのchromedpでBotGuardトークン自動発行APIを作成し、実際の攻撃時に自動化可能
実際の攻撃手順
- Looker Studioの所有権移転で被害者の名前（表示名）を取得
- 「パスワードをお忘れですか」フローで対象メールの電話番号の一部マスキングを収集
- gpbツールを通じて、名前、マスキング、国コードを基に総当たり攻撃を実行
時間と効率
- 16 vCPU、3000スレッドのサーバー基準で、1秒あたり約4万件をチェック
- 国ごとの番号組み合わせ／ヒント長に応じて、米国（20分）、英国（4分）、オランダ（15秒）、シンガポール（5秒）で十分
- 他サービスで完全なヒントが提供される場合（例：PayPal）は、時間をさらに短縮可能
Googleおよび修正タイムライン
- 2025.4.14：Googleに報告、4.25にパネルで謝辞表示
- 2025.5中：5,000ドルのバグバウンティ支払い
- 2025.5：No-JSフォームを段階的に停止し、対策を適用
- 2025.6.9：公式に脆弱性を公開
結論
この事例は、アカウント復旧フロー、電話番号マスキング、表示名など複数情報の組み合わせだけで大規模な自動化攻撃が可能であることを示している。Googleは手順内の脆弱性を補強し、関連フォームを閉鎖することで対応を完了した。
問い合わせはSignal／メール（原文参照）で可能
1件のコメント
Hacker Newsのコメント
この記事で興味深いのは、ほとんどのホスティング事業者やISPが少なくとも1つの /64 IPv6ブロックを提供しているにもかかわらず、依然として大半のレート制限やIPブロックが単一IPに対して適用されている点だ。IPv6環境では、レート制限やブロックは /64 ブロック全体を基準に行うべきだと思う
こうした問題を管理する責任がある、あるいはそれで収益を上げている企業ですら、IPv6管理で的外れな対応をしているのをよく見かける。私の勤め先は有名なCDNサービスを使っているが、同じ /64 ブロック内からアクセスしていても「見慣れないIPからのログイン」といったばかげたセキュリティ通知を受けることがある
IPv6の登場以降、従来のIPブロック方式は大きく無力化されたと思う。一般家庭のインターネット利用者であっても、DHCPv6 Prefix Delegationで /56 や /48 ブロックを自動的に受け取れる。たとえば私はComcast経由で /56 を受け取っており、これは最大65536個の /64 ブロックに分割できる。IPv6で効果的なIPフィルタリングを行うには、従来の単一IPベースを単純に /64 に置き換えるだけでは不十分だ
/64 ブロックでレート制限をかけても十分でないかもしれない。/48 ブロックを受け取るのもあまりに簡単だ。最適な制御のためには、ASNごとに分類し、各事業者がどのようにIPを割り当てているかまで見て granularity を調整する必要がある
IPv6での /64 単位のレート制限は業界ではすでによく知られており、Googleも他のサービスには適用している。これはIPv6導入時に既存ポリシーをきちんと更新しなかった結果だと判断している
BuyVM のような格安ホスティング業者でも、最安プランに /48 単位のアドレスを提供している（月額2ドル、現在は月額7ドルの在庫しかない）。そのため、怪しい運用者に好まれる傾向がある
以前、Facebookで特定人物の電話番号を見つけるために似たような方法を試したことがある。パスワード再設定の過程でFacebookが電話番号の大部分を表示していたので、その数字を vcard ファイルにまとめて自分のスマホに取り込み、写真で照合した。この方法は予想外に有効だった
Googleのプロフィール写真やGoogleアプリにも似たような穴がある。たとえばGoogleマップのレビューに John Smith と表示されていたら、複数のメールアドレス候補（johnsmith@gmail.com、smithjohn@gmail.com など）をハングアウトに追加し、プロフィール写真を確認して同一人物を追跡できる
こういう理由で、自分の本当の電話番号は絶対に入力しない。サービス運営に必須でもないのだから
1人が長時間にわたって毎秒4万件のリクエストをサーバーに送り続けても、リソースが大きく跳ね上がったりアラートが鳴ったりしなかった点が印象的だ
実際にはアラームが鳴っていた可能性もあるが、行動がすぐ止まったり状況が素早く回復したりして、エンジニアがダッシュボードを見る頃にはすでに正常化していたのかもしれない。4万QPSはFocusやGoogle APIのトラフィック規模ではそれほど目立たず、さまざまなIPやIPv6 /64 ブロックに分散されていれば見逃されることもある。今回の本質はモニタリングではなく、JS無効化フロー（以前のJS有効化フローから借用したトークンを使用）にまったくレート制限がなかった点だと思う
ボットネットを使ったのではとも思うが、リクエストごとにIPを変えていたようにも見える
この種のバグバウンティは報奨金がばかげているほど低いことが多い。残念だ
報奨を削り続ければ、結局は自分の首を絞めることになる
こうしたセキュリティ問題に10万ドル未満しか支払わないのは本当にしょぼい
レガシーWebページを維持・管理することがとてつもない負担だとよく感じる。何十年も前のコードやページまで維持し続けなければならないサイトは多く、あらゆる組み合わせをテストするのも事実上不可能だ。Gmailの設定の奥深くを掘ると、今でも2004年風の古いポップアップが出てくるのを自分で確認できる
バグバウンティプログラムは非常に効率のよいコスト活用だと思う。数千ドル払うだけで、極端なエッジケースを見つけてくれる自発的な人員を動員できる。社内人員を使うより、はるかに大きなコストがかかったはずだ
これこそが、企業が昔のサービスや製品を積極的に廃止しようとする最大の理由だ。「そのまま置いておけばいいのでは」という問いへの答えは、結局すべてのレガシーサービスがセキュリティホールになり得るからだ。本当に安全なコードは、そもそも存在しないコードだけだ
Facebookの「トーク」機能のようなものを誰が担当しているのか、いつも気になる
大企業の内部でも似たようなレガシーインフラが動き続けている。たとえば私の友人はグローバル大企業の内部リンク短縮アプリを保守しているが、利用量がほぼ爆発していても、Nodeのバージョン更新のような非常に単純な理由で毎回1〜2件のチケットしか来ない。モニタリング自体が正常に動いていなくても、バグ報告が稀なくらいだ
最近、私もGoogleで昔の（〜2013年の）Catullロゴが出るページに遭遇したことがある
「2025-05-15 – パネルが $1,337 + スウェグを支給。根拠: 悪用可能性が低い（lol）」と書かれていたが、実際には悪用可能性は非常に高いと思う。露出する電話番号の当事者は多くないかもしれないが、必要とあれば私立探偵、犯罪者、調査員など誰でも実際にこの脆弱性を利用するはずだと確信している
パスワード再設定フローで電話番号の一部をヒントとして見せることが、実際にはセキュリティリスクだと今回あらためて気づいた。もし複数のサービスがそれぞれ異なる順序でマスクされた電話番号やメールアドレスのヒントを提供していれば、危険性はさらに高まる
慰めになるかは分からないが、2FAなどさまざまな理由で何百、何千ものサービスがすでに私の電話番号を収集しており、同意の有無にかかわらず相当数がすでに流出している。実名・メールアドレス・電話番号の組み合わせは、ほぼ確実に公開データとしてダンプされている
こうした情報を探してくれるTelegramボットも存在する。このようにブルートフォース脆弱性が明るみに出ると、自動化ツールを使っていた利用者でさえ不快感を覚えるようだ（EoGボットが代表例だ）
こうした個人情報を自動で集める有料サービスも、すでにかなり前から存在している。メールアドレス、電話番号などさまざまな情報が複数のソースから蓄積され、世界中で十分なインセンティブがあるため、サービスのセキュリティ上の穴を積極的に突いてくる。結局は大規模流出につながる構造だ
以前は、ある会社のカスタマーサポートにカード番号下4桁を尋ね、それを使って別の会社の本人確認を突破したソーシャルエンジニアリング事例もあった
私も大学時代、クレジットカードでも同じように情報を取得できるというセキュリティ研究者の発表を聞いた記憶がある
2025年、2023年、2021年にも「防ぐ方法がない」という記事と大規模データ流出が繰り返されている。2025年版、2023年版、2021年版と延々繰り返されている。どの版がいちばん笑えるのか悩む
今回の件はとても創造的で見事だと思う。Brutecatがまたやってくれた
Googleはもう本当に幽霊船のように感じる。5,000ドルのバグバウンティは侮辱レベルで、こんな少額から始めたこと自体が、Googleがユーザーデータ保護に本気ではない決定的な証拠のように思える