Major Security Vulnerability on PrestaShop Websites

Attackers have found a way to use a security vulnerability to carry out arbitrary code execution in servers running PrestaShop websites. For details, please read the entire article.

What’s happening

The maintainer team has been made aware that malicious actors are exploiting a combination of known and unknown security vulnerabilities to inject malicious code in PrestaShop websites, allowing them to execute arbitrary instructions, and potentially steal customer’s payment information.

While investigating this attack, we found a previously unknown vulnerability chain that we are fixing. At the moment, however, we cannot be sure that it’s the only way for them to perform the attack.
To the best of our understanding, this issue seems to concern shops based on versions 1.6.0.10 or greater, subject to SQL injection vulnerabilities. Versions 1.7.8.2 and greater are not vulnerable unless they are running a module or custom code which itself includes an SQL injection vulnerability. Note that versions 2.0.0~2.1.0 of the Wishlist (blockwishlist) module are vulnerable.

How the attack works

The attack requires the shop to be vulnerable to SQL injection exploits. To the best of our knowledge, the latest version of PrestaShop and its modules are free from these vulnerabilities. We believe attackers are targeting shops using outdated software or modules, vulnerable third-party modules, or a yet-to-be-discovered vulnerability.

According to our conversations with shop owners and developers, the recurring modus operandi looks like this:

1. The attacker submits a POST request to the endpoint vulnerable to SQL injection.
2. After approximately one second, the attacker submits a GET request to the homepage, with no parameters. This results in a PHP file called blm.php being created at the root of the shop’s directory.
3. The attacker now submits a GET request to the new file that was created, blm.php, allowing them to execute arbitrary instructions.

After the attackers successfully gained control of a shop, they injected a fake payment form on the front-office checkout page. In this scenario, shop customers might enter their credit card information on the fake form, and unknowingly send it to the attackers.

While this seems to be the common pattern, attackers might be using a different one, by placing a different file name, modifying other parts of the software, planting malicious code elsewhere, or even erasing their tracks once the attack has been successful.

What to do to keep your shop safe

First of all, make sure that your shop and all your modules are updated to their latest version. This should prevent your shop from being exposed to known and actively exploited SQL injection vulnerabilities.

According to our current understanding of the exploit, attackers might be using MySQL Smarty cache storage features as part of the attack vector. This feature is rarely used and is disabled by default, but it can be enabled remotely by the attacker. Until a patch has been published, we recommend physically disabling this feature in PrestaShop’s code in order to break the attack chain.

To do so, locate the file config/smarty.config.inc.php on your PrestaShop install, and remove lines 43-46 (PrestaShop 1.7) or 40-43 (PrestaShop 1.6):

if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
    include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php';
    $smarty->caching_type = 'mysql';
}

How to tell if you have been affected

Consider looking at your server’s access log for the attack pattern explained above. This is an example shared by a community member:

-  "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"
 
-  "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"
 
-  "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 vulnerable module’s path has been modified for security reasons)

Be aware that not finding this pattern on your logs doesn’t necessarily mean that your shop has not been affected by the attack: the complexity of the exploit means that there are several ways of performing it, and attackers might also try and hide their tracks.

Consider contacting a specialist to perform a full audit of your site and make sure that no file has been modified nor any malicious code has been added.

Additional information

A patch version is currently being tested, and should be released soon.

We would like to take the opportunity to stress out once more the importance of keeping your system updated to prevent such attacks. This means regularly updating both your PrestaShop software and its modules, as well as your server environment.