Home
Services
PrestaShop Checkout vulnerability

PrestaShop Checkout vulnerability

We found a vulnerability that hit around 200 PrestaShop stores worldwide. Here's what it does, and how to protect your shop.

Let's talk about your store See the details

What we found

In recent months we've seen far more hacked PrestaShop stores than usual, even though the platform is known for its security. In the previous 10 years we had only 3 or 4 hacked shops; in the last 4 months we've had more than 10 requests to analyse or fix one.

The aim of these attacks is to inject JavaScript skimmers into checkout pages. The attackers get into the website, directly or through a third-⁠party service, and inject malicious JavaScript that steals what customers type into the payment form. In the cases we saw, they replaced the standard card form on the checkout page with their own.

Online shops rarely have a clear view of the parts of their site exposed to the web, and that's what attackers exploit. Victims often don't notice that their JavaScript has been changed, so the malicious code can stay there indefinitely. In supply-⁠chain attacks, the shop often doesn't even know it's running code from a compromised supplier.

What this can cost you

Stolen personal data: card details are the main target, but attackers can also take personal information, potentially affecting millions of consumers.
Lost revenue: a small or medium shop hit by these attacks can see online sales fall significantly, as customers stop trusting it to prevent the next breach.
Further infections: with stolen admin and user logins, attackers can spread the attack to more websites, including a brand's secondary sites.
Legal damages: a breach exposes a business to customer lawsuits, legal consequences under laws such as the GDPR, and industry penalties such as a PCI DSS audit or losing the ability to take card payments.

What we can do

A thorough check of the shop's files for intrusions, to find any unwanted changes.
Imunify deployed on the server, so compromised files can't run.
Clarity Module Pro, which we used extensively to locate the problems and check whether card data had been compromised.
Two-⁠factor authentication for the admin panel, which we recommend.

These measures cost a one-⁠time fee of 200 EUR plus 15 EUR a month.

Preventing a problem is always better than fixing one, so we strongly recommend taking these precautions to keep your store secure.

Price200 EUR+ 15 EUR / month

Case study

01
The issue
A shop owner noticed he hadn't received any orders for several hours. That was very unusual: he normally gets more than 60 orders a day.
02
The reaction
He came to us to fix the checkout, thinking it was a simple bug that could easily be corrected.
03
Our approach
At first we assumed the bug came from a module he had installed in the previous days, and started there. We quickly found significant code changes, and discovered that the original checkout form had been completely replaced by a fraudulent one.
04
The solution
There are two options, depending on whether your server has Imunify360 Proactive Defense.
1. Automatic removal with Imunify360 Proactive Defense (imunify360.com, imunify360.com). Its real-⁠time scanner checks every file as it's loaded onto the system and removes it straight away if it's malicious. This limits the damage on an unprotected system and is especially useful on one that's already infected.
2. Finding the malicious files by hand. This means searching the server's files for base64-encoded code and removing it without breaking the shop. These six files are the most often infected: classes/db/Db.php: code at the end of the file sends the value of the 'statistics_hash' parameter to the IP address 106.15.179.255. classes/controller/FrontController.php: usually modified so the checkout page loads an extra JavaScript file with a random name, such as /js/HQf6b.js, which replaces the payment section with a fake card form. /public_html/js/STRANGENAME.js: the file loaded on the order page that swaps the payment section for a custom form, most likely sending the money to the attacker. Once you find the infection, this is the most important file to delete. classes/module/module.php: must be cleaned too, as it contains encoded PHP that can receive encoded parameters and run encoded PHP code. controllers/admin/AdminLoginController.php: sends your admin panel's URL, login email and password to 45.197.141.250/statystics.php. app/Mage.php: contains code similar to classes/module/module.php, and should be deleted.
If your server or hosting only has the free version of ImunifyAV, there's no active protection, so you need to run file scans regularly and delete malicious code from infected files by hand:
support.cpanel.net