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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一次就进去了。

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

菜单	功能
Current Status	设备状态、型号、固件版本、通信统计
Network parameters	IP、掩码、网关、DNS 配置
Port Parameter	波特率、数据位、校验位、工作模式、目标地址
Modbus	Modbus TCP/RTU 网关配置、预置指令
System Parameters	设备名、管理端口、登录用户名与密码
Module Management	重启、恢复用户默认参数、恢复出厂设置

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

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

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

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

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

javascript 复制代码

// system.shtml 内嵌脚本（节选）
var uname = 'admin';
var upwd  = 'admin';

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

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

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

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

CVE-2026-7786 （CVSS 9.8，严重）：固件镜像中内嵌明文管理员凭据，可通过固件分析提取并用于认证；
CVE-2026-25715 （CVSS 9.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 TCP
认证	❌ 无
加密	❌ 无
授权	❌ 无（读/写无区分）
完整性校验	❌ 仅靠 TCP 校验和
重放防护	❌ 无

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

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

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

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

漏洞编号	影响产品	CVSS	类型
CNVD-2020-02275	USR-TCP232-410S	10.0	拒绝服务
CVE-2026-7786	USR-W610	9.8	硬编码凭据 (CWE-798)
CVE-2026-25715	USR-W610	9.8	弱密码要求（空凭据）
CVE-2026-24455	USR-W610	7.5	HTTPS/TLS 缺失 (CWE-319)
CVE-2026-26049	USR-W610	5.7	密码明文回显 (CWE-522)

更值得警惕的是，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），技术分析仅用于安全防护研究。