Over the past year we have seen a rash of credit card swipers in Magento and other ecommerce-based websites. In fact, we have been finding new variants nearly every week. It is no surprise that ecommerce sites are lucrative for attackers. Although attackers have many ways of making money by hacking websites (such as with malware distribution and SEO spam) stealing credit cards is one of the most notorious.
It is common knowledge that there can be risks associated with shopping online. Identity and credit card theft continue to cause concern among would-be shoppers. If a website takes credit card payments and is not PCI compliant there can be fines and other repercussions when customers are impacted by hacks like these.
Typically the malicious code will grab credit card numbers or login details and send them to the attacker’s email address or dump them into a file. In this case, however, there was an interesting twist.
Scanning Magento for Swipers
Our initial scans came up clean which meant we needed to investigate further. With Magento sites there are a few common themes when it comes to cleaning and removing credit card swipers. I decided to check the following Magento core file:
app/code/core/Mage/Payment/Model/Method/Cc.php
This is a very common location for attackers to place swiper code on Magento sites:
Would you look at that! The file had been modified recently compared to the rest of the files in that directory. The last modified date and time stamp can prove quite useful for narrowing down infected files.
In this case, the file did just as we expected.
Credit Card Details in Image Files
Taking a look inside Cc.php I found the malicious code that dumps stolen details into an image file.
This is not out of the ordinary. It is actually characteristic of a lot of the credit card swipers we have seen lately.
Attackers use image files as an obfuscation technique to hide stolen details from the website owner. The image file usually doesn’t contain a real image, however, no one really suspects an image file to contain malware. This gives the attacker a secret place to store data. If the attacker had chosen to store the stolen credit card details in a simple text file then it might be easier for someone to discover it and take steps to remove the hack.
What we found to be very peculiar in this case is that the image itself actually worked:
It looks like a regular image from the website!
Legitimate Image
The most interesting fact is that this image was related to products sold on the victim website. Most website owners would be none the wiser if they came across this image and opened it to make sure it worked.
Very often when trying to view the images that contain stolen cards you would receive an error response such as:
There was an error displaying this image
Even checking the source of the image nothing seemed out of the ordinary at first:
This matches what a typical image looks like when viewing its source in a text editor. The jumbled mass of code is translated by image-viewing programs to show you a pretty picture. The source code behind the image appears overwhelming and cryptic.
In this case, I had to look closer in order to see what the attacker had done with the stolen credentials.
Below all of the legitimate image source code is a long list of stolen credit card numbers:
We blurred out the content to protect the innocent but you can see the first four numbers of each credit card number that has been stolen.
Most people impacted by this Magento credit card swiper were from the United States, but some were from overseas in Japan, Turkey, and Saudi Arabia (even a few near me in Vancouver, BC).
To obtain the stolen numbers the attacker would not even have to maintain access to the site. The image was publicly accessible. All the attacker would need to do is download the image from the website just like any other and view its source code.
Of course, we deleted the entire contents so that nobody would be able to download it going forward.
Protect Your Site
Keep your Magento website up to date and apply all the latest patches!
If you are uncertain how to update, you can protect your website with our Sucuri Firewall. Also, make sure your administration panel uses a long, complex password that is difficult to guess or brute force. You should also spend some time becoming familiar with our series of PCI compliance posts.
Rianna MacLeod
John Booker
Ashley Sand
Ben Martin
9 comments
Its also important to note that some hacks preserve the file modification date, so changed files cannot be easily found.
Yes that is correct. Time stamps can be easily modified so you can’t
always trust that, however in many, many cases we work with the
attackers are lazy and don’t even bother to conceal that. It’s important
to have file integrity monitoring in place in order to keep track of
modifications.
You can always check the ctime rather than the mtime.
A simple cron is
find /home/XXXXXXXX/public_html -type f -cmin -30 -exec ls -ls {} ; | mail -E -s “File Changes in Last 30 Minutes” myemail@domain.com
In fact, steganalysis techniques and metadata analysis can identify changes in that image
Yes, that is true! In this case no such analysis was needed, though. Just found the reference to the image in the Magento core file, downloaded the image, viewed its source using vim and scrolled to the bottom of its contents.
I guess what we are saying is this needs something stronger than happenstance to protect sites from this emerging issue.
That is good to know but is there any php based tool that will do that?
We run cron jobs to detect all types of files changes but this is not something we have a tool for.
Unfortunately, not that i’m aware (for steganalysis). You will need to implement the code, that basically is math… you can search for some algorithms the help your understanding:
-blindHide
-HideSeek
-FilterFirst
-BattleSteg
Some Filter like:
-Laplace
-Sobel
-Prewitt
Some Analysis:
-RS Analysis
-Sample Pairs
-Laplace
-LSB Enhancement
– RGB atack
Etc..
So is there any tool that would check all images in a folder to detect if they had been modified? Would the metadata a different file size to the actual file size for instance?
Comments are closed.