内网“影子资产“：串口服务器安全盲区剖析

内网"影子资产"：串口服务器安全盲区剖析

从一台被忽略的 IoT 网关，看工业联网设备的结构性安全缺陷

关键词：内网安全 · IoT 安全 · 串口服务器 · 弱口令 · Modbus · OT 安全 · 影子资产

引子：你无法保护你不知道的东西

做安全的人大多认同一条朴素的道理——你无法保护你不知道的东西。

但现实中，内网的资产表几乎从来不是完整的。服务器、终端、网络设备通常会被纳入盘点，而有一类设备长期缺席：串口服务器、DTU、协议网关、工业路由器。它们不跑通用操作系统，装不了杀毒，不产生安全日志，也进不了域控，安静地蹲在机柜角落，干着"把串口信号搬上网"这种不起眼却关键的活。

我给这类设备起了个名字：影子资产。

它们平时无人问津，可一旦出事，往往就是内网里最短的那块木板。前段时间一次常规的内网资产梳理，让我和这样一台设备正面相遇——顺着它往下挖，我看到的远不止一个弱口令，而是一整类产品在安全设计上的结构性缺失。

一、扫出来一台"安静"的设备

资产梳理的第一步永远是主机发现。用常规手段对所在网段做完存活探测和端口扫描后，一台设备的表现有点"反常"：

• 它开放了80/tcp，但 HTTP 指纹不像任何常见的 Web 应用；
• 页面返回的是极其简单的静态 HTML，标题是厂商名；
• 除了 Web 管理端口，几乎没有其他暴露面。

进一步做服务指纹识别，结果指向一个熟悉又容易被忽视的身份——某国产厂商的 USR-TCP232 系列串口服务器。

这类设备的定位很清晰：把 RS232/RS485 串口信号双向转换成 TCP/IP 网络数据，让那些只有串口、没有网口的老设备也能接入以太网。在工业现场、能源、交通、广电等场景里，它是再常见不过的"协议翻译官"。

正因为太常见、太不起眼，它几乎从不出现在安全团队的关注清单上。

二、第一道门：形同虚设的默认口令

出于对这类设备"出厂即默认配置"的刻板印象，我做了个再常规不过的尝试——用厂商的标准出厂凭据去登录。

一次就进去了。

管理界面的功能比我预想的要"丰富"：

从"看设备是不是活着"到"改它的网络方向、串口参数、管理密码"，一整套管理权限，全部拿到了。

到这一步，其实还只是**“默认口令未修改”**这个老生常谈的问题——说它严重，也谈不上多新鲜的发现。

真正的"惊喜"，在下一步。

三、密码就写在网页源码里

出于习惯，我顺手看了一眼管理页面的前端源码。在system.shtml里，一行 JavaScript 让我停了下来：

// system.shtml 内嵌脚本（节选）varuname='admin';varupwd='admin';

管理员用户名和密码，就这么硬编码在前端页面的脚本里，页面加载时直接赋给表单字段。

也就是说——哪怕没人改过密码，攻击者也不需要"猜"。打开页面源码，密码就在那里。

这和"默认口令未修改"是两回事。前者是运维问题，后者是产品设计缺陷。用安全术语来说，这属于CWE-798：硬编码凭据。

而巧的是，该厂商另一款更主流的型号，正是因为完全同类的设计缺陷被公开披露：

• CVE-2026-7786（CVSS9.8，严重）：固件镜像中内嵌明文管理员凭据，可通过固件分析提取并用于认证；
• CVE-2026-25715（CVSS9.8，严重）：允许将管理员用户名和密码设为空值，导致所有关键管理通道认证失效。

模式几乎一模一样，只是"暴露的位置"不同：一个在固件二进制里，一个在 Web 前端脚本里。

四、从头到尾的"明文"

继续往下看协议层，情况只会更糟。这台设备在数据链路上，从头到尾没有一丁点加密。

4.1 Web 管理：只有 HTTP，没有 HTTPS

管理界面清一色走 HTTP。虽然用了 Basic 认证，但 Basic 认证只是 Base64 编码、并非加密——同一网段里，用抓包工具就能直接还原出用户名和密码。更"贴心"的是，密码字段在管理页面上是明文回显的（对应同厂商 CVE-2026-26049，密码明文显示）。

4.2 串口透传：TCP 数据零加密

从端口参数页面可以看到，设备当前工作在TCP Client模式，串口数据被原样打包成 TCP 报文发往目标地址，中间没有任何加密或完整性保护。

这意味着：串口线上跑的一切，在网络上都是裸奔的。任何能触及这条链路的设备，用tcpdump或 Wireshark 就能完整窥探串口通信内容——如果串口那头连的是控制系统，攻击者拿到的不只是数据，还有整套控制逻辑和指令格式。

顺带一提，目标地址还停留在出厂默认的占位 IP 上（且通信量为 0），说明这台设备其实还没真正接上业务链路——它是一颗还没引爆、但已经上了膛的子弹。

4.3 Modbus：协议层面的先天缺陷

设备支持完整的 Modbus TCP/RTU 网关功能（当前处于关闭状态）。而 Modbus 协议本身就是个"重灾区"：

这些不是某家厂商的锅，而是 Modbus 在 1979 年被设计时的时代局限——它假设网络是物理隔离、完全可信的。可今天的网络早已不是了。2024 年造成实际物理破坏的FrostyGoop恶意软件，就是靠标准 Modbus 命令直接篡改供暖系统设定值，全程没用任何 0day。

对一个随时能通过 Web 界面改动设备的攻击者来说，一旦 Modbus 被启用，这台串口服务器就从"内网设备"变成了通往 OT 网络的桥头堡。

五、这不是孤例：公开情报佐证

把视野拉高到整个产品系列，会发现这类问题早已被业界反复记录：

更值得警惕的是，USR-W610 已被 CISA 发布 ICSA 安全公告，厂商明确表示产品已 EOL（停止服务），无任何补丁计划。

也就是说，这批设备将永久带着高危缺陷继续服役。

而本次遇到的设备，其缺陷模式与上述 CVE 高度重合——硬编码凭据、明文传输、明文回显密码。它没有被单独编号，只是因为还没人正式提交，不代表它更安全。

六、为什么这类设备总在"踩雷"

单个设备的问题，可以归咎于某次偷懒的部署。但当整个品类都反复出现同类缺陷时，就该反思背后的结构性原因了：

1. 成本与周期导向的设计。这类设备单价低、迭代快，安全往往被排在功能、兼容性、成本之后。加密要算力、要证书管理，能省则省。

2. "默认可用"的出厂哲学。出厂密码统一、界面不做强制改密，是为了降低现场部署门槛。方便了工程师，也方便了攻击者。

3. 超长生命周期，且无补丁机制。工业设备动辄服役十年以上，很多根本不提供固件升级通道（本次设备的管理界面甚至没有固件上传入口），发现问题也无从修复。

4. 网络边界模糊。这类设备经常被"随手接入"——一根网线连上就完事，既不在资产台账里，也没人给它做安全基线。它游离在管理边界之外，成了名副其实的影子资产。

5. 安全责任不清。IT 团队管不到它，OT 团队不了解它，厂商不负责它——最后谁都不管。

七、防御视角：如何管好内网的"哑设备"

针对这类设备，我整理了四层可落地的建议：

① 资产层：先把它找出来

• 用主动扫描 + 被动流量分析识别内网中的 IoT/OT 设备，尤其是串口服务器、DTU、网关；
• 建立专门台账，记录型号、固件版本、用途、责任人，别再让它"隐身"。

② 网络层：隔离与收敛

• 将这类设备划入独立 VLAN，与办公网、业务网严格隔离；
• 在边界防火墙上配置白名单，只允许管理员 IP 访问其管理端口；
• 修改默认管理端口，降低自动化扫描的命中率。

③ 设备层：加固配置

• 立即修改默认口令为强密码（12 位以上，大小写+数字+特殊字符）；
• 关闭一切用不到的协议（如本例中的 Modbus、UDP 设备发现服务）；
• 关注厂商固件更新，若产品已 EOL，评估替换计划。

④ 管理层面：机制保障

• 把 IoT/OT 设备纳入安全基线和定期巡检范围；
• 对新接入设备实行"默认拒绝"——未登记、未加固的设备一律不得入网；
• 保留串口链路的数据审计手段，及时发现异常通信。

结语：影子资产，考验的是管理的颗粒度

这次分析的起点，只是一个弱口令；但往下挖，挖出的是硬编码凭据、明文传输、零认证协议这一整套结构性缺陷，以及背后一整个品类的安全现状。

它提醒我们两件事：

其一，安全短板往往不在最显眼的地方。服务器和终端有 EDR、有补丁、有基线，反而是这些不起眼的"哑设备"，成了内网里最柔软的下腹。

其二，IoT/OT 安全的核心不是某个漏洞，而是可视性与治理能力。只有当这些影子资产真正被"看见"、被纳入管理，后续的一切防护才有意义。

所以下次做资产梳理时，别只盯着那些会"说话"的设备。那些最安静的，往往才是最危险的。

本文基于一次常规内网资产梳理的技术观察整理，涉及的环境坐标、业务场景均已脱敏处理。文中所涉漏洞编号均来自公开漏洞库（NVD / CNVD / CISA ICS Advisories），技术分析仅用于安全防护研究。