Web Security Company Cloudbric Running Outdated and Insecure Version of WordPress on Their Website

When it comes to improving the security websites one of the major roadblocks we see is that often the security industry is pushing people in the wrong direction, a direction they themselves are heading. Instead of focusing on security basics they are pushing people to more advanced solutions, which are not necessarily better than doing the basics. As an example of that take Trend Micro that decided instead of keeping WordPress up to date with security updates (which normally are applied automatically) they would try to use some solution to block attacks, which didn’t stop one of their websites being successfully attacked. Even after that, they didn’t update WordPress, which would have prevented any chances of the attack being successful in the first place.

The other day we came across Cloudbric, which “is a cloud-based web security service” when they helped to spread false web security information put out by SiteLock and the repeated by SC Magazine. We were curious as to what kind of web security company would be unaware that they were spreading information that was rather obviously false and went to take a look into them we found that they were also running an outdated version of WordPress on their website, while misleading people about what protects websites.

The company claims that 99 percent of websites are left unprotected, based on incorrect notion that active protection is the only protection:

As was the case with Trend Micro, active protection can actually fail to provide protection over passive protection. So the claim that “Hosting services and CMS do not actually protect individual websites.” isn’t true, as they do to varying levels.

Cloudbric seems to really believe the misleading information they are giving others as they are still running WordPress 4.2.2:

That version was superseded with the security update 4.2.3 back in July 2015. Normally that and the subsequent 4.2.x updates would have been applied automatically due to WordPress’ automatic background updates feature, so either Cloudbric disabled those or their server environment has an incompatibility with that (which they could help WordPress to resolve). After 4.2.3, they have missed the next 10 security updates: 4.2.4, 4.2.5, 4.2.6, 4.2.7, 4.2.8, 4.2.9, 4.2.10, 4.2.11, 4.2.12, 4.2.13.

You have to wonder if when Cloudbric says that “Most unprotected website operators feel that proper web protection is expensive or unnecessary.” that is based on their own feelings.

More Tolly Group Testing

One of the things we take a look at with companies providing security services that claim to provide protection is if they are providing real evidence to back up their claims (so far we haven’t seen one that provides that). With Cloudbric they claim their WAF provides “the most effective security”:

Penta Security’s web application firewall provides the most effective security. It was rated considerably higher than the widely known vendor Imperva’s technology. Cloudbric is known for higher performance and greater functionality than Incapsula. Sitelock and Sucuri are built on an open-source engine called Mod Security.

(They also claim to that SiteLock’s WAF is based on Mod Security, when in fact they actually reselling Incapsula’s service, so that make us suspicious as their claim about their service.)

That claim seems to rest on a report by the Tolly Group. If you follow our blog you might recall the test that they did for SiteLock, which would it would probably be accurate to describe as rigged, as SiteLock provided the samples that their product were supposed to be detecting in the test.

Looking in to the report for this company the same thing was true:

A collection of 1,000 attacks were used to test the effectiveness of each solution, in both default and maximum security settings. This was run multiple times to ensure accuracy. The attack set was a random subset of attacks collected by Penta from Exploit-DB, 1337 Inj3ct0r, SQL Injection Wiki, fuzzdb and other online security communities.
Unlike SiteLock, which correctly identified all the samples they provided as having been malicious in the test, this service missed 101 of the 1,000 of their chosen samples when using the services “maximum security settings”.

SiteLock Promotes The Idea That Protecting Websites Involves Leaving Them Vulnerable to Being Hacked

When it comes to cyber security, it has been clear to us for some time that most of the companies in the field don’t really care about security. Just yesterday we discussed a cyber security company that doesn’t even bother to keep the software running their websites up to date, despite that being a really basic security measure (that is far from the first time we have spotted that type of situation either). One of the areas where we see this lack of care about security is shown by the fact that security companies services and products often are focused not on things that would actual prevent systems from being hacked in the first place, but on detecting the system has been hacked after the fact.

That brings us to a recent post on the web security company SiteLock’s blog. The post uses the results of a test they recently had done by the Tolly Group to argue their product is better at protecting against threats to website than another product of a different type. As we discussed last week the test was, at best, quite poor, but might be accurately describe as being rigged. The test involved testing if their product and another product could detect malicious code on a website and SiteLock not only had access to the samples being tested, but provided the sample code that was tested. Not surprisingly they were able to detect 100 percent of it (the developer of the other product wasn’t provided the sample code). To make things even ridiculous they then promoted the testing as having been independent, despite the fact that they even provided the samples to be tested.

First off, the post really could have used some editing, as it has some quite bad statements such as one in this paragraph:

In recent years, though, informal blogging environments, such as WordPress, have blossomed into full-blown web application platforms. Commercial and community developers contribute blocks of codes, known as “plugins” to enable just about any type of functionality that you can imagine. (A Google search on “WordPress Plugins” shows over 11 million hits.)

If you want to measure how many WordPress plugins there are, you could look at the homepage of the official Plugin Directory, where most WordPress plugins are made available, as that provides a count of plugins available through that, currently 47,146. If SiteLock was as familiar with WordPress as they promote themselves, they should have known that.

Explaining the basis of the test you can see what is so wrong with the view that SiteLock appears to agree with:

The basis of the test was the assertion that traditional endpoint security solutions are not designed to detect web application threats and, therefore, would have a low detection rate when scanning for such threats.

The actual threats against web applications would be vulnerabilites in the software, not malicious code that can be added by exploiting those. But the testing instead looked at the end results of threats being exploited:

A corpus of nearly 3,000 web-based malware samples, defined by SiteLock, was run through a prominent “traditional” endpoint security solution to illustrate SiteLock’s point.

The conclusion on the post is:

The point, really, is not the absolute percentage of malware detected. The point is to illustrate that there is an entirely new set of threats “out there” that traditional endpoint solutions have not been designed to detect. And, those new threats clearly require an additional, “next-gen” endpoint security solution in place to provide protection.

The reality from dealing with many hacked websites that many of those could have been prevented by taking basic security measures and many other could have prevent if other security practices were improved. From what we have seen of automated methods for trying to detect and clean malicious code, they produce poor results. Also, websites don’t just get hacked to place malicious code on them, so leaving a website vulnerable and trying to detect malicious code added to it, would among other things, allow for the possibility of sensitive data being extracted from it on a repeated basis.

While the post was written by the found of the Tolly Group, it isn’t just a situation that SiteLock posted someone else’s words with this very wrong view on the security, our past experience has shown that SiteLock view is in line with this. For example we have found that they label websites as being secure when they are using outdated software with known vulnerabilites and they don’t make sure that the software on a website is upgraded when they are cleaning up after a hack.

Would You Be Surprised to Hear That SiteLock’s Idea of Independent Testing Doesn’t Involve Actual Independence?

Recently for several different reasons we have taken a look at claims made about quite a few web security services and products and noticed that there are often bold claims that seem highly unlikely to be true. There also is a decided lack of evidence put forward to back those claims, much less independent third-party evidence to back them. So we were surprised today to see a press release from the web security company SiteLock, Independent Testing Shows SiteLock Web-Based Malware Protection Outperforms Traditional Endpoint Solutions. Considering their track record, we wouldn’t have expected them to be the ones actually having independent testing done. After taking a quick look over the details of the testing, we found that, not surprisingly, the testing was actually the opposite of independent.

The test compared their ability to detect malicious code on websites against McAfee Complete Endpoint Protection ability to do that. It appears the testing was intended to show that products of the type that McAfee have are not well suited to doing this, but since there is not a comparison of multiple products in each category, the value that could be gleamed from the test is limited.

One finding of the test did stick out to us though:

SiteLock SMART provided 100 percent PHP and JavaScript coverage versus less than 6 percent coverage by McAfee

Considering the poor quality we have seen with SiteLock’s detection in the past, whether it be missing malicious code or falsely identifying non-malicious code as malicious, we had a hard time believing that that they would possibly detect 100 percent of the tested malicious code in a reasonable test.

A key question to determine the quality of the testing was how the malicious code being used in the test was picked. When the items tested are mentioned in the press release there source isn’t mentioned either time, here:

Testing a group of nearly 3,000 web-based malware examples to determine effectiveness

and here:

Tests showed that the SiteLock solution detected and cleaned 100 percent of the samples provided.

Looking at the complete report (PDF) by the Tolly Group, there is the answer:

The test corpus was provided by SiteLock and consisted of 2,972 samples that included PHP, JavaScript and other executables that contained a variety of attacks.

So SiteLock provided the items that would be tested against. The test clearly isn’t independent at that point and the real story would have been if SiteLock didn’t detect them all.

The complete report also makes no claim to the testing being independent.

While SiteLock knew ahead of time what would be tested, since they provided the items being tested, the company behind the other product was not allowed to see them:

In accordance with Tolly’s Fair Testing Charter, Tolly personnel invited representatives from McAfee/Intel to participate in the testing. Because of internal guidelines, McAfee/Intel was unable to review the test corpus in detail and had no further comment.

Based on that you wonder what else might be in their internal guidelines that could skew the test results.