- Freedom Chat というMAGA（米国保守陣営）テーマのメッセンジャーアプリで、ユーザーの 電話番号とPINコード を露出させる深刻な脆弱性が発見された
- このアプリは Converso という以前のプロジェクトの後継で、過去にも暗号化実装の誤りやデータ露出の問題があった
- 分析の結果、チャンネル機能を通じて 全会員のPINコードが他のユーザーへ送信 され、連絡先同期APIを通じて 電話番号とUIDの対応付けが可能 であることが判明した
- 研究者は レート制限（rate limiting） がまったくなく、1日で Freedom Chatの全ユーザーの電話番号を収集 できたことを確認した
- この事件は、「セキュリティを強調する」アプリが、むしろ 基本的な個人情報保護にすら失敗した事例 として指摘されている
ConversoからFreedom Chatへの移行
- 2023年に公開された Converso は「サーバーレスな分散構造」と「最新のE2EE」を主張していたが、研究者 crnković の分析により、すべての主張が虚偽 であることが明らかになった
- 実際には 中央サーバーとサードパーティの暗号化サービス（Seald） を使用しており、暗号鍵は公開情報から導出可能だった
- すべてのメッセージが 公開Firebaseバケットにアップロード され、誰でも閲覧可能だった
- その後、CEOの Tanner Haas はアプリを撤回し、「保守陣営のプライバシー懸念」を理由に Freedom Chat へとリブランディングした
- 彼は「批判を受け入れて改善せよ」という教訓に言及したが、セキュリティ問題は繰り返された
Freedom Chatの構造と機能
- アプリは 電話番号ベースの登録 と 2FAコード認証 を使用し、PIN設定は任意
- 主な機能は 1対1チャット と チャンネル（Channels） で、Telegramに似た構造
- アプリは スクリーンショット防止機能 を掲げて「セキュリティ機能」として宣伝していたが、実際の安全性とは無関係だった
PINコード流出
/channel APIリクエストの結果、チャンネルメンバー1,519人の ユーザーオブジェクト（user object） に PINフィールド が含まれていた
- 各ユーザーのUID、Sealdキー、作成日などとともに、6桁のPINコードが平文で露出 していた
- 新しいアカウントを作成して確認した結果、自分のPINがそのまま応答データに含まれていた
- つまり、デフォルトチャンネルに残っている全ユーザーのPINが他のユーザーに露出 する構造だった
電話番号マッチングの脆弱性
/user/numbers APIはWhatsAppと同じ方式で 連絡先の存在有無を確認 する
- リクエストに含まれた番号のうちFreedom Chatユーザーである場合、UIDとSealdキー を返す
- 研究者はこのAPIに レート制限が一切ないことを確認 し、米国の全電話番号を順次テスト可能だった
- 結果として 電話番号とUIDの対応付け が可能で、先に露出した UIDとPINのデータと組み合わせる と 電話番号とPINの対応表が完成 する
全ユーザーデータ流出の実験
- 研究者はPythonスクリプトを作成し、北米の全電話番号（7桁の組み合わせ × 市外局番） を自動でリクエストした
- 1リクエストあたり40,000件の番号を送信し、平均応答時間は約1.5秒
- 27時間にわたりすべてのリクエストが正常に処理され、Freedom Chatの全ユーザーの電話番号収集を完了 した
- サーバーは レート制限や遮断措置なしに応答 し、完全に データ閲覧可能な状態 だった
対応とその後の措置
- 2025-11-23: 脆弱性を発見
- 2025-12-04: TechCrunch記者 Zack Whittaker がFreedom Chatに脆弱性を開示
- 2025-12-05: Freedom Chat側は「PINはメッセージ復元用ではなく、すでに監査手続きを進めている」と説明
- 2025-12-09: 修正完了の通知
- 2025-12-11: 本レポートとTechCrunch記事を同時公開
核心的な教訓
- Freedom Chatは「スーパーセキュリティ」をうたっていたが、基本的な認証・レート制限・データ保護設計が欠如 していた
- 結果として 全ユーザーの電話番号とPINが露出 し、セキュリティ機能は事実上無力化された
- これは セキュリティマーケティングと実装実態の乖離 を示す代表的な事例と評価される
1件のコメント
Hacker News の意見
Signal の 暗号化された電話番号照会システムは興味深い
サーバーがハードウェア暗号化された RAM 上でビット単位の XOR 演算を使って番号を照会するため、システムを最下層レベルで観察しても、要求された電話番号が存在するかどうかは分からない
もちろん rate limiting は別の重要な問題だ。セキュリティシステムを作る際には、カバーすべき エッジケース が本当に多い
Matrix のような 非商用・プライバシー重視のプラットフォーム では、こうしたマッピング自体を不可能にすべきだ
たとえば、ユーザーの連絡先リストにいる相手だけがそのユーザーを見つけられるよう、各ユーザーペアの電話番号をハッシュ化した値をアップロードする方式が提案できる
利点は、ハッシュ空間が広く逆追跡が難しいこと、そしてユーザーが 発見許可範囲 を自分で決められることだ
欠点は、攻撃者がすべての番号の組み合わせを生成して連絡先関係を抽出できる点と、政府が SMS 認証を傍受してこれを悪用できるかもしれない点だ
ユーザーオブジェクトの
pinフィールドが怪しいおそらく opt-out 型のシリアライズライブラリ を使ったことで生じた問題の可能性がある。デフォルトでオブジェクト全体をシリアライズするため、開発者が特定フィールドを除外する設定を忘れると、そのまま露出してしまう
あるいは、サーバー側で単に JS の辞書を使っていて、レスポンス前にフィールドを削除しなかったのかもしれない
この脆弱性は ウィーン大学研究チームの論文 で言及された古い問題で、2016 年には Telegram でも同じ方法で悪用され、イラン政府が 1,500 万人のユーザーの電話番号を収集した
関連リンク: Telegram ブログ
最近のセキュリティ脆弱性の多くは、単に想定外の方法で HTTP エンドポイントを呼び出す ことから生じている
2025 年のハッキングと聞くと複雑な技術を思い浮かべるが、現実には rate limiting すらない API を公開しているのが実情だ。Nginx の設定 1 行で解決できる問題だ
ほとんどの目標はユーザーの摩擦を減らし、商業的効率性 を高めることだ。多くの開発者は XSS や SSRF のような基本的な脆弱性を知らないまま機能だけを実装している
Docker のポートマッピングのミスや CSP の欠落のような 初歩的なセキュリティミス があまりにも多い
「最高のブログ記事だけを読者に届けたい」という文を見て、書き手と 似た気質の人 を見つけた気がした
Freedom Chat® に、記者がグループチャットに参加できないようにする機能があるのか気になる。半分冗談、半分本気で DoD の友人 のために聞いている
今年だけでも、「セキュリティアプリ」がユーザーデータを扱って 流出させた事例 が何度もあった
覚えているだけでも 20 セント分（=4 件）くらいはあるが、たぶんもっと多いだろう
関連事例: 1, 2, 3
昨年、GOP の求人掲示板 を偶然見たのだが、応募書類が求人公告と同じ検索インデックスに保存されていた
「bob」と検索したら応募者たちの 履歴書と回答 がそのまま露出していて衝撃だった
Anom 事件以降、「honeypot」よりもっと適切な言葉が必要だ
本当に安全なメッセンジャーは、こういうやり方では出てこないだろう。だがマーケティングは続き、そのたびに新しいユーザーが引き寄せられる
データ流出があまりにも頻繁に起きるので、人々ももう鈍感になってきている。集団訴訟の補償ですら、結局は 個人情報をさらに提供する プロセスになってしまう
予測市場や暗号資産なども結局は 参加者に損をさせる構造的失敗 を「成功」であるかのように包んでいる感じがする
Freedom Chat は「問題の修正完了」と告知したが、本当に修正されたのか疑問 だ
「モバイルアプリ開発の経験はなかったが、頭がいいから難しくないと思った」という文が実際の引用なら、ほとんど スタンドアップコメディの台詞 のように聞こえる