Serious Vulnerability in PrestaShop Sites

A NEWLY DETECTED EXPLOIT MAY ALLOW REMOTE ATTACKERS TO TAKE CONTROL OF YOUR STORE.
Securing the store against attack: Securing the store against such an attack
Rebuilding the store after the attack: Rebuilding Prestashop after the attack
Attackers have found a way to exploit a security vulnerability to execute arbitrary code on the servers hosting PrestaShop sites. Read the full article for details.

What's going on
It turns out that hackers use a combination of known and unknown vulnerabilities to inject malicious code into PrestaShop pages, allowing them to execute arbitrary instructions and potentially steal customer payment information.

While investigating this attack, a previously unknown chain of vulnerabilities was found. At the moment, however, you cannot be sure that this is the only way they can attack. This issue seems to affect stores based on version 1.6.0.10 or later, which are affected by SQL injection vulnerabilities. Versions 1.7.8.2 and later are not vulnerable unless they run a module or custom code that itself contains a SQL injection vulnerability. Note that versions 2.0.0~2.1.0 of the blockwishlist module are vulnerable.

If the store is already infected, it displays its own module on the payment page, regardless of whether it is installed in the store (e.g. PayPal) - an example of such a page below:

How the attack works
The attack requires the store to be vulnerable to SQL injection attacks. To the best of our knowledge, the latest version of PrestaShop and its modules are free from these vulnerabilities. Attackers target stores that use outdated software or modules, vulnerable third-party modules, or an as yet undiscovered vulnerability.

Research shows that the repeated modus operandi looks like this:

The attacker submits a POST request to an endpoint vulnerable to SQL injection.
After about one second, the attacker sends a GET request without parameters to the home page. This creates a PHP file named blm.php in the root directory of the store.
The attacker now sends a GET request to the newly created blm.php file, allowing it to execute any instructions.
After the attackers successfully take control of the store, they introduce a fake payment method to the store's payment page. In this scenario, store customers can enter their credit card information in a fake form and unknowingly send it to the attackers.

While this seems to be a common pattern, attackers may use a different one by placing a different file name, modifying other parts of the software, placing malicious code elsewhere, or even removing traces of a successful attack.

How to make your store safe?
First of all, make sure your store and all modules are updated to the latest version. This should prevent your store from being exposed to known and actively exploited SQL injection vulnerabilities.

Based on our current understanding of the exploit, attackers may be using Smarty's MySQL cache storage as part of an attack vector. This feature is rarely used and is disabled by default, but an attacker can enable it remotely. Until a patch is released, it is recommended that you conduct a professional audit of the stores in order to break the chain of attacks.

How can you tell if your store has been hacked?
Consider reviewing the server log for the attack pattern described above. Here is an example shared by a community member:

- [14/Jul/2022:16:20:56 +0200] "POST /modules/XXX/XXX.php HTTP/1.1" 200 82772 "-"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko)
Version/10.0.1 Safari/602.2.14"

- [14/Jul/2022:16:20:57 +0200] "GET / HTTP/1.1" 200 63011 "-"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/54.0.2840.98 Safari/537.36"

- [14/Jul/2022:16:20:58 +0200] "POST /blm.php HTTP/1.1" 200 82696 "-"
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0"
(Note: the path of the vulnerable module has been modified for security reasons)

Note that not finding this pattern in the logs doesn't necessarily mean your store hasn't been affected: the complexity of the exploit means there are several ways to execute it, and attackers may also be trying to hide traces of tampering with your store's code.

Consider contacting a professional for a full website audit to ensure that no files have been modified or any malicious code has been added.

Below is a link to our service that will protect the store against this attack (we audit the store's files and protect it against this exploit):

Serious vulnerability in PrestaShop exploit - fix