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

内网影子资产串口服务器安全盲区剖析从一台被忽略的 IoT 网关看工业联网设备的结构性安全缺陷关键词内网安全 · IoT 安全 · 串口服务器 · 弱口令 · Modbus · OT 安全 · 影子资产引子你无法保护你不知道的东西做安全的人大多认同一条朴素的道理——你无法保护你不知道的东西。但现实中内网的资产表几乎从来不是完整的。服务器、终端、网络设备通常会被纳入盘点而有一类设备长期缺席串口服务器、DTU、协议网关、工业路由器。它们不跑通用操作系统装不了杀毒不产生安全日志也进不了域控安静地蹲在机柜角落干着把串口信号搬上网这种不起眼却关键的活。我给这类设备起了个名字影子资产。它们平时无人问津可一旦出事往往就是内网里最短的那块木板。前段时间一次常规的内网资产梳理让我和这样一台设备正面相遇——顺着它往下挖我看到的远不止一个弱口令而是一整类产品在安全设计上的结构性缺失。一、扫出来一台安静的设备资产梳理的第一步永远是主机发现。用常规手段对所在网段做完存活探测和端口扫描后一台设备的表现有点反常它开放了80/tcp但 HTTP 指纹不像任何常见的 Web 应用页面返回的是极其简单的静态 HTML标题是厂商名除了 Web 管理端口几乎没有其他暴露面。进一步做服务指纹识别结果指向一个熟悉又容易被忽视的身份——某国产厂商的 USR-TCP232 系列串口服务器。这类设备的定位很清晰把 RS232/RS485 串口信号双向转换成 TCP/IP 网络数据让那些只有串口、没有网口的老设备也能接入以太网。在工业现场、能源、交通、广电等场景里它是再常见不过的协议翻译官。正因为太常见、太不起眼它几乎从不出现在安全团队的关注清单上。二、第一道门形同虚设的默认口令出于对这类设备出厂即默认配置的刻板印象我做了个再常规不过的尝试——用厂商的标准出厂凭据去登录。一次就进去了。管理界面的功能比我预想的要丰富菜单功能Current Status设备状态、型号、固件版本、通信统计Network parametersIP、掩码、网关、DNS 配置Port Parameter波特率、数据位、校验位、工作模式、目标地址ModbusModbus TCP/RTU 网关配置、预置指令System Parameters设备名、管理端口、登录用户名与密码Module Management重启、恢复用户默认参数、恢复出厂设置从看设备是不是活着到改它的网络方向、串口参数、管理密码一整套管理权限全部拿到了。到这一步其实还只是**“默认口令未修改”**这个老生常谈的问题——说它严重也谈不上多新鲜的发现。真正的惊喜在下一步。三、密码就写在网页源码里出于习惯我顺手看了一眼管理页面的前端源码。在system.shtml里一行 JavaScript 让我停了下来// system.shtml 内嵌脚本节选varunameadmin;varupwdadmin;管理员用户名和密码就这么硬编码在前端页面的脚本里页面加载时直接赋给表单字段。也就是说——哪怕没人改过密码攻击者也不需要猜。打开页面源码密码就在那里。这和默认口令未修改是两回事。前者是运维问题后者是产品设计缺陷。用安全术语来说这属于CWE-798硬编码凭据。而巧的是该厂商另一款更主流的型号正是因为完全同类的设计缺陷被公开披露CVE-2026-7786CVSS9.8严重固件镜像中内嵌明文管理员凭据可通过固件分析提取并用于认证CVE-2026-25715CVSS9.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-02275USR-TCP232-410S10.0拒绝服务CVE-2026-7786USR-W6109.8硬编码凭据 (CWE-798)CVE-2026-25715USR-W6109.8弱密码要求空凭据CVE-2026-24455USR-W6107.5HTTPS/TLS 缺失 (CWE-319)CVE-2026-26049USR-W6105.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技术分析仅用于安全防护研究。