Magento Platform Targeted By Credit Card Scrapers

We’ve been writing a lot about ecommerce hacks and PCI Compliance recently. The more people buy things online, the more of an issue this will be come and the more important it will be to talk about it. We live in an online world where a single mistake can lead to catastrophic results; that impact is amplified when we’re dealing with commerce. In this article, I’d like to describe some interesting credit card scrapers for Magento which are on the rise.

My colleague, Denis Sinegubko (a.k.a., Unmaskparasites), wrote a very informative article about e-commerce hacks specifically affecting the Magento platform back in April. It is a good read, encourage you to give it a once over if you have time – users and webmasters. By coincidence, the sample he used in his article is a Magento Credit Card stealer as well. His example, along with what I’m seeing leads us, me, to believe that we’re in for a new trend of Magento based credit cards stealers.

Recent Wave In The Wild

Now let’s have a look at an example, or in other words – a real threat that can be affecting you.

The sad part is that you won’t know it’s affecting you until it’s too late, in the worst cases it won’t become apparent until they appear on your bank statements.

So how does attack work? We’re still investigating the attack vectors. It seems though that the attacker is exploiting a vulnerability in Magento core or some widely used module/extension. Using this vector, the attacker is able to inject malicious code into the Magento core file.

We’ve seen several different files being injected with this:

After this code is injected, nothing else happens – attacker has everything he needs to successfully spy and steal sensitive/personal information from the infected website. In fact, the attacker gets the content of every POST request.  This is more than enough because POST requests contain data being sent to the server for storage.

Let’s have a look at few interesting parts of this code.

Part One: Conditions

While we’ve seen and detected several slightly different variants, but the PUBLIC_KEY variable seems to be a constant. This indicates that it’s likely the same author who created this whole family of credit card stealers. The variable is later used for encrypting stolen content which means that only the attacker will be able to decrypt it. Also, there’s a nice little purge function implemented for clearing the trails.

How does it work?

There are two conditions:

1. The visitor must have a Visvo user agent. The attacker is able to use whatever user agent they like,  this is probably used to make malicious requests harder to spot in the access logs. There are tons of crawlers out there that show up in your logs with different names, using a random agent helps mask the events. This is important, because such requests are almost always ignored when searching for suspicious activity manually – which is a mistake.
2. Another custom parameter is set. In our case it’s this pbf7aac5 stored in the $k2 variable, the file in which all the stolen information is stored is cleared. The malicious script even preserves the file change time to make sure that it won’t trigger suspicion.

If there is no custom parameter passed via the GET method, the script shows the word “Pong” in the browser. This simple   function checks which of the infected sites are still infected. The attacker could use this on regular basis, and I’m sure the attacker has a nice collection of infected sites that he keeps tabs on.

Part Two: Collection

In this part of the malicious code, we can see the attacker is grabbing all of the POST requests. The attacker even tries to store the content transferred by the POST method based on some structured rules which identifies the payment details.

If the structure of the POST parameters match, the attacker stores them all – nothing more, but nothing less. They’ve got all the billing details processed by the infected site. What else do they need?

Part Three: Hiding

Here we can see the encryption and storing of the stolen data that was collected. As I mentioned bit earlier, the data is encrypted using the Public Key that the attacker defines in the beginning of the script. After the billing data is processed, it’s saved in the fake image file which is also defined in the beginning of the script:

$y0 = ‘/home/cloudpanel/htdocs/www.site_name_removed.ca/skin/adminhtml/default/default/images/icon_feed_bg.gif';

Again, they’re modifying the file modification timestamp so it looks like the file has not been touched for some time, thus making it less suspicious. They’re also adding a fake JPEG header and put the base64 encoded (and previously encrypted) data after this header.

Too complicated?

No, it’s actually quite clever! If somebody loaded this “image” file via the web browser by coincidence, all the visitor would see is the broken image. Nothing more.

The attacker, however, is able to download the whole “image” file to decrypt the stolen contents using their Private Key, and Voila! – now they have all the billing information processed by the Magento e-commerce website. It’s all nicely packed, formatted and collected. All they need is to use the data…

I’d also like to mention one great post which I found during my research of this malware. You can find a nice description of one of the malware variants here: http://www.snapfast.com/blog/magento-mage-jpg-hack/

It was a pleasure to read about their findings (which correlate with my own research) and even more to read – at the end of their article – they recommend our services to affected website owners. Thanks guys!

Another Variant Example

In the previous case the attacker stole sensitive data by checking all POST content and storing it in case of a recognized structure, thus the injection can be placed in any core file that is loaded when the CMS starts. In this second case study, the attacker aims the Checkout Module and the attack itself is more straightforward.

This is the code we found injected:

Yes, it’s one (and not really long) line of injected code. Here it is decoded:

The code is pretty clear – it’s a simple mailer. It doesn’t modify the data, just steals them “in the middle” of the transaction processing so that it’s not detected. All the data which should be secured is sent in a plaintext form to the attacker’s email.

The only interesting thing about this is realizing how the attackers received the data. This time the attack is dependent on a particular module. The attacker knows how the module works and the code it’s built on; all he needed to do was use the module’s own variable in which all the sensitive data is stored unprotected.

It’s the $data variable which is used in the savePayment() function:

public function savePayment($data)

The attackers are getting all of what they need from this variable as you can see in the decoded code screenshot. Simple and effective. Now all your billing data is traveling the internet in the plain-text form!

Conclusion

Magento credit card stealers are indeed on rise.

Is there a solution for avoiding these thefts? Sure there is! Merchants need to understand that they are responsible for the processed data and should do everything they can to secure their environment. The answer to this is hidden behind PCI Compliance. Daniel Cid, our Founder / CTO, released a nice intro to E-Commerce and PCI Compliance post recently that you should definitely read if your website depends on online commerce.

While the information here is specific to Magento, realize that this can affect any platform that is used to support E-Commerce. As the industry grows so will the specific attacks targeting the industry.

Keep your eyes open and stay safe!