飞牛NAS安全漏洞公告再分析：回应中的四大疑点与缺失信息

飞牛私有云系统 (fnOS) 于2月12日通过官方微信公众号发布了一篇题为《致飞牛用户：近期安全事件的完整说明与深刻反思》的公告，试图回应此前爆发的重大安全漏洞事件。然而，通篇阅读下来，这份所谓的“完整说明”恐怕难以称之为反思，其中多处说法逻辑上站不住脚，关键信息依旧缺失。

事实上，从1月31日安全社区开始曝光相关漏洞并引发广泛关注，到飞牛拿出这份长篇回应，中间间隔了不短的时间。遗憾的是，这份迟来的公告并未能有效澄清疑虑，反而暴露出更多问题。

飞牛官方公告链接：https://mp.weixin.qq.com/s/onHmVw2Nh9bPnp3icM_UoQ

先修复后通告：是保护用户还是掩耳盗铃？

公告中，飞牛为前期长时间保持沉默提供了一个理由：担心发布安全公告会“刺激黑客升级破坏或吸引全网黑客积极挖掘漏洞并发起攻击，这可能会危害更多用户的数据安全”。

这个说法初听似乎有些道理，但完全经不起推敲。根据已披露的信息，在1月31日相关漏洞被公开曝光之前，实际上已有2到3个不同的黑客团队在利用该漏洞发起主动攻击。部分用户设备早已沦为“肉鸡”，系统命令被恶意替换，内核后门被安装，审计日志也被清空。

在黑客已经掌握漏洞并开始大肆利用的情况下，飞牛选择不发布公告，瞒住的根本不是黑客，而是广大的普通用户。用户不知道自己可能正面临攻击，不知道需要立即断网隔离，也不知道如何进行安全排查，只能继续在联网状态下“裸奔”，被动等待攻击者安装后门。

从1月20日飞牛内部发现入侵迹象，到1月31日被社区舆论“逼”着公开事件，整整10天时间里，飞牛仅仅以“常规版本升级”的名义推送补丁，既未发布任何安全公告，也未主动通过短信等渠道通知用户，更没有强制断开存在风险的 fnConnect 公网连接。

飞牛自己在公告中也承认了后果：安全论坛公开爆料后，事件性质瞬间从单一黑客入侵转变为全网蠕虫式攻击。但问题恰恰在于，如果飞牛在1月21日就果断强制所有未升级设备断开公网连接，后续的大规模扩散是否就能避免？

12月的漏洞报告被当成了“普通BUG”？

公告中，飞牛轻描淡写地提到：“在12月期间，论坛有用户反馈相关漏洞记录，我们虽然提单上报，但相关人员缺乏安全视角，仅当作普通BUG处理。”

这句话，恐怕是整篇公告里最严重的问题所在。据了解，早在12月23日，就有用户在飞牛官方论坛明确提交了关于“路径穿越”的漏洞报告，并且得到了官方账号的回复。然而，从12月23日到1月20日漏洞大规模爆发，将近一个月的时间里，飞牛依然保持着每周更新的节奏，却唯独没有修复这个已被报告的安全漏洞。

将责任归咎于“相关人员缺乏安全视角”，恰恰说明了飞牛团队在组织层面就缺乏基本的安全意识。一个用于存储用户大量隐私数据的NAS系统，竟然连基本的漏洞分级和响应机制都没有。用户上报了明确的路径穿越漏洞都不被重视，这显然不是某一个员工的问题，而是整个团队安全文化和流程的缺失。

“暂未发现数据被加密或破坏”等于安全吗？

公告中，飞牛声称“暂未发现用户数据被加密或破坏”。这句话看似在安抚用户情绪，实则是一种“正确的废话”，回避了最核心的风险。

数据没有被加密或破坏，绝不意味着数据没有被窃取。恶意程序会连接远程的C2（命令与控制）服务器，那么，被感染的设备到底向攻击者回传了哪些数据？用户的私人照片、重要文档、乃至各种密钥证书，有没有被打包 exfiltrate（渗出）？

更关键的一点是，飞牛自己也承认，病毒清除了关键的系统日志。既然核心的审计日志都已经被清空，飞牛又是如何“确认”数据没有被窃取的呢？这种“没有证据所以声称未发现”的说法，在安全事件响应中是非常不负责任的，本质上是一种回避。

甩锅离职员工，代码审计流程何在？

飞牛还将此次重大漏洞的根源，归结为“早期已离职人员的代码缺陷未被发现”。这显然又是一次试图转移焦点的操作。

代码最初是由谁编写的并不最重要，重要的是谁在维护、谁在定期审计、谁最终为产品的安全性负责。离职员工留下的代码长期无人进行安全审计，这是否意味着飞牛根本没有建立常态化的代码审计流程？此次漏洞最早在 v0.9.35 版本中就存在，这意味着大量用户可能在不安全的状态下运行了长达一年之久。难道在这一年里，相关的代码都从未经过任何形式的安全审查吗？

公告未提的关键信息：透明度依然欠缺

尽管标题冠以“完整说明”，但飞牛的公告透露的有效信息其实非常有限，更大篇幅仍停留在公关话术层面。从一次严肃的安全事件复盘角度来看，飞牛理应提供更完整、更具体的数据。

1. 感染规模：到底有多少台设备被确认感染？飞牛作为服务提供商，理论上应能通过连接状态等方式统计到这部分数据，但公告中只字未提。
2. 攻击者溯源：被感染设备上的恶意程序使用了 chattr +i 防删除、伪装内核模块、替换系统命令等高级持久化手段，这表明攻击者绝非“脚本小子”。飞牛对攻击者的溯源调查有何进展？
3. 数据泄露评估：恶意程序连接了多个C2服务器，被感染设备究竟回传了多大体量、什么类型的数据？这才是用户真正关心的问题。
4. 历史影响评估：漏洞从 v0.9.35 版本就已存在，在这段漫长的时间里，有多少用户的数据可能被未授权访问过？

鉴于飞牛在公告中对这些涉及具体数据和深入分析的内容避而不谈，我们只能认为其态度依然是希望“蒙混过关”，而非本着真正负责任、透明、公开的原则来解决问题。对于一家NAS系统开发商而言，这种态度尤为令人担忧。NAS设备存储着用户海量的私密数据，安全性永远应排在第一位。如果连基本的安全响应机制和坦诚的态度都无法保证，那么功能再丰富，也难以让用户安心使用。

对于这类涉及基础设施安全与应急响应的事件，业内通常会在专业的安全事件响应社区进行深入复盘与讨论。我们也欢迎大家在云栈社区的相关板块继续探讨NAS设备的安全实践与厂商责任。