Freedom Chat | 这款美国通讯应用泄露了所有人的电话号码

原创已于 2025-12-17 16:02:47 修改 · 366 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #网络安全 #安全架构 #安全威胁分析

于 2025-12-17 16:00:15 首次发布

飞函安全观察专栏收录该内容

4 篇文章

订阅专栏

Freedom Chat 是一款宣称具备顶级端到端加密、无元数据收集和去中心化架构的通讯应用，主要面向保守派群体。然而，安全研究员通过简单的逆向工程发现，该应用实际上并未兑现其安全承诺，反而暴露了用户的敏感信息。

虚假的安全承诺

该应用声称：

采用最先进的端到端加密（E2EE）
不收集任何元数据
使用无服务器的去中心化架构

此前，一款名为 Converso 的应用也曾做出类似承诺，但被安全研究员 crnković 揭露其虚假宣传：收集大量元数据、使用第三方中心化服务器、甚至将密钥暴露在公开信息中。讽刺的是，Freedom Chat 的 CEO 正是 Converso 的 CEO Tanner Haas，在 Converso 下架后，他带着这款“重新品牌化”的应用卷土重来。

现实：元数据与中心化服务器

研究员通过流量分析发现，Freedom Chat 实际上收集了大量元数据，并且加密消息的密钥可以从公开信息中推导出来。这意味着所谓的“顶级安全”形同虚设。

漏洞一：泄露所有用户的 PIN 码

应用中包含一个“频道（Channels）”功能。当用户查看频道信息时，服务器会返回一个巨大的 JSON 响应，其中包含频道内 所有成员 的详细列表。

在这里插入图片描述

惊人的是，这个列表中竟然明文包含每个用户的 pin 字段！

"members": [
    {
        "user": {
            "uid": "...",
            "pin": "123456", // 用户的PIN码直接暴露
            ...
        }
    }
]

这意味着，任何加入频道的人（默认所有用户都在官方频道中）都会将自己的 PIN 码广播给其他所有用户。

漏洞二：泄露所有人的电话号码

应用还存在一个经典的联系人发现漏洞。其 API 接口没有速率限制（Rate Limit），允许攻击者批量上传电话号码进行匹配。

研究员编写了一个简单的脚本，遍历了所有可能的北美电话号码（约 800 万个组合），向 API 发送请求。结果，服务器一一响应，返回了已注册用户的 UID。

结合前一个漏洞中获取的“UID - PIN”对应关系，攻击者可以：

枚举所有电话号码，找到注册用户。
获取注册用户的 UID。
通过频道列表将 UID 与 PIN 码匹配。

最终结果是：所有用户的电话号码和 PIN 码都被完全泄露且一一对应。

从 Freedom Chat 事故看企业通讯安全：公有云 vs 私有化

Freedom Chat 的安全崩塌并非个例，它暴露了公有云通讯软件在架构层面的天然劣势：只要数据汇聚在中心化公网服务器上，就是攻击者眼中的“蜜罐”。 相比之下，以飞函为代表的企业级私有化即时通讯方案，从底层逻辑上规避了上述两类风险：

1. 架构层面的“物理隔离”

Freedom Chat 的漏洞根源在于攻击者可以轻易访问其公网 API 接口，进而遍历所有用户数据。

飞函的机制：采用私有化部署，服务器直接架设在企业内网或私有云中。这意味着 API 接口不对互联网开放，外部攻击者在物理网络层面上就被隔绝在外。数据不流出企业围墙，即便发生类似 API 无限流的配置失误，由于内网环境的封闭性，外部黑客也无法触达利用。

2. 身份认证的“封闭闭环”

Freedom Chat 为了追求用户增长，采用了便利但并不安全的“手机号匹配”机制，导致任何人都能通过遍历手机号探测用户。

飞函的机制：放弃公网手机号匹配，采用基于**组织架构（LDAP/AD）**的封闭认证体系。
- 不可遍历：只有经过企业管理员授权创建的内部账号才能登录。
- 不可见：通讯录仅对组织内部成员可见，并非开放给任意注册用户。
- 即使有人知道了某个员工的手机号，也无法通过外部手段反查其在飞函内部的账号信息或 PIN 码，从根源上阻断了信息刺探路径。

对于重视数据隐私的组织而言，真正的安全不应依赖于厂商口头的“顶级加密”承诺，而应建立在可控的物理架构与严谨的权限体系之上。