飞牛 OS 疑似 0day 漏洞，许多用户设备遭到攻击，请尽快检查设备或暂停使用

@curtinp 加一条 还违反协议授权

搜索引擎看了下，2025 年 12 月底好像就有这个 Bug ，也是很离谱了：

https://club.fnnas.com/forum.php?mod=viewthread&tid=48354

我已经拔掉电源了,自己设置了半天的禁止外网的端口,我发现好像没啥用

只能说爱用多用，用国产系统的福报是这样的，想方便是吧，这么想方便不如直接用百度网盘。😂

一直不知道为啥要用国产 nas ，现在有 ai ，让 claude 搭建个 samba 文件系统，文件共享，各种服务就跟玩似的，有 debian 不用，非要自己搞这些，图个啥

@Chengnan049 图 1 的吗，Beyond Compare

开了 FN connect 和放在公网都有中招的风险，跟 http 无关，我之前还以为是 http 传输 cookie 被盗的问题
我一直都没开 FN connect ，总觉得不安全
内网访问有 nat 挡着，接着奏乐接着舞😁

@Chengnan049 #93 只是因为网络/监控都是用的他们家, 存储也选它们可以在统一的面板管理所有设备, 而且我设备都是机架式, 机架式的 NAS 就那几家, 群晖才是性价比完全没有

还好我一直用 wireguard ，用 FN Connect 不就相当于把安全交给一个初创商业公司了吗，暴露后台端口到公网更是天真，但凡有点安全意识都不能干出这种事，只能说飞牛的宣传还是太好了，新人小白入坑太多

@f360967847 #87 因为这是漏洞本来就不是给你前端点的, 直接 Url 改成你想看的路径就好了, 像下面这样, 只要别人能够访问你的 Web 登陆界面就相当于能访问你设备上的所有文件, 写个脚本直接给你全拉走了, 用官方的 FN Connect 也没用, 只要外网能访问就相当于被看光

@jjx 和中间人没关啊，直接起一个嗅探器检测端口，能打开 web 就能拿到文件

我擦 居然 2026 年还能看到这种漏洞...

[]( https://hot.cm/image/ScreenShot-2026-01-31-233814-568.mZs)
关机是最安全的，已放弃使用！

很好奇官方把锅甩到中间人攻击，到底是真不懂还是装不懂。无论是哪一种都很吓人。

@lnbiuc #26 你这个 changelog 图片和我见到的有一点细节不一样 ;)



亮点自寻

拔电最安全（滑稽）

路径： /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 是不要了么，都现在了，没关机断网结束映射就算了，系统也没更新

所以这波下来，飞牛 OS 用户群体的 Linux 技术突飞猛进！

http://NSA 地址/app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../