文章总结： Forescout团队在BlackHatUSA2026披露TP-LinkOmadaZTP信任链的13个CVE，涉及硬编码密钥、弱凭据、证书复用、客户端劫持、存储型XSS和CORS绕过。攻击者可冒充控制器或客户端，获取全网配置。建议用户启用MFA、更换默认密码、及时更新固件。 综合评分： 95 文章分类： 漏洞分析,渗透测试,iot安全,web安全,红队

Zero-Day 配置：TP-Link ZTP 信任链上的 13 个 CVE

原创

AIxSec69 AIxSec69

AIxSec69

2026年8月24日 21:54 中国香港

在小说阅读器读本章

去阅读

Zero-Day 配置：TP-Link ZTP 信任链上的 13 个 CVE

来源：Black Hat USA 2026 Briefings

标题：Zero-Day Provisioning: Chaining TP-Link ZTP Vulnerabilities for Infiltrating Networks

作者：Stanislav Dashevskyi、Francesco La Spina（Forescout）

适合读者：网络基础设施安全工程师、IoT/网络设备安全研究者、企业网络管理员、安全评估团队

简介：TP-Link Omada 的 Zero-Touch Provisioning（ZTP）让交换机、路由器和 AP 插电即可自动加入网络。但”零接触”也意味着攻击者的零接触：Forescout 团队逆向 Omada 协议后，发现整条信任链从加密到证书到认证都建立在硬编码密钥和模糊性之上。17 个问题、13 个 CVE，覆盖协议 V1/V2 的弱凭据、可复用的证书私钥、客户端劫持、存储型 XSS 与 CORS 绕过——攻击者既能冒充控制器接管未配置设备，也能冒充客户端从云端偷走全网配置，还能顺着这条信任链摸到 TP-Link 的 Festa、Tapo、Kasa、VIGI 整个产品家族。

◆ ◆ ◆

Zero-Touch Provisioning（ZTP，零接触配置）是个听起来很美的功能：设备插电、联网、自动从控制器拉取配置、自动加入网络，全程不需要管理员碰它。在企业部署 500 台交换机时，它救了很多 IT 人的周末。

但它也带来了安全研究者很难抗拒的吸引力：ZTP 依赖一条极强的信任链——控制器和设备之间、云和本地之间、固件里藏着的密钥和证书之间。 集中管理意味着单点故障，而且 ZTP 没有统一的协议标准。Forescout 的 Stanislav Dashevskyi 和 Francesco La Spina 在这条信任链上挖出了 17 个问题、13 个 CVE，结论是：ZTP 用它换来的”易用性”，把安全性押在了模糊性上。

一套 ZTP 系统只有两个主要组件：客户端设备（需要被配置和管理的交换机、路由器、Wi-Fi AP、网关）和控制器（负责配置、监控、更新客户端设备的专用硬件或软件平台）。攻击者的所有思路，都围绕着”这两者之间的信任从何而来”展开。

▲ ZTP 基础模型：客户端设备（交换机/路由器/AP/网关）与控制器（云/本地硬件/软件）之间的零接触配置（来源：Black Hat USA 2026 Slides）

目标：TP-Link Omada

Omada 是 TP-Link 面向中小企业（SME）的 ZTP 生态：支持云托管、本地硬件控制器（OC200）、本地软件控制器（虚拟机），也可以混合部署。

选择它的理由很现实：

– 攻击面大且研究少——TP-Link 全球部署量大、客户基础广，Omada 是中小企业广泛采用的 ZTP 生态，但公开安全研究很少；过去公开的漏洞大多在客户端设备上，控制器侧基本是空白。

– 功能丰富、性价比高——对中小企业来说，Omada 与 Ubiquiti、Cisco 相比硬件好、易部署、价格有竞争力，这意味着它有真实的存量用户。

逆向 Omada 协议

研究者买了两条路同时逆向：一边是 ER7206/ER605 Omada 网关（客户端），一边是 OC200 硬件控制器和 Java 写的软件控制器。

客户端方向：没有 root 权限装不了调试器，只能做静态分析。客户端设备的 Web UI 基于 OpenWRT 的 LuCi 构建，研究者还得先反混淆 Lua 字节码——这本身就很费功夫。逆向的结果是两条独立于主研究的漏洞：CVE-2025-7851（Cisco Talos 的 CVE-2024-21827″残留调试代码”修复不充分）和 CVE-2025-7850（通过 Web UI 的 WireGuard VPN 设置进行已认证 OS 命令注入）。

控制器方向：硬件和软件控制器都成了协议分析对象，客户端和控制器之间的通信协议被完整还原。

Omada 消息格式

• 自定义协议，UDP 和 TCP 负责传输，TLS 负责加密；

• 每条消息是一个 JSON payload，前面加 4 字节网络字节序的长度前缀；

• 协议分多个阶段：Discovery（发现）、Adopt（采用）、Manage（管理）、Reset（重置）、Prelink、Rebuilt 等；

• 这些协议和其他（非 Omada）TP-Link 设备用的协议有相似之处。

Discovery：本地与云端

– 本地发现走 UDP 广播：客户端广播基本信息（序列号、MAC 地址、型号、版本），控制器回应类似信息外加用于 Adoption 的 IP/端口。

– 云端发现走 TCP/TLS：交换类似信息，但客户端会去联系 Omada Cloud 主机。

研究者特别指出一个关键细节：当网络里没有本地控制器时，Omada 设备仍然持续广播 Discovery 消息——这为远程攻击留了门。

Adoption V2：看起来双向，其实偏颇

Adoption（采用）是 ZTP 的核心阶段，V2 版本走 TCP/TLS，本地和云端没有实质差别。它的认证流程是：

1. TLS 握手阶段只有客户端验证控制器的身份；

2. 客户端向控制器认证（自定义 challenge-response）：控制器发一个”随机”认证挑战，客户端用两轮哈希回复自己的凭据，第二轮用挑战做盐——不是标准 HMAC；

3. 控制器向客户端认证：客户端发自己的”随机”挑战，控制器用两轮哈希回复设备凭据；

4. 之后控制器读取当前配置并推送新配置：主配置是网络设置和”站点凭据”，次配置是模块（WireGuard VPN 等）。客户端到此被成功采用。

▲ Adoption V2 协议流程：TLS 下双向 challenge-response 认证 + 配置推送，但只有客户端验证控制器身份（来源：Black Hat USA 2026 Slides）

问题就藏在”看起来双向”的认证里。三处独立的漏洞分别砍向这个流程的不同环节。

13 个 CVE：信任链逐环断裂

协议 V1：硬编码密码学（CVE-2025-15627）

V1 是旧协议，但仍然存在于最新的客户端里，而且控制器可以强制客户端降级到 V1。V1 用非对称加密做认证和会话密钥交换，对称加密保护数据——但：

• 非对称密钥是硬编码的：公钥放在客户端固件里，私钥混淆在控制器软件里；

• 会话密钥熵不足（CVE-2025-15629）：攻击者可以解密流量、拿到凭据。

V1 的认证就是 username + md5sum(password) 再套一层——密码学上的每一个决定都是坏决定。

协议 V2：不安全的凭据（CVE-2025-9290、CVE-2025-15544）

V2 的认证公式是：

AUTH\_dev = sha256sum(sha256sum(username + md5sum(password)) + randomKeyForDeviceVerify)

MD5 的不安全性叠加两次哈希，没有意义。更糟的是 CVE-2025-15544：控制器不验证客户端的身份。这意味着攻击者完全可以伪造一个客户端，而且真实客户端没法证明”我是我”。

默认凭据（FSCT-2025-008）

一台全新的客户端永远有默认凭据 admin/admin。 这带来一个推论：

• 如果攻击者伪造控制器，总能知道一台客户端是否还停在默认凭据上；

• 如果攻击者伪造客户端且被控制器接受，总能凭默认凭据认证。

更”划算”的是：被采用的设备会收到站点凭据——攻击者免费拿到整个站点的凭据。

信任链断裂：本地（CVE-2025-15628）

V2 的流量是加密的，客户端也验证控制器的身份（TLS），看起来是标准 PKI：

• Root 证书自签名、作为 Root CA 导入客户端 keystore；

• Intermediate 证书由 Root 签名，导入控制器 keystore；

• Server 证书被控制器和客户端用于 TLS。

但整条链是硬编码的：

• 所有证书的过期日期都是硬编码的；

– 控制器有一个硬编码的私钥，用在 TLS 上；

• 控制器的 Server 证书足以通过客户端的身份检查——攻击者可以复用控制器的 Server 证书和私钥。

也就是说，只要能接触一个本地控制器，攻击者就拿到了一个可以冒充任意控制器的完整身份。

▲ 信任链断裂：证书层级硬编码，控制器持有用于 TLS 的硬编码私钥——攻击者复用 Server 证书和私钥即可通过客户端的身份检查（来源：Black Hat USA 2026 Slides）

唯一的例外是云控制器：它必须出示一个 CN 以 tplinkcloud.com 结尾的证书，攻击者伪造不了。

信任链断裂：云端（CVE-2025-9291）

云端的证书链同样硬编码，但 CN 检查有绕法。这个漏洞用了一个经典的标点玩笑来解释：

• “Let’s eat, Grandma!”（让我们吃饭，奶奶！）和

• “Let’s eat Grandma!”（让我们吃奶奶！）

标点位置不同，语义完全不同。攻击者利用公共 IP 绕过 CN 检查——证书校验的语义被一个可以伪装的字段绕过了。

客户端枚举（FSCT-2025-003、FSCT-2025-011）

通过云采用客户端时，攻击者只需要知道序列号（S/N），不需要所有权证明。而序列号是顺序的，可以用 Omada Cloud API 批量获取，型号和 MAC 还能从 S/N 推断出来——极其容易被暴力破解。

客户端劫持（CVE-2025-15630）

云端采用流程里，客户端先联系 Default Controller，Default Controller 再把 Regional Controller 的 URL 发过去。关键缺陷是：

Discovery 阶段和 Adoption 阶段不绑定在同一个状态机里。

攻击者可以替客户端发起 Adoption 阶段——连 Discovery 请求都不用等到。一个伪造的客户端会被采用、出现在管理员的 Web UI 里。攻击者还能用伪造客户端刷爆云端控制器。

存储型 XSS（CVE-2025-9289）

控制器 Web UI 会展示已采用客户端的属性，而 UI 更新客户端信息时用了旧版 jQuery 的 eval()。研究者指出，由于严格的内容安全策略（CSP），这里能做的有限——但这为下一步铺了路。

CORS 绕过（CVE-2025-9292）

Omada Cloud 跑在 AWS 上。研究者检查了云端控制器的 CSP，发现默认 CSP 里有些片段允许向 AWS 上托管的任何东西发起跨站请求。XSS 加上 CORS 绕过，组合出完整的前端攻击面。

两种攻击场景：从本地到外部

本地攻击：中间人接管

攻击者位于受害者局域网内时：

1. 拦截客户端的 Discovery 请求（UDP 广播），作为伪造控制器响应；

2. 把修改过的 Discovery 请求转发给真实控制器，同时冒充伪造客户端；

3. 真实控制器响应攻击者，攻击者从此可以拦截、修改、转发真实控制器和真实客户端之间的所有通信（CVE-2025-15628 / 15544 / 9290）。

▲ 本地攻击场景：拦截 Discovery 广播冒充控制器，转发给真实控制器冒充客户端，成为两者之间全通信的中间人（来源：Black Hat USA 2026 Slides）

影响：获取并篡改敏感信息（如设备配置），接管客户端。

外部攻击：竞态条件与云端钓鱼

攻击者位于受害者网络之外，利用的是采用流程的竞态条件：

1. 收集 MAC 地址（Omada API 或暴力破解），冒充一台尚未被采用的客户端；

2. 每 60 秒重发一次冒充消息——攻击 1000 个 MAC 只需要每秒约 17 个请求，然后等待设备被采用；

3. 拿到原设备被供给的配置；

4. 用存储型 XSS/CSP 绕过钓鱼管理员，窃取云账号凭据。

▲ 外部攻击场景：用竞态条件冒充未采用的客户端，拿到配置后借存储 XSS/CSP 绕过钓鱼管理员、窃取云账号凭据（来源：Black Hat USA 2026 Slides）

影响：获取敏感信息（哈希过的站点凭据、VPN 密钥等）；通过窃取的云凭据修改设备配置、修改防火墙规则、加 VPN 进内网、从站点设置里拿站点凭据。

信任链问题，比 Omada 更严重

最后一块拼图是 CVE-2025-9293：同一条信任链被用在大量 TP-Link 产品家族里——Omada、Festa、Tapo、Kasa、VIGI、以及 Aginet、Deco、KidShield、Tether、tpCamera、Wi-Fi Navi、WiFi Toolkit 等一堆 Android 应用。研究者演示了从 Android 应用的 TLS 连接里嗅出凭据。

一个厂商的坏设计选择，变成十几条产品线共享的漏洞——补丁窗口因此拉得极长，用户在整个期间持续暴露。

披露时间线：300 天的拉锯

研究的披露过程也值得一看：

• 17 个上报的问题里，13 个获得 CVE；

• 第一批补丁是 CVE-2025-7851 和 CVE-2025-7850（客户端方向的两个）；

• FSCT-2025-003 和 FSCT-2025-011 因需要系统级架构变更，至少 394 天没有补丁；厂商以其 CVSS 评分低为由不为其分配 CVE ID；

• 默认密码问题（FSCT-2025-008）最终没有修复；

• 所有修复计划耗时超过 300 天。

▲ 披露时间线：17 个问题、13 个 CVE，默认密码未修复，架构级问题 394+ 天无补丁，全部修复计划超过 300 天（来源：Black Hat USA 2026 Slides）

教训

给厂商：

– 密码学是工程，不是创作过程——遵循标准、用经过验证的算法、提前规划 PKI。硬编码密钥、”自创”哈希、两轮 MD5 套壳，这些都是”安全通过模糊性”的典型形态，而模糊性从来不生效；

– 坏设计选择的代价是长期的——一个共享的信任链拖垮十几条产品线，超长的补丁窗口让用户持续暴露。

给用户：

• 如果你在用任何 ZTP 平台：启用所有能启用的安全措施——MFA、不用默认密码、频繁轮换密码和密钥、及时更新设备。

研究者用一句话收尾这场演讲的核心观察：改进可用性，常常会牺牲安全性。 ZTP 的”零接触”省掉了管理员的手动配置，也省掉了管理员对每一台设备的信任判断——而这条信任链的每一环，都被 TP-Link 硬编码的密钥和模糊性的伪装撑起来了。

◆ ◆ ◆

原文链接：https://www.blackhat.com/us-26/briefings/schedule/#zero-day-provisioning-chaining-tp-link-ztp-vulnerabilities-for-infiltrating-networks-51879

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AIxSec69 AIxSec69 AIxSec69《Zero-Day 配置：TP-Link ZTP 信任链上的 13 个 CVE》