NortonLifeLock Safe Web Blocks Websites Without Providing Basic Details to Justify Doing So

The power of big tech companies to censor has recently been getting spotlighted quite a bit. One element of that which doesn’t seem to get nearly as much focus when that comes up, is whether those actions are being taken in line with the stated policy justifying it when not involving high profiles actors and if there is a fair process to fix a mistake or undo things if changes have been made. While the focus on that censoring is usually in relation to social networks, it can impact other areas as well. NortonLifeLock’s Safe Web system being an example of one with problems, which we ran across again while dealing with a website that had been hacked.

The website was cleaned of malicious code about a month ago. But the company doing that Sucuri, failed to do other work that is part of a proper cleanup, so we were brought in. Another issue with the website is it being blocked NortonLifeLock’s software that relies on their Safe Web system. The block page shown when using their Norton Safe Search Enhanced extension for the Chrome web browser warns “Dangerous Webpage Blocked” and “This is a known dangerous web page. It is highly recommended that you do NOT visit this page.”:

That most likely would be connected to the hack, but it isn’t clear and, even if it is connected, there is no way to tell if that is based on the state of the website before it was cleaned or after.

Clicking the “View Full Report” button brings up the entry for the website on NortonLifeLock’s Safe Web website, which provides almost no additional detail. At first glance it just provides the same exact information:

Clicking the “Click here to submit dispute” link provides one additional detail, the website has been categorized as “Malicious Sources/Malnets”:

If you don’t know what that means, you are not alone, as despite dealing with hacked website for years, we are not familiar with any significance of that terminology.

How exactly are you supposed to reasonably dispute such an action when you don’t know what is you are even disputing?

While in this situation the website was in fact hacked, so the blocking could be justified, NortonLifeLock isn’t exactly a company that has shown it should be trusted. One of their predecessor companies paid major fines for false claims and the other has years worth of behavior that seems like it should have put them out of business.

Web Host Caching Can Cause Changes to Websites To Be Applied in a Delayed Manner

When we are contacted about issues with websites, we often find that important details haven’t been provided at first, and asking for more detail is better than trying to jump into dealing with the issue. That far too often runs into another issue, people managing websites think they know what needs to be done, even though they don’t know how to do that, and don’t want to provide more details.

A recent example of the first part of that occurred when we were contacted by someone we had previously done work on a Zen Cart based ecommerce website for. They now had an issue where when adding some products to the shopping cart a message, “Whoops! Your session has expired.”, was being displayed, while others were added normally. While doing an initial assessment of what was going on, it looked like some pages were being cached from one session were then being displayed for others visiting the website.

They also had mentioned in the initial message that when editing products, they were not looking the same on the frontend as it was on the backend. We further inquired about that and the response made it sound like caching was in place on the website, as they described that there was a delay between changes being made to products and those showing up on the frontend. If we had known that at the beginning, we could more easily determined what was at issue. Once we inquired if there was any caching enabled, they were able to take care of that, and got their issue fixed with no charge from us.

Caching built in to web software or as an addon for said software is generally designed in a way that avoid these types of problems. When that is done in other places that isn’t always true and people managing websites don’t necessarily know the caching is occurring, much less would they understand the implications of that. We see problems because of that most often with web hosts providing caching, but we also sometimes see it with security services that also include caching.

That is a good reminder that service providers should be more careful about caching usage, but also that talking to someone with more expertise and answering the questions they asked can lead to a better result than going it alone or dictating how something should be handled that you don’t have expertise in.

Dealing With Incorrect Results in Zen Cart’s Best Products Purchased Report After Upgrade

While the Zen Cart team usually resolves bug introduced in to new versions quickly, an issue with the Best Products Purchased report has existed for over two years. The issue produces obviously incorrect data in the report. Here was the result it was producing on a website we just upgraded to the latest version of Zen Cart, 1.5.7c:

While there are only 7 products shown, the stats at the bottom of the table say there are 20 shown out of 27,899.

Previously the report showed three products:

The different result is due to a change made to the query used to get the relevant data from the database. The comment included with the changed code that caused this is “new query uses real order info from the orders_products table, and is theoretically more accurate”. The results are clearly not always more accurate, though.

A quick fix for this is to restore the SQL query used to generate the results as of the last working version, 1.5.5f. In the file /[admin directory]/stats_products_purchased.php, the relevant line to change looks like this in version 1.5.7c:

          $products_query_raw = "SELECT SUM(products_quantity) AS products_ordered, products_name, products_id
                                 FROM " . TABLE_ORDERS_PRODUCTS . "
                                 GROUP BY products_id, products_name
                                 ORDER BY products_ordered DESC, products_name";

The previous version looks like this:

  $products_query_raw = "SELECT p.products_id, sum(p.products_ordered) as products_ordered, pd.products_name
                         FROM " . TABLE_PRODUCTS . " p, " . TABLE_PRODUCTS_DESCRIPTION . " pd
                         WHERE pd.products_id = p.products_id
                         AND pd.language_id = '" . $_SESSION['languages_id']. "'
                         AND p.products_ordered > 0
                         GROUP BY p.products_id, pd.products_name
                         ORDER BY p.products_ordered DESC, pd.products_name";

Dealing With Slow Loading of Zen Cart Admin Dashboard in Zen Cart 1.5.7

While working on a recent Zen Cart upgrade, we ran into an issue where the admin dashboard went from loading nearly instantaneously to taking at least 5 seconds to load in Zen Cart 1.5.7. The page loading would pause when the “New orders” section was next to be shown, so that seemed to be the source of this. That seemed to either be because of a bug or a change that significantly increased the amount of data being processed.

It turns out to be the later, as Zen Cart 1.5.7 by default queries attribute data for products when generating that section, which can significantly slow things down in some circumstances.

As of Zen Cart 1.5.7a, there is a simple way to disable that and return to previous load times for those that don’t require that data to be queried. In the file /[admin directory]/includes/modules/dashboard_widgets/RecentCustomersDashboardWidget.php, near the top is the following line:

$includeAttributesInProductDetailRows = true;

Switching that from “true” to “false” will disable the queries and restore the previous load time.

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.


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.**


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:


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, 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:
  • 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:


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.