Shopping Cart
There are no more items in your cart
- Tecnoacquisti.com
- Online Security Blog
On July 22, 2022, a notice from PrestaShop arrived regarding a vulnerability that allows a malicious actor to take control of your ecommerce based on this CMS. As of now, not all the dynamics of this newly discovered exploit are clear. It should be noted that the vulnerability does not seem to affect version 1.7.8.2 and later versions. However, if your version is still a 1.6 or an older 1.7, it is necessary to secure it.
How does the attack work?
The precise dynamics are still under examination, but the attack requires that the e-commerce be vulnerable to SQL injection exploits. Attackers target stores that have non-bypassed forms or known vulnerabilities. This includes the Wishlist module (blockwishlist). It is important to clarify that the attack exploits a vulnerability related to the Smarty Cache saved in MySQL, an option rarely enabled as the benefits compared to file system caching are often minimal, if not detrimental.
You can check if this cache is active by going to Advanced Settings > Performance
The fact that it is not active does not guarantee safety, as it seems that attackers can activate it by exploiting other vulnerabilities in third-party modules. However, I do not believe that the initial attack carried out via bot would then erase the traces of its passage. So if you find the option disabled, you are very likely not compromised; however, after a similar exploit, a general check is mandatory.
The detected procedure is as follows:
- An attack is sent via POST to check if the target is vulnerable.
- Immediately after, a GET request without parameters is sent to the home, which translates into a PHP file called blm.php in the root of our PrestaShop installation.
- The attacker then sends requests to the created file and performs operations directly on our ecommerce.
One of the activities detected after the criminals took control of our store is the installation of a fake payment module on the front-end. This is done to steal credit card information from our customers. It should be emphasized that in Europe, with 3D Secure, these attacks are less devastating. However, this may only be one of the methods used; attackers can use a different name than blm.php for the file and insert malicious code elsewhere for different purposes. If the attack is successful, they can also erase their traces.
The problem is serious, but the method is only successful in particular situations. However, it is necessary to secure oneself to ensure that you are not vulnerable.
How to stay safe?
First of all, as mentioned, the attack exploits the smarty cache on mysql. If you are using this mode, switch to file system caching, so immediately go to Advanced Parameters > Performance, even as you read this article of mine. Then, while waiting for an official PATCH, modify the file config/smarty.config.inc.php as recommended in the PrestaShop notice. This involves removing or commenting out a small portion of code; this portion of code is useless if you are not using mysql caching, so the modification will not need to be restored in the future.
You can find this code in version 1.6 on lines 40-43 and in 1.7 on lines 43-46.
Just comment on this block then:
Once done, your ecommerce is safe from this attack, but it is not safe from other attacks and it is possible that it has already been compromised.
I recommend again to always keep all modules updated, uninstall those not in use, and update PrestaShop; this exploit is not the only one, there are more serious and less serious ones that affect many outdated versions. Here you can view the known vulnerabilities:
https://www.cvedetails.com/vulnerability-list/vendor_id-8950/Prestashop.html
It is important to clarify that this applies to all CMS and software, including WordPress, Joomla, Magento, etc. A secure system is one that is updated.
How do you check if your PrestaShop is compromised?
This type of attack makes it more difficult to understand if you are a victim; once they take control, as mentioned, criminals can cover their tracks by leaving a well-hidden backdoor and modifying module or core files of the CMS. The dynamics are similar to the vulnerability related to PHPUnit (CVE-2017-9841). In this specific case, not finding the file blm.php in the root or in the logs is no guarantee of security that you have not already been hacked.
So you can perform a check, but I recommend verifying recently modified or added files, which can be done via SSH. A very useful thing is to check if there is any encrypted or encoded code, for example in base64: its presence is always suspicious. Keep in mind that for modules purchased on Prestashop Addons, using these systems is prohibited, so a module that uses them would not be present in the catalog.
Some tools available on cPanel and Plesk can be very useful in identifying any infected files, for example ImunifyAV.
I remind you that SSH access to your Hosting allows you to use the find command to obtain all recently modified files, filtering them by extension, thus searching for changes mainly to .php and .tpl files in the case of PrestaShop. There are also server-side tools for cPanel and Plesk that allow you to monitor changes to certain files/folders.
Author: Loris Modena
SENIOR DEVELOPER
Per Ind Loris Modena, owner of Arte e Informatica, started working in the IT sector in 1989 as a system administrator responsible for the maintenance and installation of computer systems. He began programming for the web in 1997, focusing on CGI programming in PERL and later transitioning to programming in PHP and JavaScript. During this time, he became familiar with the Open Source world and the management of Linux servers.