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

1.1 攻击时间线#

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

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

1.2 响应大小指纹#

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

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

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

2.1 BEpusdt 的签名算法#

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

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

具体来说：

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

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

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

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

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

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

2.2 ACG-Faka 的回调处理流程#

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

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

关键文件：

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

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

1
/www/wwwroot/faka/
2
├── index.php
3
├── app/
4
│   └── Pay/BEpusdt/Config/Config.php   ← 包含 API Token
5
├── config/
6
│   └── database.php                     ← 包含数据库密码
7
├── site_backup_20260810.zip             ← 整站备份，包含以上所有文件
8
└── 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：

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

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

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

攻击者直接看到了：

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

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

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

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

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

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

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

安全的实现应该是：

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

hash_equals() 的作用有两个：

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

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

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

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

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

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

5.1 攻击向量#

5.2 审计结果#

关键发现：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1
public static function safetyEquals(mixed $str, string $local): bool
2
{
3
    if (!is_string($str) || $str === '') {
4
        return false;
5
    }
6
    return hash_equals($local, $str);
7
}

6.2 P1 加固措施#

回调端点 IP 白名单：

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

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

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

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

6.3 P2 监控告警#

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

6.4 架构层面#

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