PrestaShop is a popular freemium open source e-commerce platform used by hundreds of thousands of webmasters to sell products and services to website visitors. While PrestaShop’s CMS market share is only 0.8%, it should still come as no surprise that attackers have been crafting malware to specifically target environments who use this software.
In this post, I’ll document how I recently came across an infected PrestaShop website containing an interesting injection found overriding the site’s existing credit card payment form — and outline the steps you can take to protect your site from these types of attacks.
Script injected into payment.tpl
As I launched my investigation, I noted that the website owner was using the One Page Checkout module which allows website owners to configure and compile popular ecommerce features on the purchase page, including functionalities for personalization, shipping and billing details, and order summaries.
Inspecting the site revealed a script injection located within the module in modules/onepagecheckoutps/views/templates/front/payment.tpl.
This js/dfsasdf3124sfcad2.js script was found injected on the payment.tpl file and appeared to load every time a user navigated to the purchase process:
A cursory review of this dfasdf3124sfcad2.js file revealed some obfuscated code, which immediately piqued my curiosity.
Once decoded, results unveiled a customized fake payment form which was being inserted into the checkout process to override the legitimate form.
The overlaid form did not appear to contain any suspicious features or typos which might flag a victim’s attention as they’re navigating the infected site.
Let’s examine how the injection works.
The checkout page loads the legitimate modules/onepagecheckoutps/views/js/front/onepagecheckoutps.js file which happens to contain the following obfuscated injection.
Once decoded, the injection reveals itself to belong to a credit card skimmer.
As seen above on line 24, the malicious JavaScript skims the data from the payment form, base64-encodes it, and then sends it to the site’s own /index.php?pop=7.
While the /index.php file is not infected per se, it is the main PrestaShop file responsible for loading the rest of the CMS scripts on the website — including controllers/front/IndexController.php and classes/tools.php which happen to contain the server-side part of the malware.
Let’s take a look at how the attacker processes and exfiltrates the stolen credit card data.
A single line of malicious code found injected in IndexController.php file is responsible for checking and intercepting requests for payment details before passing them along for processing. You can see it below on line 40.
This malicious code is used to detect requests containing credit card details by checking the pop= request parameter. If pop=7, the malware activates the function that processes the stolen data by calling the Tools::redirectErrorPage() that is defined by the attacker in classes/tools.php.
The redirectErrorPage() function first encrypts the data using openssl_public_encrypt with the attacker’s public key. It then initiates a curl request to exfiltrate the harvested credit card information to hxxps://fastfixtuning[.]nl/cache/cache.php via POST request.
To make detection and troubleshooting more challenging for the website owner, the malware sets the following cookie and displays the warning “Selected payment method is currently unavailable, please try again.” as soon as the payment details have been stolen:
Presta_Shop=433e5179e5aa1923.1653055359.1.1653055379.1653055359
Once set, users with this cookie will no longer see the fake payment form during the checkout process.
Website Backdoor in config/alias.php
Attackers regularly plant backdoors in compromised environments to maintain access long after the initial infection has occurred. Backdoors can come in a variety of flavors — and may use HTTP requests to upload files and web shells or remotely execute code.
During our analysis, we also found the following line of code in the website’s config/alias.php file.
While small and easily confused for normal code, this snippet allows the attacker to upload a webshell or execute malicious code in a POST request onto the compromised environment.
It’s worth noting that while the eval function itself isn’t malicious, searching for eval( can in fact help you identify many backdoors on your website; attackers regularly use this method to inject malicious content or run malicious code on the server. But since backdoors come in so many shapes and sizes, it’s not likely to find everything.
Attack & Exfiltration Sequence
Our analysis revealed five distinct parts to this skimming attack.
- Initial injection into the compromised environment.
The attacker injects malicious obfuscated dfasdf3124sfcad2.js script into the payment.tpl file. - JavaScript creates and overlays form.
The contents of dfasdf3124sfcad2.js create a fake form which is overlaid on top of the existing checkout cart. - Second JavaScript skims data.
A skimmer from onepagecheckoutps.js monitors changes in the payment form and sends the payment details to the server-side part of the malware. - Injected code checks for parameter and activates function.
A single line of malicious code injected into IndexController.php file checks and intercepts POST requests containing payment details and activates the function redirectErrorPage(). - Function exfiltrates data to a third party server.
The redirectErrorPage() function from tools.php encrypts harvested data then initiates a curl request to send stolen credit card details to the hacker controlled hxxps://fastfixtuning[.]nl/cache/cache.php via POST request.
Conclusion & Mitigation Steps
It’s not typical for the same skimmer to be found on thousands of websites. Credit card skimming attacks are often highly targeted and customized campaigns — and we regularly find malware hand-crafted for just one (or a small handful) of sites.
Attackers clearly went to great lengths to craft this swiper specifically for this particular PrestaShop installation. The customized credit card form and handler function to process stolen data along with obfuscation techniques and naming conventions to evade detection showcase the steps that attackers will take to steal sensitive information from e-commerce websites.
Fortunately, there are a number of initiatives you can take to protect your website, checkout process, and customers from targeted skimmer attacks like these.
- Always keep your website software updated with the latest patches.
It cannot be stressed enough how important patching your software is. Regardless of what CMS you use, you should always keep all of your website software up-to-date with the latest patches and security updates — including modules, plugins, themes, and core CMS. - Use strong passwords.
Always use unique, complex passwords for your CMS, database, FTP/SSH, hosting and cPanel accounts to protect against brute force and dictionary attacks. - Follow the principle of least privilege.
Ensure that all user accounts are only assigned to their needed roles by following the principle of least privilege. - Check your file integrity regularly.
Monitoring for changes on your website is an important component of identifying indicators of compromise. There are a number of tools you can use to alert you of any unexpected changes to your website’s files or environment. - Use a web application firewall.
Leverage a firewall to filter traffic between your server and visitors and virtually patch known vulnerabilities in the event that you forget to patch an update.
As always, if you think your website has been hacked or may contain a credit card skimmer and you need a hand cleaning it up, we’re here to help.
