Deco XE75 Pro V3 — 所有者认证的调试通道：任意 root 文件写入

配套 VLAN 项目：针对确切 XE75 Pro V3 固件/配置文件的实验性固定 VLAN-30 源码 alpha 版本。它需要操作员提供原厂文件，且没有通用安装程序或可刷写镜像。访客 VLAN 591 仍未解决；最终三单元冷启动、UI 和客户端隔离验收尚未完成。 参见当前状态。

研究披露，TP-Link Deco XE75 Pro V3，固件 1.5.0 Build 20260603 Rel.15804。为 [email protected] 准备，并与我们的 802.1Q IoT VLAN 实现（deco-iot-vlan）一同公开发布。

摘要

Deco 的所有者认证调试 SSH 通道（TCP 20001 上的 Dropbear，仅 direct-tcpip 转发，密码认证）可访问 127.0.0.1:20002 上的内部 tmpsvr 服务。其 Lua 处理器之一 inner_file_push（操作码 0xC456）以 "w" 模式打开 params.file，并以 root 身份原样写入 params.content，没有路径允许列表、没有大小限制、也没有权限降级。一个同级操作码（0xF0）提供匹配的 root 文件读取。两者结合：认证后的整个 root 文件系统读写，而在路由器上这就是整个设备。

SSH :20001  (username = SHA1(owner_email), password = TP-Link account password)
  -> direct-tcpip -> 127.0.0.1:20002 (TMPv2)
     -> 0xC456 inner_file_push : io.open(file,"w"); write(content); close()   [root]
     -> 0x00F0 root file read  : byte-exact file read                          [root]

影响（实机验证，非破坏性）

• /etc/config 是一个可实时写入的 ramfs → 修改某个键值后，路由器会采纳该改动。
• /www 由 uhttpd 通过 HTTPS 提供服务 → 推送的文件可立即访问。
• /tp_data/user_data 是持久化的 ubifs 闪存 → 重启后仍然保留。
• LuCI 路由缓存可被攻击者的 Lua 替换，通过 GET /cgi-bin/luci 触发 → 以 root 执行 Lua → io.popen → 以 root 执行任意 二进制文件。

全部四个步骤均已在所有者自己的主设备上执行并回滚。

为何这是新发现——以及为何 tmpsvr 在 CCS'24 / Black Hat '24 两年后仍未修复

UCR SecLab 团队两年前在 CCS 2024 — "Untangling the Knot: Breaking Access Control in Home Wireless Mesh Networks"（以及 Black Hat USA 2024 — "Fallen Tower of Babel"）中公开记录了 :20001 -> 127.0.0.1:20002（tmpsvr）调试通道。他们在较旧 Deco 型号（X55，固件 1.2.2）上的入口点是分解 512 位 RSA 主机密钥并滥用未经验证的 tmpsvr 处理程序。

在此确切固件上观察到的差异及仍然存在的处理程序：

• 他们将 ssh-rsa 主机密钥大小从 512 位增加到 2048 位（在所有三个 mesh 单元上观察到同一共享密钥，SHA256:9feb3ac4...932a36，外加每单元的 ecdsa-sha2-nistp521），从而关闭了 2024 年演讲中提到的 512 位分解路径。
• 以下 root 级处理程序存在于固件 1.5.0 中：
  1. :20001 上的密码认证（svr_auth_uci） 仍然有效，使用 SHA1(owner_email) + 共享的 TP-Link ID 密码。
  2. 操作码 0xC456（inner_file_push） 仍以 root 身份以 "w" 模式打开任意调用者提供的路径，且零路径验证。
  3. 操作码 0x00F0 仍以 root 身份读取文件系统上的任意文件。
  4. 甚至操作码 0xC505（tty2tcp/start）——2024 年论文中重点指出的那个未加引号的 /bin/sh -c 命令注入处理程序——在 2026 年 6 月的固件（1.5.0）中仍然完全未修复。

受影响范围（观察结果）

• 产品：TP-Link Deco XE75 Pro V3（3 单元 mesh；一个主单元 + 两个从单元）
• 固件：1.5.0 Build 20260603 Rel.15804
• 攻击面：可从 LAN 访问的 TCP 20001（调试 SSH）；该处理程序位于 提取的 1.5.0 用户空间中（luci/controller/admin/mobile_app/iot_device 模块，inner_file_push）。

严重性（CVSS v3.1 + v4.0）

仅演示了 LAN 可达性。对于观察到的仅 LAN 场景， 我们使用 AV:A 变体：v3.1 6.8 / v4.0 8.5。下方的 AV:N 评分以已演示的网络路径为条件； 云可达性尚未验证。

这是一个认证后、所有者权限提升至 root 的漏洞——并非未认证 RCE——下方观察场景的评分为 6.8（v3.1）和 8.5（v4.0）。完整理由及 被拒绝的虚高评分见 docs/cvss-analysis.md。

CVSS v3.1 — 仅 LAN 评估 6.8（中危）；条件性远程变体 7.2（高危）：

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H   = 7.2 (High)
CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H   = 6.8 (Medium)   # if LAN-only

决定性判定：PR:H（所有者 / TP-Link-ID 账户是该设备的管理主体）和 S:U（处理程序已以 root 身份运行——未跨越权限边界）。早先的草案通过 PR:L + S:C 评分为 9.9；两者均被否决。

CVSS v4.0 — 仅局域网评估 8.5（高）；条件性远程变体 8.6（高）：

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N   = 8.6 (High)
CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N   = 8.5 (High)       # if LAN-only
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L   = 9.3 (Critical)   # with Subsequent-System LAN/mesh impact

现实世界中的风险——被盗用/复用的 TP-Link-ID 密码转化为整个 mesh 上的持久 root 权限，外加客户端流量 MITM——应归入叙述部分（以及 v4.0 的 SC:H/SI:H/SA:L Subsequent-System 指标），而不是塞进一个虚高的 v3.1 基础向量中。

概念验证

poc/deco_filepush_poc.py —— 自包含（标准库 + paramiko）。凭据仅通过 DECO_EMAIL / DECO_PASSWORD 环境变量提供。实时模式需要 DECO_HOSTKEY，并需独立验证：原始 base64、公钥行，或一行 ssh-keyscan 密钥行（支持注释）。仅靠扫描并不能对设备进行身份验证。HTTPS 检查会比较所提供服务的字节，但不验证其证书。必须且只能指定一种模式；验证失败时以非零状态退出。

python3 poc/deco_filepush_poc.py --selftest        # offline framing sanity
[email protected] DECO_PASSWORD=*** DECO_HOSTKEY="$TRUSTED_DECO_HOSTKEY" \
  python3 poc/deco_filepush_poc.py --run           # write marker + readback + HTTPS check
[email protected] DECO_PASSWORD=*** DECO_HOSTKEY="$TRUSTED_DECO_HOSTKEY" \
  python3 poc/deco_filepush_poc.py --cleanup <nonce>   # overwrite marker with empty content

PoC 会向 /www/log_export（ramfs；重启后也会被清除）写入一个无作用的标记文件，然后要求通过设备自身的 root 读取操作码进行逐字节精确回读，并且HTTPS 服务未被修改，才会报告成功。

复现摘要（实机，2026-10-17）

1. ssh-keyscan -p 20001 <deco> → 固定主机密钥（2048 位 RSA，在整个 mesh 中共享，外加每台设备的 nistp521）。
2. 使用 SHA1(owner_email) / TP-Link 账户密码进行 SSH 连接，请求 direct-tcpip 到 127.0.0.1:20002。
3. TMPv2 关联（01010100 → 01010200 → 01010200），然后请求操作码 1 的令牌。
4. 操作码 0xC456，{"params":{"file":"/www/log_export/deco-write-<nonce>.html", "content":"..."}} → {"error_code":0,...}。
5. 操作码 0xF0，{"params":{"file":"..."}} → 逐字节精确回读。
6. GET https://<deco>/log_export/deco-write-<nonce>.html → 200，字节完全一致。

范围 / 诚实声明

• 所有者自己的硬件，所有者自己的凭据。
• 非破坏性：单个标记文件，逐字节精确恢复，已验证回滚。
• 在主设备上演示；同一处理程序存在于整个 mesh 的提取 1.5.0 用户空间中。
• tty2tcp（0xc505）路径已确认存在且未验证（静态），但未作为单独的注入进行实机验证；为完整性起见列出。

为何公开发布（防止电子垃圾与网络安全的权利）

这项研究始于一个简单的防御性目标：将不受信任的 IoT 设备隔离到一个带标签的 802.1Q VLAN 上，跨 3 台以接入点模式运行的 Deco XE75 Pro V3 mesh。

在 2026 年，基本的网络分段（将 IoT 设备放在隔离的 VLAN 上）是一项基本的安全要求——然而在出厂固件 1.5.0 上，该功能被人为地留作未完成状态（/lib/iot_network/iot_eth.sh 从 rootfs 中被省略，/etc_ro/init.d/iot_network 中的 VLAN 逻辑被注释掉）。这留下了一个 stark 的选择：要么把三台完全可用的 Wi-Fi 6E mesh 路由器当作电子垃圾扔掉，要么逆向工程固件并自行修补缺失的功能。

我们选择公开发布这份安全公告和配套的 VLAN 实现（deco-iot-vlan），以便：

1. 每位 Deco 所有者都能立即采取防御措施（设置强且唯一的 TP-Link ID 密码，并在其 LAN/VLAN 上限制 TCP 端口 20001，而不是对暴露的 root 文件写入接口一无所知）。
2. 所有者可以为其现有的 Deco 硬件配备适当的 802.1Q IoT VLAN 分段，而不是在基本安全功能被扣留时将可用的硬件变成电子垃圾。

文件

• README.md — 本文件
• TEAM-SUMMARY.md — 多智能体团队（claude、codex、gemini 和 hermes/Qwen）如何发现它
• poc/deco_filepush_poc.py — 自包含 PoC
• docs/cvss-analysis.md — 评分理由 + 回退矩阵
• docs/handler-source.md — 反编译的 inner_file_push 处理程序 + 参考资料
• tp-link-email.md — 供应商报告草稿；交付未验证
• reddit-post.md — 社区帖子草稿

致谢

由所有者驱动的独立逆向工程。可应要求分享完整的反编译模块、离线帧推导和 mesh 主机密钥清单。