The Online Trust Alliance Doesn’t Seem Too Trustworthy

When it comes to words that might be reasonably associated with the web security company SiteLock one of them isn’t “trust”. You don’t have to look farther that Google’s search suggestions to see that:

Google;s second search suggestion for "sitelock" is "sitelock scams".

But if you do want to look farther you could look at the situation where with a couple of their services, their content delivery network (CDN) and web application firewall (WAF) services, they promote the services as if they themselves provide them. For example, they use phrases including “SiteLock servers“, “SiteLock patent-pending technology“, and “our IP addresses“. But in reality the service are provided by another company, Incapsula. Beyond just having a security company lie about something that there doesn’t seem to be a need to, the lie is rather troubling because both of those service involve sending a website’s traffic through a third-party’s systems. While SiteLock’s customers are told those systems are theirs, it turns out they belong to a company that the customers neither are aware or have a business relationship with. That raises some pretty obvious privacy and security concerns.

Based on that we don’t understand how an organization named the Online Trust Alliance would think it is appropriate to name SiteLock to their “Online Trust Audit and Honor Roll”, as announced by a SiteLock press release.

The press release lists what is evaluated for that:

As the only comprehensive, independent online trust benchmark study, the ninth annual OTA Online Trust Audit evaluates websites in three categories: consumer protection, responsible privacy practices and security. Based on a composite weighted analysis, sites that scored 80 percent or better overall, without failing in any one category, received Honor Roll status.

If you look at the complaints from SiteLock customers it sounds like the public is need of protection from SiteLock (just last week looked at an example of SiteLock trying to sell a customer on getting unneeded work done). As for security, while SiteLock’s website may be secure, that isn’t even the case for customers included in SiteLock’s cases studies.

A Single Tweet Nicely Sums Up the Problem With WordPress Allowing SiteLock to Be Involved With WordCamps

The web security company SiteLock has a well earned reputation that can be summed up with what Google suggests when you type in their name:

Google's second suggestion is "sitelock scams".

That obviously isn’t a reputation you would think that any company would want. It would probably be difficult for SiteLock to legitimately change it though since their business model seems to be based around the activity that gets them labeled as such.

It would also be difficult because if they, for example, stopped partnering with web host to try to get people to pay them to clean up hacked website that are not in fact hacked, then they would actually have to really clean up websites to get paid and from everything we have seen they are even worse than the average web security company, which is already quite bad, when doing that. For example, we are often brought in to re-clean hacked websites after some other company had previously had done that and then the website got hacked again. While that isn’t always their fault, in almost every instance we have been told that the determining how the website was hacked never even came up, despite trying to do that that being a basic part of the cleanup and important to make sure the vulnerability that allowed the website to be hacked has been fixed. That is certainly something we have seen with SiteLock. What we haven’t seen with other companies is that SiteLock has caused websites to be broken after doing their work.

Instead of trying to change, SiteLock looks to have focused on various efforts to present a public face very different than the one that their customers and not always willing potential customers can find themselves dealing with. What looks to be an important component of that effort is their involvement and sponsorship in the conferences for WordPress, WordCamps, which uses money they have gotten from their questionable business practices. We think a tweet put out by one of those WordCamps succinctly shows what the problem with WordPress allowing that to occur is:

The claim that SiteLock wants make your WordPress secure is belied by many things we have run across, including a few recent examples: thinking that leaving malicious code on a website for a while is not a threat, not taking the actions needed to prevent hacked websites from being reinfected, and not warning about vulnerable plugins or insuring they are being kept up to date on a website they are supposed to be keeping secure. But maybe the most troubling recent example is that SiteLock is still knowingly spreading false information about the security of the core WordPress software and using it to make a profit. We would love to hear from someone on the WordPress or WordCamp side of things how that makes anyone’s WordPress secure.

At some point, maybe we have already reached that point, you have to say that WordPress is complicit in what is going on here. Back in September of last year we contacted the central WordCamp organization to let them know that about the issues with SiteLock and ask for a comment about the situation or a more general comment on any restrictions on who can be a sponsor. We never got any response from them, though it was pretty clear they saw the message. So it seems that they can’t actually justify what is going on, but are still willing take money SiteLock has gotten through less than above board business activity. We later left a comment on a blog post about SiteLock on the WordCamp US’ website, shortly afterwards the comments left on that post were removed and commenting was disabled, so there does seem to an effort to hide what is going on.

What could explain some of why they continue to allow SiteLock’s participation is that SiteLock’s owners don’t just sponsor WordCamps under the SiteLock brand, but also through brands of the web hosting company Endurance International Group, which they run. For example, at WordCamp Europe they were a higher level sponsor through EIG brands Bluehost and MOJO Marketplace (MOJO Marketplace also doesn’t seem to be too concerned about security):

SiteLock Uses Harmless Activity on Website as a Reason to Try to Sell Unneeded Malware Removal to One of Their Customers

When you have a malware infected or otherwise hacked website it can make a lot of sense to hire someone with expertise in handling the cleanup of them to do that for you. Beyond that they would have the knowledge to quickly resolve the issue for you, where we have seen the value of doing that for our clients is that they often can use help understanding what is going on. Often times they are concerned about things that they don’t need to be and we can easily clear things up for them.

Unfortunately, far too often they are concerned about things due to misleading or outright false information being put out by other security companies. That then leads in to the big problem when it comes trying to hire an individual or a company for any type of security service, many of them really don’t know and or care much about security. On top of that there doesn’t appear to be good way to find one that isn’t true about, since these companies don’t seem to have a problem with lying and reviews of them come from customers who often are unlikely to have a good sense of the quality of the service they have gotten since they don’t have the expertise needed to determine that (we have had people saying another company did a good job even after they have hired us to re-do work that wasn’t done right by that company).

We recently had someone that came to us that believed there website had a re-occurrence of a malware issue and were looking for an alternative to the company they were already paying to secure their website, SiteLock, to do deal with it. That was in part because SiteLock had not detected any issue they had noticed.

The first thing we always do when someone comes us to about dealing with a malware infected or otherwise hacked website is to determine that it is in fact hacked. In this situation the belief that the website was infected with malware was based on some things the website’s owner had seen in the log file of HTTP activity. In reviewing those we found that those things were harmless. There were several request for spammy URLs, but the status code of the responses was 404, which indicates that a page with that URL did not exist. The other concerns related to request coming from a Russian search engine and requests coming from the file that does cron jobs for WordPress. Other checks should no current issue with the website.

SiteLock had given them a very different response when they had brought up what the customer had seen the log. SiteLock didn’t address the specifics that were raised and seemed to just assume that the website infected. They implied that the infection coincided with the SiteLock’s web application firewall (WAF) service that was in use being downgraded from “Enterprise level” to the “Premium level” (contrary to SiteLock’s marketing that service is actually provide by another company). To resolve the issue they suggested upgrading the WAF back to “Enterprise level” and having their “Expert Services” clean it up.

If all that were true it would seem to be reasonable to ask why they offer the “Premium level” WAF that permitted the website to get infected. You might also ask why you should pay more to clean up a website when the service you already paying to protect didn’t actual accomplish that.

While it is possible that SiteLock assumption that the website was infected and recommending that more money being spent with them was based on them not understanding that you should determine that a website was hacked before trying to clean it up, everything we have seen points to something else. That being that from everything we have heard and seen when you get in touch with SiteLock you are usually going to interact with commissioned sales person. It wouldn’t be surprising that a person that is not a tech and are getting paid if they can sell you something, would instead of determining that there wasn’t any issue, try to sell this person on an additional service and to a more expensive version of an existing service. It also would be in line with what have heard in numerous other instances when SiteLock failed to provide protection, that the answer was to move to a more expensive service.

SiteLock Still Spreading False Information About the Security of WordPress to Their Customers

Back in September we wrote about how the web security company SiteLock had introduced a new feature that was supposed to warn about vulnerabilities on WordPress websites, but would falsely claim that websites running older WordPress versions had vulnerabilities in them that they didn’t.

This seemed to be caused in part by a fundamental lack of understanding of how WordPress handles security, which involves security fixes being released for older version of WordPress that have the automatic background updates feature (WordPress 3.7 and above). This is something that anyone dealing with hacked WordPress websites should know since part of properly cleaning them involves determining, to the extent possible, how they were hacked and you would need to know what vulnerabilities would exist in a version of WordPress when cleaning it. From everything we have seen SiteLock doesn’t properly clean up hacked websites (and they even use that fact as a reason to upsell their customers), so maybe it shouldn’t be surprising they wouldn’t know this.

It also seems to be caused in part by them not understanding the underlying data source for the vulnerability information, the WPScan Vulnerability Database, as that correctly labels which versions of WordPress are vulnerable to the vulnerabilities (as we will show in a bit).

We know that SiteLock is aware of all of this as they clearly read our post as they filed a DMCA takedown notice to remove an image we had included in the post.

You would think that after becoming aware of this SiteLock would have fixed this, right? Well it turns out 9 months later they are still falsely claiming that WordPress website contain vulnerabilities they don’t.

The other day someone contacted us after they had been told by their web host iPage that they their website had security issues and they should sign up for SiteLock. After doing that they contacted us after seeing our previous post about this issue and thinking that what SiteLock had told them about vulnerabilities on their website wasn’t true.

The website was running WordPress 4.6.6 at the time and SiteLock claimed it had the following medium and high severity vulnerabilities:

Severity: High
Category: csrf
Summary: WordPress 4.2-4.7.2 – Press This CSRF DoS
Description: CSRF DoS vulnerability in WordPress versions 4.2 to 4.7.2 through the Press This functionality.

Severity: Medium
Category: rce
Summary: WordPress 4.3-4.7 – Potential Remote Command Execution (RCE) in PHPMailer
Description: Potential Remote Command Execution (RCE) in PHPMailer used in WordPress versions 4.3 to 4.7.1 can potentially be used to remotely execute commands.

Severity: High
Category: bypass
Summary: WordPress 4.2.0-4.7.1 – Press This UI Available to Unauthorised Users
Description: Authentication bypass vulnerability in WordPress Press This versions 4.2.0 to 4.7.1 allows unauthorized users to access the UI.

Severity: High
Category: csrf
Summary: WordPress 2.8-4.7 – Accessibility Mode Cross-Site Request Forgery (CSRF)
Description: Cross-Site Request Forgery (CSRF) in WordPress versions 2.8 to 4.7 via Accessibility Mode allows unauthorized actions to be performed.

Severity: Medium
Category: bypass
Summary: WordPress 2.8.1-4.7.2 – Control Characters in Redirect URL Validation
Description: Control Characters vulnerability in WordPress versions 2.8.1 to 4.7.2 through the Redirect URL Validation

Severity: Medium
Category: unknown
Summary: WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Description: Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability in WordPress versions 3.0 to 4.7 in the multisite activation key creates the potential to guess/brute-force the activation key.

Severity: High
Category: xss
Summary: WordPress 3.4-4.7 – Stored Cross-Site Scripting (XSS) via Theme Name fallback
Description: Stored Cross-Site Scripting (XSS) WordPress versions 3.4 to 4.7 via Theme Name fallback allows malicious code to be stored on the site.

Severity: High
Category: xss
Summary: WordPress 4.3.0-4.7.1 – Cross-Site Scripting (XSS) in posts list table
Description: Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.3 to 4.7.1 through the posts list table.

Severity: Medium
Category: xss
Summary: WordPress 2.9-4.7 – Authenticated Cross-Site scripting (XSS) in update-core.php
Description: Authenticated Cross-Site scripting (XSS) WordPress versions 2.9 to 4.7 via update-core.php allows malicious code to be injected to the page.

Severity: High
Category: xss
Summary: WordPress 4.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) in YouTube URL Embeds
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 4.0 to 4.7.2 allows an attacker to inject malicious code on to the site through YouTube URL Embeds.

Severity: High
Category: xss
Summary: WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata
Description: Authenticated Cross-Site Scripting (XSS) vulnerability in WordPress versions 3.6.0 to 4.7.2 allows malicious code to be injected on to the site via Media File Metadata

Severity: High
Category: sqli
Summary: WordPress 3.5-4.7.1 – WP_Query SQL Injection
Description: In WordPress 3.5 to 4.7.1 WP_Query is vulnerable to a SQL injection (SQLi) when passing unsafe data.

Severity: Medium
Category: unknown
Summary: WordPress <= 4.7 – Post via Email Checks mail.example.com by Default
Description: Post via Email Checks mail.example.com by Default in WordPress version 4.7 and earlier.

Those vulnerabilities don’t exist in WordPress 4.6.6, which can be seen by looking at the relevant entries in the WPScan Vulnerability Database. Let’s take a look at a couple of examples:

For the vulnerability “WordPress 3.0-4.7 – Cryptographically Weak Pseudo-Random Number Generator (PRNG)” the vulnerability was fixed in version 4.6.2:

For the vulnerability “WordPress 3.6.0-4.7.2 – Authenticated Cross-Site Scripting (XSS) via Media File Metadata” you can see that it was fixed in version 4.6.4:

It also worth noting here that the severity ratings that SiteLock provides here look to be vastly overstated since none of these vulnerabilities is likely (or has in fact been) exploited on wide scale, which you would expect at least for vulnerabilities rated as being high severity.

iPage isn’t innocent in this, as not only do they get a significant percentage of the price being paid for SiteLock services sold through their partnership, but their parent company also happens to be run by SiteLock’s owners.

You would also think that WordPress might make a point of warning people away from SiteLock since they are profiting off falsely claiming that WordPress websites contain vulnerabilities, but instead they have welcomed them as sponsor and speaker at various WordCamps, WordPress conferences. In fact they thanked them for their “commitment to the WordPress community”:

We’d like to thank each of our 2017 global community sponsors for their commitment to the WordPress community. Their generous contributions support community events like WordCamps and WordPress user groups worldwide.

The Problems Caused By SiteLock Using Nessus as Their Vulnerability Scanner

The other day we mentioned how we often have people that contact us about situations where the web security company SiteLock has contacted them claiming that their website has malware, but SiteLock has not provided any evidence of that. Recently we have started being contacted about situations where SiteLock is contacting a website’s owner claiming that the website has some vulnerability that could lead to the website being hacked. So far in those instances SiteLock has not provided any evidence to back up their claims, so we can’t access their validity directly. But we have continued to see problems with their vulnerability scanner, which seems like it would likely also be what would be the source of their claims.

What looks to be an overarching issue with their vulnerability scanner is that the underlying technology isn’t really designed to be in the fashion it is. Back in December we stumble on to the fact that at least part of their vulnerability scanner is really just them using a piece of software named Nessus, which as best we can tell that is something that isn’t really designed to be used by end users. Instead it looks like it is designed to be used by security professionals and software developers. For them producing false positives would be less of an issue since they could fairly easily evaluate if there is an issue, whereas end users are not usually going to have that capability. It is even more of a problem if someone is using those unreliable results to try to sell people on security service, as SiteLock might be doing.

An example of the issue can be seen in a recent thread on the WordPress Support Forum, where someone got notified of a claimed security problem in the login page of a WordPress blog:

This was sent to me by SiteLock about a security problem on my wordpress blog. The CGI issue is attached to the login page. Can this be fixed please?

Synopsis: A CGI application hosted on the remote web server is potentially prone to SQL injection attack.

Description: By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.

An attacker may be able to exploit this issue to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system.

Note that this script is experimental and may be prone to false positives.

Solution: Modify the affected CGI scripts so that they properly escape arguments.

Right off the bat this information doesn’t seem end user friendly as it looks as though the reference to CGI script in that is really a reference to any sort of code running on a website (as can be seen by this list of CGI abuses on the website for Nessus).

That confusion lead to a moderator falsely claiming that it would appear the website is compromised:

WordPress does not use CGI for anything, so if you’re getting that on WordPress’s login page, it would appear that your site has been compromised as their tool has identified.

Carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures.

Beyond that two things stick out.

The first being the statement noting that “this script is experimental and may be prone to false positives.” Why is something experimental and known to produce false positives being used to produce the results of SiteLock’s vulnerability scans?

The second one being the part that states “By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.”. Changing the values that are sent with a request could produce a very different response for obvious non-security reasons. Say if you changed the value of parameter specify what to be search for on a search page, you would expect to get different results. If you sent an invalid value with a request you might also get a very different result than if you sent a valid one.

Based on everything we have seen from the results of SiteLock’s vulnerability scanner so far, the results don’t look reliable. So we would recommend avoiding it if you are looking to determine the security of your website. If you do have them claiming that there is a vulnerability and you want to be on the safe side, we would recommend you get a second opinion from someone familiar with handling security issue with the software you are using.

Hacker Provides More Information on Fixing Defacement Hack Than SiteLock and HostGator

When it comes to claims that a website contains malware or is otherwise hacked coming from the web security company SiteLock or their web hosting partners our recommendations is to not ignore their claims despite the serious problems with false claims. Instead we recommend getting a second opinion from another company that deals with hacked websites. We are happy to do that for free and a lot of people have been taking us up on that offer.

The first thing we do when contacted about a second opinion is to find out what evidence SiteLock and or the web hosts has provided as to the claimed issue. In doing that we have seen that in most cases the supporting evidence of the claim falls in to one of two very different categories. In the first they have provided a listing of examples of impacted files and in the other they provided no details whatsoever. So far we haven’t seen a strong correlation between either of those and veracity of the claim.

In one recent instance where a website was really hacked they provided no information whatsoever, while the hacker actually provided helpful information.

In response to our question about what evidence the owner of the website mentioned they had received none despite multiple calls a day, but they had noticed a couple of pages in the Google search results with hacked content.

From that we already had a good idea as to what was going on.

When we looked at those pages we found that they had the following message:

Hacked By Not Matter who am i ~ i am white Hat Hacker please update your wordpress

The only vulnerability that has existed in the core WordPress software that has been exploited in a wide scale in years (maybe close to a decade) was vulnerability that allowed modify the content of posts, which existed in WordPress 4.7.0 and 4.7.1. As long as WordPress’ automatic background updates were working properly this vulnerability was not a threat, as it was fixed with a new version well before the vulnerability started being exploited. That issue could have explained how a hacker was able to add that message to the pages they did.

Based on all those things it wasn’t surprising to find that the website was running WordPress 4.7.1.

At that point we recommend that the website’s owner update WordPress, undo any changes made to the post content, and see about making sure that automatic updates are able to function going forward.

If SiteLock or HostGator had told them that in the first place the issue could have easily been resolved, but it likely wouldn’t have lead to a SiteLock sale, which is possible explanation why they wouldn’t do that. You might be wondering why a web host wouldn’t want their customer to be secured, the answer is in part that HostGator and other Endurance International Group brands received a lot of money when SiteLock sales are made through their partnership. Another part of the answer is that SiteLock’s owners also run the web hosting company.

It isn’t just that they didn’t provide any details; they told them something that is not accurate with this type of issue:

“During a recent SiteLock security scan of your website, malware was detected that could jeopardize the safety of your website and your customers’ data.”

The website doesn’t look to have contained any malware. The reason for the claim that malware was detected appears, based on our previous experiences, to be due to SiteLock’s malware scanner not just be used to detect malware, but any evidence of a hack, but any issue detected incorrectly being labeled as a malware issue.

iPage Provides Conflicting and Bad Advice on Cleaning Hacked Websites

When it comes to dealing with a hacked website, the advice you are going to get from a web host isn’t necessarily very good. For example, we have often seen them tell people their websites must have been hacked due to outdated software, without the web host having done anything to determine if that was true (and in some cases despite the website not even using outdated software). In one recent instance we found that one of the brands of the web hosting company Endurance International Group, JustHost, was pointing toward an outdated version of Joomla as the source of hack, while they were offering to install that version on websites despite support for it ending over two years before. Since the installation occurred through another Endurance brand, MOJO Marketplace, it looks like that version probably being offered for install across their other brands as well.

With that that type of thing happening at Endurance, it might not be surprising to see what we recently came across while doing a consultation with someone with a hacked website using one of their other brands, iPage, in which they provided conflicting and bad advice on dealing with a hacked website.

Here was is most of the original email they sent to their customer about a hacked website:

During a routine scan, we detected suspicious contents that suggest your ‘[redacted]’ account has been compromised. We have temporarily suspended your website to protect your website visitors from getting impacted and also preventing the impact on your website reputation as well as our server’s reputation.

We have uploaded a file ‘websitescan.txt’ within the stats directory of your account which contains the full list of infected files. We need you to take one of two actions suggested below:

Please follow the steps given below to remove the infected contents on your own:
1. Open the ‘websitescan.txt’ file through your FileManager (OR use ‘FTP’ software like FileZilla).
2. Clean or remove each of the listed files.
3. You can also upload a clean copy of web files from your local backup.

Alternatively, we encourage you to contact our preferred partner, SiteLock. In addition to long-term solutions like their Fix and Prevent products, which offer daily scans and removal of malware, SiteLock also provides an emergency service, SiteLock 911. You can call our dedicated SiteLock support representatives using the Toll Free number (United States and Canada customers only): (855) 378 6200. International: +1 415 390-2500. To learn more about SiteLock, please go to: https://www.ipage.com/product/sitelock

So in that email they recommend simply cleaning/removing or replacing the files they identified.

When they refer to SiteLock as their preferred partner what they really mean they are getting paid a lot of money to push their services (SiteLock’s owners also happen to run Endurance International Group).

In a follow up email they had these recommendations:

Please remove the malicious contents or replace the infected files with a clean copy of web files from your local backup.

Our best recommendation is to completely remove all the files from the account and restore the contents from a known clean backup. An alternative would be going through a company such as SiteLock to clean and secure all scripts. If this isn’t done and the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again.

Those two paragraphs seem to conflict with each other as the second one states that if “the malicious files that are found through scanning are simply removed, the vulnerability will still exist and you will encounter the files again and again”, but the first paragraph and the first email suggest doing just that.

The larger problem with this is that whether you were to “completely remove all the files from the account and restore the contents from a known clean backup” or remove the indicated files that isn’t going to resolve the vulnerability. The malicious code in files on the website had to get there somehow, so there must be something that allowed that and you would need to fix that. To be sure you had fixed it, instead of just guessing that you had, you would need to figure out how the website was hacked in the first place. Nowhere in the emails do they suggest doing those things and those are things their “preferred partner” SiteLock usually doesn’t do based on everything we have seen with them.

SiteLock Wants You to Believe That Leaving Malicious Code on Your Website for a While Is Not a Threat

When it comes to the much maligned web security company SiteLock we hear many complaints, but the two we hear the most about are them falsely labeling websites as being infected with malware (as we discussed in another post earlier this week) and that they provide protection services that don’t end up actually doing much, if anything, to protect websites.

One example of them not really protecting websites is when their idea of protection is try to detect that malicious code has been added to the website after that it has been hacked. While we would hope would be obvious is that if malicious code is getting on the website it isn’t being protected in the first place, but it would appear that isn’t the case considering they are not the only ones that market services along those lines as protecting websites.

That this would protect as website is something they actively promoting, as can be seen in these lines from a recent post on their blog:

Wyatt plays a key role in manually reviewing code that our SMART scan flags as suspicious. If the code is found to be malicious, he’ll write new scripts for our scanners that are designed to automatically detect and remove malicious website code before any damage is done.

There are several issues with that.

First, is what we were mentioning before, malicious code is getting on the websites in the first place.

Second, if there scanner is able to flag it as suspicious (which isn’t a given) it is still going to remain there unless code is written to be able to remove it, which delays removal for new code (which based on the variety of code we see is likely occurring frequently).

The most galling part of it though is this, that it will “remove malicious website code before any damage is done”. Unless the code is removed immediately after it is added then the chances of it being removed before any damage is done are very small. Usually the code would start impacting visitors immediately or the hacker would utilize it to take further actions right after they added it. From what we can tell it looks like they usually scan the files once a day, so the chances of it being removed immediately are also very small. One day is long time for a website to serving malicious code or a hacker to take further actions.

Where this becomes even more problematic is if the code is used to copy sensitive data off of the website, as once that has happened, removing the malicious code won’t undo that having happened.

What makes this all so unfortunate is that just doing the basics would keep many websites from being hacked and those are things that SiteLock can’t or doesn’t provide in their services. Furthermore, just looking at SiteLock’s case studies show their customers are not doing one of those things. We would guess that is in part due to their customers being misled by SiteLock that they providing protection for their website that they are not.

SiteLock Incorrectly Labels Spam Content In Databases as Malware

When it comes to the many problems that we hear about with the web security company SiteLock one of the most prominent is that they falsely claim that websites contain malware and then web hosts they are partnered with shut off access to the websites based on those false claims, while suggesting to their customers that they hire SiteLock to clean it up. (It is important to note that while this significant problem, you shouldn’t ignore claims coming from either SiteLock or your web host that the website contains malware or is otherwise hacked.)

There are a lot of questions that issue raises.

One being why would web hosts shut off access to their customers websites based on the word of company known to make false claims? That one is answered in part by the fact that those same web hosts make a lot of money if their customers purchase SiteLock services and by the fact that the owners of SiteLock also run a major web hosting company.

Another question being, what causes the false claims? For that, part of the answer is the SiteLock’s scanner, while labeled as a malware scanner, also tries to detect issues other than malware. That causes problems in trying to resolve real issues because people are being told that they have an issue other than they really have. Another issue with that is that they don’t seem to very careful in their detection of those other issue, so in one situation where we consulted on it looks like a website was falsely claimed to contain malware due to the phrase “hacked by” appearing on a page (we recently ran across a similar issue with the Sucuri SiteCheck scanner). Then people at SiteLock and their web hosting partners either don’t understand the quality issues with the malware scanner’s data or don’t care, leading to owners of websites falsely being told their website contain malware and having them shutdown.

A recent tweet from SiteLock shows another example of this, as they have a pretty bad idea of what constitutes malware in the database:

Malware refers to one of two things when it comes to websites, malicious code in general or malicious code being served to those visiting a website. Spam content itself would not be considered malware.

More problematic with that, is that if you had someone submit a comment with spam content on a WordPress website it would be stored in the database, so if you start labeling any spam keywords in the database as malware you would cause any database with spam comments, even if they were in the trash, as having malware.

That seems like a possible explain of another problem we have been hearing about recently with SiteLock, which is them claiming that backups of website’s databases contain malware.

Why SiteLock’s Poor Cleanups Lead to Website Reinfections

If you follow our blog you will have seen us say before that we are often brought in to re-clean hacked websites after another has cleaned and then it hacked again. And as we have said before, while it isn’t always the fault of a company that did the a clean up that a website has gotten hacked again, what we have found is that in almost all the instance where we are brought in to re-clean websites the first company has cut corners. As one of three main components of a proper cleanup is trying to determine how the website was hacked and when we ask if the source of the hack was determine by the first company that answer is almost always that trying to determine that never even came up.

One of company that comes to mind as one that doesn’t do proper cleanups is SiteLock. As we seen for years they don’t upgrade the software on the website (which is large part of one of the other main components, getting the website secure as possible) and they don’t determine how the website was hacked.

So we were somewhat surprised to see a recent SiteLock had a post on their blog “Why Website Reinfections Happen”, which while written to get around the issue, is really a indictment of how SiteLock’s improper cleanups leaves websites vulnerable to being reinfected.

In the post they start out by explaining why websites get reinfected:

The short answer is that it’s most likely due to unresolved vulnerabilities. While it may seem like you’ve been singled out and targeted by some menacing hackers, most of the time that isn’t the case. The majority of website compromises are preceded by automated campaigns that locate websites vulnerable to a particular exploit the hacker wishes to employ.

That would dictate as part of the original cleanup you would want to resolve the vulnerability, so what does SiteLock claim are the causes of the vulnerabilities.

Up first is outdated software with vulnerabilities:

It is for this reason that we stress not only cleaning the website, but also patching all software and identifying and remediating all vulnerabilities present on the website.

While they stress this, their cleanup don’t actual involve updating the software and neither doing their ongoing security services. They do try to get to what they actual provide by saying this:

It is also advisable to take a more proactive approach in the future by utilizing a web application firewall (WAF) to protect your website.

The problem with this is using a WAF isn’t more proactive, instead it is reactive, as the WAF often would need to have code or a rule written to protect against a vulnerability, so unless the WAF maker is aware of a vulnerability before it is fixed that will happen after the software is able to be upgraded. There is another problem with this that trying to protect in this manner is more likely to not work properly, as can be seen with what happened recently to another security Trend Micro, decided not to keep their one of their WordPress installations up to date.

Also, worth pointing at this point is a post from yesterday where we look at the fact that one of SiteLock’s major web hosting partners (which also happens to be run by SiteLock’s owners) is offering installing outdated and insecure software on their customers websites.

Next up is unfixed vulnerabilities, which are usually newly discovered (unless a software developer doesn’t fix vulnerabilities promptly when they are notified of them):

On the less common end of the spectrum we see compromises due to undocumented vulnerabilities, where the bad guys were the first to the punch with discovering that a vulnerability exists.

To know if there is an unfixed vulnerability that was exploited you would need to know how the website was hacked, which isn’t what SiteLock does. Instead they get back to the WAF:

In this instance, your best defense is taking a proactive approach by implementing and training a web application firewall (WAF) to block future attacks.

There is no explanation of how you are supposed to be able to train the WAF to block future attacks, when you haven’t determined how the attack happened. Going back to previous issue, it also would be more effective to get vulnerability fixed in the software than trying to block attacks, because sometimes even a minor change can evade a block, whereas properly fixing the vulnerability at its root should stop any attack. Doing this would also would likely leave others using the same software vulnerable unless they used a WAF that provided protection against the vulnerability.

Also worth noting here, is that while SiteLock promotes the WAF that is included in some of their services as being their own it is fact Incapsula’s WAF.