我对最近国产 NAS 系统 FnOS 重大漏洞链的一些看法

前言 | 我对 FnOS 的印象

这篇文章说是“最近”，其实距离漏洞被大规模利用有一段时间了。

不过最近也确实没啥能写的，就胡乱朝飞牛身上扯扯吧。

我并不是公测老用户，FnOS 是去年年底发布正式版的时候才被我注意到的。

说实话，当时只觉着飞牛界面现代美观，这玩意儿靠着“国产 NAS OS”的“噱头”和免费的优势得到了我的一点点青睐——当然只有一点点。毕竟我一不是元老测试时期来的用户，二没给飞牛送过钱，三又不是 NAS 重度用户，整 NAS 只是为了塞一些文件。我不怎么喜欢拍照，也没有多少照片是关于我的。我用飞牛其实只是为了飞牛影视。所以我只认为 FnOS 是一个不错的 NAS 系统——仅此而已。

一切的开始

就在最近（2026.1.30，那两天是事故高发期，漏洞在 2026.1.19 左右就已经出现过反馈记录了），不少群友开始反馈自己的路由器间歇性断网、网络很卡之类的问题，进到 ikuai 里一排查，一看自己的 NAS 连接数暴涨到了几十 W，CPU 资源也被直接吃满。这时候，大家才反应过来：大家的 NAS 被攻击并且做了肉鸡了。

我自然是没有踩坑的——我给飞牛开的 FRP 隧道加了访问鉴权，任何未经授权的 IP 都无法访问我的飞牛。而且我也并没有公网 IPV4 地址（总不能有人扫 IPV6 吧）。况且，上文也提到过，我对 NAS 的要求比较低，因为我并没有什么重要的、敏感的数据存在里面。也就是说，理论上来讲，这件事对我没有任何影响。

但我心里实在还有些不快。

飞牛团队在第一时间并没有对漏洞做出任何回应，甚至没有组织出任何一句上下文逻辑通顺的回答。飞牛团队试图以“HTTP 不安全连接导致的信息泄露”为由建议社区用户“开启 HTTPS 访问”来“避免中招”。

哥们你们爆出来的是路径穿越漏洞啊！和你他妈的 HTTP 有什么关系！？

看着群里越来越多的群友被攻击投毒然后疯狂发起对外连接，飞牛团队此时却像死掉了一样——没有短信、没有邮件——我知道许多 NAS 用户十分反感强制升级，但好歹给用户一个升级通知吧？拿 HTTP 不安全为理由搪塞那些真心希望飞牛团队越来越好的用户并把他们的数据安全先放在一遍，真的很难不造成用户流失吧？

团队在后来好几天（2月2日）终于是发布了官方查杀指南了——不过慢半拍的响应终究还是是晚了一步。的。

漏洞 | 投毒

其实就在漏洞被大规模利用前夕，也有别人的雷池捕捉到并反馈进社区（系统可能存在漏洞 - BUG反馈飞牛私有云论坛 fnOS），但是可以看见官方没有对这个帖子进行任何回应。

漏洞受影响范围为 1.15 到 1.18 之间的全部。首先是因为漏洞不止一个，而且飞牛团队对漏洞的处置方式绝对有问题。

除了路径穿越漏洞，还有一个 WS 登陆后远程执行任意命令的漏洞（其实如果严密点，不止两个）。后者看起来没啥危害，毕竟需要有效的登录凭据，但是这俩漏洞加起来变成了一个组合拳：

路径穿越：系统的一个Web接口（/app-center-static/serviceicon/myapp/…）未能正确过滤用户输入的路径，允许攻击者读取服务器文件系统上的任意文件。
在此攻击链中的作用：用于下载一个伪装成RSA私钥、但实际内嵌了硬编码AES密钥的文件 (/usr/trim/etc/rsa_private_key.pem)。这是整个攻击的起点。
上述下载的文件中，在固定偏移量（100字节处）硬编码了一个32字节的AES主密钥（Root Key）。这为攻击者提供了“万能钥匙”。这是后续伪造合法用户凭证的核心要素。
系统的WebSocket网关在验证用户身份时存在致命逻辑缺陷。它允许攻击者使用上述获取的AES主密钥，在本地凭空“创造”出一个服务器会认为是合法的临时token。攻击者利用此漏洞，无需任何用户名和密码，即可伪造出一个“已登录”的管理员身份，从而有权调用需要高权限的API接口。
在通过认证后，一个用于添加Docker镜像的API接口（appcgi.dockermgr.systemMirrorAdd）未能正确处理其url参数。这是最终的执行环节。攻击者将恶意系统命令（如反弹Shell或下载执行脚本）注入到url参数中，服务器在处理该请求时会无条件执行这些命令

我是真的忍不住想把飞牛团队安全负责人拉过来问问，路径穿越难道是什么很高深的漏洞吗？一个刚入门 Nginx 几天的小白都知道 Path Traversal 这种低级问题怎么解决，就算只是用正则过滤一下也完全可以避免，但这个疏忽为什么在 FnOS 中留存了将近半年？

再说病毒。

既然暴露在公网上的飞牛拿 FOFA 一扫就出，就不免要中毒了。配合路径穿越得到的 Token/Key，攻击者应当可以毫无难度地进行大规模投毒。

根据相关人士分析，病毒是为飞牛系统量身定做的。隐藏的进程号、毫无痕迹的植入、甚至是破坏 OTA 更新功能使用户无法升级到安全的版本。

不过，由于我算不上是受害者，我只想说：私有云变成公共云了，还怪有意思的。

最后的想法

不是说因为飞牛是“国产”的我们就要骂要排挤它，也不是说别的 NAS 系统没有出现过 0Day 漏洞，一个软件在生命周期内遵循发现漏洞→解决漏洞的循环也是正常的，但是飞牛团队着实是让人感到不靠谱。不知道是店大欺客还是说真的是自己埋的后门被黑客挖出来了。

漏洞集中爆发时，飞牛刚发布自己的成品 NAS 硬件，正在做 Arm 架构的飞牛 OS，这样一个状态下的团队注定是在安全上不上心的，这样一次风口注定是要波及用户对飞牛团队的信赖的。飞牛可能是秉着“大事化小，小事化了”的原则，把漏洞在一开始藏着掖着，甚至企图悄悄更新蒙混过去——这都令我极度感到厌恶。

不过骂归骂，我还是要用飞牛的。

上文其实也说过原因，我挺喜欢飞牛影视的傻瓜式刮削，也会接着用下去的——唯一的区别是现在以及以后，我的飞牛里都不可能出现敏感文件。就那点音乐和电影，被别人弄去，或者被勒索加密了也没啥问题。

我自建私有服务一般都秉着没公网需求就只放在内网；对于有需求的，不怎么用的就 FRP 出去再加个鉴权，使用频率高的也只 WG 组网用。——要是这样也能体验 0Day 漏洞的话那我可真不知道该怎么办了。

此外，我不用 TrueNAS 反而用飞牛的原因还有一个：那就是我的硬盘直通进 TrueNAS 后压根无法正常休眠，飞牛却可以。可能有一些人不太理解硬盘休眠的需求——这玩意儿还不如不开。实际上对于一个命苦的中国大陆高中生来说，不放长假时，一周也就一天可能用到 NAS，不休眠就是在浪费硬盘 99% 的生命了。

这次官方态度是有点恶心了。但既然我也没啥重度 NAS 需求，这功能发展快于安全的飞牛我就先用着吧。要是下一次 0Day （如果有）官方还是这态度的话，我立刻去隔壁 TrueNAS。