In the past, there have been plenty of articles and blog posts recommending the use of Content Security Policy (CSP) and Sub Resource Integrity (SRI) to prevent the insidious skimming malware from taking hold of a website. However, what can a small business owner do if resources are limited and implementing these countermeasures is just not feasible? What can a normal everyday user do to check and see if their favorite shopping site is compromised? In this blog post, I will go over a few steps that don’t require any security training to perform.
Put in the URL or hostname that you want to check, then run the Public Scan. Here’s what I got when I put in bumperworksonline.com:
The part we want to look at is in the lower left corner where the Domain & IP information is located.
This section shows all the IPs and domains of all the requests performed on this website. We see that most of the requests are from the same domain as the site (ASMALLORANGE) and there are some from Google and Facebook. However, there is one that we don’t recognize. This could simply be an externally loaded ad or resource, but we’ll need to dig deeper to find out.
Clicking over to the IP Detail tab shows us that the request is from the domain, scriptvault.org, located in France. Let’s take a look at what exactly was getting loaded on the site by click on the HTTP tab on top. To the right of the HTTP tab are filters for various file types. Click on Script to view only Javascript files.
At the bottom, we see that the file loaded is ‘bumperworksonline.js’. In normal circumstances, this script file would be loaded from the same domain as all the other script files. This is a big red flag. Clicking on Show Response, we see an obfuscated Magecart script.
So, now that we’ve found the skimming script, we’re done here, right? Not so fast. The skimmers can hide in other existing files as well. Take this normal looking credit card validation script for example:
Even though the file is served by the same host as the website itself it can still be compromised. If we view the response and scroll down, we see yet another skimmer script.
Those who have read the Fortinet blog should recognize the skimmer as Inter. It is a common kit that is highly customizable and sold in the underground. Fortunately for us, this version of it is typically not obfuscated at all and provides some useful information. As further evidence that this script is malicious, we can look into the ‘Gate’ field which contains the exfiltration URL.
Now we just take the IP/domain and do a WHOIS lookup. Any of the online WHOIS sites will do. Here is what I got from whois.domaintools.com:
Looks like the credit card numbers are going to a server in Hong Kong. As for the other script, all we need to do is take the decoder function and run it to see the decoded strings. We can use repl.it to do this and here is the result:
On the right, we can see the exfiltration URL as ‘https://scriptvault.org/tr/’.
Throughout my research, I’ve seen many skimming domains get taken down. However, it is ultimately a game of whack-a-mole because new domains get created all the time. The only reliable way of preventing Magecart is to detect, fix, and harden the security of websites. There are currently a few tools online that can help with these three steps:
Detect/Fix
Harden
I hope that by providing a simple means of detecting it, more people can take action and do what is necessary to stop Magecart.
Magecart - An Overview and Defense Mechanisms
Digging Deep Into MageCart Malware
Digging Deep Into MageCart Malware Part II