起因：
在近期使用飞牛时，发现会时不时的出现设备卡死、网络报错的情况，因为每天我都会通过飞牛去跑数据同步，所以没有关心这个问题，只以为是数据太多导致 FNOS 出现的什么莫名奇妙 Bug 。
直到本周周五，我又出现了这个问题，于是就想去查询一下是什么起因。
没想到，不查不知道，一查吓一跳，社区中许多人都出现了设备连接数异常、导致断网或无法连接飞牛服务器的情况。
再一搜索，这居然是一个很普遍的问题！社区中有人已经分析出这是一个专门针对 FNOS 的恶意程序，即便我已经开启了 SSL 、2FA ，且密码为非弱密码的情况下，这个恶意程序仍然植入到了我的设备。
根据一些大佬分析，飞牛疑似存在的 0day （路径穿越漏洞）可以在未授权的情况下可以访问整个 NAS 全部文件，包括系统的配置文件，这可能也是导致如上安全措施归零的主因之一。
这种 T0 级别的重大问题居然被官方一句 “别走 http 明文方式访问设备” 一笔带过，没有任何安全预警。像我一样的普通用户如果不是注意到近期的设备异常，甚至根本不知道有这么一回事。
这么大的一个技术团队，在出现这么大的安全事件后没有任何官方公告是什么用意？能不能有一个正面的态度？？？
附一些官方社群的分析：
https://club.fnnas.com/forum.php?mod=viewthread&tid=53230
https://club.fnnas.com/forum.php?mod=viewthread&tid=52580
在近期使用飞牛时，发现会时不时的出现设备卡死、网络报错的情况，因为每天我都会通过飞牛去跑数据同步，所以没有关心这个问题，只以为是数据太多导致 FNOS 出现的什么莫名奇妙 Bug 。
直到本周周五，我又出现了这个问题，于是就想去查询一下是什么起因。
没想到，不查不知道，一查吓一跳，社区中许多人都出现了设备连接数异常、导致断网或无法连接飞牛服务器的情况。
再一搜索，这居然是一个很普遍的问题！社区中有人已经分析出这是一个专门针对 FNOS 的恶意程序，即便我已经开启了 SSL 、2FA ，且密码为非弱密码的情况下，这个恶意程序仍然植入到了我的设备。
根据一些大佬分析，飞牛疑似存在的 0day （路径穿越漏洞）可以在未授权的情况下可以访问整个 NAS 全部文件，包括系统的配置文件，这可能也是导致如上安全措施归零的主因之一。
这种 T0 级别的重大问题居然被官方一句 “别走 http 明文方式访问设备” 一笔带过，没有任何安全预警。像我一样的普通用户如果不是注意到近期的设备异常，甚至根本不知道有这么一回事。
这么大的一个技术团队，在出现这么大的安全事件后没有任何官方公告是什么用意？能不能有一个正面的态度？？？
附一些官方社群的分析：
https://club.fnnas.com/forum.php?mod=viewthread&tid=53230
https://club.fnnas.com/forum.php?mod=viewthread&tid=52580
第 1 条附言 · 1 月 31 日
设备被感染特征：
- 无法使用官方的更新功能，提示错误或异常
- /usr/trim/bin/system_startup.sh 中存在异常的 wget 命令
- 近期出现死机、网络连接突然失效、网卡超时等情况
- 存在 /usr/sbin/gots 、/usr/trim/bin/trim_https_cgi 等病毒文件
若被感染，请断开外部网络，立即检查是否存在可疑进程
可参照社区这篇帖子进行修复： https://club.fnnas.com/forum.php?mod=viewthread&tid=53230
- 无法使用官方的更新功能，提示错误或异常
- /usr/trim/bin/system_startup.sh 中存在异常的 wget 命令
- 近期出现死机、网络连接突然失效、网卡超时等情况
- 存在 /usr/sbin/gots 、/usr/trim/bin/trim_https_cgi 等病毒文件
若被感染，请断开外部网络，立即检查是否存在可疑进程
可参照社区这篇帖子进行修复： https://club.fnnas.com/forum.php?mod=viewthread&tid=53230
第 2 条附言 · 1 月 31 日
在漏洞在野且 POC 已经被公布的当下，飞牛技术团队（广州铁刃智造技术有限公司）仍未发布任何关于本次 0day 问题的预警或公告，也没有发布任何专项补丁或修复工具。在官方论坛、社区中，针对此 0day 的后遗症全部以其他技术问题作为掩饰。此处建议停用该团队所发布的软件和产品，审慎评估其安全风险和可能带来的问题。
 |
102
J0d3r 1 月 31 日
|
 |
103
diudiuu 1 月 31 日
我已经拔掉电源了,自己设置了半天的禁止外网的端口,我发现好像没啥用
|
 |
104
JJBOOM 1 月 31 日
 |
 |
105
HojiOShi 1 月 31 日  3
只能说爱用多用，用国产系统的福报是这样的，想方便是吧，这么想方便不如直接用百度网盘。😂
|
 |
106
v2exgo 1 月 31 日
 一直不知道为啥要用国产 nas ，现在有 ai ，让 claude 搭建个 samba 文件系统，文件共享，各种服务就跟玩似的，有 debian 不用，非要自己搞这些，图个啥 |
 |
107
oppose2336 1 月 31 日
@Chengnan049 图 1 的吗，Beyond Compare
|
 |
108
python35 1 月 31 日
开了 FN connect 和放在公网都有中招的风险，跟 http 无关，我之前还以为是 http 传输 cookie 被盗的问题
我一直都没开 FN connect ，总觉得不安全 内网访问有 nat 挡着，接着奏乐接着舞😁 |
 |
109
MiKing233 1 月 31 日
@Chengnan049 #93 只是因为网络/监控都是用的他们家, 存储也选它们可以在统一的面板管理所有设备, 而且我设备都是机架式, 机架式的 NAS 就那几家, 群晖才是性价比完全没有
|
 |
110
Hugehard 1 月 31 日
还好我一直用 wireguard ，用 FN Connect 不就相当于把安全交给一个初创商业公司了吗，暴露后台端口到公网更是天真，但凡有点安全意识都不能干出这种事，只能说飞牛的宣传还是太好了，新人小白入坑太多
|
|
111
MiKing233 1 月 31 日
@f360967847 #87 因为这是漏洞本来就不是给你前端点的, 直接 Url 改成你想看的路径就好了, 像下面这样, 只要别人能够访问你的 Web 登陆界面就相当于能访问你设备上的所有文件, 写个脚本直接给你全拉走了, 用官方的 FN Connect 也没用, 只要外网能访问就相当于被看光
 |
 |
113
mcone 1 月 31 日
我擦 居然 2026 年还能看到这种漏洞...
|
 |
114
Joming 1 月 31 日
[]( https://hot.cm/image/ScreenShot-2026-01-31-233814-568.mZs)
关机是最安全的，已放弃使用！ |
 |
115
LnTrx 1 月 31 日
很好奇官方把锅甩到中间人攻击，到底是真不懂还是装不懂。无论是哪一种都很吓人。
|
 |
117
labubu 3 天前
拔电最安全（滑稽）
|
 |
118
donaldliang6 3 天前
路径： /usr/trim/bin/dockermgr
执行 strings ，结果如下 ``` leoknox@LeodeMacBook-Air ~ % strings dockermgr | grep -E "wget|curl|mirror" curl_easy_cleanup curl_easy_escape curl_easy_strerror curl_url curl_global_cleanup curl_easy_unescape curl_url_get curl_url_cleanup curl_url_set curl_easy_init curl_easy_setopt curl_easy_perform curl_free curl_slist_append curl_global_init curl_easy_getinfo curl_slist_free_all curl_easy_reset libcurl.so.4 mirrors-I mirrors-I mirrors-H mirrors-H mirrors-H mirrors-H mirrors-H t-mirrorH mirrors left-curly-bracket right-curly-bracket touch /run/test-mirror.json && dockerd --registry-mirror %s --validate --config-file /run/test-mirror.json Update the mirrors with v2 Invalid mirror name for url: {}, set to default name: {} Not found registry-mirrors in daemon.json Handle daemon mirror url: {}, name: {} mirrorsV2 current-mirror registry-mirrors mirrors-v2 mirrors Couldn't initialize curl handle ``` 其中包含这一行 ``` touch /run/test-mirror.json && dockerd --registry-mirror %s --validate --config-file /run/test-mirror.json ``` 其中的 %s 可以被用来注入 至于怎么先获取到登录状态，还在挖，估计是挖不出来了 哎，伪造的 cookie 不行 说一下我获得了什么吧 # 系统身份标识 - Machine ID - 管理员信息 # 加密密钥 - RSA 私钥 - 疑似静态 Secret （应该是系统初始化的 HMAC 密钥） # 系统架构深度洞察 - RPC 框架: 系统采用自研的 trim-rpc-go 框架，各组件通过 Unix 域套接字（如 /var/run/trim_http_cgi.socket ）进行通信 - 鉴权机制： 1. 双重校验: 系统同时使用 RS256 签名的 JWT （用于身份识别）和 HMAC-SHA256 签名（用于请求完整性校验） 2. 错误码 65534: 该错误码明确代表“签名校验失败”，意味着后端网关 trim_app_cgi 拦截了请求 # 配置管理 - 系统使用 trim_registry 工具动态管理配置，配置信息多以 JSON 格式存储或在内存中维护 # 关键日志分析 - 通过扒下来的 service_logger_data.db3 数据库 1. 确认管理员 确实使用 token 方式登录 2. 发现应用中心（ App Center ）频繁记录应用状态（如 APP_STARTED, APP_CRASH ），但目前内存中的 Session Map 计数为 0 # 当前瓶颈与渗透难点 - 无 Session 状态：/run/trim_token_counter 显示当前没有活跃会话，这导致后端不接受任何基于动态 Secret 的请求 - 签名屏障: 虽然获得注入点和私钥，但由于不知道确切的 fnos-Secret 计算逻辑（是静态 UUID 、machine_id 还是两者的派生值），无法通过 trim-rpc-go 的 HMAC 校验 睡了睡了，俺也不是专业的，就是好奇而已 话说我的靶子 nas 是不要了么，都现在了，没关机断网结束映射就算了，系统也没更新 |
 |
119
azhaojingjing 3 天前
所以这波下来，飞牛 OS 用户群体的 Linux 技术突飞猛进！
|
 |
120
quu 2 天前
http://NSA 地址/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../
|
Select Language