SiteLock Provides More Evidence That They Are Not Being Truthful About Who Provides Their CDN and WAF Services

Back in November we discussed evidence we had found that indicated that the web security company SiteLock’s TrueSpeed CDN and TrueShield Web Application Firewall services were actually provided by another company Incapsula, while SiteLock made it sound like they are providing them directly. At the time we mentioned that is “troubling as all of the customer’s website’s traffic is going to be running through a company that they don’t have a relationship with or are even likely to know is involved”. It is also troubling to think that a security company would be lying to their customers like that, since a big part of security is trust. If they are lying about something like this, where we don’t see why they even would need to, you reasonably have to wonder if there is something they wouldn’t be willing to lie about.

A recent post on SiteLock’s blog provided further confirmation that these services are actually provided by Incapsula while at the same time making it sound like SiteLock is providing them directly. In the December 18 post SiteLock TrueShield Updates they let their customers know of new IP addresses being used by those services that some of their customers would need to whitelist. Those IP addresses are

107.154.129.0-107.154.129.255
107.154.192.0-107.154.192.255
107.154.193.0-107.154.193.255
107.154.194.0-107.154.194.255
107.154.195.0-107.154.195.255
107.154.196.0-107.154.196.255

If you look up who those belong to it is Incapsula: example 1, example 2, and example 3.

In the post there is no mention of Incapsula, but they is plenty that would make you think that SiteLock is actually providing the services. In a large font they refer to the IP addresses being used by the services as “ours”:

If you are adding our IP addresses for the *FIRST TIME* 

In explaining why the new IP addresses are being added they mention their servers and IP address, despite those pretty clearly being Incapsula’s instead (emphasis ours):

The SiteLock servers periodically make requests for updated content from your website’s hosting server. This ensures that we are delivering the freshest content to your visitors. During periods of high traffic, we may make more frequent requests for content than during off-peak periods. Cloud technology of this kind uses a finite number of unique IP addresses to fulfill these requests, making this behavior appear as a security threat to some firewall services. This can be due to the large number of requests from a disproportionately low number of perceived unique visitors. Whitelisting or creating firewall exceptions for our servers’ IP addresses prevents your other security systems from blocking legitimate traffic relayed through our servers.

If we were not already familiar with a litany issues with SiteLock (you can see some of those by looking over our previous post about them) we would say this would be a good reason to avoid them, but with all the others you should have more reasons to avoid them then you should possibly need.

GoDaddy Doesn’t Disclose The True Source of SiteLock’s CDN and WAF Services

The last time we discussed GoDaddy’s partnership with SiteLock back in September it involved a situation where SiteLock managed to break a website they were supposed to be cleaning, GoDaddy was partly responsible for the website being hacked, and SiteLock failed to detect that GoDaddy issue due to their failure to do a basic part of a hack cleanup. Based on that an expansion of their partnership doesn’t seem like a good thing, but it is happening.

Today GoDaddy announced that they would now be offering SiteLock’s content data network (CDN) and web application firewall services (WAF) services. What they neglected to mention is that these services are not actually provided by SiteLock, but as we recently discovered, by another company, Incapsula. That is a rather important item to disclose since both of those services involve sending your website’s traffic through someone else’s systems. Having a company you have no involvement with having access to all of your website’s traffic obviously raises some serious issues. Even if you are not concerned with Incapsula having access to your traffic, it looks like SiteLock could switch to another provider at any time without you being aware of it.

Also missing from the press release is any evidence that SiteLock’s WAF actually provides any protection (which we haven’t seen provide elsewhere either). Instead you get unsupported claims as to the protection it supposedly provides. One claim included has actually been indirectly disputed by SiteLock. That claim being that it prevents backdoor access:

Trust that website content will be protected from potentially harmful spam comments, and backdoor access to website files will be blocked.

In previous post we looked at situation where a SiteLock customer using their firewall got hacked again and said that “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.”.

If you are actually looking to keep your website then these are things you should focus on, which are not things that any SiteLock services provides. You also would probably be best off not using a web host, like GoDaddy, that partners with SiteLock.

More Evidence That SiteLock’s TrueShield Web Application Firewall Is Really Incapsula’s WAF

Last week we looked at the evidence we had found that a couple of services that SiteLock was claiming to provide directly were actually provided by Incapsula. That would be an issue both because you have a security company pretty blatantly lying, but also because websites using the services would have traffic is going through a company they are neither aware would have access to their traffic and or that they have a relationship with.

For one of the services, Sitelock’s TrueSpeed CDN, the evidence was beyond a reasonable doubt to us that the service is really provided by Incapsula. For their TrueShield Web Application Firewall (WAF) it seemed likely that was also the case, due in part that it would be easier to use Incapsula’s WAF when they already were using their CDN, but the evidence wasn’t as strong. We ran into another piece of evidence that makes it pretty conclusive that the service is also actually provided by Incapsula.

While requesting a page be saved on archive.org, so that we could link to it if it got removed from the website it was on, this was saved instead:

sitelock-trueshield-web-application-firewall-captcha-page

That page claims that the website is “protected and accelerated by SiteLock” and that there is a ” SiteLock security network”:

The web site you are visiting is protected and accelerated by SiteLock. Your computer might have been infected by some kind of malware and flagged by SiteLock security network. This page is presented by SiteLock to verify that a human is behind the traffic to this site and malicious software.

Here is one of a number a screenshots we found with of the exact same page when coming from Incapsula:

incapsula-waf-captcha-page

The only difference with it is the branding. There really isn’t a way that could be coincidental.

That doesn’t match with SiteLock’s description on the page for the service though. For example, they claim that SiteLock is analyzing the request, when in fact it is Incapsula:

sitelock-trueshield-web-application-firewall-diagram

Is SiteLock Lying About Patent-Pending Technology and the True Source of Some of Their Services?

In looking in to some things for recent posts about SiteLock, their web application firewall (WAF) had come up a number of times and that then made us recall that previously it seemed that service was actually provided by the company Incapsula. Looking at the page for the service there was no mention of that or anything that might indicate that SiteLock was not providing the service themselves. The only mention of Incapsula on SiteLock’s website according to Google is them being cited in a couple of blog posts. The same holds true for mentions of SiteLock on Incapsula’s website.

So were we confused in thinking that there was connection between the two companies or have they just hidden it away from the public (like how one of their hosting partners wouldn’t admit to the ownership connection between SiteLock and them)? A little more looking showed the connection actually existed.

The True Provider of TrueSpeed CDN

Doing a traceroute for www.sitelock.com showed their IP address to be 199.83.134.143, for the which the canonical name is 199.83.134.143.ip.incapdns.net. Incapdns.net as in Incapsula, which you wouldn’t expect since you expect that SiteLock would be using their own TrueSpeed content delivery network (CDN) to serve their website. Next up we did a traceroute on their WordPress focused sub-domain wpdistrict.sitelock.com, which showed a canonical name of iasx4.sitelockcdn.net and an IP address of 192.230.66.155, which in turn has a canonical name of 192.230.66.155.ip.incapdns.net. We then looked at several of their customers websites listed in case studies on wpdistrict.sitelock.com and found they were running through Incapsula as well.

From all that it is clear that the TrueSpeed CDN is actually being provided by Incapsula, which you wouldn’t have any clue if you looked at how SiteLock describes the service. One part of the description that stood out for us was this:

Dynamic Content Caching

SiteLock patent-pending technology continuously profiles website resources, gathering information on how content is displayed. Static content can be safely cached. Some dynamic content might change continuously, while other content might rarely change or change only for specific users. This information enables truly optimized caching, and ensures content that is rendered is accurate—a premium feature you won’t get with most content delivery networks.

To claim you have a patent pending certainly makes it sounds like you provide the service yourself. But a quick search pulled up a PDF datasheet for Incapsula’s Content Delivery Network, which pretty clearly is the source of material on SiteLock’s page, with some rewriting of the text having been done. Here is relevant section from Incapsula’s document:

Dynamic Content Caching

Patent-pending advanced learning algorithms continuously profile website resources, gathering intelligence on each resource. Some of these resources, which may be dynamically generated, rarely change over time and for different users. This intelligence allows for optimized caching and ensures resource accuracy.

SiteLock’s lack of truthfulness to their customers about this is pretty troubling as all of the customer’s website’s traffic is going to be running through a company that they don’t have a relationship with or are even likely to know is involved. Even if there is no concern about Incapsula, SiteLock could always switch to some other provider without notice, that isn’t as trustworthy and their customer could find that out too late.

This definitely is something that should make people avoid SiteLock, as trust is so important when it comes to security companies.

What About TrueShield Web Application Firewall?

Our looking into a connection between Incapsula and SiteLock started with looking for a connection with SiteLock’s web application firewall (WAF), so is that also provided by Incapsula as well? The circumstantial evidence points in that direction, but there was no smoking gun that we have found so far.

From a practical stand point if you are already running the website’s traffic through Incapsula it would seem to be easier to use their existing WAF in their systems than creating your own and then integrating that in to their systems, if they would even allow it. SiteLock’s CDN and WAF were introduced at the same time, so that would certainly fall in line with the possibility of them having the same source.

Here is the screenshot of a report from SiteLock’s WAF from the service’s page on SiteLock’s website:

sitelock-trueshield-web-application-firewall-dashboard-screenshot

And here is a screenshot of a report form Incapsula, also related to “Bot Access Control”:

incapsula-events-log-screenshot

The data presentation is quite similar between the two of those, which we have hard time believing could have been coincidental.

Know Something More About The Connection Between The Companies?

If you are aware of additional details related to the connection between SiteLock and Incapsula please leave a comment.