对不起飞牛，你们最新公告里的说法经不起任何推敲
对不起飞牛，你们最新公告里的说法经不起任何推敲。飞牛昨晚发布所谓的完整说明回应漏洞问题，但蓝点网看完后实在忍不住吐槽。所谓完整说明还是在蒙混过关，例如不公告是害怕黑客升级攻击，问题是黑客早就已经发起攻击，这时候不通知用户升级和断网无疑是把用户丢进火坑里，另外还说没数据被加密或破坏，那有多少数据被窃取呢？
飞牛私有云系统 (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 月的漏洞报告去哪了？
在公告里飞牛轻描淡写的表示：在 12 月期间，论坛有用户反馈相关漏洞记录，我们虽然提单上报，但相关人员缺乏安全视角，仅当作普通 BUG 处理。
这句话才是整篇公告里最严重的问题，因为在 12 月 23 日用户在飞牛官方论坛明确提交了路径穿越漏洞，官方账号回复了。从 12 月 23 日到 1 月 20 日大规模爆发，在将近 1 个月的时间里飞牛仍然保持每周更迭节奏，但就是不修复漏洞。
飞牛把黑锅甩给相关人员缺乏安全视角也说明飞牛团队在组织内部就缺乏安全意识，用于存储用户隐私数据的 NAS 系统，连漏洞分级机制都没有，用户上报路径穿越都不当回事，这不是某个员工的问题，而是整个团队的问题。
暂未发现用户数据被加密或破坏？
在公告里飞牛称暂未发现用户数据被加密或破坏，这句话看着像是在安抚用户，但实际上什么都没说。
数据没被加密或破坏不代表数据没有被窃取，恶意程序连接 C2 服务器，被感染设备到底回传了哪些数据？用户的照片、文档、密钥有没有被打包下载？
更关键的是，飞牛自己也承认病毒清除了关键系统日志，既然日志都清空了，你怎么确认数据没有被窃取呢？没有日志就说暂未发现，这是非常不负责任的说法，这是没有证据所以不承认。
早期已离职人员的代码缺陷：
飞牛还将此次重大漏洞归咎到早期已离职人员的代码缺陷未被发现，显然这也是甩锅，代码是谁写的不重要，重要的是谁在维护、谁在审计、谁在为产品安全负责。
离职员工写的代码没人审计，这是否意味着飞牛根本没有代码审计流程呢？因为此次漏洞最早是在 v0.9.35 就存在，也就是大量用户裸奔时间长达 1 年，这 1 年里代码都没有审计过？
飞牛在公告里没有提的事：
尽管飞牛公告号称完整说明，但其实透露的信息非常少，更大篇幅仍然是公关，从安全事件复盘角度来说飞牛应该提供更多完整的数据。
1. 到底有多少台设备被感染？飞牛应该是可以统计到这部分数据的，但飞牛在公告里只字未提。
2. 被感染设备上的恶意程序使用 chattr+i 防删除、伪装内核模块、替换系统命令、清空审计日志，这种高级持久化手段说明攻击者不是脚本小子，飞牛对攻击者的溯源有什么进展？
3. 恶意程序连接多个 C2 服务器，被感染设备回传多少数据？这才是用户关心的问题。
4. 漏洞从 v0.9.35 版就存在，在这段时间里有多少用户的数据被访问过？
鉴于飞牛在公告里不愿意提及这些涉及具体数据的内容，我们只能认为飞牛依然是公关和蒙混过关，而不是本着负责任、透明、公开的态度解决问题，作为 NAS 系统开发商，飞牛的这种态度还是让人担心的，毕竟 NAS 存储用户太多私密数据，安全性永远排在第一，如果不能解决安全问题，功能再多也不适合使用。
蓝点网从 1 月 31 日开始追踪飞牛系统的安全事件并发布多篇文章，直到现在飞牛才拿出像样的长文回应这件事，只不过这篇所谓的完整说明里有太多经不起推敲的地方。
飞牛官方公告链接：https://mp.weixin.qq.com/s/onHmVw2Nh9bPnp3icM_UoQ
先修复后通告的做法是掩耳盗铃：
在公告中飞牛为自己前期的沉默找了个理由：担心发布安全公告后会刺激黑客升级破坏或吸引全网黑客积极挖掘漏洞并发起攻击，这可能会危害更多用户的数据安全。
这个说法听起来好像有点道理，但其实经不起推敲：1 月 31 日相关漏洞被曝光前，已经有 2~3 个不同的黑客团队在野外积极利用漏洞发起攻击，部分设备已经沦为肉鸡，恶意程序替换系统命令、安装内核后门以及清空审计日志。
在黑客已经知道怎么利用漏洞的情况下，飞牛不发布公告瞒住的不是黑客，而是广大使用飞牛系统的用户，用户不知道自己被攻击或者即将被攻击、不知道要断网、不知道如何排查，就这么继续裸奔等着被人装后门。
从 1 月 20 日发现入侵到 1 月 31 日被社区逼着公开，整整 10 天飞牛都以常规版本升级名义推送补丁，不发布安全公告、不主动发短信通知用户、不断开 fnConnect 公网连接。
飞牛自己也在公告中承认后果：安全论坛公开爆料后，事件性质瞬间从单一黑客入侵转变为全网蠕虫式攻击，但问题是，如果飞牛在 1 月 21 日就强制断开未升级设备的公网连接，哪来后面这些事？(飞牛给出的理由是有些用户不在设备身边，断开公网连接后用户拿不到数据，这说法也太蹩脚了)
12 月的漏洞报告去哪了？
在公告里飞牛轻描淡写的表示：在 12 月期间，论坛有用户反馈相关漏洞记录，我们虽然提单上报，但相关人员缺乏安全视角，仅当作普通 BUG 处理。
这句话才是整篇公告里最严重的问题，因为在 12 月 23 日用户在飞牛官方论坛明确提交了路径穿越漏洞，官方账号回复了。从 12 月 23 日到 1 月 20 日大规模爆发，在将近 1 个月的时间里飞牛仍然保持每周更迭节奏，但就是不修复漏洞。
飞牛把黑锅甩给相关人员缺乏安全视角也说明飞牛团队在组织内部就缺乏安全意识，用于存储用户隐私数据的 NAS 系统，连漏洞分级机制都没有，用户上报路径穿越都不当回事，这不是某个员工的问题，而是整个团队的问题。
暂未发现用户数据被加密或破坏？
在公告里飞牛称暂未发现用户数据被加密或破坏，这句话看着像是在安抚用户，但实际上什么都没说。
数据没被加密或破坏不代表数据没有被窃取，恶意程序连接 C2 服务器，被感染设备到底回传了哪些数据？用户的照片、文档、密钥有没有被打包下载？
更关键的是，飞牛自己也承认病毒清除了关键系统日志，既然日志都清空了，你怎么确认数据没有被窃取呢？没有日志就说暂未发现，这是非常不负责任的说法，这是没有证据所以不承认。
早期已离职人员的代码缺陷：
飞牛还将此次重大漏洞归咎到早期已离职人员的代码缺陷未被发现，显然这也是甩锅，代码是谁写的不重要，重要的是谁在维护、谁在审计、谁在为产品安全负责。
离职员工写的代码没人审计，这是否意味着飞牛根本没有代码审计流程呢？因为此次漏洞最早是在 v0.9.35 就存在，也就是大量用户裸奔时间长达 1 年，这 1 年里代码都没有审计过？
飞牛在公告里没有提的事：
尽管飞牛公告号称完整说明，但其实透露的信息非常少，更大篇幅仍然是公关，从安全事件复盘角度来说飞牛应该提供更多完整的数据。
1. 到底有多少台设备被感染？飞牛应该是可以统计到这部分数据的，但飞牛在公告里只字未提。
2. 被感染设备上的恶意程序使用 chattr+i 防删除、伪装内核模块、替换系统命令、清空审计日志，这种高级持久化手段说明攻击者不是脚本小子，飞牛对攻击者的溯源有什么进展？
3. 恶意程序连接多个 C2 服务器，被感染设备回传多少数据？这才是用户关心的问题。
4. 漏洞从 v0.9.35 版就存在，在这段时间里有多少用户的数据被访问过？
鉴于飞牛在公告里不愿意提及这些涉及具体数据的内容，我们只能认为飞牛依然是公关和蒙混过关，而不是本着负责任、透明、公开的态度解决问题，作为 NAS 系统开发商，飞牛的这种态度还是让人担心的，毕竟 NAS 存储用户太多私密数据，安全性永远排在第一，如果不能解决安全问题，功能再多也不适合使用。
关于作者
评论1次
--- ### 结论 飞牛私有云（fnOS）在安全事件响应与漏洞管理上存在xi统性缺陷，主要问题集中在**漏洞修复流程失效**、**安全意识缺失**、**责任推诿**及**数据保护措施形同虚设**。其公告刻意回避关键数据与攻击细节，本质是试图掩盖自身责任，而非真正解决问题。 --- ### 分析路径 #### L1 攻击面识别 1. **漏洞披露时间线矛盾**： - 用户于2023年12月23日提交路径穿越漏洞（CVE风格漏洞），但飞牛仅将其归类为普通BUG，未优先修复。 - 从漏洞提交到1月31日漏洞被公开曝光期间，攻击者已利用漏洞横向渗透，说明飞牛未主动监控漏洞利用行为。 2. **攻击路径暴露**： - 恶意程序通过替换xi统命令、植入内核后门、清除日志等高级手段长期驻留，表明漏洞未被彻底修复，且内部缺乏对异常行为的检测机制。 3. **数据泄露风险**： - 公告声称“未发现数据加密或破坏”，但恶意程序连接C2服务器且日志被清除，无法证明数据未被窃取，存在严重信息不对称。 #### L2 假设与验证 1. **假设1：漏洞修复流程存在缺陷** - **验证步骤**： - 检查漏洞修复版本（如v0.9.35+补丁）的commit记录，分析是否仅修复漏洞表面，未彻底清理后门或恶意代码。 - 调取飞牛内部工单xi统（如Jira）中关于该漏洞的处理记录，确认是否被标记为高危并优先处理。 2. **假设2：攻击者具有高级持续性威胁（APT）特征** - **验证步骤**： - 分析恶意程序代码中持久化机制（如chattr+i、内核模块伪装），确认是否针对特定xi统设计。 - 逆向C2通信协议，判断攻击者是否存在长期数据窃取行为。 #### L3 边界/异常场景 1. **未断开公网连接的合理性**： - 公告称因用户需访问数据而不断开公网连接，但攻击者可通过漏洞绕过认证直接接入，此逻辑自相矛盾。 - **验证步骤**： - 模拟攻击者利用漏洞远程访问未升级设备，验证飞牛是否具备快速隔离受感染节点的能力。 2. **日志清除对取证的影响**： - 清空审计日志导致无法追溯数据泄露范围，飞牛应提供替代方案（如内核级日志保护）。 #### L4 防御反推与修复 1. **漏洞管理漏洞**： - **修复建议**： - 建立**漏洞分级机制**，对路径穿越、命令注入等高危漏洞强制安全团队介入评估。 - 实施**代码审计流程**，要求所有提交代码必须通过静态分析工具（如Coverity、SonarQube）扫描，离职员工代码需独立审计。 2. **应急响应缺陷**： - **修复建议**： - 制定**零日漏洞响应预案**，在漏洞暴露初期强制断开受感染设备公网访问，优先保障用户数据隔离。 - 部署**实时漏洞利用检测xi统**（如Falco），监控异常行为并触发自动防御机制。 3. **透明度与信任问题**： - **修复建议**： - 公开受感染设备数量、C2通信数据量及溯源进展，以技术报告形式替代公关声明。 - 提供用户侧日志恢复工具或第三方审计通道，证明数据未被窃取（若属实）。 --- ### 验证步骤（最小可执行） 1. **漏洞修复验证**： - 下载飞牛最新版本fnOS固件，使用IDA或GDB逆向分析关键组件（如文件上传接口、命令执行模块），确认路径穿越漏洞是否被彻底修复。 2. **日志取证验证**： - 请求飞牛提供受感染设备的xi统日志备份（需经公证或第三方审计），检查是否存在数据外发记录。 3. **漏洞响应流程验证**： - 要求飞牛公开12月23日漏洞上报工单详情（如优先级、处理人、修复周期），对比同类高危漏洞的处理时效。 --- ### 总结 飞牛事件本质是**安全工程能力不足**与**组织责任缺失**的综合体现。若无法根本性重构漏洞管理、应急响应及透明沟通机制，其产品将长期暴露于xi统性风险中。用户应警惕NAS设备未公开的后门残留，并优先迁移数据至具备成熟安全体xi的云服务。