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

1 月 31 日
 izToDo
起因:
在近期使用飞牛时,发现会时不时的出现设备卡死、网络报错的情况,因为每天我都会通过飞牛去跑数据同步,所以没有关心这个问题,只以为是数据太多导致 FNOS 出现的什么莫名奇妙 Bug 。

直到本周周五,我又出现了这个问题,于是就想去查询一下是什么起因。
没想到,不查不知道,一查吓一跳,社区中许多人都出现了设备连接数异常、导致断网或无法连接飞牛服务器的情况。

再一搜索,这居然是一个很普遍的问题!社区中有人已经分析出这是一个专门针对 FNOS 的恶意程序,即便我已经开启了 SSL 、2FA ,且密码为非弱密码的情况下,这个恶意程序仍然植入到了我的设备。

根据一些大佬分析,飞牛疑似存在的 0day (路径穿越漏洞)可以在未授权的情况下可以访问整个 NAS 全部文件,包括系统的配置文件,这可能也是导致如上安全措施归零的主因之一。

这种 T0 级别的重大问题居然被官方一句 “别走 http 明文方式访问设备” 一笔带过,没有任何安全预警。像我一样的普通用户如果不是注意到近期的设备异常,甚至根本不知道有这么一回事。



这么大的一个技术团队,在出现这么大的安全事件后没有任何官方公告是什么用意?能不能有一个正面的态度???


附一些官方社群的分析:
https://club.fnnas.com/forum.php?mod=viewthread&tid=53230
https://club.fnnas.com/forum.php?mod=viewthread&tid=52580
18610 次点击
所在节点    信息安全
120 条回复
y1y1
1 月 31 日
这玩意刚开始疯狂引流的时候,有不少人劝不要用,这不福报就来了
Hantong
1 月 31 日
@PrinceofInj 是这样的, CVE 也应该有, 这种妥妥 CVSS 9.X 的洞, 毫无利用难度
jiuu
1 月 31 日
@Ryanxxx 测试了,没问题,这个漏洞好像是很老的版本才出现的,早就修复了吧。
bzcrl
1 月 31 日
这种东西 运营商机器对公的都不敢直接丢公网上 好几层放白的堡垒机用 u 盾才能跳过去 直接开放到公网上给全球做殴打测试 很不合理
yykadmin
1 月 31 日
@jiuu 1.1.12 还是 11 来着,刚刚才测试过,是有漏洞的,15 就已经 404 修了,明显已经知道漏洞存在,但是刻意隐瞒
strobber16
1 月 31 日
jjx
1 月 31 日
这个回复看不懂, 感觉味道不对

按这个意思是不是只要 http, 所有(非飞牛) 都会被攻击成功?
asuraa
1 月 31 日
我中招了, 无法更新,把这几个杀了之后就可以更新了
165924
1 月 31 日
这东西纯玩具性质的,还真有人正经用来存数据&开放公网啊
mercury233
1 月 31 日
@jjx #47 只要中间人读取明文 post 或篡改登录页,基本就能得到 http 服务的密码,如果这个服务的权限够高就能进一步入侵
jjx
1 月 31 日
@mercury233
都中间人了,啥都防不住啊

正常的情况 80 端口也只有服务端有漏洞才会被 入侵成功 , 至于被攻击, 啥协议都有可能阿
jjx
1 月 31 日
就像上面所说的造成连接过多, 也不算入侵成功
MiKing233
1 月 31 日
@jjx #47 无关 HTTP, 即使是 HTTPS 访问也一样, 只要别人能访问你的登陆面板就能拿到你 NAS 中的任何文件, 这是系统漏洞不是 TLS 传输层的问题
mercury233
1 月 31 日
@jjx #51 确实,飞牛这个漏洞看起来与中间人攻击是毫无关系的,带漏洞的服务不会因为 https 就更安全(因为浏览器的默认安全策略,可能还更危险一点,不过实际上还是暴露于中间人攻击更危险)
verygood
1 月 31 日
@MiKing233 https://imgur.com/a/11GjB0u
结合这个回复看来还有更大隐情,至少目前看隐瞒了很多信息,还在继续甩锅,有理由怀疑是否找到根因
verygood
1 月 31 日
MiKing233
1 月 31 日
@verygood 原因肯定已经找到了, 因为测试最新的 1.1.15 已经修好这个漏洞访问变成 404 了, 至于论坛...官方接着忽悠呗, 反正都是 user 的错, 是 user 没用 https 访问, 是中间人攻击, 是被境外 IP 利用了, 是第三方进程导致的 xxx, 总之资料泄露怪你自己下次注意点和我们没关系噢, 不公布不负责, 能忽悠一个是一个, 论坛大多数都是小白还被它们蒙在鼓里呢, 按剧本接下来要是瞒不住估计要请出临时工大法来祭天了
moyue
1 月 31 日
#!/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"


自查删除脚本,基于上面的自查脚本改造
shuiduoduo
1 月 31 日
通过域名固定高位端口 nginx 反代 会中招吗
a9htdkbv
1 月 31 日
@shuiduoduo 没升级到 1.1.15 的话,被扫到估计就会中招

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1189672

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX