利用虚假 GIF 进行多阶段反向代理卡盗刷攻击

在今天的文章中，我们将回顾一次针对 Magento 电商网站的复杂、多阶段信用卡欺诈攻击。该恶意软件利用伪造的 gif 图像文件、本地浏览器sessionStorage数据，并使用恶意反向代理服务器篡改网站流量，从而窃取受感染网站的信用卡数据、登录信息、Cookie 和其他敏感数据。

客户在结账页面上遇到了一些异常情况，包括无法正常输入银行卡信息，订单也无法处理。他们联系我们寻求帮助。我们原本以为这只是一起简单的信用卡盗窃案，结果却发现这是一个相当先进且引人入胜的恶意软件，我们将在这篇文章中详细探讨。

过时的Magento

首先，值得一提的是，该网站使用的是非常过时的Magento 安装，具体来说是1.9.2.4版本。此版本的 Magento 电商平台是 1.X 分支中最后一个同类版本，Adobe 已于2020 年 6 月（近五年前）终止了对该版本的支持。

然而，尽管由于缺乏 Adobe 持续的官方支持而存在安全风险，但仍有许多电商网站仍在使用这个已弃用的软件平台。Magento 并非一个易于管理的平台（与 WooCommerce/WordPress 等其他电商平台相比），从 Magento1 到 Magento2 的完整迁移/网站升级可能是一项耗时且昂贵的工作。如果网站管理员/店主本身不懂技术，而是依赖网站开发人员代劳，情况尤其如此。

因此，许多网站所有者似乎安于使用这个老旧、弃用的软件平台，祈祷一切顺利。然而，我们再怎么强调保持核心CMS平台更新的重要性也不为过，务必尽快安装所有可用的安全补丁。

请务必查看我们关于如何安装 Magento 安全补丁的新指南！

可疑的 JavaScript

有了这一强制性警告，我们就可以深入研究这种感染了，好吗？

在调查MageCart恶意软件案例时，我们首先要做的当然是检查页面源代码，查找可能在结帐页面上加载的任何可疑 JavaScript 代码片段。虽然 Magento 网站上的许多恶意软件注入都基于后端/PHP，并且外部不可见，但 JavaScript 注入仍然是攻击者的最爱，因为它易于使用，并且可以通过简单的管理面板入侵或 SQLi 攻击进行注入。

这时我们遇到了以下代码：

这段代码位于两个<!– Bing UET Tag –>标签之间。乍一看，这似乎只是 Bing 广告的转化跟踪代码（在网站上很常见），但这里的某个字符串似乎有些不对劲：

bpumediabpumagentothembpuimgbpuline

具体来说，这个字符串中间的直接引用了 magento。这在通用的 Bing 跟踪代码中是不会出现的，所以我们知道肯定有什么地方出了问题，但这到底意味着什么呢？

让我们把注意力转向 JavaScript 代码的这一部分：

('rep' || 'bing')['concat']('lace')](/bpu/g, '/')

该脚本使用了一些 JavaScript 技巧，通过将字符串 ` rep ` 与 ` lace ` 连接起来，并在中间插入字符串 ` bing ` 来动态构建方法名“ replace ”，使其看起来更加无害。全局标志 ' g ' 确保目标字符串中所有出现的子字符串“ bpu ”都被替换为正斜杠，而 JavaScript 的编码方式（通过滥用“ truthy ”和“ falsy ”值的解释方式）使得字符串“ bing ”被忽略：

那么我们还剩下什么呢？

/media/magentothem/img/line

这看起来确实像是一个目录路径，不是吗？但它引用的是什么文件呢？让我们回到刚才提到的那个有问题的 JavaScript 代码，重点关注下一行：

["concat"]("","msg" && "." || "push", !1 || "g", "chat" && "if?",new Date().getTime())

这使用了和之前相同的技巧：将字符串与被忽略的项目连接起来，以转移注意力。最终我们得到以下结果：

/media/magentothem/img/line.gif?<timestamp>

真奇怪！为什么它会引用一个 .gif文件？我们来看看里面有什么！

神秘.gif 事件

毫不奇怪，这个“ .gif ”文件实际上并不是图像或动画，而是包含恶意的PHP脚本：这使用了和之前相同的技巧：将字符串与被忽略的项目连接起来，以转移注意力。最终我们得到以下结果：

“ backend_url ” 被混淆了，但通过反转字符串并对其进行 base64 解码，我们可以看到它正在与哪里通信：

hxxp://217[.]12[.]207[.]38/positions/02/

一旦我们仔细观察这种感染，我们实际上就会发现这是一种反向代理恶意软件，它能够拦截 Magento 网站上的所有请求，同时对网站访问者和管理员几乎不可见。

但是，在我们将其分解之前，让我们快速探究一下反向代理到底是什么，以及它与大多数用户熟悉的常规代理有何不同。

反向代理与常规代理

大多数使用过VPN（虚拟专用网络）的用户都了解代理的基本工作原理。一旦您的计算机连接到 VPN，计算机/浏览器发出的所有请求都会通过第三方服务器进行路由，该服务器会从网络上抓取内容，然后将其返回给用户。这有效地掩盖了用户的 IP 地址，无论是相关的网络服务器还是用户的 ISP 都无法看到。这类服务在那些希望提升在线隐私（无论出于何种原因）的用户中很受欢迎。

反向代理则略有不同。它并非供普通用户使用，而是供服务器使用，通常用于负载平衡、安全或缓存等目的。

Web 服务器配置通常比常规代理所能处理的复杂得多，并且涉及后端的多个服务器，这需要更复杂的流量路由。这时反向代理就派上用场了：要将流量分配到后端的适当目的地：

现在让我们来探讨一下该恶意软件如何充当反向代理来拦截对受感染的 Magento 网站发出的请求。

反向代理功能

让我们仔细看看这个伪造的 .gif / PHP 脚本的其他部分，这些部分赋予了它反向代理功能：

我们可以看到，恶意软件捕获了传入的请求（标头、正文、IP 地址等），并拦截了POST数据（登录信息、表单、文件上传）。甚至原始文件数据也会被包含在这里，并被恶意反向代理服务器拦截。所有数据（例如请求、Cookie、会话令牌等）都会被转发到恶意服务器。

不过，可能最有趣（也是最狡猾）的部分是反向代理如何在将请求发送回用户之前篡改请求：

在这里我们可以看到该恶意软件：

• 删除并重写Location:标头以防止重定向泄露后端服务器

• 重写 cookies 以匹配合法域名

• 传递标头，以便浏览器认为它只与 Magento 商店对话

然后，在抓取后端响应、对其进行篡改并掩盖其踪迹后，它只需将结果打印回受害者的浏览器即可。此外，值得一提的是，该代码注释清晰，准确解释了其功能（而且还是英文注释）。

由于恶意 JavaScript 被植入到所有页面（包括主页），因此实际上通过 Magento 网站的所有请求（包括付款详情、登录详情、cookie 等）都会通过攻击者的服务器进行清洗，而受害者不会有任何迹象表明他们在受感染网站上进行的所有活动和请求都被拦截或篡改，而且所有这些都是通过一个虚假的.gif文件进行的！

篡改付款文件

但这还不是全部！我们的调查还发现了一个被篡改的支付文件，它与前面提到的 JavaScript 注入密切配合，发起了一场多阶段、针对特定用户的攻击。让我们来回顾一下！

除了上面描述的恶意软件之外，恶意代码还被添加到以下结帐模板文件中：

./app/design/frontend/base/default/template/onestepcheckout/onestepcheckout.phtml

虽然注射量相对较小，但它的作用实际上相当先进，尤其是与之前描述的初始注射协同工作时。

此恶意 JavaScript 代码片段会进行一些可疑的活动：

navigator.userAgent.replace(/D/g,'')

此处的字符串会从浏览器的用户代理字符串中剥离所有非数字部分，并将其转换为动态密钥，从而创建一个用户特定的密钥/标记标识符，并在本地浏览器sessionStorage 中查找该密钥。如果找到，则继续执行。您可以将sessionStorage想象成浏览器中的一个微型数据库，用于存储与当前浏览器会话相关的信息。第二次注入会检查本地sessionStorage密钥以触发注入，这可能是由恶意反向代理植入到受害者浏览器中的。

请注意， onestepcheckout.phtml文件中缺少任何泄露域名或 IP 地址。该恶意软件利用受害者浏览器内部的sessionStorage来执行有效载荷。通过这种方式，大多数实际的银行卡窃取和恶意行为都是在客户端进行的，这使得检测更加困难。此外，这种感染是特定于会话的；当标签页或窗口关闭时，sessionStorage 数据会被从浏览器中清除，因此一旦交易完成并关闭浏览器，受害者的环境中就不会残留任何内容。

总而言之，伪造的“ bing ”JS 注入会在用户的浏览器中植入触发器，而当用户到达结帐页面时，onestepcheckout注入会引爆它。

总结与缓解

我们在本文中探讨的是一种相当先进的多阶段信用卡欺诈攻击，其目标是在易受攻击的电商平台（本例中为 Magento1）上购物的用户。这些威胁行为者显然相当先进，在搭建攻击基础设施和精心设计有效载荷方面投入了大量心血。

很明显，MageCart 恶意软件短期内不会消失。因此，电商网站管理员和购物者都需要继续保持警惕，以保护他们的在线数据和客户安全。