What Versions of PHP Are Compatible with Prestashop?

When upgrading web software, one of the first issues you need to deal with is whether the new of the software is compatible with the PHP version you are using or if you need to make a change. With PrestaShop, that has become more complicated as the range of PHP versions being supported has shrunk with recent releases. Version 1.6.1.x supported PHP versions from 5.2 to 7.1. The latest version, 1.7.7.x, only supports PHP 7.1 to 7.3.

Figuring out what versions of PHP are supported by PrestaShop is not made as easy as can be. PrestaShop does provide a chart (current as of when this was posted):

But it isn’t given its own page on PrestaShop’s website, instead you have to scroll down on the “System requirements for PrestaShop 1.7” page to find it.

That doesn’t tell the entire story though, since, for example, if you are running an older version of PrestaShop 1.6.1.x it won’t include PHP compatibility updates for newer versions of PHP that were included in later releases.

Managing PHP Version Differences

If you are keeping PrestaShop up to date, you usually shouldn’t run into PHP version compatibility issues. If you have a more out-of-date PrestaShop version that needs to be brought up to date, then you are more likely to run into issues. That is one of the many reasons why you should do a test of the upgrade first, since it makes it easier to handle any issues like that. In the best-case scenario, your web hosting setup allows running different PHP versions in different website directories and the various versions of PHP you need access to are available. Things get more complicated when either of those are not true.

We can help you with either of those as we provide both one time upgrades, with a test done first, and ongoing upgrades on a subscription basis.

How PHP Version Support is Determined?

If you are wondering how the developers of PrestaShop decide which versions of PHP to support, you can find a detailed explanation here. The short version is that it is based on what versions of PHP are currently supported and what versions of PHP are supported by software that PrestaShop depends on.

You Shouldn’t Hire Someone to Clean Up a Malware Infected Website Until They Have Confirmed There is an Issue

If you deal with malware infected websites on a regular basis, like we do, you know that with just about any issue that can occur with a website there will be someone who thinks it was caused by malware or some other hack, so what we always want to determine before taking on a cleanup of a website the owner thinks is infected, is if it is really infected. That isn’t the case with everybody, as this recent review of another company in the industry, Sucuri, which we noticed while looking at another review that a recent clients of ours (after having hired previous hire Sucuri) left about them on Trustpilot:

In December 2019, I received several urgent messages from my webhost, SiteGround, stating that Malware had been detected in 3 URLs on my website. Each alert urged me to use professional clean-up service by Sucuri and included a link to purchase Sucuri’s service. Panicked, I signed up for an annual service with Sucuri for $199.99 (the cheapest option) that included a 30-day trial period in which I could cancel. I immediately put in a ticket for Sucuri to address the urgent malware problem on my website that I’d been informed about by SiteGround. Sucuri was unable to find any evidence of malware. Meanwhile, SiteGround continued to send me malware notifications, and each time, Sucuri said there was no malware to be found. Realizing Sucuri couldn’t fix the issue and that I’d need to find another service, I immediately requested my service be cancelled as I was still well within the initial 30 day trial period. I was informed by Sucuri that they could not refund me anything because if a customer puts in even one ticket for malware removal–and EVEN IF SUCURI FAILS TO REMOVE IT–it voids the customer’s ability to cancel their service.

That Sucuri wasn’t finding something that existed, isn’t surprising considering our own experiences like what we mentioned in a previous blog post, a situation where we were brought in after they were claiming there was no issue, despite it being easy to find.

That all is out of line with how they market their service, as they make claims like this:

Our dedicated researchers monitor active malware campaigns. With a trained team of analysts, we aim to provide the best malware removal service around.

And this:

We use scripts and tools to quickly scan your website for malware. Our analysts check your site manually too. No hack is too complex for our incident response team.

Trustpilot

That review also highlights a problem when it comes to trying to find the right company to hire to do website malware removal, as that company, like others, is paying review sites, which allows them to hide negative reviews:

**I’d like to also point out that where Sucuri’s customer service team does appear to spend their time is flagging their negative reviews here on Trust Pilot. This is my 2nd time posting a review about Sucuri. Sucuri challenged my last review as not being valid, stating I wasn’t one of their customers. After I provided evidence of my customer status and my back-and-forth with Sucuri to Trust Pilot, my review was reinstated. However, Sucuri then claimed that my review violated Trust Pilot’s guidelines (for reasons that have not been disclosed to me) and they ultimately succeeded in getting my first review removed. If this is how Sucuri conducts themselves on Trust Pilot in order to get the numerous negative reviews about their services removed, then I think there’s likely little hope of their customer service and business model improving anytime soon.**

SiteGround

Also worth noting, is that like people we have dealt with after they had a bad experience with Sucuri, the web host SiteGround had promoted them. It would appear they continue to do that despite at least having some awareness of the problems with Sucuri:

After getting nowhere with Sucuri’s customer service, in February, I finally decided to address my terrible experience with Sucuri with SiteGround, my webhost, since SiteGround was the one who referred me to Sucuri–a fact that made me question whether or not I should continue using SiteGround as my webhost. SiteGround immediately contacted Sucuri on my behalf and got them to issue a refund in the full amount of $199.99. Prior to SiteGround’s involvement, I had been in contact with multiple customer service representatives at Sucuri and their only reply was basically, “Sorry you misunderstood the terms of our contract, but it is what it is and we can’t refund you.” I’m very relieved to see that at least SiteGround takes an interest in their customers and in doing the right thing in their business practice because my webdesigner recommends SiteGround to all her clients. As for Sucuri, my opinion of them remains unchanged. I have no interest in ever using their services again and I cannot in good faith recommend them to anyone.

What might explain why they continue to promote them is that they are getting paid to do that.

The Wordfence Security Plugin Continues to Fail to Live Up to its Claim to Stop Websites from Being Hacked

A couple of hacked websites we were contacted about recently are reminders contrary the marketing of the most popular WordPress security plugin, Wordfence Security, that it “stops you from getting hacked”, it doesn’t accomplish that.

In one of those situation we were provided a list of malicious files that had been supplied by the web host and one of them was stored in directory for the Wordfence plugin:

/home3/[redacted]/public_html/thefaraharchives/wp-content/plugins/wordfence/modules/login-security/classes/model/wp-pingg.php: SL-PHP-SHELL-yp.UNOFFICIAL FOUND

So it clearly didn’t stop the website from being hacked.

In the other we were told after the website was hacked the plugin “locked the site down”, which means it only came in to play after the website was hacked.

That shouldn’t be surprising since a) the developer of that plugin doesn’t provide evidence to support the claim (before using something like that there should be that type of evidence provided) and b) a plugin simply can’t do that, so the developer is lying (something we ran across an employee of theirs admitting several years ago).

Hackers Using Insecure Magento Extensions to Access Magento Admin Login Page Without Knowing Normal Address

While reviewing the log files while cleaning up a hacked Magento website recently we ran across a reminder that a common security practice isn’t full proof. With the Magento software and some other software the software has a built in capability to use a non-standard address for the login page for the admin portion of the website. With other software that is commonly promoted security feature to be implemented with an add-on.

The value of that is limited as while there are widespread claims that there are frequent brute force attacks against admin passwords, in truth what is going on are dictionary attacks, which involved trying to log in using common passwords and that can easily be prevented from being successful by using a strong password. There is the possibility of some value of doing this in a far more limited situation where the hacker has access to valid login credentials for the website, but it turns out that there can be various ways to get access to login page without knowing that address.

In the logs of this hacked website we were seeing many POST requests to this address:

/index.php/magenotification/adminhtml_feedback/index/

When visiting the page we saw that the Magento admin login page was showing. In looking into if that all there was that we found that this is something that hackers are looking around with pages like that generated by various extensions.

Magento added protection against this issue with SUPEE-6788, which was part of Magento 1.9.2.2, but by default the protection is not enabled.

Hacker Using SQL Injection Vulnerability to Add “magentoupdate” Admin Account to Magento Websites

As is a common occurrence, we were recently hired to re-clean a hacked website that the security company Sucuri, which is owned by GoDaddy, had repeatedly failed to properly clean. This time it was a Magento based ecommerce website we were cleaning. As is standard issue in those situations they had missed malicious code that should have been easy to find. What we also found was that the hacker had been able to add an additional admin account, unfortunately that had occurred prior to the time period logging was still available, so we didn’t have evidence of how that had been done.

In a situation where we haven’t been able to determine how the hacker has gotten access, part of our cleanup process is to recheck things for a couple of weeks to see if the hacker tries to get back in. In this case the admin account returned a couple of days later.

For others dealing with the admin account in this situation had these details:

  • User Name: magentoupdate
  • Email: support@media.com
  • First Name: support
  • Last Name: support:

With the logging available from when this occurred we found a log entry where one of the URL parameters was this:

');insert%20into%20%60admin_user%60%20(firstname,lastname,email,username,password,created,lognum,reload_acl_flag,is_active,extra,rp_token,rp_token_created_at)%20values%20('support','support','support@media.com','magentoupdate','8df1e8abd8ce4761633042eb8958db97:rp',NOW(),0,0,1,'N;',NULL,NOW());INSERT%20INTO%20%60admin_role%60%20(parent_id,tree_level,sort_order,role_type,user_id,role_name)%20VALUES%20(1,2,0,%22U%22,(SELECT%20user_id%20FROM%20admin_user%20WHERE%20username%20=%20'magentoupdate'),'support');

That is SQL code that generates that admin user, which would be exploited through a SQL injection vulnerability. In this case it involved exploiting a SQL injection vulnerability in an extension on the website, which we then patched up.

A Web Application Firewall (WAF) is Not the Way to Deal With the Reoccurrence of a Hack of a Website

These days quite a bit of our business dealing with the cleanup of hacked websites is re-cleaning websites after other security companies didn’t clean them up properly before us. Troublingly we recently noticed a company that offers to clean up websites, ASTRA Security, treating that as a normal result and using it to promote using web application firewall (WAF), which they also sell:

Even after clean up and restoring your site, the Magento admin hack may reoccur. The reasons could be a backdoor left by the attacker or simply a vulnerability that may be left unpatched. To avoid such scenarios it is highly recommended to use a WAF or security solution of some sort.

If there is still a backdoor on the website that means it hasn’t been cleaned up, since that would be something would be removed during the cleanup, which someone cleaning up hacked websites should understand.

Part of a proper cleanup is trying to figure out how the website was hacked, so if a vulnerability is left unpatched then things probably have not been done right either.

The providers of WAF’s don’t provide evidence that they provide effective protection against vulnerabilities, while we have seen plenty of evidence that they don’t provide it. It would be even more difficult for them to protect against exploitation of backdoors due to wide variety of their location and what is done through them, which someone cleaning up hacked websites should also understand.

The best way to handle a reoccurrence is to avoid one in the first place by hiring someone like us that will properly clean up the website. If you didn’t do that then the next best solution is to hire someone to re-clean it that will do things properly.

ASTRA Security is Promoting Cleaning Up Hacked Magento Websites Despite Not Knowing Basics of Dealing With Them

While looking around to see if others had already written blog posts about something we ran across while dealing with a hacked website we noticed something from a security company, ASTRA Security, that seems like worth noting, since the company appears to not have a basic understanding of what they are doing. In a post that seems to be built around promoting having that company clean up hacked Magento websites there were multiple glaringly strange claims.

There is this section:

Config.php is an important file of the Magento installation. This file basically facilitates connection between the file system and the database. Config.php contains the database connection credentials. Apart from this, it can also be used to:

  • Define the security keys.
  • To specify the database prefix.
  • To set the default language for your admin panel.

Magento 1

In the first version of Magento, app/etc/config.php contained the list of installed modules, themes and language packages apart from the shared configuration settings.

That file doesn’t exist in Magento 1 and in Magento 2, where the file does exist, it doesn’t contain what is mentioned there.

Things getting odder right after that as this written:

Magento 2

In the newer version which is Magento 2, the app/etc/config.php file is no longer an entry in the .gitignore file. This was done to facilitate better development of the software.

Multiple times, config.php has been infected with malicious code by the hackers to steal user credentials. Here is one such malware sample which was found inside /includes/config.php

The files /app/etc/config.php and /includes/config.php are different files, it seems that this company doesn’t understand that the two files can share a name without being the same.

All of that indicates this company shouldn’t be dealing with Magento websites since they lack a basic understanding of the software, but it appears they don’t have even a basic understanding of web development, as they also wrote this in their post:

Tools like phpMyAdmin are of great help in searching for multiple Magento admin hack infected files in one go. Search for malicious code using phpMyAdmin as shown in the image below.

phpMyAdmin is a database administration tool, so it can’t search files at all, much less search multiple at once. That is very common tool, so failure to understand that seems odd for someone dealing with websites, much less doing something more advanced, namely cleaning up hacked websites.

Unfortunately the security industry seems to be filled with companies that don’t seem to care about having the necessary skills to handle the work they offer and the results are not surprisingly often bad.

If you need someone to clean up a hacked Magento website that actually has years of experience of working with Magento websites and cleaning up hacked ones, we provide that.

index.php Files with the Comment “Silence is golden.” on a WordPress Website Are Not Malware

When it comes to dealing with hacked websites a lot of people would be best off leaving it to professionals (assuming you can find one, among all the unqualified companies), as it is easy for people to get very confused about what is going on. We recently had someone contact us about cleaning up a hacked WordPress website where they were saying that part of the malware was that index.php files had been corrupted with “Silence is golden.” and nothing else.

What they were referring to are files that come with WordPress that had the following contents:

<?php
// Silence is golden.

The purpose of those files is to make sure that a listing of files in the directory they are located is not shown in certain server configurations. So those files are harmless and not in any way malware.

MySQL 5.7 Upgrades By Web Hosts Can Lead to or Expose MySQL Table Issue That Causes Errors on Websites

We were recently brought in to provide support for a Moodle website where when submitting an answer to a quiz question the following error was shown:

Error reading from database

That error message doesn’t provide much to go on. Something like that should not happen randomly, so some change likely caused it, but the webmaster for the website wasn’t aware of any changes that had occurred shortly before that happened.

Turning Moodle’s debugging to its highest setting led to more details being shown about the error:

Debug info: Table ‘performance_schema.session_variables’ doesn’t exist
SHOW VARIABLES LIKE ‘max_allowed_packet’
[NULL]
Error code: errorprocessingresponses

That table isn’t a Moodle table, but instead one that is one of the tables for the MySQL database server.

When we did a search on part of that message we found a Stack Overflow conversation that seemed to match the situation, as the MySQL version in use, 5.7.26, had been out for less than week, so it must have been recently upgraded to and that conversation described the error occurring after an upgrade to a version of 5.7.

Based on the information in that conversation either something gets messed up with that table when doing the upgrade or there was a pre-existing issue that is now causing an error because MySQL 5.7 is relying on that table in a way it previously wasn’t.

If you have dealt with the tech support at a web host before you might not be surprised what came next. When they were contacted about the issue they at first didn’t address what was being mentioned and suggested unrelated solutions. When it came to the former, they stated they couldn’t downgrade MySQL, which was an odd response to the suggestion that the upgrade needs to be fixed. When it came to the latter, they were suggesting upgrading Moodle, claiming that it would resolve this and that the new version was compatible MySQL 5.7 (the version of Moodle in use was actually also compatible with that version of MySQL).

While it took several back and forths between them and our client, eventually they seem to come around that there really was an issue on their end and from there it took tens of minutes for it to be fixed, much to the relief of our client.

Sucuri’s 30 Day Refund Guarantee Scam Gets Worse

Back in May of last year someone contacting us about cleaning a hacked website mentioned that Sucuri had told them that they had 30 day refund guarantee, but when we went to look into that we found that in reality Sucuri didn’t provide refunds if someone had requested a cleanup, which is what that person had contacted them about having done.

Here is how the refund guarantee was advertised on their homepage at the time:

30-Day Guarantee

You have 30 days to request a refund according to our Terms of Service.

If you looked at the terms of service it turned out there was one exception for that refund guarantee, the aforementioned limit if you had requested a clean up to be done:

You will have thirty (30) days from the Service Commencement Date or any Renewal Commencement Date to cancel the Service (the “Cancellation Period”), in which case the Company will refund your Service Subscription Fee for the applicable Service Term provided that you have not submitted a Malware Removal Request during the Cancellation Period.

They could spelled that on the homepage in less than words than it took to mention the terms of service, which seems like a good indication they are tying to hide that.

Since then the terms of service haven’t changed, but as we noticed when we went to look at something on their website recently, the marketing of the refund guarantee has gotten worse. For example at the top of the page about their website malware removals they write this:

Repair and restore hacked websites before it damages your reputation. We offer a 30-day money-back guarantee because we know we can help. You can rely on our dedicated incident response team, state-of-the-art technology, and excellent customer service.

If you actually try to get help though, they won’t provide you a refund, even if they didn’t even do anything, seeing as there is no refund if you request help.

Similar on the Immediate Help page which has its own menu section at the top of all the website’s pages, the description of the second step in the process is:

We offer a 30-day money-back guarantee because we know we can help. After completing your billing information, you’ll get access to the Sucuri Dashboard.

Why Are Experienced Security Analysts Failing To Get Websites Clean?

If you look at the rest of their information on their website malware removal page it seems like they are providing a good warning they something is amiss.

They claim that their cleanups are done by “experienced security analysts” and that that “we aim to provide the best malware removal service”:

Experienced Security Analysts

Our dedicated researchers monitor active malware campaigns. With a trained team of analysts, we aim to provide the best malware removal service around.

They also claim that “[n]o hack is too complex for our incident response team”:

Automatic and Manual Cleanups

We use scripts and tools to quickly scan your website for malware. Our analysts check your site manually too. No hack is too complex for our incident response team.

That makes another section seem rather odd, since they highlight that they provide “unlimited cleanups”, which shouldn’t be needed if they properly cleaning and securing websites (they actually do neither of those things properly):

Unlimited Cleanups

We love complex malware infections, and you’ll never pay more for them. Each plan covers your website for a year, including unlimited cleanups, pages, and databases.

Another claim that stands out is this:

Consider us an extension of your team. With professional security analysts available 24/7/365, you never have to worry about dealing with a hacked site.

In reality what we have hearing over and over from people coming to us after having used their service, is that they can’t get in touch with anyone at Sucuri. That doesn’t seem to be isolated issue, as numerous recent reviews of Sucuri on the website Trustpilot include the same complaint.