廉价智能门铃存在全设备群账户接管和通话劫持漏洞

# 任何人都可以按你家的门铃 来源：https://www.abgeo.dev/blog/anyone-can-ring-your-doorbell ## 更新 \# (https://www.abgeo.dev/blog/anyone-can-ring-your-doorbell#updates) **2026-05-06。** 我已通过 CERT/CC 的 VINCE（https://kb.cert.org/vince）系统开立了一个协调案例，涵盖以下发现。CVE 分配将通过该流程进行。 **2026-05-07。** 本文发布一天后，Naxclow 联系了我，确认收到报告，并启动了内部审查流程。来自 Naxclow 技术总监的电子邮件确认收到披露报告。 Naxclow 在发布次日回复。 --- 最近我在 Temu（过去几年在全球流行的中国电商平台）上买了一个智能门铃。我想了解该平台上出售的廉价联网硬件实际上有多安全。该设备以“Smart Doorbell X3”的名称销售，并通过名为“X Smart Home”的手机应用配对。它配备摄像头、麦克风、双向音频和亚 GHz 室内接收器。这类设备悄无声息地出现在许多人家的前门上。 经过几个周末的研究，我发现可以： - 悄悄地将任何此类门铃从所有者的账户中偷走 - 在实时通话中冒充该设备，在所有者手机上显示攻击者选择的视频 - 通过前部一个价值 12 美元的螺丝刀即可访问的调试端口，窃取家庭 WiFi 密码 - 进而攻陷整个网络 第一个漏洞只需在该平台上拥有一个免费账户，即可将所有来自门铃的真实呼叫重定向到我的手机，而非所有者的手机。第二个漏洞甚至不需要任何账户，可以任意向所有者手机发起新通话，并播放我选择的视频。无论哪种方式，真正的门铃仍保持在线，且浑然不觉。你基本上相当于花了 12 美元让互联网上的任何人都能按你的门铃。 这些发现位于后台的平台层，而非 Temu 列表中的某个设备本身。门铃与一个名为 Naxclow 的品牌所运营的后台通信，其背后是广州的公司——广州千贵物联网科技有限公司。相同的硬件以多个转售品牌的名义出货，而同一提供商运营着一系列名为 Naxclow 的消费者应用，每个应用都有自己的子域名。V720 是其中之一（已经公开逆向工程，见 intx82/a9-v720（https://github.com/intx82/a9-v720））。另一个姐妹应用名为“ix cam”。我没有单独测试它们。它们的前端网页与 X Smart Home 共享相同的 Vue 脚手架，而该公开工作已涵盖了 V720 与门铃之间的线缆协议重叠部分。共享的 SPA 代码库加上协议重叠表明，相同后台代码运行在每个品牌域名下。这是一个关于平台的故事，而非关于某个设备。 这篇博客是经过处理的负责任的披露的一部分。找到 Naxclow 的联系方式并不容易。他们的网站没有联系页面。我最终在他们某个页面上找到了一个电子邮件地址，并通过暴力尝试同一域名下的常见别名来扩大范围。大部分邮件都被退回了。2026 年 4 月 29 日，我通过已送达的地址以及 X Smart Home 应用内的反馈表单发送了报告。截至目前，我尚未收到回复。我在通知发出后一周发布本文，并删除了敏感的具体细节。问题列表很长，所以请拿上你最喜欢的零食或饮料，耐心阅读。 ## 范围与伦理 \# (https://www.abgeo.dev/blog/anyone-can-ring-your-doorbell#scope-and-ethics) 以下所有测试均在我自己拥有的设备上进行，使用了我的两个 X Smart Home 账户。通信流量接触了 Naxclow 的生产后台，但仅使用我自己的凭据。我从未接触过任何其他人的账户、设备或流量。真实的端点路径、确切的参数名称、字面硬编码的盐值、完整的签名实现以及任何可用的 PoC 代码均未包含在本文中。重点是方法论和故障模式，而非配方。 ## 设备 \# (https://www.abgeo.dev/blog/anyone-can-ring-your-doorbell#the-device) 包含三部分： - 门铃：摄像头、按钮、麦克风、扬声器、WiFi、亚 GHz 发射器 - 一个小型室内接收器，监听亚 GHz 信号，按下按钮时发出铃声 - 用于实时查看、双向音频和事件历史的移动伴侣应用 Smart Doorbell X3 及其亚 GHz 室内接收器放在工作台上 门铃及其亚 GHz 室内接收器，在我拆开任何东西之前。设备背面标签列出了 FCC ID、制造商、进口商和批号标识符 设备背面。标签比盒子更有趣。硬件设计制造商是深圳瑞朗科技有限公司，而非 Naxclow 或卖家在列表中打印的任何品牌。FCC ID：2A5LK-X3PRO（https://fcc.report/FCC-ID/2A5LK-X3PRO），于 2024 年 3 月获批，支持 2.4 GHz WiFi 和 433.91 MHz 亚 GHz 频段。瑞朗的授权代码 `2A5LK` 下至少有七个 WiFi 摄像头产品备案。其中一个是 intx82 作为 V720 迷你摄像头逆向工程过的 A9 型号。同一工厂，不同型号代码的 WiFi 摄像头系列，均默认指向 Naxclow 的后台。标签上的欧盟和英国进口商是 Whaleco，即 Temu 在这些地区的企业实体。 拆开后，芯片数量很少。一颗 MCU 几乎完成所有工作：Beken BK7252N，一种廉价的 WiFi + 音频组合芯片。JTAG 和 UART 接口位于电路板正面。UART 的布局对于调试接口来说不常见：TX 和 RX 成对出现，作为一对小焊盘，GND 在边缘处，无 VCC 焊盘。我在启动时探测 TX，看到电压以类似串行通信的方式移动，接下来的一天便从那里向下进行。 门铃 PCB 正面：摄像头、红外 LED、麦克风、USB-C、环形按钮 PCB 正面：摄像头、用于夜视的红外 LED、麦克风、USB-C 端口、环形按钮。UART 为 115200 8N1。亚 GHz 链路采用普林斯顿编码的 24 位 OOK 调制，频率 433.91 MHz，任何能发射该频率 OOK 信号的设备均可重放。WiFi 运行 RT-Thread 3.1.0 以及 Beken SDK。这些都不特别。它们都自由地泄漏信息。 BK7252N MCU 特写：未焊接的 JTAG 接口、UART 焊盘、音频放大器 BK7252N 特写：未焊接的 JTAG 接口、UART 焊盘、音频放大器。按下按钮时，三件事同时发生： 1. 亚 GHz 脉冲发送到室内接收器，后者在室内发出铃声 2. 门铃向 Naxclow 后台发送 HTTP 请求，将通知推送到所有者手机 3. 如果所有者点击“接听”，设备与应用建立点对点通话，进行双向音频和视频 亚 GHz 链路可从人行道上使用 Flipper Zero 重放。我捕获一次按键信号，然后从设备上重放，室内接收器如我按下真实按钮一样响铃。我没有进一步深究：这是常见场景，并非我的主要目标。我专注于 WiFi 端：按键信号如何到达手机，以及通话如何开始。 ## 第一阶段：读取线路 \# (https://www.abgeo.dev/blog/anyone-can-ring-your-doorbell#phase-1-reading-the-wire) 在实验室中使用 MITM（https://www.abgeo.dev/projects/mezz/），长时间运行 Wireshark，单个捕获从按键到通话接听的整个过程。线路上首先出现的是警报。门铃通过纯 HTTP 访问后台，后台向所有者手机推送通知，通话连接在此之后才开始。 Wireshark 捕获的明文 HTTP 发送警报请求和响应 发送警报请求和响应，明文。控制平面没有任何 TLS。请求是一个 multipart 上传。三个字段突出：设备 ID、每个请求随机的字符串，以及看起来像签名的令牌（固定长度十六进制值，参数变化时改变）。还附带了一张 JPG，即所有者在通知中看到的快照。 发送警报请求体：设备 ID、随机 nonce、签名式令牌、附带的 JPG 警报请求体。设备 ID、nonce 风格的随机字段、签名式令牌，以及作为警报图像附带的 JPG。响应变得有趣了。有一个 `conf` 键，提供了后续 P2P 通话所需的主机和设备级凭据。这些凭据是静态的。它们与设备 ID 绑定，并且即使在恢复出厂设置或重新绑定到不同账户后仍保持不变。每次返回相同的值。 警报响应：conf 块中包含明文格式的静态设备级 P2P 凭据 警报响应。conf 块以明文形式返回设备的永久 P2P 凭据。查看多个捕获，`random` 和 `token` 值每次请求都改变。设备从未预先获取它们，因此产生它们的一切都在设备本地运行。令牌具有加密签名的形状：固定长度的十六进制字符串，随请求不可预测地改变。`random` 字段随之改变，表明它为令牌签名提供了额外的熵。我尝试重放请求，成功了：后台生成了新的事件 ID 并推送了通知。篡改任何基本参数（例如随机字段）会使请求失败，确认令牌确实覆盖了它们。然而，替换 JPG 主体后，警报顺利通过，并在所有者手机上显示我的新图像。图像不在签名范围内。 警报返回后，设备打开一个 TCP 连接，连接到 `conf` 块中的主机和端口。从此处起，协议为二进制，看起来像是自制的 STUN。我花了一些时间逆向分析帧结构。每个消息有一个 20 字节的固定头部，后跟 JSON 主体。头部包含长度字段、类型指示（数据与心跳）以及会话 ID。主体携带命令代码及该命令的参数。一旦掌握了帧结构，剩下的交换就显而易见了。 Wireshark 中完整的 P2P 信令会话：从认证到通话结束，包含自定义二进制头部、JSON 主体和明文凭据 设备与服务器之间的完整信令会话：从认证到通话建立，再到应用发起的 status-0 挂断。自定义二进制头部、JSON 主体，全程明文凭据。第一条消息是认证。设备发送其设备 ID、来自 `conf` 的中继密码以及同一响应中收到的域名。请求中的域名表明同一后台在域名选择器下服务多种设备家族，而非每台设备一个独立实例。注册 ACK 后，连接空闲。警报已经发出；设备在等待所有者通过手机接听。移动应用在其自己的连接上运行相同的认证流程。它使用其账户 ID 和账户的持久令牌注册到中继，然后发出针对目标设备的通话请求。这唤醒了设备的连接。中继将一条消息转发给设备，使用相同的帧结构，包含到达呼叫手机所需的一切：目标客户端的账户 ID（移动应用）、匹配的账户端令牌、客户端的公网和私网 IP 地址，以及客户端探测到的 NAT 映射端口。经典的 STUN 式会合，中继的工作是将两个已认证的注册桥接为点对点通话。在交换了一些配置参数后，双方都有了通过 UDP 直接进行 NAT 打洞所需的信息，此后通话流在该通道上进行点对点传输。 打洞后设备与应用程序之间的 P2P 连接：包含双方令牌的 JSON 会话建立、status-200 确认和原始 JPEG 帧数据 打洞后的 P2P 连接：一个包含双方令牌的 JSON 会话建立（`cliToken` 和 `devToken` 在同一数据包中）。对端确认 status-200。从那时起，通道主要是原始字节：带有 JFIF 魔数的 JPEG 帧，以及同一流中的音频样本。该连接也未加密。该会话建立本身就是一个凭据广播。任何在打洞两端观察到该数据包的人都可获得设备和账户的长期令牌。由于媒体也未加密，路径上的任何人也能获取实时视频和音频。 这是被动侦察：读取流量、映射协议。要做到更多，我需要伪造请求，而签名函数位于设备上。这意味着固件。 ## 第二阶段：UART 无需询问便透露的内容 \# (https://www.abgeo.dev/blog/anyone-can-ring-your-doorbell#phase-2-what-the-uart-says-without-being-asked) 外壳已经打开，UART 对已经识别。为了便于访问，我焊接了细线到 TX 和 RX 焊盘。更干净的选择是使用 PCBite 探针，但我手头没有。 门铃 PCB 上 TX 和 RX UART 焊盘焊接的细线 细线焊接到电路板正面的 TX 和 RX 焊盘。线缆连接到 Flipper Zero 的 UART 桥接模式，主机上运行终端模拟器。门铃在事件之间深度休眠：按下按钮唤醒它，运行完整的应用程序循环，然后将其送回休眠。以下内容来自这样一个循环，从我按下门铃按钮的那一刻开始。 线路上首先出现的是启动横幅。固件版本、未经过滤的寄存器转储、RT-Thread 版权块，以及早期的 OTA 初始化失败： ``` BK7252N_1.0.14 REG:cpsr spsr r13 r14 SVC:0x000000D3 0xA4AAB8CC 0x22CA0058 IRQ:0x000000D2 0x00000010 0x227AA88D 0x48C9A634 ... [I/FAL] Fal(V0.4.0)success [E/OTA] (rt_ota_init:105) Initialize failed! The download partition(download) not found. [E/OTA] (rt_ota_init:115) RT-Thread OTA package(V0.2.8-beken-1133282d-20220604) initialize failed(-2). go os_addr(0x10000).......... \ | / - RT - Thread Operating System / | \ 3.1.0 build Jun 30 2025 2006 - 2018 Copyright by rt-thread team ``` 在操作系统完成启动之前，已有三个发现。生产固件在每个运行周期打印调试模式的寄存器转储。OTA 模块初始化失败，因为 `download` 分区缺失，设备没有空中升级路径。构建信息为 RT-Thread 3.1.0，日期 2025 年 6 月，Beken SDK 3.0.76。 等待 WiFi 关联后，设备打印出 SSID、PSK 以及在四路握手期间派生的成对密钥和组密钥： ``` _wifi_easyjoin: ssid: bssid:00:00:00:00:00:00 key = ... WPA: TK <32 hex chars> ... WPA: GTK <32 hex chars> ``` 任何通过 UART 访问该设备的人都可以获得家庭网络的名称、密码以及活跃的会话密钥。门铃上的 UART 访问门槛并不高：该设备通常安装在房屋前方，因此物理访问只需一把螺丝刀和几分钟安静的时间。这意味着一扇门铃即可导致整个网络沦陷。 一旦设备获得 IP 地址，即进行首次 HTTP 调用。这与第一阶段的警报请求相同，固件内联打印响应。`conf` 键的值也在此出现，其中两个标签位置错误： ``` [SOC_connectSockerDevice -237] Debug :CONNECT IP= PORT = 80 ... [cjson_api_for_device_config_pic_stun:1054] server port server pwd server host domain .naxclow.com ``` “server pwd” 行实际是中继主机的 IP。“server host” 行是设备的静态中继密码。值是正确的；标签不对。无论如何，它们都在线路上。 然后 STUN 协议开始运行。设备将整个与中继的 TCP 交换（双向）通过 JSON 格式镜像到 UART： ``` [start_stun_talk:78] CONNECT IP= PORT = . ```