Web 安全 on 逍遥笔记

虚拟发卡系统回调伪造漏洞全链路拆解 — 从备份文件泄露到批量盗取卡密

Thu, 13 Aug 2026 23:00:00 +0800

一分钟速读： 一个朋友的虚拟发卡站在一夜之间被批量盗走了上百张卡密。攻击者没有碰数据库，没有拿 Shell，甚至没有登录后台——他只是向一个公开的回调接口发送了一条精心构造的"支付成功"通知，系统就乖乖地把卡密吐了出来。本文从攻击日志逆向还原完整攻击链，揭示密钥泄露的两条路径——备份文件暴露（官方公告确认）与 Nginx 配置错误导致 Config.php 源码可读（日志分析发现），拆解回调签名机制的致命弱点，并用同一套方法对五个同类站点进行实测审计。

前言

事发后，ACG-Faka 官方发布了安全公告：

严禁在网站根目录存放备份文件。 近期排查发现，多个 V3 新版网站出现伪造支付回调，主要原因是在网站根目录存放了整站备份、数据库备份或 ZIP 压缩包。这些文件可被公网直接下载，其中通常包含支付密钥、货源接口密钥、数据库账号密码等敏感信息。攻击者获取后，可直接伪造支付回调并自动提取商品。

公告一针见血：问题不在签名算法，而在密钥泄露。 签名算法再安全，密钥被攻击者拿到了也白搭。

那密钥是怎么泄露的？公告指出是备份文件，我们的日志分析还发现了另一条独立路径——Nginx 配置错误导致 PHP 源码直接暴露。两条路径殊途同归，都指向同一个运维盲区：敏感文件可被公网直接下载。

虚拟发卡系统的核心流程很简单：

用户下单 → 跳转支付网关 → 链上确认 → 网关回调通知 → 系统标记已付 → 释放卡密

问题出在第四步。支付网关（BEpusdt）向发卡系统（ACG-Faka）发送回调通知时，系统需要验证这条通知确实来自网关、而非攻击者伪造。如果验证机制存在缺陷，攻击者就可以跳过真实支付，直接"通知"系统订单已付，白拿卡密。

这不是假设场景。我拿到了一份真实攻击日志，下面是完整拆解。

一、攻击复盘：从日志还原 660 条请求

1.1 攻击时间线

通过分析受害站点的 Nginx Access Log，攻击者（IP: 203.27.106.***）的行为可以清晰地分为四个阶段：

时间	阶段	行为	日志特征
14:22	路径探测	尝试 `/callback/BEpusdt` vs `/callback.BEpusdt`	404 → 200，锁定正确路径格式
14:50	签名试探	发送全零签名 `000...000`	29 字节响应 = `{"code":0,"msg":"sign error"}`
17:01	源码窃取	反复请求 `/app/Pay/BEpusdt/Config/Config.php`	200，响应体包含 PHP 源码
17:32	首次得手	发送携带正确签名的伪造回调	33 字节响应 = `{"code":200,"msg":"success"}`
18:31+	批量收割	自动化脚本，每 6 秒一单	持续 33 字节成功响应

注意 14:50 到 17:01 之间的两小时空白——攻击者在第一次签名试探失败后，没有继续暴力枚举签名，而是转向了一个完全不同的方向：读源码。

1.2 响应大小指纹

Nginx 日志中的 body_bytes_sent 字段暴露了一切：

29 字节 → {"code":0,"msg":"sign error"} # 签名错误，攻击失败
35 字节 → {"code":0,"msg":"handle not found"} # 插件不存在
33 字节 → {"code":200,"msg":"success"} # 攻击成功，订单被标记已付

当日志中突然出现 33 字节的响应时，攻击已经得手了。

二、回调签名机制：为什么能被伪造

2.1 BEpusdt 的签名算法

BEpusdt 是一个 USDT 收款网关，当链上确认收款后，它向商户系统发送 HTTP POST 回调。签名计算方式：

signature = MD5( 按字母排序的参数字符串 + API_TOKEN )

具体来说：

# 1. 取所有非空参数（排除 signature 本身）
params = {k: v for k, v in data.items() if v != '' and k != 'signature'}

# 2. 按 key 字母排序，拼接成 key=value& 格式
sorted_str = '&'.join(f'{k}={params[k]}' for k in sorted(params.keys()))

# 3. 末尾拼接 API Token，取 MD5
signature = md5(sorted_str + api_token)

商户端验证时，用自己存储的 API Token 重新计算签名，与收到的签名做比对。

这个算法本身没有问题。 问题在于：

如果 API Token 泄露了，攻击者可以算出合法签名
如果 API Token 为空，签名 = MD5(params + "")，任何人都能算
如果比对方式有缺陷（PHP 弱类型），签名验证可被绕过

2.2 ACG-Faka 的回调处理流程

ACG-Faka 收到回调请求后的处理链：

/user/api/order/callback.{Handle}
 ↓
路由到对应插件（BEpusdt / Epusdt / Alipay）
 ↓
插件的 Signature.php 验证签名
 ↓
验证通过 → Order.php 更新订单状态 → 释放卡密
 ↓
返回 "success"（BEpusdt）或 "ok"（Epusdt）

关键文件：

文件	作用
`app/Pay/BEpusdt/Config/Config.php`	存储 API Token（签名密钥）
`app/Pay/BEpusdt/Impl/Signature.php`	签名验证逻辑
`app/Service/Bind/Order.php`	订单状态更新

三、根因分析：密钥泄露的两条路径 + 两重代码缺陷

攻击成功的前提是拿到 API Token。从目前掌握的信息看，攻击者有两条互相独立的路径可以拿到密钥，命中任何一条就够了。

3.1 路径一：备份文件泄露（官方公告确认）

这是官方通告明确指出的主因。很多站长习惯用宝塔面板的"一键备份"功能，把整站打包成 .zip 或 .tar.gz 放在网站根目录：

/www/wwwroot/faka/
├── index.php
├── app/
│ └── Pay/BEpusdt/Config/Config.php ← 包含 API Token
├── config/
│ └── database.php ← 包含数据库密码
├── site_backup_20260810.zip ← 整站备份，包含以上所有文件
└── db_backup_20260810.sql ← 数据库导出，包含所有订单和卡密

Nginx 默认会把 .zip 当静态文件返回。攻击者只需猜到文件名（常见模式：backup.zip、www.zip、域名.zip、日期.zip），就能一次性下载全站源码 + 数据库，其中包括支付密钥、数据库凭据、货源接口密钥——全部明文。

这比后面要说的 Config.php 泄露更严重，因为数据库备份里连卡密都有，攻击者甚至不需要走伪造回调这条弯路。

3.2 路径二：Nginx 配置错误导致 Config.php 直接暴露

这是我们在日志分析中发现的另一条路径。ACG-Faka 的 PHP 配置文件存放在 /app/Pay/BEpusdt/Config/Config.php。如果 Nginx 没有做目录级 deny：

# ❌ 缺少这条规则，攻击者可以直接请求 PHP 文件
location ~* ^/(app|config|runtime|vendor)/ {
 deny all;
}

后果因 Nginx 对 .php 的路由配置而异：

Nginx 配置	请求 Config.php 的结果	危险等级
`.php` 正确路由到 PHP-FPM	PHP 执行 `return [...]`，输出为空（200 空响应）	⚠️ 中
`.php` 未路由到 PHP-FPM（当静态文件返回）	PHP 源码原文输出，API Token 明文暴露	🔴 致命

第二种情况在宝塔面板上比想象中常见——如果 Nginx 的 location ~ \.php$ 规则只匹配了网站根目录下的 .php 文件，深层路径（如 /app/Pay/.../Config.php）的 .php 可能不会交给 PHP-FPM 处理，而是被当成普通文本文件返回。

攻击者直接看到了：

<?php
return [
 'api_url' => 'https://pay.example.com',
 'api_token' => 'a1b2c3d4e5f6...', // ← 签名密钥，明文暴露
];

我们审计的五个站中，Config.php 都返回 200 空响应（PHP 正确执行了 return []），Token 没有泄露。但路径可达本身就是隐患——如果未来某次运维操作改了 PHP-FPM 配置，Token 就会暴露。

两条路径的关系： 备份文件是"一锅端"，Config.php 是"精准窃取"。攻击者会两条路都试——先扫备份文件（自动化成本低），扫不到再尝试直接读 Config.php。实际攻击日志中两种行为都有出现。

3.3 代码缺陷一：PHP 弱类型比较（高危）

即使 Token 没有泄露，BEpusdt 插件的签名比对方式也可能存在问题。如果 Signature.php 使用了 PHP 的 ==（宽松比较）而非 ===（严格比较）或 hash_equals()：

// ❌ 危险：PHP 弱类型比较
if ($calculated_sign == $received_sign) { ... }

// 攻击向量：
// - signature=0 → int(0) == "any_string" 在特定条件下为 true
// - signature=false → false == "" 为 true
// - signature=[] → 数组与字符串比较行为不可预测

安全的实现应该是：

// ✅ 安全：类型检查 + 时序安全比较
if (!is_string($sign) || $sign === '') {
 return false;
}
return hash_equals($calculated, $sign);

hash_equals() 的作用有两个：

防止类型混淆——只接受字符串
防止时序攻击——比较耗时恒定，不会因为前几位匹配而提前返回

3.4 代码缺陷二：回调端点无访问控制（中危）

回调端点 /user/api/order/callback.BEpusdt 对任何 IP 开放。攻击者可以从任意位置发送请求，系统只靠签名验证来区分合法回调与伪造请求。

理想状态下，应该叠加 IP 白名单：

location ~* ^/user/api/order/callback\. {
 allow 1.2.3.4; # 支付网关服务器 IP
 deny all;
}

即使签名验证被绕过，IP 白名单也能兜底。

四、完整攻击链

两条密钥泄露路径最终汇聚到同一个攻击终点：

 ┌─────────────────────────┐ ┌─────────────────────────────┐
 │ 路径 A: 备份文件扫描 │ │ 路径 B: Config.php 直读 │
 │ GET /backup.zip │ │ GET /app/Pay/BEpusdt/ │
 │ GET /www.zip │ │ Config/Config.php │
 │ GET /db_2026.sql │ │ (Nginx 未路由到 PHP-FPM) │
 │ → 下载整站+数据库 │ │ → PHP 源码明文返回 │
 └────────────┬────────────┘ └──────────────┬──────────────┘
 │ │
 │ ┌────────────────────┐ │
 └────►│ API Token 泄露 ★ │◄────┘
 └─────────┬──────────┘
 │
 ┌───────────────▼───────────────┐
 │ Step 1: 路径探测 │
 │ GET /user/api/order/callback. │
 │ → 确认 BEpusdt Handle 存在 │
 └───────────────┬───────────────┘
 │
 ┌───────────────▼───────────────┐
 │ Step 2: 伪造合法回调 │
 │ 用窃取的 Token 计算 MD5 签名 │
 │ POST callback.BEpusdt │
 │ → "success" (33B) ★ │
 └───────────────┬───────────────┘
 │
 ┌───────────────▼───────────────┐
 │ Step 3: 批量收割 │
 │ 自动化创建订单 → 伪造回调 │
 │ → 查询卡密 → 每 6 秒一单 │
 └───────────────────────────────┘

整个过程不需要任何漏洞利用工具，只需要 curl 和 md5sum。路径 A 甚至不需要走回调——数据库备份里直接就有卡密。

五、五站实测审计

拿到攻击手法后，我用同一套方法对五个同类站点进行了黑盒审计。测试矩阵包含 13+ 种攻击向量，每次攻击后通过 API 验证订单状态是否变化。

5.1 攻击向量

#	向量	目标
A1	全零签名 / 随机签名	基础验签能力
A2	空签名 / 缺失签名字段	空值绕过
A3	`signature=0` (int)	PHP `==` 弱类型：`0 == "string"`
A4	`signature=false`	PHP `==` 弱类型：`false == ""`
A5	`signature=[]` (数组)	PHP 数组比较行为异常
A6	空密钥 MD5 签名	Token 为空时可伪造
A7	空密钥 HMAC-SHA256	同上，适配 Epusdt 插件
A8	金额篡改 (0.01)	金额绑定验证
A9	非成功 status 值	状态字段校验
A10	form-urlencoded 格式	Content-Type 混淆
A11	路径穿越 Handle	插件路由安全

5.2 审计结果

站点	框架	回调安全	状态验证	源码泄露	CF 防护	综合
站点 A	ACG-Faka	✅ 34/34 SAFE	有 API	路径泄露	无	⚠️ 中
站点 B	ACG-Faka	✅ 全部 SAFE	有 API	路径泄露	无	⚠️ 中
站点 C	Next.js/Vercel	N/A	需认证	无	全站	✅ 低
站点 D	ACG-Faka	✅ 全部 SAFE	无 (404)	路径+composer	无	⚠️ 中
站点 E	ACG-Faka	✅ 64/64 SAFE	有 API	路径+composer	无	⚠️ 中

关键发现：

回调签名验证全部正常——五个站都没有被伪造回调突破
但四个 ACG-Faka 站都有源码路径泄露——攻击者可以看到 Fatal Error 中暴露的物理路径
Config.php 虽然返回 200 空（PHP 正确执行了），但路径可达本身就是隐患
唯一一个 Next.js + Vercel 站完全不受此类攻击影响——非 PHP 框架，无弱类型问题，Vercel 不暴露源码

5.3 为什么这五个站没被攻破

没有备份文件暴露——五个站的 Web 根目录下没有扫到可下载的 .zip / .sql / .bak 文件
Config.php 正确走了 PHP-FPM 路由——返回 200 空响应，Token 没有泄露

但隐患仍在：四个 ACG-Faka 站的 /app/ 路径仍然可达，只是 PHP-FPM 兜住了。如果未来某次运维操作改错了 PHP-FPM 配置，或者站长在根目录放了一次备份文件，攻击者立刻就能得手。这是一颗定时炸弹。

六、防御方案

6.1 P0 紧急修复（立即执行）

清理并封锁备份文件——这是最紧急的一步：

# 1. 立即删除 Web 根目录下的所有备份文件
find /www/wwwroot/faka/ -maxdepth 1 \
 \( -name "*.zip" -o -name "*.tar.gz" -o -name "*.rar" \
 -o -name "*.sql" -o -name "*.bak" -o -name "*.7z" \) \
 -exec rm -f {} \;

# 2. 在 Nginx 中彻底封锁备份文件下载

# 封锁所有备份/归档文件类型
location ~* \.(zip|tar\.gz|rar|sql|bak|7z|gz|tgz)$ {
 deny all;
 return 403;
}

Nginx 封锁源码目录——阻断 Config.php 泄露路径：

# 阻止所有对 PHP 源码、配置、运行时文件的直接访问
location ~* ^/(app|config|runtime|vendor)/ {
 deny all;
 return 403;
}

# 阻止敏感文件
location ~* (composer\.(json|lock)|\.env|\.git) {
 deny all;
 return 403;
}

更换所有凭据——如果曾经在 Web 目录放过备份文件，必须假设已泄露，一律重置：

API Token（支付密钥）
数据库密码
货源接口密钥
后台管理员密码

升级签名验证——确认 Signature.php 使用 hash_equals() + is_string() 类型检查：

public static function safetyEquals(mixed $str, string $local): bool
{
 if (!is_string($str) || $str === '') {
 return false;
 }
 return hash_equals($local, $str);
}

6.2 P1 加固措施

回调端点 IP 白名单：

location ~* ^/user/api/order/callback\. {
 allow 支付网关IP;
 deny all;
}

签名算法升级——从 MD5 升级到 HMAC-SHA256：

// MD5 拼接（BEpusdt 默认）→ 容易被长度扩展攻击
$sign = md5($sorted_string . $token);

// HMAC-SHA256（推荐）→ 密钥参与哈希内部运算，无法伪造
$sign = hash_hmac('sha256', $sorted_string, $token);

6.3 P2 监控告警

回调端点频率限制（单 IP 每分钟 ≤ 10 次）
异常响应监控：连续出现 33 字节（success）响应时触发告警
回调日志独立记录：IP、签名、时间、订单号，便于事后追溯

6.4 架构层面

如果条件允许，考虑迁移到非 PHP 框架（如 Next.js + Vercel），从根本上消除 PHP 弱类型比较和源码泄露的风险。审计中唯一零风险的站点正是这种架构。

七、总结

这次攻击的本质不是密码学层面的签名绕过，而是运维层面的密钥泄露。攻击者有两条路可走：

路径 A: Web 根目录残留备份文件（.zip / .sql）
 → 攻击者下载备份 → 解压得到全部凭据（甚至直接拿到卡密）

路径 B: Nginx 配置错误，Config.php 当静态文件返回
 → 攻击者读取 PHP 源码 → 得到 API Token

两条路殊途同归：
 → 用 Token 计算合法 MD5 签名
 → 伪造回调通知
 → 系统认为已付款
 → 卡密被释放

官方通告指向路径 A，日志分析发现路径 B。多个受害站点同时存在两个问题。

修复其实不复杂——删备份文件、加 Nginx deny 规则、换密钥，三步就能阻断整条链。但现实是，四个受审计的 ACG-Faka 站点连 /app/ 目录的 deny 规则都没有。

安全不是只靠签名算法。签名验证是最后一道防线，不应该是唯一一道。 纵深防御意味着即使签名被绕过，IP 白名单能兜底；即使白名单没配，源码和备份至少不应该暴露密钥。任何一层失守都不会导致全盘崩溃——这才是安全架构的正确姿势。

本文所有测试均在授权范围内进行，已获得站点所有者许可。文中不包含任何真实域名和凭据。

一次 Nginx Lua 木马应急响应实录：从移动端跳转博彩站到 root 级入侵溯源

Sun, 21 Jun 2026 17:00:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

事件等级：🔴 严重 — 已确认 root 级入侵 攻击链：root SSH 认证登录 → Nginx Lua 木马植入 → 服务脚本持久化 → 日志清洗 持久化方式：init.d 服务脚本回灌 + chattr +i 文件锁定 + 时间戳伪造 处置结果：活跃链路已切断，已知残留已隔离，证据已归档

一、事件概述

某电商站点运维人员收到用户反馈：移动端访问站点时偶发跳转到博彩风格的外部页面，桌面端访问正常。同时该站点通过 CDN 访问时频繁出现 520 错误。

初步排查后发现，这不是前端 Bug，也不是支付插件异常，而是一次已经落证的服务器侧入侵事件。攻击者通过已认证的 root SSH 会话进入系统，在 Nginx 层植入 Lua 恶意模块实现流量劫持，并配合了服务脚本持久化、文件不可变属性锁定和日志清洗等全套反取证手段。

本文脱敏后完整记录此次应急响应的全流程，包括排查思路、取证方法、处置步骤和经验教训。

二、事件影响

业务层面：移动端用户访问站点时被服务端重定向到外部博彩风格域名，直接影响用户体验和业务信誉。
CDN 层面：CDN 出现间歇性 520 错误，并非单纯的 CDN 问题，而是叠加了 Nginx worker 进程崩溃风险。
支付链路：排查期间发现支付反代服务偶发超时，经分析属于 Docker 网络桥接配置问题，与 Lua 木马无直接关联。
运维安全：root 密码登录仍处于开放状态，且系统日志被清洗，导致部分入侵入口无法百分百回溯。

三、核心时间线

3.1 首次入侵（约一个月前）

HIDS 记录到一条真实的 root SSH 会话，该会话执行了以下操作：

动作	说明
修改 Nginx 配置文件	操作 `proxy.conf` 等反向代理配置
植入恶意 Lua 文件	将恶意 WAF 脚本写入 Nginx 相关目录
锁定文件	对植入文件执行 `chattr +i` 使其不可变
伪造时间戳	修改文件修改时间，掩盖植入时间点
重启 Nginx	执行 `nginx -t && /etc/init.d/nginx restart` 使木马生效
清洗日志	清空 `/var/log/auth.log`、`wtmp`、`btmp`、审计日志
清除痕迹	执行 `history -c` 和 `lastlog` 清除命令历史和登录记录

关键判断：这不是端口扫描或爆破尝试，而是「已认证」的入侵行为——攻击者拥有合法的 root 凭据。

3.2 第二次落地（事发当天凌晨）

系统出现第二段落地行为：

服务启动脚本 /etc/init.d/nginx 被植入恶意回灌逻辑
出现可疑的 .so 动态库文件
出现隐藏标记文件，内容为木马版本标识
内核日志出现 Nginx worker 进程的段错误

关键判断：这不是临时文件误报，而是服务重启级的持久化链路——即使当前恶意文件被删除，重启 Nginx 后木马会自动复活。

3.3 应急响应窗口

从用户反馈到完整处置，应急响应推进路径如下：

复现移动端 UA 与桌面端访问表现差异
对比应用层日志和 Nginx 访问日志
确认异常 302 重定向出现在 Nginx 层而非 PHP 应用层
通过 nginx -T 导出全量配置，顺 Lua 加载路径定位恶意模块
先备份证据，再替换为 no-op 空壳
深挖持久化点，确认 init.d 脚本回灌逻辑
清理认证面、隔离残留样本、打包证据并记录哈希
复测移动端、桌面端、支付接口和关键服务状态

四、排查分析过程

4.1 区分问题层级

用户报障后，首先要判断异常发生在哪一层：

层级	如果是这层的问题	实际表现
前端 / CDN 缓存	服务端日志仍返回正常 HTML	❌ 服务端日志存在异常 302
PHP 应用层	应用代码、路由或日志中能找到跳转逻辑	❌ 应用层无异常
Nginx 请求入口层	访问日志出现应用无感知的 302	✅ 命中了

本次通过移动端 UA 请求复现了 302，并发现跳转参数中包含原始域名和设备类型，说明跳转逻辑在 HTTP 请求入口层——也就是 Nginx 层被劫持。

4.2 访问日志分析

访问日志中出现了关键特征：

正常路径如 /、/item/1、/products → 间歇性 302，与正常 200 混杂

这个特征非常关键：

正常业务跳转通常有稳定规则（如未登录跳登录页）
恶意流量劫持常按设备类型、流量比例、来源 Referer 或时间随机触发
本次恶意 Lua 中确实存在移动端比例控制逻辑——只在部分移动端请求中触发跳转

4.3 定位 Nginx Lua 加载链

审计 nginx -T 全量配置后，重点排查以下位置：

lua_package_path — Lua 模块搜索路径
rewrite_by_lua / access_by_lua — 请求阶段 Lua 钩子
include luawaf.conf — WAF 配置文件
Nginx Lua 库目录
WAF 脚本目录
反向代理配置文件

最终确认活跃恶意模块是一个伪装成正常模块名的 .lua 文件，内容包含：

外部博彩风格跳转域名
移动端 UA 识别和比例触发逻辑
远程配置拉取功能
ngx.redirect() 跳转实现

与线上表现完全一致。

4.4 先取证再处置

本次没有直接删除任何可疑文件。 原因：

直接删除会破坏法证链，无法回溯入侵过程
直接删除 Lua 文件可能导致仍存在的调用点把 Nginx 打挂
攻击者使用了 chattr +i、时间戳伪造和重启回灌，单点删除不能解决持久化

处置策略：

将恶意原件保留到证据备份目录
生产路径中的恶意 Lua 替换为同名 no-op 空壳模块
保留导出函数签名，避免隐藏调用点异常
执行 nginx -t 验证配置后再 reload

4.5 追踪持久化机制

仅替换当前活跃恶意模块后，不能认为修复完成。后续检查发现 init.d 服务脚本已被改造：

从外部 URL 拉取远程载荷
向 Nginx 配置文件写入 Lua 钩子
操作 lua_package_path 确保模块加载
操作 ld.so.preload 预加载共享库
配合 chattr +i 保护植入文件

这就是木马的复活机制——只要 Nginx 服务重启，远程载荷会重新落地，配置会被重新注入。清理当前文件而不处理服务脚本，等于什么都没修。

4.6 用 HIDS 建立根因证据链

系统日志和 shell history 被清空后，常规取证手段失效。本次的关键证据来自 HIDS（主机入侵检测系统）的日志：

HIDS 中保留了 root SSH 会话记录及命令样本
能证明约一个月前已发生真实入侵
这个证据比猜测 IP 来源、猜测插件漏洞有价值得多

教训：HIDS 日志是日志清洗后唯一可信的证据源，必须保证不被同机单点覆盖，最好外送或异地备份。

4.7 扩展扫描残留

切断已知攻击链后，继续检查：

检查项	内容
进程	当前进程列表、高 CPU 进程
端口	监听端口和对应进程
服务	systemd 启用服务和 timer
定时任务	root 与系统级 crontab
预加载	`/etc/ld.so.preload`
启动脚本	shell profile、自启动脚本
认证文件	authorized_keys、uid=0 账户
SUID	SUID 提权文件
Nginx worker	当前加载的动态库映射
近期变更	最近修改的系统文件
IOC 搜索	恶意模块名、可疑域名、隐藏标记文件

最终确认并隔离了三个残留工件：隐藏标记文件、恶意动态库、异常数据文件。

4.8 认证面收敛（避免自锁）

发现 root 已泄露后，凭据轮换必须做，但不能为了「看起来更安全」直接关闭当前唯一的远程入口。

本次策略：

清空 root 的 authorized_keys
隔离未确认但仍需使用的 SSH 密钥
确认没有其他 uid=0 账户或异常用户的认证文件
暂时保留 root 密码登录，等待新管理员入口就绪后再关闭

这是安全和可运维之间的必要取舍——没有替代入口时直接关闭 root 登录，只会把正常运维锁在外面。

4.9 四层验证

验证层次	检查内容	结论
配置层	`nginx -t`、`nginx -T` 全量导出	✅ 无语法错误，无恶意 include
运行层	进程、端口、worker 映射库、内核日志	✅ 无崩溃，无异常动态库加载
业务层	移动端 UA / 桌面端 UA 访问核心页面	✅ 200 正常，无跳转
支付层	支付配置接口、支付回调日志	✅ 200 正常

只看服务状态 active 不等于业务可用；只看页面返回 200 也不等于木马已清理。必须四层同时验证。

五、处置措施总结

已执行操作

将恶意 Lua 模块替换为 no-op 安全空壳
将恶意 WAF 脚本替换为安全空壳
移除 init.d 服务脚本中的恶意回灌逻辑
移除 Nginx 全局配置中的异常 lua_package_path
去除攻击者遗留在相关文件上的 immutable 属性
隔离隐藏标记文件、恶意动态库、异常数据文件
清理 root 本机 SSH 私钥驻留
归档完整事件证据并生成 SHA256 校验值
恢复 Docker bridge 网关，修复支付反代超时问题

后续动作

24 小时内：

持续观察 Nginx 访问日志中的异常状态码
持续观察内核日志中的 worker 崩溃
观察支付链路的稳定性
保存 CDN 安全事件和访问日志

1-3 天内：

新建非 root 管理员用户并配置公钥
验证新入口可用后，关闭 root 密码直接登录
轮换面板密码、API key、部署密钥和数据库密码
将关键日志外送或定时同步到异地

中期：

评估系统重装和业务迁移窗口
用干净系统重新部署服务栈
只迁移业务数据，不迁移旧系统脚本和二进制
建立上线后基线：端口清单、文件哈希、日志保留策略

六、经验教训

1. 偶发跳转必须优先怀疑请求入口层

移动端跳转博彩站、桌面端偶发正常——这是典型的按 UA 或比例触发的流量劫持特征。不能只从前端缓存或应用路由找原因，必须第一时间查 Nginx 层的异常。

2. CDN 520 可能是源站进程崩溃

CDN 的 520 错误表示源站连接异常。本次 520 与恶意 .so 文件导致的 Nginx worker 进程崩溃直接相关。排查 CDN 错误时必须同时看源站内核日志和 worker 状态。

3. 单点删除木马不等于修复

攻击者使用了：

服务脚本持久化（重启复活）
chattr +i 文件不可变属性（防删除）
时间戳伪造（掩盖时间线）
日志清洗（销毁证据）

只替换一个恶意文件会留下重启复活的风险，必须深挖持久化链。

4. 证据保存必须早于清理

先打包证据、记录哈希、保留备份，再清理生产路径。否则后续无法解释完整的入侵链，也无法判断是否存在第二阶段攻击。

5. 安全加固不能盲目锁死

关闭 root 密码登录是正确方向，但前提是有可验证的新管理员入口。没有替代入口就直接关闭，等于把自己也锁在门外。

6. HIDS 是日志清洗后唯一的可信证据源

系统日志被清空后，HIDS 日志成为了唯一能证明入侵时间点和攻击行为的关键证据。后续必须保证 HIDS 日志异地存储，不能被同机攻击者一并清理。

7. 运行态问题要和入侵事件分层处理

本次排查中发现的支付反代超时问题，经分析是 Docker 网络配置问题，与 Lua 木马无关。应急响应中必须严格区分：

安全事件（入侵、木马、持久化）
运行态故障（网络、配置漂移、资源耗尽）
业务 Bug（代码逻辑、支付流程）

混为一谈会误导排查方向，浪费时间。

七、应急响应检查清单

以下模板可直接复用于类似事件的排查：

1. 复现用户侧异常
 记录 UA、URL、时间、响应码、跳转目标

2. 分层对比日志
 CDN → Nginx → 应用 → 系统日志，定位异常发生层级

3. 审计 Web 服务器配置
 导出全量配置，检查 Lua/WAF/include/proxy/rewrite/动态模块

4. 搜索 IOC
 关键词搜索，但不要在取证前删除任何文件

5. 取证归档
 对可疑文件做 stat、lsattr、sha256sum、备份归档

6. 检查持久化点
 systemd、init.d、cron、profile、ld.so.preload、Docker entrypoint

7. 检查认证面
 uid=0 账户、authorized_keys、私钥、面板用户、API key

8. 检查运行态
 进程、端口、worker 映射库、内核崩溃日志

9. 最小化清理
 先切断活跃链路，再处理持久化机制和残留文件

10. 重新验证
 配置层 → 运行层 → 业务层 → 支付层，四层全部验证

11. 归档与复盘
 归档证据和哈希，记录回滚点与剩余风险

八、判断边界

可以确认的：

存在已认证的 root SSH 入侵行为
存在 Nginx 服务脚本级持久化机制
移动端博彩跳转来自服务端 Nginx Lua 恶意模块
恶意动态库与 Nginx worker 进程崩溃相关
已知活跃链路已切断，已知残留已隔离

不能百分百确认的：

最初 root 凭据是如何泄露的
是否还存在未知 rootkit 或内核级隐藏组件
不同时间点的两次操作是否完全同源
不重装系统的情况下机器是否永远可信

因此后续安全策略不应停留在「已清理木马」，而应按「已发生 root 级入侵后的恢复流程」推进——最终闭环仍是重装系统、重建凭据、重新部署业务。

本文由真实应急响应案例脱敏整理，涉及域名、IP、路径等信息已做匿名化处理。

CVE-2026-33032：Nginx UI MCP 未授权访问漏洞详解 (CVSS 9.8)

Fri, 17 Apr 2026 04:30:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

漏洞等级: 🔴 CRITICAL (CVSS 9.8) 影响版本: Nginx UI ≤ 2.3.5 CVE 编号: CVE-2026-33032 CWE 编号: CWE-306 (关键功能缺少认证) 披露日期: 2026-03-30 最后更新: 2026-04-16

漏洞概述

CVE-2026-33032 是 Nginx UI（Nginx 服务器的 Web 管理界面）中的一个严重未授权访问漏洞。攻击者可以利用该漏洞在无需任何身份认证的情况下，通过 MCP (Model Context Protocol) 集成端点执行任意管理操作，包括：

🔄 重启 Nginx 服务
📝 创建/修改/删除 Nginx 配置文件
⚡ 触发自动配置重载
🎯 完全接管 Nginx 服务

该漏洞的 CVSS 3.1 基础评分为 9.8 (CRITICAL)，攻击向量为网络 (AV:N)，攻击复杂度低 (AC:L)，无需权限 (PR:N)，无需用户交互 (UI:N)，对机密性、完整性、可用性均有高影响 (C:H/I:H/A:H)。

漏洞原理

问题根源

Nginx UI 的 MCP 集成暴露了两个 HTTP 端点：

端点	认证要求	状态
`/mcp`	IP 白名单 + AuthRequired() 中间件	✅ 安全
`/mcp_message`	仅 IP 白名单	❌ 存在漏洞

致命缺陷

/mcp_message 端点的问题在于：

仅应用 IP 白名单检查，没有身份认证
默认 IP 白名单为空 ([])
空白的 IP 白名单被中间件解释为 “允许所有 IP”

这意味着任何能够访问 Nginx UI 的网络攻击者都可以：

任意攻击者 → /mcp_message → 调用所有 MCP 工具 → 完全控制 Nginx

代码层面分析

根据 GitHub 安全公告 (GHSA-h6c2-x2m2-mwhf)，问题出在中间件配置上：

// /mcp 端点 - 正确配置
app.use('/mcp', ipWhitelistMiddleware, AuthRequired(), mcpHandler);

// /mcp_message 端点 - 错误配置
app.use('/mcp_message', ipWhitelistMiddleware, mcpHandler);
// ⚠️ 缺少 AuthRequired() 中间件
// ⚠️ 默认 ipWhitelist = [] 被解释为允许所有

影响范围

受影响版本

软件	受影响版本	修复版本
Nginx UI	≤ 2.3.5	暂无公开补丁

CPE 标识

cpe:2.3:a:nginxui:nginx_ui:*:*:*:*:*:*:*:* versions up to (including) 2.3.5

潜在影响

如果 Nginx UI 暴露在公网或不受信任的网络中，攻击者可以：

服务中断: 重启 Nginx 导致网站下线
配置篡改: 修改 Nginx 配置植入恶意规则
反向代理滥用: 配置反向代理进行流量劫持
SSRF 攻击: 利用 Nginx 的 proxy_pass 功能内网探测
WebShell 部署: 通过配置写入恶意脚本

漏洞复现

环境准备

# 安装受影响的 Nginx UI 版本
docker run -d --name nginx-ui \
 -p 8080:80 \
 -p 9000:9000 \
 0xjacky/nginx-ui:2.3.5

检测步骤

步骤 1: 确认 Nginx UI 可访问

curl -I http://target-ip:9000/
# HTTP/1.1 200 OK 表示服务在线

步骤 2: 测试 /mcp_message 端点

curl -X POST http://target-ip:9000/mcp_message \
 -H "Content-Type: application/json" \
 -d '{"method":"tools/call","params":{"name":"nginx.restart"}}'

步骤 3: 如果返回成功响应，说明存在漏洞

{
 "result": {
 "status": "success",
 "message": "Nginx restarted"
 }
}

攻击利用链

1. 信息收集
 └─→ 扫描 9000 端口 (默认 Nginx UI 端口)

2. 漏洞验证
 └─→ 访问 /mcp_message 端点测试未授权访问

3. 权限提升
 └─→ 调用 MCP 工具读取/修改 Nginx 配置

4. 持久化控制
 └─→ 修改配置植入后门或反向代理规则

5. 横向移动
 └─→ 利用 Nginx 作为跳板探测内网

临时缓解方案

⚠️ 截至 2026-04-17，官方尚未发布修复补丁。建议采取以下临时缓解措施：

方案 1: 网络隔离 (推荐)

将 Nginx UI 限制在内部网络访问：

# 防火墙规则 (UFW 示例)
ufw deny 9000/tcp
ufw allow from 10.0.0.0/8 to any port 9000 proto tcp
ufw allow from 192.168.0.0/16 to any port 9000 proto tcp

方案 2: Nginx 反向代理认证

在 Nginx UI 前部署认证层：

server {
 listen 80;
 server_name nginx-ui.example.com;

 location / {
 auth_basic "Nginx UI Admin";
 auth_basic_user_file /etc/nginx/.htpasswd;

 # 仅允许受信任 IP 访问 MCP 端点
 location /mcp_message {
 allow 10.0.0.0/8;
 allow 192.168.0.0/16;
 deny all;
 }

 proxy_pass http://127.0.0.1:9000;
 }
}

方案 3: 禁用 MCP 功能

如果不需要 MCP 集成，可以在配置中禁用：

# Nginx UI 配置文件
mcp:
 enabled: false

方案 4: 修改 IP 白名单

在 Nginx UI 配置中显式设置 IP 白名单：

mcp:
 ip_whitelist:
 - 127.0.0.1
 - 10.0.0.1 # 仅允许可信 IP

检测与监控

日志审计

检查 Nginx UI 访问日志中的可疑请求：

# 搜索 /mcp_message 端点访问
grep "/mcp_message" /var/log/nginx-ui/access.log

# 检测异常 POST 请求
grep "POST /mcp_message" /var/log/nginx-ui/access.log | \
 awk '{print $1}' | sort | uniq -c | sort -rn

SIEM 规则

# Splunk 检测规则
index=nginx_ui
uri_path="/mcp_message"
http_method=POST
status=200
| stats count by src_ip, user_agent
| where count > 5

网络监控

监控对 Nginx UI 端点的异常访问：

# 使用 tcpdump 捕获可疑流量
tcpdump -i eth0 'port 9000 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354'
# 过滤 POST 请求

时间线

日期	事件
2026-03-30	GitHub 收到漏洞报告，分配 CVE-2026-33032
2026-03-30	GitHub 发布安全公告 (GHSA-h6c2-x2m2-mwhf)
2026-04-01	NIST NVD 收录该漏洞
2026-04-16	NVD 更新漏洞记录，添加参考链接
2026-04-17	暂无官方补丁发布

参考资源

总结

CVE-2026-33032 是一个典型的认证缺失漏洞，根源在于开发者错误地认为 IP 白名单可以替代身份认证。这个案例提醒我们：

防御深度: 单一安全措施（IP 白名单）不足以保护敏感功能
默认安全: 默认配置应该是安全的（空名单应解释为"拒绝所有"）
及时更新: 使用 Nginx UI 的管理员应密切关注官方补丁发布

🔔 建议: 如果你正在使用 Nginx UI ≤ 2.3.5，请立即实施上述缓解措施，并监控官方仓库获取补丁更新。