近期安全事件的完整说明与深刻反思
2026年2月12日
致所有飞牛用户：
近期飞牛系统发生了一起严重安全事件。这次安全事件，确实给部分用户带来了风险与困扰。
过去一段时间，我们一直把精力放到了系统安全的自查和改进上，没有公布事件的细节或做相应的公关。
无论出于什么考虑，未能第一时间充分保障用户知情权，都是我们的责任。在反复排查并相应的做出产品改进和补充后，现在也到了跟大家公开整个事件真实细节的时候了。
事件经过: 从发现到控制
1月20日-21日：入侵与发现
黑客利用系统漏洞开始入侵暴露公网IPv4地址的设备。
1月21日接到用户反馈后，我们连夜紧急联系了几百名内测用户，分析发现几例IPv4公网与http端口直接映射的用户，同样存在中木**情况。经过对入侵案例的分析确认：入侵者为CC攻击型远程控制木马，首次攻击时间为20日，暂未发现用户数据被加密或破坏。但由于病毒清除了关键系统日志，我们只能定位部分入侵路径，核心的"验证绕过"漏洞点尚未找到。
基于早期安全样本分析，异常行为主要集中在通过 HTTP 及公网 IPv4 访问的场景，因此我们在第一时间向存在类似访问特征的用户发送了安全提醒，以降低潜在风险。（后续确认该特征并非实际入侵路径，仅为攻击活动共性特征）
1月22日-30日：静默修复与攻坚
鉴于两点严峻现实，我们选择采取"先修复、后通告"策略：
- 风险权衡：当时入侵呈针对性特征，若贸然公告，极可能刺激黑客升级破坏（加密/删除数据），或瞬间吸引全网黑客利用尚未找到的"验证绕过"漏洞，进而引发大规模入侵；
- 用户习惯：同时考虑到安全更新覆盖需要一定时间（至今仍有用户停留老版本）。
因此，我们以常规版本升级名义推送了1.1.15，封堵已发现的漏洞以阻断入侵面，同时集中技术力量全力寻找缺失的关键验证绕过点。原计划待彻底封堵所有路径、用户大面积升级后，再提醒安全补丁更新。
30号，我们通过几个关键案例现场，完成了对入侵过程的逆向，并开始准备完整修复版本。
1月31日-2月1日：事态升级与紧急处置
安全论坛公开爆料飞牛漏洞并披露部分入侵方式，事件性质瞬间从单一黑客入侵转变为全网蠕虫式攻击。
大量黑客及模仿者开始对未打补丁的系统进行攻击探测，导致使用fnConnect中转的内网未暴露用户也遭受波及——这是我们最不愿看到的后果。
对于这个情况，我们立即采取两项措施：
- 凌晨紧急推送1.1.18正式版，修复全部三个漏洞（越权访问、路径穿越、验证绕过），全渠道(社区、短信、新媒体等多个渠道)发布安全通告；
- 主动中断未升级设备的fnConnect中转服务——此举虽影响部分用户访问，但为阻断攻击扩散所必需。
2月2日-至今 对抗攻击与查漏补缺
- 木马出现新变种（修改hosts阻止更新），我们推出云端查杀脚本对抗
- 官方服务遭受DDoS攻击，更新服务器一度承压
- 观察到定向撞库攻击，紧急增加云端防护
- 推送1.1.19版本，默认关闭SSH，引导密码修改与双重验证
- 持续进行代码审计、渗透测试、安全机制建设与整改
- 推送1.1.20版本，系统安全强化更新
根源反思: 漏洞为何如此低级
我们必须承认：这次漏洞（越权访问、路径穿越、验证绕过）属于基础安全缺陷，本不该发生。 根源在于：
- 重功能迭代轻安全：过去过度追求功能迭代速度，懈怠了安全基建投入；
- 安全反馈机制失效：在12月期间，论坛有用户反馈相关漏洞记录，我们虽提单上报，但相关人员缺乏安全视角，仅当作普通Bug，未按照高风险问题处理；
- 代码审核缺位：早期已离职人员的代码缺陷未被发现，后续也缺乏强制安全审计机制，导致漏洞遗留。
整改措施与长期承诺
过去一段时间，我们已开展以下整改：
后续我们会持续采取的措施：
- 扩大安全团队规模与研发投入，引入SDL安全开发流程
- 建立持续安全审核机制，每季度一次渗透测试，每年一次代码审计
- 建立漏洞分级响应与披露机制，高危漏洞24小时内响应与通知
- 定期接受第三方机构安全评估
- 持续发布用户NAS安全配置与防护指南
最后的话：
飞牛一直坚持免费开放，但免费绝不是可以忽视安全的理由。这次事件给大家带来的麻烦，我们深感自责。
我们也看到了大量用户的包容、理解与技术建议，这让我们在愧疚中更添动力。请相信：任何挫折都不能改变我们做好NAS系统的初心。
成长不能成为安全的借口，安全没有捷径，我们将用每一次代码提交、每一次安全更新、每一次透明沟通来证明。请用户和行业持续监督。
飞牛团队
2026年2月12日
2026-2-13 10:26:36
2026-2-13 10:37:20
2026-2-13 17:54:23 楼主
