飞牛fnOS路径穿越漏洞深度解析：从原理到实战加固

1. 项目概述：一次惊心动魄的飞牛fnOS安全漏洞应急响应

作为一名在NAS和家庭服务器领域折腾了十多年的老玩家，我经历过各种系统崩溃、数据丢失，但像这次飞牛fnOS爆出的高危路径穿越漏洞（Path Traversal）这样，直接让超过30万台设备在公网上“裸奔”的事件，还是头一遭。这不仅仅是某个功能的小Bug，而是一个足以让攻击者读取你所有私钥、照片、文档，甚至将你的设备变成DDoS肉鸡的“核弹级”漏洞。整个事件从去年年底发酵到今年年初，时间线横跨数月，涉及漏洞发现、官方迟缓响应、大规模感染爆发、紧急修复等多个阶段，堪称国产NAS软件发展史上一次深刻的安全教训。

这篇文章，我将从一个深度参与者的视角，为你完整复盘这次飞牛fnOS路径穿越漏洞的来龙去脉。我不会仅仅复述新闻，而是会深入技术细节，拆解漏洞的原理、攻击链的构成，并分享我如何在自己的测试环境中验证、分析，以及最终成功加固系统的全过程。更重要的是，我会告诉你，如果你的设备不幸中招，应该如何一步步排查、清理恶意程序，以及未来如何构建更健壮的安全防护体系。无论你是飞牛fnOS的用户，还是对网络安全、漏洞分析感兴趣的技术爱好者，这篇文章都将提供极具价值的实操参考和深度思考。

2. 漏洞深度解析：从“任意文件读取”到“完全沦陷”的攻击链

很多人看到“路径穿越漏洞”这个名词，可能觉得只是个能读到几个无关紧要文件的小问题。但这次飞牛fnOS的漏洞之所以被定义为“高危”，甚至“严重”，是因为它并非孤立存在，而是与后续的认证绕过、命令注入漏洞形成了一条完整的“攻击链”。攻击者可以像玩多米诺骨牌一样，利用这一个初始漏洞，最终达成完全控制你NAS的终极目标。理解这条攻击链，是理解整个事件严重性的关键。

2.1 核心漏洞：App Center静态资源服务的路径穿越

漏洞的起点，位于飞牛fnOS的“应用中心”相关服务。具体来说，是app-center-static这个用于提供应用图标等静态资源的服务接口。官方设计这个接口的初衷，可能是为了方便动态加载不同应用、不同尺寸的图标。其接口路径大致为/app-center-static/serviceicon/myapp/{appName}/?size={size}，其中{appName}是应用名，size参数指定图标尺寸。

漏洞原理：问题出在对size参数的处理上。在代码层面（根据安全研究者的逆向分析，函数地址约为0x11542e0），程序会直接将用户传入的size参数值，替换到文件路径的某个占位符中，然后拼接出完整的文件路径去读取图标文件。关键在于，这里没有对size参数进行任何有效的安全校验，比如检查是否包含路径遍历字符（../），或者使用类似Go语言中filepath.Clean()这样的函数来规范化路径。

于是，攻击者可以构造这样一个恶意请求：http://[你的飞牛NAS IP]:5666/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../etc/passwd这里，%7B0%7D是URL编码后的{0}，可能被用作一个占位符。而size参数被填充为../../../../etc/passwd。当服务端拼接路径时，就会从预期的图标目录向上回退四级，最终指向系统的/etc/passwd文件。服务器会误以为这是合法的图标请求，并将/etc/passwd文件的内容以HTTP响应的形式返回给攻击者。

可读取的敏感文件举例：

• 认证密钥：/usr/trim/etc/rsa_private_key.pem。这是飞牛系统内部用于加密通信的RSA私钥，一旦泄露，后果不堪设想。
• 系统配置：/etc/目录下的所有配置文件，包含网络、服务、用户等信息。
• 用户数据：通过不断尝试../../../../的组合，攻击者可以定位到用户的数据存储目录，读取照片、文档、备份文件等一切隐私数据。
• 历史记录：/root/.bash_history,/root/.psql_history等，可能包含管理员执行过的敏感命令。

实操心得：在测试环境中复现这个漏洞时，我发现关键在于{0}这个占位符。在某些版本或特定请求下，可能需要尝试不同的占位符或留空。使用curl命令配合--path-as-is参数（避免curl自动标准化路径）可以很好地测试：curl -v --path-as-is "http://NAS_IP:5666/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../etc/hosts"。如果返回了/etc/hosts的内容，证明漏洞存在。

2.2 攻击链第二步：利用泄露信息实现认证绕过

仅仅能读文件还不够，要执行命令还需要通过系统的身份认证。飞牛fnOS的Web管理界面和API调用通常需要有效的会话或Token。然而，攻击者利用第一步读取到的敏感文件，找到了绕过认证的方法。

根据漏洞分析报告，攻击链涉及对系统认证逻辑的逆向。简单来说，系统生成Token的机制可能依赖于一些存储在文件中的秘密值（Secret）。当攻击者通过路径穿越漏洞读取到包含这些Secret的配置文件或二进制文件中的硬编码值后，他们就可以伪造出合法的Token。报告指出，在某些情况下，系统验证Token时存在逻辑缺陷：如果请求中已经携带了token字段，系统会直接尝试解密这个token来获取secret，而不是先去验证请求的合法性。这就给了攻击者一个“后门”，只要他们通过文件读取拿到了生成token所需的原始secret，就能轻松构造出被系统认可的“合法”凭证。

2.3 攻击链第三步：WebSocket命令注入实现远程控制

拿到“合法”身份后，攻击者就可以与系统进行更高权限的交互。飞牛fnOS的部分管理功能通过WebSocket接口实现。研究人员发现，在/websocket?type=main这个接口中，存在命令注入漏洞。

攻击者可以构造一个特殊的WebSocket消息，在看似正常的JSON请求参数中嵌入系统命令。例如，在添加Docker镜像源的url字段里，除了正常的URL，后面还跟了一个分号;，接着就是系统命令/usr/bin/touch /tmp/hacked20260131。由于后端程序没有对输入进行严格的过滤和校验，直接将整个字符串传递给了系统shell执行，导致命令注入成功。

一个简化的PoC示例结构：

{ "reqid": "随机ID", "req": "appcgi.dockermgr.systemMirrorAdd", "url": "https://mirror.example.com ; /usr/bin/touch /tmp/hacked ; echo 'done'", "name": "恶意镜像源" }

当这个请求被处理时，系统会尝试执行https://mirror.example.com ; /usr/bin/touch /tmp/hacked ; echo 'done'，这会被shell解析为三条顺序执行的语句，从而在/tmp目录下创建一个名为hacked的文件。

注意事项：最令人担忧的是，根据报告，这个WebSocket命令注入漏洞在官方声称已修复路径穿越的v1.1.15-1493版本中仍然存在。这意味着即使你及时升级到了1.1.15，如果攻击者通过其他手段（比如利用你未更改的默认密码）获得了低权限账户，依然可能利用这个注入漏洞提升权限。这暴露了飞牛在安全修复上的不彻底性。

2.4 完整攻击链复盘与影响评估

让我们把这三步串联起来，还原一次完整的攻击：

1. 信息收集：攻击者扫描公网开放了5666端口（飞牛默认管理端口）的IP，发送路径穿越漏洞的探测请求。
2. 初始入侵：利用漏洞成功读取/usr/trim/etc/rsa_private_key.pem等关键文件。
3. 权限提升：分析读取到的文件，找出认证逻辑的弱点，伪造出高权限的Token或会话。
4. 建立据点：通过WebSocket命令注入漏洞，在设备上下载并执行第一阶段的恶意脚本或二进制程序。
5. 持久化与横向移动：恶意程序会植入后门、隐藏进程、感染其他服务，并可能尝试扫描内网或通过飞牛的FN Connect服务攻击其他设备。

影响范围之广令人咋舌：估计有超过30万个公网IP地址运行着存在漏洞的飞牛fnOS。从v0.9.35到v1.1.14的版本均受影响，这意味着漏洞可能已潜伏了相当长的时间。对于家庭用户，这意味着所有家庭照片、工作文档、私人视频完全暴露；对于将飞牛用作轻量级服务器的小型企业，数据库、代码仓库、客户信息同样危在旦夕。

3. 恶意程序分析与系统清理实战

如果你的设备在漏洞爆发期间（2026年1月底）暴露在公网，并且没有及时升级，那么有很大概率已经感染了恶意程序。官方在v1.1.18版本中加入了病毒清理功能，但对于无法立即升级或想手动确认的用户，了解恶意程序的行为并掌握清理方法至关重要。我在一个受感染的测试虚拟机中进行了详细的排查和分析。

3.1 恶意程序驻留手段分析

攻击者并非简单地运行一个进程，而是采用了多种深度隐藏和持久化技术，以确保持续控制并躲避排查。

1. 文件替换与伪装：

• 替换系统关键程序：最常见的伎俩是替换/usr/bin/nginx和/usr/sbin/gots。通过md5sum命令检查，你会发现这两个看似不同的文件，MD5哈希值竟然完全相同，说明它们其实是同一个恶意程序副本。真正的Nginx可能被移动或删除。
• 创建恶意服务：在/usr/trim/bin/目录下放置名为trim_https_cgi的恶意程序，并为其创建systemd服务单元文件/etc/systemd/system/trim_https_cgi.service，设置开机自启。
• 内核模块注入：这是更高级的隐藏手段。恶意程序会向系统插入一个内核模块，通常伪装成声卡驱动，如/lib/modules/$(uname -r)/snd_pcap.ko。内核模块运行在最高权限的Ring 0，可以隐藏文件、进程、网络连接，普通用户态工具根本无法察觉。

2. 系统配置篡改：

• 修改/etc/rc.local：这个文件会在系统启动的最后阶段执行。恶意程序会在这里添加启动命令，确保即使服务被禁用，重启后也能复活。
• 劫持现有服务：除了创建新服务，它也会修改飞牛原有的服务文件，例如在真正的服务启动脚本中夹带恶意代码。

3. 反检测与破坏行为：

• 破坏系统工具：重命名或删除/bin/cat、/usr/bin/top、/usr/bin/netstat等常用排查命令，让管理员无法正常检查文件内容和系统状态。
• 杀死安全进程：主动终止飞牛自身的network_service和resmon_service等监控进程。
• 清理日志：删除或清空/var/log/目录下的系统日志、审计日志（audit.log），抹除入侵痕迹。

3.2 手动排查与清理步骤

以下是我在测试环境中总结的一套手动排查清理流程。操作前请务必断开设备与公网的连接（关闭端口转发或FN Connect）。

步骤一：初步检查与网络隔离

1. 立即在路由器上撤销对飞牛NAS的端口转发，或直接在飞牛系统中关闭“FN Connect”远程访问功能。
2. 检查系统版本。在飞牛Web管理界面查看，或SSH登录后执行cat /etc/trimos-release。如果版本低于v1.1.18，感染风险极高。
3. 使用ss -tunlp或netstat -tunlp（如果可用）检查异常网络连接。重点关注与可疑IP（如报告中提到的45.95.212.102、151.240.13.91）的连接，以及监听在非常见端口（如57132）上的进程。

步骤二：文件系统排查

1. 检查关键二进制文件：

   # 检查nginx和gots是否被替换 md5sum /usr/bin/nginx /usr/sbin/gots # 如果两者MD5相同，极有可能已被替换。可与官方安装包中的哈希值对比。 # 检查可疑程序 ls -lah /usr/trim/bin/trim_https_cgi 2>/dev/null file /usr/trim/bin/trim_https_cgi # 查看文件类型

2. 检查恶意内核模块：

   # 查找可疑内核模块 find /lib/modules/ -name "snd_pcap.ko" -o -name "*.ko" | xargs ls -lah 2>/dev/null # 检查当前加载的模块 lsmod | grep -E 'pcap|snd'

3. 检查启动项：

   cat /etc/rc.local systemctl list-unit-files --type=service | grep -E 'trim|nginx' systemctl status trim_https_cgi.service 2>/dev/null

步骤三：清理操作警告：以下操作可能影响系统稳定性，建议在升级到v1.1.18后进行，或做好数据备份。

1. 停止并禁用恶意服务：

   sudo systemctl stop trim_https_cgi.service sudo systemctl disable trim_https_cgi.service sudo rm -f /etc/systemd/system/trim_https_cgi.service sudo systemctl daemon-reload

2. 删除恶意文件：

   # 删除恶意程序，先备份被替换的系统命令（如果有） sudo cp /usr/bin/nginx /usr/bin/nginx.backup.malicious sudo rm -f /usr/trim/bin/trim_https_cgi # 删除恶意内核模块 sudo rm -f /lib/modules/$(uname -r)/snd_pcap.ko sudo depmod -a # 重新生成模块依赖关系

3. 修复系统命令和启动脚本：
   • 从官方v1.1.18安装包中提取干净的nginx、gots等二进制文件进行替换。
   • 检查并清理/etc/rc.local，删除可疑的启动命令。
   • 检查/usr/trim/bin/system_startup.sh，删除末尾添加的恶意命令。
4. 修复系统日志：日志通常会被自动重建，但需确认rsyslog或systemd-journald服务正常运行。

步骤四：升级与加固

1. 立即升级系统：这是最重要的一步。通过Web管理界面或SSH，将系统升级到v1.1.18或更高版本。该版本包含了针对此漏洞的彻底修复和病毒清理脚本。
2. 运行官方清理工具：升级后，系统可能会自动运行清理脚本，或在管理界面提供安全扫描功能，请务必执行。
3. 修改所有密码：包括飞牛OS管理员密码、SSH密码（如果启用）、以及所有在NAS上运行的服务的密码（如数据库、GitLab等）。
4. 复查防火墙规则：在路由器或飞牛系统防火墙中，永久屏蔽报告中提到的恶意IP段。

踩坑实录：在手动清理时，我犯过一个错误：直接删除了被替换的/usr/bin/nginx，导致Web管理界面无法访问。正确的做法是，先从官方包中获取干净版本，或者在最坏情况下，可以暂时从同版本的健康设备上拷贝一个。另外，depmod -a命令在删除内核模块后必须执行，否则可能导致下次启动时系统报错。

4. 漏洞修复方案与安全加固指南

亡羊补牢，为时未晚。飞牛官方最终在v1.1.15和v1.1.18版本中修复了漏洞。但作为用户，我们不能仅仅依赖官方的补丁，更需要从这次事件中吸取教训，主动加固自己的系统安全。

4.1 官方修复方案技术剖析

根据补丁分析和社区讨论，官方的修复主要集中在以下几个方面：

1. 路径穿越漏洞修复：在app-center-static服务的相关代码中，对size等用户输入的参数进行了严格的校验。最根本的修复方式是使用类似Go语言filepath.Clean()的函数对最终拼接的路径进行规范化，它会自动解析并消除路径中的..和.等符号，确保路径不会跳出预设的根目录。同时，增加了白名单机制，size参数只能为预设的几种图标尺寸（如small,medium,large），任何非预期的输入都会被拒绝。

2. 输入验证与过滤强化：对所有从Web接口（包括HTTP API和WebSocket）接收的用户输入，进行了更严格的过滤和转义。特别是对于WebSocket接口中可能传递给系统shell的参数，进行了字符黑名单过滤（如禁止;、|、&、$()等shell元字符），或者改为使用参数化列表的方式调用系统命令，从根本上杜绝命令注入。

3. 权限最小化原则：重新审视了相关服务进程的运行权限。可能将app-center-static这类静态文件服务的运行账户权限降低，使其即使被攻破，也无法读取/etc/、/root/等关键目录的文件。

4. 增加了安全监控和响应机制：在v1.1.18版本中，加入了病毒查杀功能和异常连接监控的模块。虽然具体实现未公开，但可以推测其包含对已知恶意文件哈希值的检测、对异常系统调用序列的监控等。

4.2 用户侧主动安全加固措施

官方修复是基础，用户自身的操作习惯和安全配置同样重要。

1. 网络层面隔离（最重要！）：

• 原则：非必要，不暴露。家庭NAS最大的安全风险就是暴露在公网。除非有绝对必要（如远程办公），否则不要在路由器上做任何端口转发到NAS。
• 禁用FN Connect：如果你不需要飞牛官方的内网穿透服务，请在“系统设置” -> “网络”中彻底关闭它。这是大量设备被攻击的直接原因。
• 使用VPN：如果需要远程访问，请使用虚拟专用网络将家庭网络和外部设备组成一个安全的私有网络，再通过内网IP访问NAS。这是最安全的远程访问方案。
• 如果必须暴露：仅暴露特定服务端口（如WebDAV的443），并使用强密码+二次验证（2FA）。绝对不要将管理端口（如5666）直接暴露给公网。

2. 系统与账户安全：

• 立即更新：开启系统自动更新，或定期手动检查更新。对于安全补丁，必须零延迟安装。
• 强密码与独立账户：为管理员账户设置20位以上包含大小写字母、数字、特殊字符的强密码。为家人或不同用途创建独立的、权限受限的普通用户账户，避免日常使用管理员账号。
• 启用二次验证（2FA）：如果飞牛系统支持，务必为所有管理员账户启用。
• 定期审计：偶尔查看系统的“日志中心”，关注异常登录、大量失败认证尝试等记录。

3. 服务与应用安全：

• 谨慎安装第三方应用/Docker：只从可信源（如官方应用商店、Docker Hub官方镜像）安装应用。仔细审查Docker镜像的Dockerfile和来源。
• 最小化容器权限：运行Docker容器时，使用--read-only（只读根文件系统）、--cap-drop=ALL（删除所有Linux能力）等参数，遵循最小权限原则。
• 定期备份：执行3-2-1备份策略（3份数据副本，2种不同介质，1份异地备份）。确保在遭受勒索软件或严重破坏时，有能力恢复数据。

4. 进阶安全监控（针对技术用户）：

• 部署网络IDS/IPS：在路由器或NAS上部署像Suricata、Snort这样的入侵检测/防御系统，设置规则拦截对/app-center-static等敏感路径的异常路径遍历请求。
• 文件完整性监控：使用AIDE（Advanced Intrusion Detection Environment）等工具，为/usr/bin/、/etc/等关键目录建立哈希值数据库，定期扫描文件是否被篡改。
• 集中式日志管理：将飞牛系统的日志转发到外部安全的日志服务器（如ELK Stack），避免攻击者清除本地日志后无从追溯。

5. 事件反思与开源NAS安全生态构建

这次飞牛fnOS漏洞事件，不仅仅是一个技术问题，更暴露了国产新兴软件在快速发展过程中对安全生命周期的忽视，以及用户安全意识的普遍薄弱。作为从业者，我有以下几点深刻的反思。

对开发者的启示：安全必须“左移”飞牛团队在漏洞处理上存在明显失误：从2025年12月23日用户报告，到2026年1月30日发布修复，响应周期长达38天。期间每周仍有常规更新，却未优先处理高危漏洞。这反映出在开发流程中，安全没有获得最高优先级。

• 安全开发生命周期（SDL）缺失：应在需求设计阶段就进行威胁建模，识别app-center-static这类接口的风险。在编码阶段，必须对所有用户输入进行校验和净化，使用安全的API（如避免直接拼接路径、使用参数化查询）。
• 建立有效的应急响应流程：需要设立明确的安全漏洞接收渠道（如飞牛后续设立的安全邮箱），并制定分级响应SLA（服务水平协议）。对于“高危”和“严重”漏洞，应在数日内提供临时缓解方案或补丁。
• 第三方组件与依赖管理：需要持续跟踪所用开源组件的安全漏洞，并及时更新。同时，对自研代码进行定期的安全审计和渗透测试。

对用户的警示：你是安全的最后一道防线许多用户将NAS视为“设置好就忘”的盒子，缺乏基本的安全运维概念。

• 默认不信任原则：不要认为家用设备就很安全。任何连接到互联网的设备都是潜在的攻击目标。
• 持续学习：花点时间了解你所用产品的安全设置。关注官方社区、安全论坛的动态。
• 社区互助的价值：这次事件最早由社区用户发现并报告，后续的分析、排查方法也大量来自社区分享。积极参与开源社区，是提升个人安全和推动产品进步的双赢之举。

对开源与国产软件的期待飞牛fnOS作为一款有潜力的国产NAS系统，此次事件是一次沉重的打击，但也是一个成长的契机。开源的优势在于透明和协作。我建议飞牛：

1. 彻底开源其核心安全模块：允许社区审查其认证、授权、输入验证等关键代码。
2. 建立公开的漏洞赏金计划：鼓励白帽子黑客以负责任的方式提交漏洞，变被动为主动。
3. 完善安全文档：清晰地向用户说明各项功能的安全假设、风险以及最佳实践配置。

最后，我想分享一个我个人在事件后的习惯改变：我为我的所有自托管服务（包括NAS）建立了一个简单的“安全检查清单”，每月执行一次。清单包括：检查更新、审查开放端口、查看异常日志、验证备份完整性、快速扫描关键文件哈希。这个简单的习惯，或许能帮你及早发现下一次潜在的风险。技术永远在演进，攻击手段也在不断翻新，唯有保持警惕和持续学习，才能让我们在数字世界中守护好自己的数据家园。