A Case Study in SiteLock Leaving a Website Insecure While Labeling It as Being Secure

When it comes to the security of websites we frequently see that while security basics are often not being done, security companies are pushing more advanced security products and services. Sometimes those two things come together, last month we looked at one cyber security company that claims to have “clients in the intelligence community, DoD and nearly every cabinet agency” and isn’t bothering to keep the software running the various parts of their website up to date while telling the public they need to take advanced measure to protect their websites. As we mentioned in a post the other day, by comparison the web security SiteLock does keep the software on their own websites up to date, while leaving the software out of date on their customers websites that they are supposed to be securing. We ran across another example of that while looking at one of their case studies that is supposed to show how great their services are.

The case study is missing basics details that would be needed to understand what was actually going on and if SiteLock had done anything to actual secure the website. The post claims the website in the case study was targeted by cybercriminals, but they don’t even mention what type of attack there was:

When cybercriminals began to target Airspeed-Wireless.com last year, he became alarmed. Spiridigliozzi took an investigative approach and soon determined the attacks were coming from an IP address in Iran. His host-provided security options were limited so instead he blocked the malicious IP, hoping it would solve the problem. Unfortunately it did not and the hacking attempts continued.

Most hacks are not targeted, so it is entirely possible that what was actually happening was that website was being hit as part of mass hacks that wasn’t even trying to exploit vulnerabilities relevant to the website and there wasn’t a real threat.

Blocking IP addresses is not an effective security measure because if there is a actually a vulnerability then a hacker could easily get around it by simply using another IP address. It is important to note that the web host, the one that SiteLock says has limited security options, is Bluehost, which is not only a SiteLock partner, but it’s parent company, Endurance International Group, is run by the owners of SiteLock. SiteLock’s partners get paid handsomely for pushing SiteLock services, so providing a poor security options would likely be financial advantageous for them (that might be a good reason to avoid web hosts that have partnered with SiteLock).

The case study that then moves on to another website:

During the process Spiridigliozzi was attacked again, this time on a website he was developing. The new attack came from an IP address in Morocco. The hacker injected malware into the newly developed site and taunted Spiridigliozzi by engaging him in online chat.

There is no explanation as to how the website was hacked, which would be important information for people to know to protect their own websites and to determine if SiteLock could have actually prevented it and whether there might a more effective way to do that.

In the next section the tout their TrueShield Web Application Firewall:

SiteLock also wanted to provide Spiridigliozzi with a preventative solution. They installed the SiteLock® TrueShield™ Enterprise Web Application Firewall (WAF) on Airspeed-Wireless.com. This top tier WAF blocks bad bots, the Open Web Application Security Project (OWASP) Top 10 threats, backdoor connections and meets PCI standards.

First it is worth noting that contrary to how they promote the service, this isn’t actually their service, instead they just slap their branding on Incapsula’s WAF.

Next, just the other day we discussed an instance where one of their customers using the WAF was hacked again and they were told that they don’t cover backdoor access :

Now, after we’ve been hacked yet again, I find out that is not true. SiteLock assures me that everything is set up correctly, and that the hacker must have a back door access point.  They don’t cover that. Bluehost doesn’t cover that. I’m screwed.

That obviously doesn’t match up with their claim in the case study that WAF blocks backdoor connections.

Then they claim that numerous threats were blocked:

Since it was installed, TrueShield has blocked 9,478 malicious threats, five SQLi attempts, and 27 visitors from blacklisted IP addresses.

What stands out is the fact that most of threats that were supposed be blocked are vaguely “malicious threats”, but a few SQL injections attempts are broken out even those would also be a malicious threat. That vagueness is important since the reality is that probably only a small fraction of one percent of hacking attempts have the possibility of being successful (many hacking attempts will involve trying to exploit vulnerabilities in software not being used on a website for example). A useful measure would how many of the blocked attempts would have actually lead to the website being exploited if not running through the WAF, SiteLock probably doesn’t have any clue as to that sort of things since they don’t actually provide that service.

The next section points to SiteLock odd idea of how to protect a website:

Spiridigliozzi is grateful for the upgraded security, “The SiteLock suite of security tools now allows me to be more proactive in preventing unwanted visitors and bots from accessing my website, the dashboard gives me an immediate indication of any problems and I also receive email alerts if there are any issues.”

If there is a vulnerability on a website the best way to protect against it is to fix it, trying to stop people that might exploit it is going to be harder to do and SiteLock doesn’t provide evidence of its effectiveness.

It turns out that the website is actually insecure now in an easy to check for way. It is running an outdated version of Magento with known security vulnerabilities:


Magento does provide patches for older versions, so an outdated version might be secure, but in this the website MageReport.com reports that the security patch that provides the same fixes as Magento 1.9.3 is not installed (both the security patch and Magento 1.9.3 were released on October 11):


SiteLock seems to be unaware of this as they are currently labeling the website as secure:


The Previous Case Study Is Running An Outdated Version of Joomla

In the case study that proceeding the one we just discussed, SiteLock promoted its scanning service:

The SiteLock 360-degree Security Scan was placed on bluedgebiz.com. As the name suggests, the scan provides a comprehensive scan of Wilson’s entire site. This includes a complete malware, network, spam, SQL Injection, and Cross-Site Scripting scan. With this scan, Wilson is alerted immediately if suspicious code or vulnerabilities are found.

In the past we discussed that we couldn’t find evidence that SiteLock was actually able to find vulnerabilities and a past commenter who had a gotten their scanning service ended up with their website hacked four months later. Both of which don’t point to this service being that great, but the other issue with this is that even if you are alerted vulnerabilities you would need to take action.

Clearly something hasn’t worked in the case of this website as the website is currently running an outdated version of Joomla 3.6.3:


Version 3.6.4 was released on October 25. That version fixed “three critical security vulnerabilities” and by critical, Joomla really meant it in this instance as websites still running older versions (the vulnerabilities existed back to version 3.4.4) were quickly being exploited (it should be noted that Joomla provided a heads up to everyone four days before that version was released).

A Better Alternative to SiteLock For Cleaning Up a Hacked Website
If your web host is pushing you to hire SiteLock to clean up a hacked website, we provide a better alternative, where we actually properly clean up the website.

Leave a Reply

Your email address will not be published.