Fake GIF Leveraged in Multi-Stage Reverse-Proxy Card Skimming Attack

In today’s post we’re going to review a sophisticated, multi-stage carding attack on a Magento eCommerce website. This malware leveraged a fake gif image file, local browser sessionStorage data, and tampered with the website traffic using a malicious reverse-proxy server to facilitate the theft of credit card data, login details, cookies, and other sensitive data from the compromised website.

The client was experiencing some strange behaviour on their checkout page, including clients unable to input their card details normally, and orders not going through. They contacted us for assistance. Thinking this would be a straightforward case of credit card theft instead what we found was actually a fascinating and rather advanced malware which we will explore in detail in this post.

Out of Date Magento

First off, it’s worth mentioning that the website in question was using a very out-of-date Magento installation, specifically version 1.9.2.4. This version of the Magento eCommerce platform is the last of its kind in the 1.X branch with Adobe having ended its support for it in June 2020, nearly half a decade ago.

However, there are a number of eCommerce websites still using this deprecated software platform despite the security risks involved due to lack of ongoing and official support from Adobe. Magento is not an easy platform to manage (when compared to other eCommerce platforms like WooCommerce/WordPress), and performing a full migration / site upgrade from Magento1 to Magento2 can be a time consuming and expensive endeavour. This is particularly true if the website administrator/store-owner is not themselves tech-savvy and instead reliant upon website developers to do their work for them.

As such it appears a number of website owners are content to reside in this old, deprecated software platform, cross their fingers and hope for the best. However, we cannot stress enough the importance of keeping your core CMS platform up to date, and be sure to apply all available security patches at the soonest possible opportunity.

Be sure to check out our new guide on how to install Magento security patches!

Questionable JavaScript

With that obligatory warning out of the way let’s dive into this infection shall we?

Naturally the first thing that we need to do when investigating a case of MageCart malware is to inspect the page source for any questionable snippets of JavaScript that might be loading on the checkout page. While plenty of malware injections on Magento websites are backend/PHP based and not outwardly-visible, JavaScript injections still remain a favourite among attackers for its ease of use and ability to inject it from a simple admin panel compromise or SQLi attack.

This is when we came across the following code:

This code was lodged between two <!– Bing UET Tag –> tags. At first glance it appeared that this was simply Bing’s conversion tracking code for their ads (not uncommon to see on a website) but something didn’t seem right about this particular string here:

bpumediabpumagentothembpuimgbpuline

Specifically the fact that lodged in the middle of this string was a direct reference to magento. This is not something that would be included in a generic Bing tracking code so we knew there must be something amiss, but what did it mean?

Let’s turn our attention to this portion of the JavaScript code:

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

The script uses some JavaScript tricks to dynamically build the method name “replace” by concatenating the strings `rep` with `lace` and sneaking the string `bing` in the middle to make it look more innocuous. The global flag ‘g‘ ensures that all occurrences of the substring “bpu” in the target string are replaced with a forward slash, and the way that the JavaScript is coded (by abusing how “truthy” and “falsy” values are interpreted) renders it such that the ‘bing‘ string is simply ignored:

So what are we left with?

/media/magentothem/img/line

Well that certainly looks like a directory path, doesn’t it? But what file is it referencing? Let’s circle back to the dodgy JavaScript in question and focus on the next line:

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

This uses the same technique as before: concatenating strings with ignored items thrown in the mix to divert attention. In the final analysis we get the following:

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

How odd! Why would it be referencing a .gif file? Let’s take a look and see what’s inside!

The Case of the Mysterious .gif

Unsurprisingly, this “.gif” file was not in fact an image or clever animation but contained a malicious PHP script:

The “backend_url” is obfuscated but by reversing the string and base64 decoding it we can see where it’s talking to:

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

Once we look closer at this infection we can actually see that this is reverse-proxy malware which is able to intercept all requests on the Magento website while at the same time remaining virtually invisible to the website visitors and admins.

But, before we break this apart, let’s quickly explore exactly what a reverse-proxy is and how it differs from a regular proxy, which most users are familiar with.

Reverse vs. Regular Proxy

Most users that have used a VPN (Virtual Private Network) understand the basics of how proxies work. Once your computer is connected to a VPN all requests made by the computer/browser are routed through a third party server which grabs the content from the web and then returns it to the user. This effectively masks the IP of the user to both the webserver in question as well as the user’s ISP. These services are popular among those who aim to improve their privacy online (for whatever reason).

A reverse proxy on the other hand is a little bit different. Rather than used by regular users these are intended to be used by servers, often for load balancing, security, or caching purposes.

Web server configurations are oftentimes much more complex than a regular proxy can handle and involve multiple servers on the backend which require more complicated traffic routing. This is where reverse proxies come into play: To distribute traffic to their appropriate destination in the backend:

Let’s now explore how this malware was acting as a reverse proxy to intercept requests made to the infected Magento website.

Reverse Proxy Functionality

Let’s take a closer look at some other portions of this bogus .gif / PHP script which gives it reverse proxy functionality:

Here we can see that the malware captures incoming requests (headers, body, IP address, etc) as well as intercepts POST data (login info, forms, file uploads). Even raw file data would be included here and intercepted by the malicious reverse proxy server. All data such as requests, cookies, session tokens, etc are being forwarded to the malicious server.

Probably the most interesting (and sneaky) part, though, is how the reverse proxy tampers with the requests before sending it back to the user:

Here we can see that the malware:

• Strips out and rewrites Location: headers to prevent redirects from revealing the backend server
• Rewrites cookies to match the legitimate domain
• Passes the headers along so the browser thinks it’s talking only to the Magento store

Then after grabbing the backend response, tampering with it, and covering its tracks, it simply prints the result back to the victim’s browser. Additionally it’s worth mentioning that the code is nicely commented and explains exactly what it’s doing (in English, no less).

Since the malicious JavaScript was lodged on all pages (including the homepage), effectively all of the requests going through the Magento website (including payment details, login details, cookies, etc) all get laundered through the attacker’s server without a single hint to the victim that all activity and requests they make with the infected website are being intercepted or tampered with and all through one bogus .gif file!

Tampered Payment File

But that’s not all! Our investigation also revealed a tampered payment file which worked hand-in-glove with the aforementioned JavaScript injection to perform a multi-stage, user-specific attack. Let’s review!

In addition to the malware described above malicious code was also added to the following checkout template file:

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

While a relatively small injection what it’s doing is actually quite advanced especially when working in tandem with the initial injection described before.

This malicious JavaScript snippets gets into some dodgy activity:

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

This string here strips all non-digits from the browser’s user agent string and converts it into a dynamic key, creating a user-specific key / marking identifier and checks the local browser sessionStorage for that key. If affirmative it proceeds to execute. You can think of sessionStorage kind of like a tiny database within your browser that stores information relative to the current browser session. This second injection is checking for the local sessionStorage key to trigger it, likely planted in the victim’s browser by the malicious reverse proxy.

Notice the lack of any exfiltration domain or IP within the onestepcheckout.phtml file. The malware leverages the sessionStorage inside the victim’s browser itself to execute the payload. In this way most of the actual card-stealing and malicious behaviour is done client-side, making it more difficult to detect. Additionally, this infection is session-specific; sessionStorage data gets wiped from the browser when the tab or window is closed so there’s not going to be anything lingering in the victim’s environment once the transaction is complete and the browser is closed.

In summary the fake “bing” JS injection plants a trigger in the user’s browser and the onestepcheckout injection detonates it when they arrive on the checkout page.

Summary and Mitigation

What we’ve reviewed in this post is a rather advanced, multi-stage carding attack targeting users making purchases on vulnerable eCommerce platforms, in this case Magento1. These threat actors are clearly quite advanced and put a lot of thought into setting up the infrastructure for this attack and crafting the payload.

It is very clear that MageCart malware isn’t going anywhere any time soon. It stands to reason that eCommerce website admins and shoppers alike need to continue to be diligent in order to protect their data and customers online.

For Website Admins

Remember, ultimately your customers are placing their trust in you to maintain the security of your website and protect their data. As an eCommerce store owner the responsibility is yours to keep these threats at bay. If you are a small-business owner and have a website out of necessity but aren’t sure how to keep up with the security requirements then hire somebody who does!

Additionally, penalties for being identified as a “common point of purchase” by Visa or other credit card vendors can be steep and are best avoided. It’s not just your customers who you need to protect but you and your business as well.

• Keep your core files up to date and ensure that you’ve issued all available security patches (<— check out our new guide on how to issue Magento security patches)
• If you’re stuck in Magento1 then work out a plan for a full migration to Magento2 at the soonest possible opportunity
• Place your website behind a WAF to help mitigate attacks

For Online Shoppers

From the outside it can be difficult (or sometimes impossible!) to know if an eCommerce store is secure or not. However, there are some general best practices that can be followed to help safeguard your security and personal info (like credit card details) when shopping online.

• Use our Sitecheck tool to determine if the website is using out-of-date eCommerce platform
• In addition to running a regular anti-virus a browser security plugin can also help mitigate attacks
• Use a script blocker to filter out unwanted or malicious JavaScript
• Check to see if the eCommerce domain is blocked by any reputable vendors

Ecommerce websites which are running out of date software should be considered untrustworthy. After all, if they cannot maintain their own environment in a secure manner then why should they be trusted to handle your payment details?

Secure your Website

As always if your eCommerce website has fallen victim to MageCart or other malware we’re here to help! Our security analysts can scan your website and perform malware removal and get your store back into working order.

If you have any questions then feel free to chat with our representatives and we’ll be happy to point you in the right direction!