Googleユーザーの電話番号をブルートフォース可能に！
引用元：https://news.ycombinator.com/item?id=44224684
この記事を読んで面白いと思ったんだけど、Hosting ProviderとかISPから/64のIPv6ブロックを少なくとも一つもらうのって結構普通じゃん？
なのに、ほとんどのレート制限やIPブロックは単一IP向けなんだよね。
IPv6を扱うなら、/64ブロック全体をレート制限したりブロックしたりすべきみたいだね。
IPv6はIPブロックの考え方にだいぶダメージ与えたんじゃないかと思うと、かなり驚くわ。
résident Userでも、DHCPv6 Prefix Delegationで自動的に/56とか/48をリクエストできるんだよ。
俺はComcastで/56を持ってる。これは Résident Userだけでも、最大65536個の/64ブロックになりうるんだから、IPv6でIP Filteringを試みるなら、単一IPブロックを/64ブロックに置き換えるより、ずっと賢くなくちゃダメだね。
もしユーザーがアドレスを一つしか持ってない場合、どうやって二つを区別するんだ？
大きなブロックを（Providerが）ブロック単位で配るか単一アドレスで配るかに基づいて、共有する必要があるみたいだけど…。
何だって？IPv6は最初の64ビットがネットワーク、最後の64ビットがHostになるように設計されたんだ。
/64はIPv6で最小のネットワークだから、ほとんどのProviderはIPv6 Public Addressを要求されたら/64を配る。なぜならA) ほとんどのRate Limitingが/64を使うから、そしてB) IPv6はIPが多すぎて、誰も気にしないからだ。
Vultrは少なくとも一つ/32を見つけたよ（2001:19F0::/32）。これを/64に分割すると、約42億の異なるネットワーク、つまり存在するIPv4 Addressと同じ数になる。
ARINは要求する誰にでも/48のIPv6 Subnetをくれるし、もっと大きなPrefixを取得するのも難しくないよ。
＞ /64がIPv6の最小ネットワーク
/64はIPv6の最小ネットワークじゃないよ。/112とか/126とか、好きなサイズを持つことは何の問題もない。
ただし、SLAACが機能する唯一のネットワークサイズだから、LANサイズとしては良い選択肢だけどね。
実用的な話をしてるんだ。もっとネットワークを減らせるって知ってるけど、壊れるものもたくさんあるんだよ。
IP Blockingから始めて、問題行動が続いたらブロックにUpgradeするのは既によくあることだよ。
/64をスタート地点と仮定するのは簡単な勝利だし、リピーターに対してそれをBump upするのも全体的な計画から見てかなり簡単そうに見えるね。
でもCGNATって、こういう手法をObsoleteにしない？俺のweb scrapingは全部スマホ経由でProxyしてるけど、Cloudflareで保護されてるサイトでもかなりAggressiveにやってもIPブロックされることはめったにないよ。
それいいね、ShadyなOperatorによく使われる人気のHost、BuyVMは、一番安いプラン（月2ドル、今は7ドルだけ在庫ありだけど）でも/48をくれるんだって。
インドの大きいISPで、家にも直接ルーティングできるIPv6が割り当てられてるんだって。Tailscaleで気づいたんだけど、どうやってだろう。90年代のネット荒らし時代が来た感じかな。
BuyVMってもっと背景知ってる？ちゃんとやってる業者で、BGPとか変わった機能もあるんだ。DMCA無視って言われるけど、怪しいブレットプルーフとは違うよ。規模は全然違うけど、Cloudflareがある特定分野で使われるのに似てるかもね。
Comcastから／56ってどうやって貰ったの？俺は／60までしか無理なんだ。それより大きいと／60になっちゃうんだけど。
BuyVMは”DMCA ignored”でかなり有名だよ。「dmca ignored buyvm lowendtalk」で検索するとフォーラムで海賊版サイトに良いってスレッドが見つかるはず。RIAAからも著作権法無視って言われたし https://www.musicbusinessworldwide.com/files/2025/01/USTR-20… CSAMサイトをホストしてたって話も少なくとも1つあるよ。
例えばGCPはVMごとに／96を配ってるから、これって理論だけじゃなく実際に使われてるんだ。
良い質問だね。今見たら／60しか貰ってないや。前は／56だったんだけど変わったみたい。ネットワークが少なくてnetworkdが自動で／64を割り当ててくれたから変更に気づかなかったんだ。
ダメなネットワーク機器はちゃんと扱えないかもね。SLAACとか、ホストに／64を前提とするIPv6ツールやブラックリスト設定は多いはず。このRFC https://datatracker.ietf.org/doc/html/rfc7421#section-4.2 には／64じゃないとダメな事が載ってるよ。
IPレート制限なんて、もう15〜20年前から悪用防ぐのにマジで役に立つツールじゃないって。
”Dmca ignored”って、”shady operators”とは全然違うからね。
大手企業でさえ、こういうこと分かってるはずなのに、笑っちゃうくらい間違えてるんだよね。
俺の会社も有名なCDNのクライアントなんだけど、同じIPv6の/64から繋いでも『いつもと違うIPからの新しい接続だよ』って通知してくるのが普通だって思ってるみたい。
ここでの問題は、大学とかの大きなネットワークでも/64を何百人もの学生が同時に使うこと。
講義でGitHubからツールをDLしてって言ったら、最初の10人はできるけど、残りはrate limitされちゃうんだ。
NATでも同じ状況はあるけど、IPv6ならもっとマシになるはずなのにね。
ほとんどの人が/64でブロックすると思ってたんだ。
でも、/64内で怪しいIPv6を数えて、閾値を超えたらブロック/スロットルするのが一番安全かもね。
/64内のIPv6ごとの怪しいトラフィックの割合を閾値にするのも良さそう。
うん、それ、よくやられてることだね。
それだけじゃ十分じゃないよ。
/48ブロックなんて簡単に入手できるからね。
ちゃんとやるには、ASNごとに分けてIPアドレスの割り当てポリシーを見て、どの粒度で対策すべきか考える必要があるんだ。
実質的に、/64は新しい/32みたいなもんだよ。
ISPは本当は/56か/48をくれるべきなんだ。
IPv6で/64にrate limitかけるのはよく知られてることだよ。
Googleも他のサービスではやってるの知ってるし。
これはIPv6導入したときにちゃんと更新されてなかったみたいだね。
connection trackingを使ったインバウンド接続のブロックは、NATとは別の話だよ。
NATはその性質上、デフォルトで前者（ブロッキング）を意味するだけなんだ。
直接接続ってのは良いことだし、本来のインターネットのあり方なんだ。
NATがあるから、IPv4はこんなに長く続いた唯一の理由だよ。
そうそう、IPv6でNATは一般的じゃないんだよ。それが大きな特徴の一つなんだよね。
古いページのメンテってマジ大変だろうね。昔からのサイトが抱える、何年も前のものの量はヤバいし、全部の組み合わせテストなんて無理だよ。
どれだけ古いアプリがあるか知りたいなら、Gmailの設定画面を探ってみな。2004年の頃のGmailの見た目のポップアップが出てくるから。
「レガシーページのメンテ大変」って？
2024年に3500億ドルの収益があっても、それじゃ足りないってことか…。皮肉たっぷりだね。
もっとコメントを表示（1）
古いページのメンテは大変だよね。僕がいた会社では、インターンや新人に古い情報やブランドに合わないものを探させるタスクをやってたよ。これは新しい人が会社の全体像や製品の歴史を学ぶのに役立ったんだ。
だから企業は古いサービスをどんどん廃止するんだよ。「なんでそのまま置いといてくれないの？」って思うかもしれないけど、そういうのって結局セキュリティホールになるから。一番安全なコードは、コードがない状態なんだよね。
これが今の”学習”のダメなとこだね。ページ読んで、本来あるべき姿と比べて、古けりゃ直して次に進む。分かってる、これって”仕事”みたいに聞こえるかもだけど、それが仕事なんだよ。君が僕が実際にやったタスクをすぐ否定するのが、皮肉言いたくなるほどイラつくね。
新人ってどうやって”本来あるべき姿”を知るの？
君の主張は一見もっともらしいけど、深く考えると違うと思うな。Google Readerにどんなセキュリティ問題があった？
認証の古いAPIが危険なのは分かるけど、もしアーキテクチャのせいでクライアントが悪用されるなら、製品を残してるのが問題じゃなくて、君が元々ヤバい設計をしたのが問題だと思うよ。
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.
Googleはお金があっても、こういう地味なプロジェクトは儲けが少ないとやらないんだよ。投資対効果低いとやらないってことね。
Something that can be hard to appreciate if you haven’t managed this sort of project is that it can be surprisingly hard to throw money at the problem.If you try to hire at your regular ”bar” for skill for boring work like this - people will often quit. This is one of the reasons many company’s integrations are lacking despite it being a strategic interest - integration work is miserable and doesn’t help your career.Hiring below the skillbar at the same pay, is dangerous and often doesn’t actually work out - if it was that easy someone more skilled probably would have fixed this a while ago.So you try to pay more for the miserable work - but hold on, now you have to pay out of band salaries, and legal tells you that opens you to massive liabilities.Ok - maybe you can just level them differently? No, HR will tell you that will mess with all your internal level processes - which are key to running the company. They’re going to add a lot of additional overhead tracking these ”fake” leveling bands and dealing with the consequences.None of this means the problem is literally unsolvable, but it now requires a huge amount of time and effort from people near the top of the company who everyone would much rather spend their time on making the company better.All of this to say - sure you could solve this problem, but it’s actually much more complex than adding some line items to a budget.Source: have watched many big companies try and fail for years to staff unsexy work like this.
こういう地味な修正作業に人当てるの、めちゃくちゃ難しいんだよね。優秀な人は辞めちゃうし、そうじゃない人はうまくいかない。給料上げたりレベル変えたりしようとすると、人事とか法務が面倒だし。結局、上の人が時間割かないと無理。予算増やすよりずっと複雑だよ。大企業がこういう作業で失敗するのよく見てきたからわかるわ。
Bug bounty program appears to be an efficient spend. For a few thousand dollars they mobilize unpaid people looking for extreme edge cases and then surface these issues. It would’ve cost way more to pay an employee to search for this.
Bug bounty programは効率的だよね。安い費用でたくさんの人がエッジケース探してくれるんだから。社員にやらせるよりずっと安上がり。
Google’s main search page is the slowest page ＆ UI I have found on the internet today (not accounting for bandwidth limits). Even on modern devices it lags at text entry and even rearranges characters in the text box so you have to wait 10＋ seconds for it to finish loading or it will go haywire. The shopping and other pages are actually worse. So it appears you’re right, ＄350B isn’t enough money to maintain a web page in 2025.
Googleのメイン検索ページ、ネットで一番遅いUIかも。入力も遅れるし、文字化けすることもある。ショッピングとか他のページはもっとひどい。ホント、350Bドルあっても2025年にウェブページすら維持できないってこと？って感じ。
In addition to having the money, Google also needs the incentive to spend that money on such projects. If the perceived return on capital is low (or negative!), the incentive is simply not there.Perhaps Google should Google the concepts of “customer service,” “standing behind your product,” and “brand reputation.”
Googleはお金があっても、こういう地味なプロジェクトは儲けが少ないとやらないんだよ。投資対効果低いとやらないってことね。Googleは「customer service」とか「brand reputation」って概念をGoogleで検索してみたら？って思うわ。
What is the point of assigning something to a new hire, if they can’t do it without another person watching the whole thing over their shoulder AND they are unlikely to benefit from this knowledge in the future (since it’s a legacy page that is supposed to be deleted)？
レガシーページみたいな仕事、新人にやらせる意味ある？誰かが見てないとできないし、どうせすぐ消すページなら将来の役に立たないじゃん。
I was recently editing the Wikipedia page for Google Bookmarks (2005-2021). I wanted to add a logo to the page, but I was having a lot of trouble finding a high-quality copy of the logo anywhere. Eventually I figured out that Google’s old URL scheme for product logos was very guessable, and they had never taken it down: https://www.google.com/intl/en-US/images/logos/bookmarks_log…
They’ll probably never stop serving those old URLs because who KNOWS where they might still be in use. One of surely a million examples of weird little legacy things Google is stuck with.
Google BookmarksのWikipediaページ編集してた時に、ロゴ探すのが大変で。結局、Googleの昔のURLスキームがまだ生きてて見つかったんだ。https://www.google.com/intl/en-US/images/logos/bookmarks_log…
こういう古いURL、どこで使われてるか分からないから消せないんだろうね。Googleが抱える遺産問題の一例だわ。
Google Reader used Google accounts for authentication, so an exploit in Reader could potentially be compromising to your entire Google account. This very article gives an example of that; Looker Studio was used to reveal the name on any account, even though most accounts have likely never used Looker Studio.Google could mitigate this by not having universally shared accounts across all services, but they’re not going to do that because most users would find that inconvenient.
Google Readerも共通アカウントだったから、そこで脆弱性が見つかるとGoogleアカウント全体が危ないかも。この記事のLooker Studioの例みたいにね。Googleはサービスごとにアカウント分ければリスク減らせるけど、ユーザーが不便がるから絶対やらないだろうね。
何かのセキュリティ影響を簡単に答えられたら、ハックや情報漏洩なんて起きないよな。単純に分かんないんだよ。それに、調べるのには金がめちゃくちゃかかるしね。
”It must be a daunting chore to maintain all the legacy pages”
レガシーなページを全部メンテするのって、大変な作業だろうな。Facebookの”poke”機能、あれ誰がメンテしてんだろうっていつも思うんだ。
いいじゃん！Cool URLs never die。Googleなら古いロゴの参照をコードベースでもっと効率的に検索できると思ってたけどさ。
なんか推測してみようと思って、moon.google.comを見てみたんだ。まだ動いてる古いGoogleのアプリ/ジョークの一つだよ。誰かがmoon.google.comをもっと新しい見た目にして、月もたくさんにしてくれたみたい。Googleは製品をすぐ捨てるって言う人もいるけどさ。
ウェブサイト作る時って、使う情報やテキストは開発者に渡されるじゃん。開発チームがちゃんとやったか確認するために、同じデータをQAチームにも渡すんだよ。どうしてこんなに鈍いんだ？わざとなのか？
元記事の投稿者は、ウェブサイトの整理作業は会社とか製品、歴史を学ぶ方法になるって言ってたね。まあ、分かりやすいことならいいけど、新しいインターンがいつ質問したらいいかって、どうやって分かるんだろ？
すごいな。ただセキュアなコードを書けばいいんだ。なんで今まで誰もそんなこと思いつかなかったんだろ？
Googleに”カスタマーサービス”、”standing behind your product”、”ブランド評判”の概念を検索させろって？
Googleは顧客（広告主）からの評判には満足してるんだろうね。G Suiteを買う法人も顧客だけど、Googleのユーザーの大半は顧客じゃない。Googleは、俺が車のガソリンの気分を気にするのと同じくらいしか、ユーザーのこと気にしてないよ。
こんな簡単なことで失敗する人が多いの、マジで驚くよ。もし従業員として、タスクに必要な情報が足りなかったら、ちゃんと声を上げなきゃ。聞かなかったからって、変なトラブルになることなんてないんだから。
僕はよく新人に仕事を任せるんだ。長年チームにいると見慣れてておかしいと思わなくなったことでも、新しい視点で質問してくれるのを期待してるからね。
新人が間違ってたら、なんでそうなのか説明すれば彼らの学びになるし、もし新人が正しければ、今のやり方がおかしいって分かってこっちの学びになる。どっちにしても得るものがあるんだ。
ずいぶん昔、Facebookを使って誰かの電話番号を見つけようとした時に似たようなことをやったな。
パスワードをリカバリーする時に、Facebookが電話番号の大部分を表示してくれたから、それをvcardファイルに書き出して自分のスマホに取り込んで、写真を見て確認したんだ。驚くほど上手くいったよ。
Googleのプロフィール写真や他のGoogleアプリでも似たような穴があるんだ。
例えばGoogleマップで「John Smith」ってレビューを見たら、Google Hangoutsでjohnsmith@gmail.comとかsmithjohn@gmail.comとか、色々メールアドレスを推測して追加してみるんだ。
そうするとプロフィール写真が見れるから、比較して本人か確認できるってわけ。
だから僕は、こういうサービスには本当の電話番号を使わないことにしてるんだ。
サービスを使うのに僕の電話番号なんて要らないしね。
Googleは何年も前から有効な電話番号を求めてるよ。他のほとんどの大手プロバイダーもそうだ。
登録した電話番号を失くすと、アカウントから締め出される可能性もあるんだ。
君はどうやってるの？
僕は数年使ってたHotmailアカウントを、電話番号を失くしたせいで失ったんだ。
昔、上司が個人的な用途で携帯代を出してくれるって言ってくれて、それでカナダに来た最初のiPhone 3Gを手に入れたんだけど、その会社を辞めた後、アカウントに問題があった時にあの電話番号が必要になるって考えてなかったんだ。
結局、全ての復旧方法を試したけどダメだった。悲しいことに、そのアカウントからたまにメールが転送されてきてたんだけど（最近は来てないけど）、何年も来てたんだ。失くしたのはすごく痛い。
さらに最悪だったのは、昔は個人情報をオンラインで提供するのをすごく警戒してたから、名前を「John Fokendoe」とか適当な誕生日で登録してたんだ。
だから、入力した情報が思い出せなくて、何年分もの情報が失われた。
Googleアカウントは、電話を失くした場合に備えてバックアップコードをダウンロードして安全なフォルダに保存してるよ。
僕には今、3つのアクティブなGmailアカウントがあるんだけど、全部最初の「口コミ」紹介時代から使ってるんだ。
昔はスパムを使い捨てアカウントにマッピングするプロジェクトとかで、もっとたくさんのGmailアカウントを作ってたよ。
これらのアカウントには一度も電話番号を紐付けたことがないんだ。
今使ってるGmailアカウントも電話番号は関連付けてないし、リカバリーとかセキュリティで電話番号の紐付けを求められても断ってる。
電話番号でサインアップしたことがないから、失くす電話番号もないんだ。
セキュリティチャレンジがあっても、関連付けられたGmailアカウントで認証してる。
僕の出生証明書上の名前とか、電話番号とか、実際の家の住所とかはネット上にはほとんど痕跡がないんだ…そういう情報でバックトレースしようとする人は、結局親戚とか、違うけど似た名前の西オーストラリアの人に行き着くことがほとんどだね。
彼ら自身のポリシーによって、「必須」にできる度合いには限界があるんだ。
新しい（または工場出荷時状態にした）Android/ChromeOSデバイスを初期設定する時、Googleアカウントが「必須」なんだ。だからアカウントを持ってない（または持ってないと言う）場合、デバイスの初期設定プロセスで新しいGoogleアカウントを生成してくれる。
デバイスに電話番号やSIMカードがなくてもね。
僕は長年何台かAndroid/ChromeOSデバイスを使ってきたけど、どれも新しいGoogleアカウントを生成させてきたよ。
これらのアカウントには電話番号は関連付けられてないんだ。
だいたいこれらのアカウントはGoogle Playストアで無料アプリをダウンロードする以外にはあまり使わないかな…
もっと extensiveに使ったら、「続行するにはこのアカウントに電話番号を追加する必要があります」ってなるかも？
もっとコメントを表示（2）
「Android/ChromeOSの初期設定でGoogleアカウントが必須」ってのは、僕がAndroidを詳しく見たのはしばらく前だけど、そうじゃなかったのを覚えてるし、ネットでちょっと検索した感じでも今もそうみたいだよ。
グーグルアカウントなしで進むってボタン押すだけでいけるの？そんなオプション毎回見逃してただけ？分かりにくい方法ならリンク貼ってよ。”ググれ”も昔みたいに簡単じゃないんだよ。
シム入れたらいつでもあなたの番号取れるよ。だって彼ら、あなたのスマホをコントロールしてるんだから。
面白いんだけど、電話番号ってシムカードに保存されてないんだ。代わりにグローバルにユニークなアイシーシーアイディー番号が入ってて、通信会社がそれをあなたの番号と紐づけてる。だから番号をシムとか会社間で移せるし、スマホ自体は自分の番号知らないままでいられるんだよ。
面白いけど、それ関係ないよ。シムをスマホに入れた瞬間にグーグルはあなたの番号を手に入れられるんだ。それ、グーグルの機能でもあるしね。
スマホが自分の番号知らないのが、うちのスマホみたいに意外と面倒なんだよね！
ユーエスエーではどうだか知らないけど、イーユーではこういう時のために2ドルでプリペイドシムカード買って、ほぼずっと使えるよ。あんまり使わないならあと1～2ドルチャージ要るかもだけど、そういう風に分けるにはそれくらいの値段だよ。
イーユーのどこ？アイルランドで見つけたベストなやつは、番号を維持するために半年ごとに最低5ユーロチャージ要るんだ。まだ自動化はできてないけどね。
確実じゃないけど、ポーランドのオレンジのプリペイドだと、チャージに関わらずアカウントを365日延長するのに7ドルくらいかかる。でも手動でアクティベートしなきゃいけないし、普通の使い方じゃないかも。
最初から番号で登録してないなら、番号追加しろって言われるけど、スキップできるよ。
本物の電話番号以外に何使ってんの？必須の電話番号認証サービス、どうやってパスすんの？教えてよ。
毎秒4万件もリクエスト送って、サーバーに長時間負荷かけてるのに、アラーム鳴らさないでリソース急増させないってすごいね！感心しちゃったよ。
アラーム鳴ったけどすぐ収まったとか、担当者が見る前に戻ったとかかもね。
Google規模だと毎秒4万件なんて大したことないし、IP変えたりIPv6使えば気づかれにくいよ。
監視じゃなくて、JavaScript無効なフローでトークン借りてレート制限かからないのが問題なんだよ。
参考までに、Googleって1秒間に検索クエリを16万件くらい処理してるらしいよ。
もしかしたら、そのためにボットネット使ったのかもね？
リクエストごとに違うIPアドレスからとかさ。
こうやってバグバウンティ減らしちゃうと、自分たちで首絞めてるようなもんだよ。
報酬が少ないせいで、ホワイトハットが報告しなくなったらどうなるか、サービス提供側は忘れてるっぽいね。企業の欲張りはみんなにとって良くないよ。
2025年、2023年、2021年の同じような話のリンクだよ。
https://qbix.com/blog/2025/06/06/%e2%80%9cno-way-to-prevent-…
https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says…
https://qbix.com/blog/2023/06/12/no-way-to-prevent-this-says…
どれが一番ウケる？
