Signal、Discordなどのプラットフォームを狙った0-click匿名性解除攻撃
(gist.github.com/hackermondev)- Cloudflareのキャッシュとプッシュ通知が組み合わさると、脆弱なアプリがインストールされたスマートフォンや、バックグラウンドで動作するアプリがあるノートPCで、ユーザーの位置を数百マイル単位まで絞り込める0-click匿名性解除攻撃が可能になる
- 攻撃者は、標的デバイスにCloudflare配下のリソースを自動取得させた後、それがどのCloudflareデータセンターにキャッシュされたかを調べ、標的に近い地域を推定する
- Signalでは
cdn2.signal.orgの添付ファイルキャッシュとモバイルのプッシュ通知により、チャットを開かなくても添付画像がダウンロードされうる。またDiscordでは、フレンドリクエスト通知のアバターURLで同じ攻撃が可能 - Cloudflareは、特定データセンターにリクエストを送るCloudflare Teleport関連のバグを修正したが、VPNサーバーを利用してもCloudflare全データセンターの約**54%**に再び到達できたという
- SignalとDiscordは責任範囲をCloudflareまたはユーザー側に帰し、Cloudflareは保護対象リソースのキャッシュ無効化は顧客責任だとの立場を示しており、アプリ・CDN・通知設計が絡み合うプライバシーリスクが残っている
Cloudflareキャッシュで位置を絞り込む仕組み
- この攻撃は、Cloudflareのキャッシュ状態情報と地理的に分散したデータセンターを利用して、ユーザーのおおよその位置を推定する
- Cloudflareは、キャッシュ可能なリソースへのリクエストに対し、レスポンスヘッダーで情報を提供する
cf-cache-statusはHITまたはMISSを示すcf-rayには、リクエストを処理したデータセンターと、その近くの空港コードが含まれる
- 標的デバイスがCloudflareベースのサイトのリソースを読み込むと、そのリソースは標的の近くのデータセンターにキャッシュされる可能性がある
- その後、複数のCloudflareデータセンターを調査して、どこにリソースがキャッシュされたかを見つければ、標的に近い地域を推定できる
- Cloudflareは120か国以上、330都市に数百のデータセンターを運用しており、先進国の居住者なら最寄りのデータセンターが200マイル以内にある可能性が高いと説明している
Cloudflare Teleportとデータセンター巡回
- 通常、CloudflareのIP帯域はanycastで動作しており、ユーザーが特定のデータセンターに直接TCP接続を要求することはできない
- Cloudflare WorkersとCloudflare WARPの内部IP帯域を使うことで、特定のデータセンターへHTTPリクエストを送る迂回が可能だったというコミュニティフォーラムの投稿をもとに、Cloudflare Teleportが作られた
- Cloudflare TeleportはCloudflare Workersベースのプロキシで、特定の
colo値を指定して任意のデータセンターにリクエストを送るツールだった- 例えば、Seattleデータセンターを表す
SEAのようなコードが使われる - 特定IP帯域とデータセンターの対応情報は
colos.jsonの形で整理されていた
- 例えば、Seattleデータセンターを表す
- Cloudflareはその後、このバグを完全に修正し、Teleportツールはこの方式ではもはや動作しない
Namecheap faviconで確認した概念実証
- 最初の検証では、Namecheapの
favicon.icoが使われた - このリソースはCloudflareキャッシュが有効な単純な静的画像で、ボット対策も厳しくなかったため、テスト対象として選ばれた
- CLIツールは、指定URLについて、どのデータセンターがリソースをキャッシュしたかと、キャッシュ年齢を列挙する
- Namecheapはキャッシュ年齢を5分という非常に短い値に設定していたが、直近5分以内にfaviconをキャッシュしたデータセンター群を確認できた
- ブラウザーはサイトを開く際にfaviconを自動ダウンロードするため、この結果は、直近5分以内に複数地域のユーザーがNamecheap.comを訪問したことを示す概念実証となった
Signalでの適用
- Signalはコンテンツ配信に2つのCDNを使っている
cdn.signal.org: CloudFrontベース、プロフィールアバター用cdn2.signal.org: Cloudflareベース、メッセージ添付ファイル用
https://cdn2.signal.org/attachments/*パスにはCloudflareキャッシュが設定されており、添付ファイルを受け取ったデバイスがそれをダウンロードすると、近くのデータセンターにキャッシュされる可能性がある-
1-click方式
- ユーザーがSignalで添付ファイルを送ると、ファイルは
cdn2.signal.orgにアップロードされる - 受信者が会話を開くと、デバイスが添付ファイルを自動ダウンロードし、Cloudflareキャッシュによる地理推定方式で受信者の位置を絞り込める
- テストでは、SignalデスクトップアプリのSSL pinningを解除し、Burpでリクエストとレスポンスを確認した
- 攻撃者側デバイスが先に添付ファイルをダウンロードすると、攻撃者の近くのデータセンターにキャッシュが作られて結果が汚染される可能性があるため、攻撃者側Signalアプリで
cdn2.signal.org/attachments/*へのGETリクエストをブロックした - ニューヨークで自分自身を対象に実行したテストでは、ニュージャージー州ニューアークの
EWRデータセンターが確認され、実際の座標から約150マイル離れた位置だった
- ユーザーがSignalで添付ファイルを送ると、ファイルは
-
0-click方式
- Signalモバイルアプリはデフォルトでプッシュ通知に送信者とメッセージを含める
- 添付画像付きメッセージでは、通知右側に表示する画像のために、デバイスがSignal CDNから画像をダウンロードする
- 標的がSignalの会話を開かなくても、プッシュ通知が届けば添付画像がダウンロードされる可能性があり、その過程で標的近くのCloudflareデータセンターにキャッシュが作られる
- この方式は、ユーザー操作なしで現在地を推定する0-click攻撃につながる
- Signalはジャーナリスト、活動家、内部告発者が利用するサービスであるため、アカウント追跡、身元相関の把握、記者と会う社員の位置推定といった悪用リスクがある
Discordでの適用
- Discordも、Cloudflareキャッシュが有効なCDNリソースのため、同種の攻撃に脆弱なアプリだと確認された
- 1-click方式では、Nitro加入者が使えるカスタム絵文字が利用された
- カスタム絵文字はDiscord CDNから読み込まれる
- メッセージ、ユーザーステータス、チャンネルなど複数の場所に表示できる
- 攻撃者はユーザーステータスにカスタム絵文字を表示し、標的がプロフィールを開くのを待てる
- Discordに提出した完全なHackerOneレポートは、別のGistで公開されている
-
フレンドリクエスト通知を使った0-click
- Discordのモバイルプッシュ通知は、メッセージ以外にもさまざまなイベントで送信される
- フレンドリクエストを送ると、標的のモバイルデバイスにプッシュ通知が発生する
- 標的がDiscordを使用中であっても、フレンドリクエスト通知は常にモバイルデバイスへ送信される
- フレンドリクエスト通知には、リクエストを送ったユーザーのアバターURLが含まれ、スマートフォンはこのアバターをユーザー操作なしでダウンロードして通知に表示する
- DiscordのアバターURL形式は状況により異なる
- プッシュ通知:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash} - Webサイト表示:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png - 2つのURLは同じ画像を指すが、パスが異なるため別々にキャッシュされ、プッシュ通知で読み込まれたキャッシュと、アプリのプロフィール表示で生じたキャッシュを区別できる
-
GeoGuesser自動化
- Discordの0-click攻撃手順は、非公開DiscordボットGeoGuesserで自動化された
- ボットは単一コマンドでユーザー名を受け取り、次の処理を行う
- Discord User APIでアカウント認証情報を使用する
- ユーザーアバターをランダム画像に変更してアバターハッシュを更新する
- 指定ユーザーにフレンドリクエストを送る
- Cloudflare Teleport CLIベースの非公開APIでキャッシュ列挙攻撃を実行する
- 結果を30秒未満でDiscord内に表示する
- Discord CTOのStanislav Vishnevskiyを対象にしたデモでは、2つのCloudflareデータセンターがアバターをキャッシュしていたことが示された
- 2つのデータセンターが確認された理由としては、複数デバイスが通知を受け取ったか、同一デバイスのリクエストが別々のデータセンターへロードバランシングされた可能性がある
- GeoGuesserはGoogle Maps APIで2つのデータセンターの中間点を計算し、半径円を表示する
- デモ地図では、Discord本社はカリフォルニア州San Franciscoにあり、外側の円の内側に含まれ、実際の位置は約300マイル範囲の内側の円の縁付近と推定された
- 全工程は1分未満で完了し、攻撃はほぼ検知困難なレベルだった
バグバウンティと各組織の対応
- Signalは報告を即座に却下し、WireGuard、Tor、オープンソースVPNソフトウェアのようなネットワーク層の匿名性機能を完全に再現しようとしたことはないとの立場を示した
- Signalへの反論は、Signalがプライバシー優先のコミュニケーションプラットフォームとしてマーケティングされており、ユーザーがエンドツーエンド暗号化以上のプライバシーリスク最小化を期待している点に基づく
- Telegramはこの攻撃に脆弱ではない例として挙げられている
- HTTPに依存しない独自プロトコルを使っている
- Cloudflareのようなクラウド事業者のキャッシュに依存していない
- Discordセキュリティチームは当初、ユーザー保護のための変更を検討するとしていたが、その後は他のCloudflare顧客も影響を受けるCloudflare側の問題だという立場に変わった
- Cloudflareは、Cloudflare Teleportがデータセンター巡回に利用していたバグを修正した
- このバグは1年前に別の報告者がHackerOneで報告していたが、当時は影響なしと判断されていた
- 今回の研究共有後、Cloudflareは既存レポートを再オープンして解決し、既存報告者と今回の報告それぞれに200ドルのバウンティを支払った
修正後も残る問題
- Cloudflareが修正したのは、内部ネットワーク経由でデータセンター巡回を可能にしていたバグであり、キャッシュベース位置推定の中核条件そのものは消えていない
- 修正後も、記事で説明された攻撃は直近24時間以内に実行できたとされる
- Cloudflare Teleportは、修正から24時間後にVPNベース方式で再実装された
- 選ばれたVPNプロバイダーは31か国に3,000台以上のサーバーを保有している
- この方式により、Cloudflare全データセンターの約**54%**に再び到達でき、人口の多い地域の大半をカバーできると説明されている
- Cloudflareの最終的な立場は、この匿名性解除攻撃を自社システムの脆弱性とは見なさず、保護が必要なリソースのキャッシュ無効化は顧客責任だというもの
- Discordのような顧客はCloudflareの責任と見なし、Cloudflareは顧客がキャッシュを調整すべきだとしており、責任の境界が分かれている
防御と実務上の含意
- この攻撃は、キャッシュとプッシュ通知という性能・利便性の機能が組み合わさると、追跡手段として悪用されうることを示している
- Cloudflare Teleportのバグは修正され、Signal・Discordのような一部アプリが公開後に緩和策を講じた可能性はあるが、基本的なリスクは残っている
- CDNでコンテンツ配信し、キャッシュを利用するアプリは、十分な注意がなければ同種の攻撃に脆弱になりうる
- 保護が必要なリソースでは、CDNキャッシュ方針、プッシュ通知で自動読み込みされる画像、ユーザーごとに一意なURLのキャッシュ挙動をあわせて考慮する必要がある
- ジャーナリスト、活動家、ハッカー、プライバシーに敏感なユーザーは、アプリ通知と外部リソースの自動読み込みが位置露出につながりうることを意識する必要がある
1件のコメント
Hacker Newsの意見
Signalユーザーに写真を送ると、Cloudflare経由で取得され、そのユーザーの近くのデータセンターにキャッシュされる。その後、キャッシュ状態を照会することで、使われたデータセンターを特定できる
ユーザーが人里離れた地域にいるのでない限り、これを匿名性の解除と呼ぶのは大げさに思えるが、それでも興味深い記事ではある
それでもCloudflareがSeattle、Manchester、Tokyoのキャッシュを返すことはないので、未知のSignalユーザーを大まかな地理的位置に絞り込めるだけでも、個人を特定するために組み合わせられる重要なメタデータになる。見事な攻撃だ
Cloudflareは非公開・グループチャットで膨大な量のメタデータを見ることができ、ファイルサイズから元のメディアの送信者、既読者、既読時刻、転送した人と転送先まで追跡できる。画像や動画を直接見られなくても、サイズを事前に知っているか、後で法執行機関からの要請などで知ることができれば十分だ
その情報だけではまだ不十分でも、特定の容疑者がいるなら確認の助けになる。疑わしい人物に直接接触でき、その人の「クリーンな」プロフィールとも友達になれるなら、同じ手法で2つの位置プロフィールを照合することもできる。匿名性の解除とは単一の情報ではなく、すべての情報が容疑者を絞り込んだり疑いを確認したりするプロフィールに積み重なるプロセスだ
ここでいう「調査者」はAIエージェントや法執行機関ではなく、一般の人を意味する。法執行機関ならCloudflareからもっと直接的に情報を得られるだろう
この特定のレベル・種類の匿名性解除が自分のユースケースで問題になるかどうかは別の問題だ。個人的には相互連絡先が私のIPアドレスをそのまま見てもあまり気にしないが、すべてのユーザーがそうというわけではない
Silk Road捜査でも、その程度の情報が実際に重要だった。Ulbrichtは初期にミスでタイムゾーンを明らかにしてしまい、そのおかげで米当局は彼を米国内の人物に絞り込めた。その情報がなければ、世界中のどこにいてもおかしくなかった
興味深い手法とアプローチが詰まった良い記事だ
ただし「匿名性の解除」や「ユーザー位置の取得」という表現はやや大げさだ。精密な位置とはほど遠く、150マイルはジョージア州Atlantaからジョージア州Augustaまで高速道路で約2時間の距離だ。その半径内にはおそらく70万人以上がいる
Signalの添付ファイルの自動取得機能は少し気になる。プライベートメッセンジャーならTorでJavaScriptを切るように無効化オプションがあると思っていたが、深く探せていないだけかもしれないものの、その機能は見当たらなかった
Signalは大衆的な普及のために、プライバシー保護と使いやすさのバランスを取った「デフォルトで有用」なアプローチを選んでいるようだ。本当に心配するユーザーは、https://www.privacyguides.org/articles/2022/07/07/signal-con... のようなガイドに従ってSignalを強化しているはずだ。高リスクのシナリオでは、VPN/プロキシと設定変更を常に推奨してきた
キャッシュもCloudFlareもなくならないだろう。IPが露出していた昔のP2PマルチプレイヤーロビーでのDDoS脅威のほうが、これより大きく見えたし、第三者の中ではCloudFlareの対応が最も良さそうに見える。機微情報はキャッシュしないのが原則であり、CDNや中間サービスに特定の項目をキャッシュしないよう伝える責任は、通信するアプリケーション側にある
すごい。一部の他のものと違って、これは確かに匿名性の解除と見なせるか、少なくともそれにかなり近い。Satoshiの位置を250マイル以内に特定できていたら、今どれほど匿名のままでいられただろうか？
この攻撃を繰り返し適用すれば、何らかの形で隠しながら、時間の経過に伴う移動を追跡できる。通常、郵便番号程度の大きさの位置が4〜5個あるだけで、1人を一意に識別できる
AppleとCloudflareが自社のプライバシー保護ソフトウェアで使っている方式も、地域は身元を明かす情報ではないという考えに基づいている。AppleのiCloud Private RelayやCloudflareのWARPがそうで、Apple Private Relayを有効にすると元のIPは隠されるが、トラフィックがルーティングされるIPは同じ国にある
https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
この攻撃は学術的には興味深く新しいが、「匿名性の解除」ではない
もちろん彼ではなく、無作為な初期ユーザーだった可能性もある。それでも彼である可能性はある程度あると思う
詳細: https://news.ycombinator.com/item?id=29728339
彼の名前や住所を探し出して公開しようとする試みは支持しない。生活を困難にしかねないからだ。ただ、長年にわたり多くの注目を集めてきたのに解けていないミステリーという意味では、抽象的には非常に興味深い
なぜこんなに多くの上位コメントが深刻さを低く見ているのか分からない。これは法執行機関や悪意ある行為者が所在の証拠を組み立てられるようにする、まさにそういうタイプの攻撃だ
所在証明は匿名性の解除ではなく、特にその「所在」がこれほど広い場合はなおさらだ
まず無視してみて、朝になっても問題が残っているかを見るのだ。それまでは、誰かがこれが問題ではない理由を見つけてくれることを期待している
SignalはなぜそれらのURLでキャッシュを有効にしていたのだろう？ 最も一般的なケースでは、添付ファイルは一度ダウンロードされて終わりのはずだ
むしろ一度以上ダウンロードできないようにし、最初のダウンロード成功後すぐ削除するものだと思っていた。もちろんクライアントが途中で失敗する可能性はあるので、再ダウンロードのための猶予期間は設けられる。それでもそれが一般的なケースだとは思えないし、CDNキャッシュをオフにすればこの問題は直せるはずで、コストも大きく増えないことを願う
いずれにせよ、ここでの「匿名性の解除」は少しクリック誘導的な表現だ。誰かの位置をおよそ250マイル以内に絞り込むのは良くないが、その人の匿名性を解除するわけではない
追記: 添付ファイルがグループチャットに送られ、複数人がダウンロードする場合を考えていなかった。ただ、その場合でも添付ファイルはグループ内の各人に個別に暗号化されるのでは？ もちろん実際にどう動作するのかはよく知らない
挙げられた項目は、そうした狂ったレベルのプライバシー・セキュリティを望む人なら実質的に設定できる。メッセージを閲覧後30秒で自動削除するようにでき、プロキシ経由で全トラフィックをルーティングするよう設定でき、そのほかにもユーザーの好みに合わせて多くを調整できる
キャッシュしている理由は、おそらく送信コストのためだろう。ファイル添付、音声メッセージ、動画などが全部積み重なると大きくなる
この人は数か月前にZendesk Slack乗っ取りの脆弱性を見つけた、まさにあの15歳だ [1]
[1]: https://news.ycombinator.com/item?id=41818459
Adobeに提出したそのバグレポートは、5歳の時に書いたことになる: https://hackerone.com/daniel?type=user
確かに「攻撃」ではあるが、普通 ゼロクリック と聞いて思い浮かべるタイプではない。コード実行はなく、どの Cloudflare データセンターが画像をキャッシュしたかを突き止めるいくつかのトリックで、ユーザーのおおまかな地域を得る方式だ
それでも印象的で洞察に富んでいる
そうした側は地域のリソースと協力して追加調査ができる。どの地域のどのリソースを動員すべきか分かるだけでも、多くのコストを節約できる
述べたとおり、印象的で洞察に富んでいる。文書は少し ChatGPT の助けを借りた感じもするが、とても明確で具体的な文が多い。こういう用途なら優れたユースケースなので、非難ではない。良い記事だった
何か見落としていない限り、これはユーザーの IP 位置を確認する非常に回りくどい方法のように見える
例えば VPN に接続したうえで https://cloudflare.com/cdn-cgi/trace を確認すると
colo:CPH（Copenhagen）と出るが、地理的に自分に最も近い CF データセンターからは遠く、VPN プロバイダーの IP 位置である Oslo にはより近いものの、それでも特に近いわけではないVPN を使わない場合も、今いる国の首都すら出ず、約250マイル北にあるデータセンターが出る。なので Cloudflare が常に「最も近い利用可能なデータセンター」を返すという話にも同意しにくい
記事自体は見事で、確かに興味深いが、実際の有用性には確信が持てない
実際の有用性と潜在的なリスクは、このデータが他のデータと組み合わされたときに生じる。スパースなデータセットを使った 匿名性解除の手法 は少なくとも15年間、活発な研究分野であり、互いに無関係に見える数片のデータからどれほど多くのことが分かるかに人々はしばしば驚く
アプリケーションが画像のようなリソース要求をプロキシするために多大な労力をかけるのには理由がある。それは無料ではない
Signal で画像を CDN にキャッシュ する利点は何だろう？
ローカルクライアントのキャッシュがあると仮定すると、そのリソースへの総リクエスト数は非常に少ないはずで、多くの場合1回である可能性が高い
それとは別に、CloudFront は
cf-rayヘッダーを返さないか、顧客が削除できるオプションを提供すれば、この問題をかなり簡単に直せそうだ。ただしタイミング情報から依然として分かってしまうかもしれないここでの「近い」は近似的なヒューリスティックで、リクエストが通過する BGP ルーターのエニーキャストルーティングテーブルの属性だ。実際には「最適経路」に近い
cf-rayヘッダーをなくしても、単に 応答時間 を見ればよい。リソースを別の大陸から取得する必要があるなら、おそらく安定して測定できるどのユーザーが存在するかを隠そうとするウェブサイトでも似たことがある。存在するユーザー名でログイン要求をするとパスワードハッシュ化を行うため、通常は応答時間が少なくとも50ms増え、存在しないユーザー名では早期終了する。解決策は常に同じコードを実行してハッシュ化も常に行うことだが、そうしているサイトは非常に少ない。あるいは脅威モデルに合うなら、ユーザー名が存在しないとすぐ知らせてもよい
Cloudflare の例に戻ると、応答を遅延させない限り役に立たない。しかし応答遅延は Cloudflare がやるべきことの逆だ
どのユーザーでも他のユーザーに CDN にキャッシュされたリソースリンク を含むメッセージを送れる、というのがここでの「攻撃」ではないのか？ 自分が誤解しているのかもしれない
ちょっと理解できない。Signalを匿名だと考えた人がいたことがあるのか？ Discordも同じ。だとしたら悪い知らせがある。どちらも匿名ではないし、まったく匿名ではなく、少しも匿名ではない
そんな主張をしたこともない。Signalはメッセージを読めないと主張しているだけ。Discordはよく分からないし疑わしい。その主張にも穴はある。暗号技術が堅牢だとしても、今使っているバージョンを徹底的にレビューして自分でコンパイルしたのか？
せいぜい弱い仮名性程度。ユーザーの利便性のために一部のセキュリティを犠牲にするアプリケーションがデフォルトでメディアを読み込むのは昔からよくあることで、一般的な脅威モデルでは妥当な選択。メッセージにメディアを入れることも、匿名性を解除する攻撃の定番だった
結局、トラッキングピクセルが今日でも依然として有効な手法だと示された程度で、良いことではあるが驚きではない
匿名でいたいならDiscordやSignalを使うべきではないし、HNに投稿するのも勧めない。もしかするとWhonix経由で使い捨てアカウントから、JavaScriptなしで、ローカルLLMで書き直したメッセージをランダムな時間に自動貼り付けするなら可能性はあるかもしれない。それでも保証はすべきではない
匿名性はもはや存在しない