A Web Browser Listing a Website as “Not Secure” Doesn’t Mean It has Been Hacked or Contains Malware

In dealing with hacked websites, a lot of what we do isn’t the work of the hack cleanup, but explaining things. Recently the issue of web browsers’ messages about websites being “Not Secure” came up during a cleanup. With that limited detail it is easy enough to assume, after having had your website hacked, that warning refers to a security issue relating to hacking, maybe malware, but it doesn’t.

What additional information, if any, is provided by the web browser when that warning is shown varies. Apple’s Safari web browser on Mac provides no additional information if you click on “Not Secure”. By comparison, the Mac version of Google’s Chrome web browser provides a pop-up that reads:

Your connection to this site is not secure

You should not enter any sensitive information on this site (for example, passwords or credit cards), because it could be stole by attackers.

What that is explaining is that by “Not Secure”, they mean that the connection between the website and the web browser is not encrypted, so information passing back and forth could possibly be read somewhere between the two. In a lot of cases this doesn’t really matter, since nothing sensitive is being shared between the two.

To stop the warning, the website should be accessed over HTTPS instead of HTTP. That generally involves setting up an SSL certificate and setting it so that requests to website are made over HTTPS instead of HTTP. Depending on the web host and software used on the website, that can be easily done and done for free.

It also worth noting that in most instances, from our experience dealing with lots of hacked websites, making a website secure in that way wouldn’t have an impact on whether a website is hacked, since the hacks do not involve taking advantage of that insecurity.

Zen Cart Stores Can Have One Step Checkout and be Mobile Friendly

If you have a website, you probably get contacted by email with web development offers. That is true even, if, like us, you are web developers. The lack of targeting goes farther than that, as earlier this week we got an email that looks to be intended to target those with Zen Cart stores. We don’t have a Zen Cart store or a store in general, but we do provide services for Zen Cart websites. The email seems to be worth noting due to what might be a more general misunderstanding about Zen Cart.

Here is the full email:

Hi ,

I heard you were the right person to speak with regards to your site whitefirdesign.com but if I am wrong, could you please point me in the right direction?

According to a survey by DigitalEra, e-stores having modern design with latest commerce features like one step checkout generate 27% more profits and have 52.5% less bounce rate compared to conventional e-stores.

Given Zen Cart stores have subpar aesthetics and appeal, lack modern features like 1 step checkout and are not mobile friendly, are you facing store performance issues like high bounce rate, low traffic and sales on your site?

If yes, I was curious to know if you are planning to migrate from Zen Cart?

We can help you evaluate your CMS options including WordPress, Shopify, Magento etc and migrate accordingly. Do let me know.

Regards,
Robert
WordPress Consultant

Like most web software, whether a website powered by Zen Cart is mobile friendly or not is determined by the theme/template that is being used. So a lack of mobile friendliness would be just as true or false as a WordPress or Magento website.

While Zen Cart by default has a multi step checkout process, if you want to reduce the number of steps, plugins have been available to handle for that years.

WordPress, which the person ostensibly was trying to promote switching over to, isn’t even e-commerce software. It started as blogging software and could now be considered CMS software. It can include e-commerce functionality through plugins. So suggesting switching over to WordPress to get functionality missing in Zen Cart doesn’t make a lot of sense, since it doesn’t include it by default either.

For anyone still wondering if emails like that are on the level, the survey cited there doesn’t appear to exist. The only entity we could find named DigitalEra is a cybersecurity provider. The domain of the email address to reply to, cmstowordpress.com, doesn’t currently serve up a website either.

PHP Deprecated Warnings in the error_log File Are Not The Cause of 500 Internal Server Errors

In dealing issues with websites for clients, one thing we deal with a lot is that others are giving advice on things they don’t understand. That is an acute problem with the security of websites, but it also comes in to play in other places. Recently we had a client contact us about having their Joomla website stop functioning after changing the PHP version in use on their website to PHP 7.1 or above. They had previously contacted another of their providers about the issue, Sucuri, and were giving a claimed explanation of what was going on, which was, if you are slightly familiar with the subject, clearly wrong.

Someone at Sucuri wrote this:

We have reviewed the 500 Internal Server error and see in the cPanel error_log that the joomla files caused the issue:

What followed that were several lines from the website’s error_log file that looked like this:

[02-Apr-2021 17:12:16 UTC] PHP Deprecated: Non-static method GantryGZipper::_getOutHeader() should not be called statically in /home/[redacted]/public_html/libraries/gantry/core/gantrygzipper.class.php on line 108

For the purposes of determining what was causing the website to stop functioning, the key piece of information there was this: “PHP Deprecated”. What that tells you is that message is a warning that something has been deprecated and won’t work in a future version of PHP, but it still works now. So if you start seeing that warning when the website stops working, it couldn’t be the cause of the issue, since the message is explicitly stating what is being warned about is something that hasn’t stopped working yet.

As further confirmation of this, the relevant PHP documentation states that this issue only starts causing an error in PHP 8:

Calling non-static methods statically throws an Error.

Prior to PHP 8.0.0, calling non-static methods statically were deprecated, and generated an E_DEPRECATED warning.

The actual error that was causing the website to stop wasn’t even shown in that error_log file, which isn’t an uncommon situation.

As with so much of the poor advice that comes from security providers, though usually about security, it sounded like the person knew what they were talking about, but they didn’t.

Sucuri Claims to Know The Most Common Cause of Website Hacking Despite Not Determining How They Are Hacked

We are often brought in to re-clean hacked websites after another provider, Sucuri, has been hired to clean them, but has intentionally cut corners, leading to the website still being hacked after they have claimed to have cleaned it up. In the most recent instances we were brought in, the website was still hacked, though to a more limited extent than usual. But what stood out more that not only was the website still also insecure, but it was still insecure because of Sucuri’s parent company, GoDaddy. That is something Sucuri would have noticed if they have done one of three key components of a proper cleanup, trying to determine how the website was hacked and fixing that.

What makes the lack of doing that stand out more, is that an email sent out by Sucuri after their cleanup made this claim:

Out of date software is the most common cause of website compromise. It’s highly recommended to get that updated as soon as you can.

So clearly they believe you can determine how websites are hacked, but they don’t do that. Beyond that being a problem to get things properly cleaned, it also would it make hard for something they claim to do right at the top of their home page, namely preventing future attacks:

We fix hacks and prevent future attacks.

How do you prevent future attacks if you don’t know how previous ones were actually done? In other instances we were brought in, the website was already using Sucuri’s service when they were hacked, so clearly their prevention didn’t work, but Sucuri wasn’t interested in figuring out what went wrong.

GoDaddy’s Insecure Hosting

The remaining piece of the hack that they missed were admin accounts for the website created by a hacker or hackers. Looking in to how those got there would be part of trying to determine how the website was hacked. If you actually do that work regularly, as we do, then what you immediately notice is that the accounts don’t look like they were created through the normal process in the software being used on the website, since most of the details, like when the accounts were registered, were empty. What that usually means is the hacker had direct access to the website’s database.

If the hacker had access to the database, that most likely mean they were able to get access to the credentials for the database. A type of vulnerability that could provide them with that information is one that is widely exploited when it exists in software. We rarely see websites that have been hacked due to that type of vulnerability, because in most cases the hacker doesn’t have a way to directly connect to the database to then use the credentials.

With this website, though, we confirmed that you could remotely connect to the database. The vast majority of websites don’t need to the database to be remotely accessible and they normally are not, since it introduces a security risk with no upside for almost all websites. Fixing that would be something that Sucuri should have done, if they were doing things properly instead of cutting corners. When we went to see about doing that we found it was already supposed to be the case, as the database wasn’t supposed to be able to be connected to remotely:

It wasn’t a one off issue, as another part of the work Sucuri failed to do was to update the software on the website. When went to work on that we created an additional database to test the upgrade and it was also remotely accessible despite being set to not be.

That wasn’t the only security issue we ran across with the hosting account, as we will discuss in a future post.

What really stands out is the website is hosted by GoDaddy, which owns Sucuri. Is it any wonder that security is so bad, when not only does a security company not do the basic work they should do, not only is a web host failing on basic security, but when the two are part of the same company.

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 &gt; 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/RecentOrdersDashboardWidget.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.

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.