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 by Default
Description: Post via Email Checks 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:

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.

Checkmarx Fails the Wikipedia Test

When looking at the poor state of the security industry one of the things we have noticed is that far too often you can get better information from the Wikipedia than you can from many in the security industry.

One re-occuring issue we see is people in the security industry referring to dictionary attacks, which involves trying to log in using common passwords, as being brute force attacks, which involve trying to log in using every possible password. The Wikipedia by comparison manages to accurately describe both dictionary attacks and brute force attack. They even mention the contrast between them:

In contrast to a brute force attack, where a large proportion of the key space is searched systematically, a dictionary attack tries only those possibilities which are deemed most likely to succeed.

While looking for some information on the website of security company Checkmarx recently we ran across them not understanding the difference between hashing and encryption.

The last sentence of an article looking at a hack of website is as follows:

Included in the leaked information of the VerticalScope forum and website users were their usernames, user IDs, email addresses and encrypted passwords.

For people that know about password security the use of encrypted passwords would seem rather odd and would indicate things were not being done securely.

Further down the article it goes in to more details.

Finally, a vast majority of the passwords were encrypted using methods that were very easy to break using MD5 with salting and less than a couple million of the 45 million passwords were sufficiently encrypted.

That brings us to the first sentence of the second paragraph of the Wikipedia article on MD5:

Like most hash functions, MD5 is neither encryption nor encoding.

To understand why that matters, it helps to think of hashing as one way encryption. When using that on a password the actual password is converted in to some other text, but unlike encryption you cannot decrypt it. That way even if someone gets a hold of the stored versions of the password, say on a website, they can’t get the original password.

If you wondering how the system then know how if the correct password is being entered in the future, the answer is that the password entered then is run through the hashing algorithm and the result is checked to see if it matches the stored version.

The misuse of the term encryption continues in the article, even being used to promote one of Checkmark’s services:

The Importance of Proper Encryption

VerticalScope attempted to hash their passwords using MD5 with salting which security minded developers agree is an “emphatically poor choice” when it comes to securing passwords. First designed in 1992, the MD5 algorithm is a hash function which produces a 128-bit hash value. As early as 1996, flaws were determined in the design of MD5 and in 2005 it became apparent that MD5 was not collision resistant, a key component for a secure encryption algorithm.

How to Ensure Proper Encryption

In addition to avoiding MD5 hashing as your method of choice, it’s important to also avoid SHA-0 since it has been conclusively broken, SHA-1 as well as DES as it can be broken by the average desktop computer’s GPU.


When choosing your encryption method, be sure to focus on using a symmetric algorithm key size that is at least 168 bit and if you’re dealing with financial transactions, use at least 256 bits. Ensuring that your application protects all cryptographic keys within the file system will also help ensure that your encrypted data is not exploited.

Additionally, using a static code analysis solution to ensure that your application has sufficient encryption is also recommended as your developers will be able to mitigate any encryption issues at the earliest stages of the SDLC. Checkmarx’s CxSAST scans and for and identifies encryption security issues in multiple languages including Java, CPP, JavaScript, Objective C, C++ and Perl.

Checkmarx Running Outdated and Insecure Version of WordPress

Back in November over at the blog for our Plugin Vulnerabilities service we discussed the fact that the security company Checkmarx was making a claim that a number of WordPress eCommerce plugins had severe vulnerabilities without providing any evidence, even what the name of the plugins was, to support that. That didn’t stop security journalists from covering the claim at the time. The details were supposed to be released later, but when went looking for them several weeks ago we couldn’t find them and when we contact Checkmarx to inquire about them, we received no response. At this point we think it is reasonable to wonder if the vulnerabilities ever existed.

It turns out though that this company that doesn’t seem to have a problem with making what appear to be baseless claims about the security surrounding WordPress, uses WordPress on its own website at the same time.

What should be surprising, but is an all too common occurrence, it also turns out that they are running an out of date and insecure version of WordPress on their website as can be seen in the source code of the website’s pages:

The Checkmarx Website is Running WordPress Version 4.6.1

There have been four releases of 4.6.x with security fixed since then: 4.6.2, 4.6.3, 4.6.4, and 4.6.6 (they also have updated to the latest major release of WordPress, 4.7). The oldest of those was released over four months ago.

The plugin listing its version number below the line for WordPress is not surprisingly also out of date.

What makes their lack of updating stick out is that WordPress would have normally automatically updated without any action required by Checkmarx, due to the automatic background updates feature. So either Checkmarx’s server environment has some incompatibility with that (which they could help WordPress to get fixed) or they intentionally disabled them. In either case you should expect that a security company would be concerned enough about security enough to manually apply those updates.

With all of that, it doesn’t seem like it should be all that surprising that security is in such bad shape these days.

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.

Another Reminder That People May Fail To Take Basic Security Measures While Doing More Advanced Ones

When it comes to what security companies do one of our major concerns is they tell people that need to take all sorts of advanced security measures while some many people are still failing to do the basics. Our main concern for that for some time was that people would feel overwhelmed and instead making sure they are doing the basics, they wouldn’t do anything. What we have seen more of recently is that people will do more advanced things instead of the basics, which can produce bad results, as was the case with one of security company Trend Micro’s websites getting hacked due to them failing to do one of the basics and relying on more an advanced measure that failed (even after they got hacked they didn’t take the more basic step).

Another example we ran across recently involved someone reporting that when trying to install plugin for checking for vulnerable WordPress plugins there was fatal error. The error was caused by the plugin trying to use a function that was introduced in WordPress 3.4, which was released nearly 5 years ago. That doesn’t seem like it should be a problem, but was in that case because the website they were trying to install it on was still running WordPress 3.2.1.

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.