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?typemain这个接口中存在命令注入漏洞。攻击者可以构造一个特殊的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 完整攻击链复盘与影响评估让我们把这三步串联起来还原一次完整的攻击信息收集攻击者扫描公网开放了5666端口飞牛默认管理端口的IP发送路径穿越漏洞的探测请求。初始入侵利用漏洞成功读取/usr/trim/etc/rsa_private_key.pem等关键文件。权限提升分析读取到的文件找出认证逻辑的弱点伪造出高权限的Token或会话。建立据点通过WebSocket命令注入漏洞在设备上下载并执行第一阶段的恶意脚本或二进制程序。持久化与横向移动恶意程序会植入后门、隐藏进程、感染其他服务并可能尝试扫描内网或通过飞牛的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。步骤一初步检查与网络隔离立即在路由器上撤销对飞牛NAS的端口转发或直接在飞牛系统中关闭“FN Connect”远程访问功能。检查系统版本。在飞牛Web管理界面查看或SSH登录后执行cat /etc/trimos-release。如果版本低于v1.1.18感染风险极高。使用ss -tunlp或netstat -tunlp如果可用检查异常网络连接。重点关注与可疑IP如报告中提到的45.95.212.102、151.240.13.91的连接以及监听在非常见端口如57132上的进程。步骤二文件系统排查检查关键二进制文件# 检查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 # 查看文件类型检查恶意内核模块# 查找可疑内核模块 find /lib/modules/ -name snd_pcap.ko -o -name *.ko | xargs ls -lah 2/dev/null # 检查当前加载的模块 lsmod | grep -E pcap|snd检查启动项cat /etc/rc.local systemctl list-unit-files --typeservice | grep -E trim|nginx systemctl status trim_https_cgi.service 2/dev/null步骤三清理操作警告以下操作可能影响系统稳定性建议在升级到v1.1.18后进行或做好数据备份。停止并禁用恶意服务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删除恶意文件# 删除恶意程序先备份被替换的系统命令如果有 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 # 重新生成模块依赖关系修复系统命令和启动脚本从官方v1.1.18安装包中提取干净的nginx、gots等二进制文件进行替换。检查并清理/etc/rc.local删除可疑的启动命令。检查/usr/trim/bin/system_startup.sh删除末尾添加的恶意命令。修复系统日志日志通常会被自动重建但需确认rsyslog或systemd-journald服务正常运行。步骤四升级与加固立即升级系统这是最重要的一步。通过Web管理界面或SSH将系统升级到v1.1.18或更高版本。该版本包含了针对此漏洞的彻底修复和病毒清理脚本。运行官方清理工具升级后系统可能会自动运行清理脚本或在管理界面提供安全扫描功能请务必执行。修改所有密码包括飞牛OS管理员密码、SSH密码如果启用、以及所有在NAS上运行的服务的密码如数据库、GitLab等。复查防火墙规则在路由器或飞牛系统防火墙中永久屏蔽报告中提到的恶意IP段。踩坑实录在手动清理时我犯过一个错误直接删除了被替换的/usr/bin/nginx导致Web管理界面无法访问。正确的做法是先从官方包中获取干净版本或者在最坏情况下可以暂时从同版本的健康设备上拷贝一个。另外depmod -a命令在删除内核模块后必须执行否则可能导致下次启动时系统报错。4. 漏洞修复方案与安全加固指南亡羊补牢为时未晚。飞牛官方最终在v1.1.15和v1.1.18版本中修复了漏洞。但作为用户我们不能仅仅依赖官方的补丁更需要从这次事件中吸取教训主动加固自己的系统安全。4.1 官方修复方案技术剖析根据补丁分析和社区讨论官方的修复主要集中在以下几个方面路径穿越漏洞修复在app-center-static服务的相关代码中对size等用户输入的参数进行了严格的校验。最根本的修复方式是使用类似Go语言filepath.Clean()的函数对最终拼接的路径进行规范化它会自动解析并消除路径中的..和.等符号确保路径不会跳出预设的根目录。同时增加了白名单机制size参数只能为预设的几种图标尺寸如small,medium,large任何非预期的输入都会被拒绝。输入验证与过滤强化对所有从Web接口包括HTTP API和WebSocket接收的用户输入进行了更严格的过滤和转义。特别是对于WebSocket接口中可能传递给系统shell的参数进行了字符黑名单过滤如禁止;、|、、$()等shell元字符或者改为使用参数化列表的方式调用系统命令从根本上杜绝命令注入。权限最小化原则重新审视了相关服务进程的运行权限。可能将app-center-static这类静态文件服务的运行账户权限降低使其即使被攻破也无法读取/etc/、/root/等关键目录的文件。增加了安全监控和响应机制在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-dropALL删除所有Linux能力等参数遵循最小权限原则。定期备份执行3-2-1备份策略3份数据副本2种不同介质1份异地备份。确保在遭受勒索软件或严重破坏时有能力恢复数据。4. 进阶安全监控针对技术用户部署网络IDS/IPS在路由器或NAS上部署像Suricata、Snort这样的入侵检测/防御系统设置规则拦截对/app-center-static等敏感路径的异常路径遍历请求。文件完整性监控使用AIDEAdvanced 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系统此次事件是一次沉重的打击但也是一个成长的契机。开源的优势在于透明和协作。我建议飞牛彻底开源其核心安全模块允许社区审查其认证、授权、输入验证等关键代码。建立公开的漏洞赏金计划鼓励白帽子黑客以负责任的方式提交漏洞变被动为主动。完善安全文档清晰地向用户说明各项功能的安全假设、风险以及最佳实践配置。最后我想分享一个我个人在事件后的习惯改变我为我的所有自托管服务包括NAS建立了一个简单的“安全检查清单”每月执行一次。清单包括检查更新、审查开放端口、查看异常日志、验证备份完整性、快速扫描关键文件哈希。这个简单的习惯或许能帮你及早发现下一次潜在的风险。技术永远在演进攻击手段也在不断翻新唯有保持警惕和持续学习才能让我们在数字世界中守护好自己的数据家园。