Do You Need to Worry About Being Hacked if WordPress is Warning of Use of an “Insecure” Version of PHP?

Recently we had someone hire us to clean up a hacked WordPress website where one of their concerns in regards to dealing with the situation was that they were being warned by WordPress that they were using an “insecure” version of PHP:

What that referred to was use of version 5.6.x of PHP, which is no longer supported, with the website.

While it is a good idea to keep software up to date and use supported versions, it also important to understand what risk there are and are not, when not doing that. Software that is outdated is not necessarily any more insecure than up to date software (as up to date software can, and in a lot of cases does, have vulnerabilities as well). More importantly, software that is insecure is often not insecure in a way that is likely to lead to a website being hacked.

With PHP, you have to go back to May of 2012 for an instance where there was a vulnerability that was fixed, which then had widespread exploit attempts. Even with that, the vulnerability was only exploitable on a subset of PHP installs, due to only being an issue with one particular setup.

That doesn’t mean that you don’t need to keep PHP up to date, but it does mean that if your website is hacked, unless a new equally serious vulnerability has been found in PHP, then the PHP version likely wasn’t part of the cause of the hack. It also means that when dealing with a hacked website you don’t need to rush to change the PHP version. Which is a good thing, since switching to a newer version could cause software that isn’t designed for it, to break.

As part of our hack cleanups of WordPress website, we can handle getting the software used on the website compatible with the newer version of PHP and the PHP version brought up to date (to the extent that isn’t something that the web host has to handle), as we did that website.

VaultPress Didn’t Protect Website From Being Hacked

Recently we had someone hire us to clean up a hacked WordPress website that mentioned that they had thought that the VaultPress service for WordPress they were using would protect their website. As they were already aware by that point, it hadn’t turned out to be true.

It is understandable that they might think that since this is what you see when you visit the homepage of the VaultPress website:

But the feature set listed in the lower portion of the homepage doesn’t make any mention of a feature that provides any protection against hacks, instead it indicates that it might detect you have already been hacked:

While detecting the aftereffects of a hack can be useful, it won’t protect the website from being hacked. Also, they don’t put forward evidence, much less, evidence from independent testing, that shows that the service is actually able to effectively detect malware. We wouldn’t recommend using a service like that if they are not providing evidence to support their claims (which means we recommend not using most security services at this time).

In this situation, the owner of the website became aware that the website was hacked because the search results for the website showed pharmaceutical spam, not from VaultPress.

HostGator and SiteLock Use a Raft of Falsehoods to Sell Unnecessary Security Service

When it comes to the selling of web security services, it is common for those to be sold using with clear falsehoods. We recently highlighted an example of that with a service called Malcare. But the breadth of the falsehoods that were used recently to get $300 out of a customer of the web host HostGator for a SiteLock service stands out.

The customer contacted HostGator support about dealing with the website not showing up as being secure despite a SSL certificate being purchased. They weren’t sure if they were then dealing with someone from SiteLock or HostGator, which sounds a bit odd, since you wouldn’t think that you would contact your web host and be transferred to another company, but that has at least in the past been the case of web hosts, like HostGator, who are partnered with SiteLock. The conversation they then had was described to us and it sounds in line with what have heard in the past and seen when provided transcripts of the conversions.

They were told that the website contained malware, when they responded that was the old website at different web host (they replacing everything because of the website being hacked), they were told that the malware was tied to the domain name and redeployed to the new website to find vulnerabilities. They were told that a firewall needed to be put on the website, for $300, to stop the website from being infected the way the old one was and that the Google search results would be cleaned. As to evidence of the claim of malware, they were pointed the search results for the website, which showed pharmaceutical spam.

There are a lot of falsehood packed in there, which include:

Google’s search results are not real time, so spam pages showing up there doesn’t necessarily mean there is anything at issue with current state of a website, unless they are from a crawl just done. Spam pages are also different than malware.

Even if there were spam pages, they wouldn’t cause the website to not be listed as secure, since that isn’t impacted by that. Potentially a hack could cause pages to not be secure, if say, they added code to existing pages that accesses a website over HTTP instead of HTTPS.

SiteLock couldn’t clean up Google’s results. If the website is still hacked, then cleaning that up would eventually lead to Google’s results no longer showing the spam pages. If it is clean now, then they would just need to wait for Google to refresh them.

Malware isn’t tied to a domain name. If someone is flagging the website as containing malware, that could be tied to the domain name, but that isn’t tied to it being listed as secure as far as we are aware, as that relates to something else.

If there are vulnerabilities, you would want to fix them, not put a firewall around the website, since among other things, there isn’t evidence that firewalls like SiteLock’s would actually effectively protect against those vulnerabilities and plenty that they wouldn’t. Also, hackers are always trying to exploit vulnerabilities on websites, that has nothing do with a domain name being tied to malware.

So almost nothing they said was true and none of it actually addressed the issue that support was being contacted about in the first place. You might think that conduct like this would have some repercussions, but right now neither journalists nor government regulators have shown an interest in it.

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.

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.

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.

GoDaddy’s Idea of Securing Websites Actually Involves Leaving Them Insecure and Trying to Deal with the After Effects of That

Yesterday we discussed GoDaddy’s usage of misleading claims to try to sell overpriced SSL certificates. Based on that it probably wouldn’t be surprising to hear that they would mislead people in other ways about security and that is exactly what we ran across while looking into things while working on that previous post.  When we clicked on the “Add to Cart” button for one of their SSL certificates, at the bottom of the page we were taken to, there was a “malware scan and removal” service offered to “Secure your site”:

The description of that is:

Defend your site against hackers and malware with automatic daily scans and guaranteed cleanup.

It shouldn’t be too complicated to understand what is wrong with that, though as we mentioned earlier today there seems to be a lot of confusion when it comes to what security services and products do.

If a website is secure it wouldn’t have malware or some other hack on it to detect or remove, so either GoDaddy doesn’t understand what they are providing or they are lying about.

The problem we see so often with this sort of service is that people will fail to do the things that will actually keep websites secure because they believe a service like this will actually keep a website secure.

Trying to deal with the after effects of having a website hacked instead of actually securing it introduces a lot of issues. One of those being that if a hacker uses the hack to exfiltrate customer data stored on the website a cleanup isn’t going to undo that.

What is a lot more important to note is that everything we have seen from the underlying provider of GoDaddy’s security services, Sucuri, is that they are not good at detecting and cleaning up hacks of websites. Their scanner seems, to put it politely, incredibly crude. Their employees seem to lack a basic capability to understand evidence that a website is hacked. And in what is most relevant to this specific service, we recently we brought in on a situation where their scanner had failed to detect that a website was hacked and then they repeatedly incompletely cleaned up the website, leaving it in a hacked state for a while. It was only after we were brought in to clean things up properly (which Sucuri doesn’t appear to even attempt to do) that it was finally cleaned and stayed that way.

Monitoring For Malware and Other Website Hacks Won’t Prevent a Website from Being Hacked

In dealing with people with hacked websites we are often reminded that things that seem like they should be easy to understand about security products and services are often not for a lot of people. What plays at least some role in that, and maybe a lot, is that the security industry frequently makes misleading and outright false claims.

We recently had someone that contacted us about a hacked websites who seemed to be unaware that monitoring for malware or other types of website hacks would not prevent the website from being hacked or clean it up if it did get hacked. In their case they said they were relying on monitoring from SiteLock and Wordfence.

What monitoring tries to do is detect evidence of malware or another hack after it has occurred. Since it comes in to play after the hacking it wouldn’t be possible to stop it from occurring. Despite that we have seen providers of monitoring services promote them as being able to stop or protect a website from being hacked. Either these providers don’t understand what they are providing or are lying about it, neither of which is a good option.

If there were monitoring solutions that were effective at doing what they are actually trying to do they might be a good option as additional measure beyond doing the basics for high profile websites that are at elevated risk of being targeted by hackers. We have yet to see any such service that presents evidence, much less evidence from independent testing, that they are effective though, which seems like it should be a baseline for using such a service at all. What we have seen of monitoring solutions and other tools to detect malicious code in years of dealing with the cleanup hacked websites is that they have a limited, at best, ability to spot malicious code on a website.

For the average website what should be the focus is doing the things that will actually make websites secure instead of hoping that a security service is going provide even a fraction of what the extraordinary claims they often are promoted with would lead people to believe they are capable of.

GoDaddy Using Google’s Change to Label Non-HTTPS Websites as “Not Secure” in Chrome To Sell Overpriced SSL Certificates

Yesterday we discussed someone’s belief that their website would be useless in its current form due to a company’s blog post about Google making a change to their Chrome web browser to label non-HTTPS websites as “not secure”. Unrelated to that, yesterday we  got sent an email from GoDaddy touting purchasing SSL certificates from them to avoid websites being labeled that way by Chrome. Two things stood out with that. The first being that GoDaddy charges much more than you need to be paying for an SSL certificate, which will in part prevent a website from being labeled as “not secure”, but also that GoDaddy doesn’t seem to really understand what they talking about when it comes to HTTPS. That latter fact isn’t all that surprising considering GoDaddy’s poor security track record.

The subject of the email was “Your customers need SSL on their sites ASAP.”.

On the page linked to from the email, their lowest end SSL certificate, which would be the level you need to avoid the “not secure” label, the introductory price is 60 dollars if you pay for two years upfront and then after that 75 dollars:

With other providers you can pay a fraction of that price. It also looks like that used to be true with GoDaddy as well, as they have apparently significantly increased the prices they charge for SSL certificates over the years despite nothing that would have increased their costs.

Using Let’s Encrypt you can even get a free SSL certificate and there are plenty of web hosting providers that have the capability integrated into their control panels to allow setting those up. It’s worth nothing that GoDaddy’s security company has been a major sponsor or donor to Let’s Encrypt, which seems like a tacit endorsement of Let’s Encrypt .

That GoDaddy is overcharging for SSL certificates instead of being like other hosting providers and offering free SSL certificates seems worse to us when reading one of the three testimonials they chose to show on that page that touts them providing an affordable solution:

I received a call from product support to let me know Google was getting more rigid about “secure sites”. We were able to make the upgrades that I could afford, and make my site more mobile accessible AND secure.

Another testimonial seems more insidious since it gives the impression that GoDaddy is providing cheaper certificates than others instead of more expensive ones:

I’ve set up SSL certificates from various companies but will never use anyone but GoDaddy every again. It’s easy to set up, great support and at a fraction of the price it’s great all around!

That is a great example of why testimonials are not a great source of information because that one allows GoDaddy to make it seem like they providing a more reasonable priced product without having to lie. If they really were providing cheaper certificates they would have been able to present evidence to back that up.

Misleading Marketing

The email made the following claim:

SSL is not only the right thing to do for your customers, it’s also great for boosting their search rankings and getting more traffic to their sites.

No link was provided that backed up that claim. On the page to purchase an SSL certificate, the claim is made repeatedly in regards to Google search results, but again no evidence is provided.

Based on what Google has said it doesn’t sound like using HTTPS has much impact. Here is in part what Google said when the disclosed that usage was a ranking factor:

We’ve seen positive results, so we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.

As far as we are aware they haven’t announced strengthening it and they seem to be using changes to Chrome to increase usage of HTTPS.

In another instance, a Google employee explained the impact as follows:

If you’re in a competitive niche, then it can give you an edge from Google’s point of view. With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.

Importantly, if both websites were using HTTPS the impact on the ranking boost of either one would be nullified.

Misleading on that seems of less importance than a page they created just to promote buying their SSL certificates due to the change to Chrome.

There they claim that “A Not Secure label on your website can devastate your business.”:

No evidence is presented for that despite it being a serious claim.

What seems like a clear indication that they are not interested in informing people about what is happening, but selling something is another part of that page which states that using HTTPS will “shows visitors they’re safe with the little green lock in their address bar”:

The next HTTPS related change in Chrome, occurring in September, involves it downgrading what is shown for HTTPS pages:

Do They Know What an SSL Certificate Even Is?

Going back to the page for selling SSL certificates there is what is supposed to be an explanation of how a HTTPS connection works, but it seems to have been written by someone that isn’t familiar with it all:

An SSL certificate doesn’t “automatically creates a secure, encrypted connection with their browser”, instead the SSL certificate is just used to validate that a secure connection is being made with the intended website instead or with another party.

Among the other issues with that is that the level encryption is determined by the server and the web browser, not the SSL certificate.

GoDaddy might be able to justify a higher price for an SSL certificate if good customer service was provided, but considering how off the marketing material is, it is hard to believe that their customer service would be well informed about them.

Sucuri’s Website Application Firewall (WAF) Makes Improving Websites’ Security Harder, While Being Easily Bypassable

When cleaning up a hacked website there are three main components to doing that properly. We often find that security companies don’t do two of those. One of them being trying to determine how the website was hacked. The other being getting the website secure as possible, which usually involves getting the software on the website up to date. If a company isn’t able to make sure the software is up to date, it seems likely they also are not familiar enough with the software that they should be dealing with hacked websites running it.

One well known company that usually skips doing those things is Sucuri. They promote as alternative to doing that securing, that you can rely on the virtual patching provided by their website application firewall (WAF). There are a number of reasons why that is bad idea, including that they don’t present any evidence, much less from independent testing, that their virtual patching is effective (they also don’t present any evidence that their service is effective at protecting websites in general). Probably the largest problem with relying on that though, is that it can be incredibly easy to go completely around their WAF, leaving websites that haven’t been properly secured wide open to being hacked.

Before we get in to that, what lead to us writing this post was our recent experience with their WAF making it harder to get a website secured.

We were recently brought in to upgrade a Joomla installation on a website that Sucuri cleaned but had failed to upgrade the software on it. When we went to do that upgrade we ran into an error, “ERROR: AJAX Loading Error: Forbidden”:

That error message doesn’t provide much information on what was going wrong and we would guess that others that run into it might get stuck at that point. In debugging that we found that when an AJAX request was made to  /administrator/components/com_joomlaupdate/restore.php the response being received was this page:

Access Denied - Sucuri Website Firewall If you are the site owner (or you manage this site), please whitelist your IP or if you think this block is an error please open a support ticket and make sure to include the block details (displayed in the box below), so we can assist you in troubleshooting the issue.

At that point we could have contacted the person we were dealing with from the website and get them to try to whitelist our IP address, but there was a far quicker solution, simply bypassing Sucuri’s WAF, which can be incredibly easy to do.

Here’s is how Sucuri explains how their WAF works:

The reality is that all HTTP/HTTPS traffic does not have to begin where they show it beginning in that graphic, instead, if you know the IP address of the Original Host you can connect directly to it, bypassing the WAF entirely.

While in something we will get to in a moment, Sucuri refers to this IP address as being “hidden”, in reality it often isn’t hidden at all. In the case of the website we dealing with we just pulled up the DNS records for the website and the second IP address (after the Sucuri one) was the Original Host’s IP address (there was another equally easy method available as well). By simply associating that IP address with the domain name in a computer’s host file the Sucuri WAF can be bypassed.

From previous real world experience we can say that people will in fact rely on Sucuri’s WAF to keep them safe instead of keeping software up to date, which can leave people wide open to attack if someone just takes time to bypass the WAF. What makes that particularly problematic is that a website could appear to be secure for a long time, leading to people claiming that Sucuri’s solution is effective, and only later it becomes clear that things were not as how they seemed.

Here’s what makes this even more troubling, Sucuri is aware of the ability to bypass their WAF, but they either don’t understand that their attempt solution to stop that doesn’t resolve the issue or they don’t care that that what they are providing is fundamentally insecure.

The page Prevent Sucuri Firewall Bypass on Sucuri’s website begins:

If someone knows your hidden Hosting IP address, they can bypass our Firewall and try to access your site directly. It is not common or easy to do so, but for additional extra security, we recommend only allowing HTTP access from our Firewall.

The best way to prevent hackers from bypassing our Firewall is limiting their access to your web server. To do this, all you have to do is add restrictions to your .htaccess file so that only our Firewall’s IP will be able to access your web server.

As we already noted, the IP address isn’t necessarily hidden at all. Calling attempting to prevent the easy bypass as “additional extra security” as opposed to being essential, doesn’t provide much assurance that they actual are concerned about the security of websites using their service.

The larger issue here is that trying to restrict what IP address can access the Original Host directly isn’t very effective. That is because all someone has to bypass that restriction is to spoof a permitted IP address, which involves making it seem a request came from a different IP address than it really did. Either Sucuri doesn’t understand that or doesn’t care that their WAF is fundamentally insecure, neither of which should be true about a security company.

Their a major limitation with spoofing an IP address that is important to note though, which is that any response would not be sent back to the system sending the spoofed requests since the response would be sent back to the spoofed IP address. But with the kind of vulnerabilities we see actually being exploited on websites that often wouldn’t be an issue since the hacker doesn’t need to receive a response to gain further access to the website. Oncee they have access they could remove the IP address restriction or send any responses they need in way they can still access (say writing them to a file accessible through the website).

While we wouldn’t recommend using Sucuri’s WAF (or their services in general), if you are using it, restricting IP addresses as suggested in that previously mentioned article would provide better security when using their WAF.