SiteLock

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:

Our Director of Product and Technology, Binod Purushothaman, shows the #WCJAX crowd the most common forms of database malware. #WordPress pic.twitter.com/peTj6sNhym

— SiteLock (@SiteLock) May 21, 2017

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.

A Nexus of Insecurity Between EIG, SiteLock, and MOJO Marketplace

Last year as we started hearing and seeing more and more complaints about the web security SiteLock one thing we wondered was why would web hosting companies continue to partner with a company that was harming their reputation. The answer is in part that they get a lot of money from SiteLock, the Endurance International Group (EIG) has disclosed to investors that they get 55 of the revenue from SiteLock services through their partnership. When you are talking about $300 for a hack cleanup or $100 a month for a protection service, their cut of that could easily be more than they are getting paid by the customer for the service they are actually providing (without the costs that come with actually providing something).

That wasn’t the only explanation for that particular partnership, as turns out that the majority owners of SiteLock are also the CEO and a board member of EIG. While EIG isn’t all the well known by that name, they provide web hosting under a number of well known brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others.

Web hosts can play an important role in keeping websites secure. They have a responsibility to keep the things in their power secure and they can also do things that help their customers do their part. The type of partnership that SiteLock has with EIG could influence EIG to not take the steps they could to keep websites secure since they can potentially make so much money off websites they host getting hacked. While we would think that might impact them doing extra things to help their customers, it turns out that EIG is not doing something that is their responsibility.

We are currently working on a cleanup of a hacked website hosted with JustHost, where JustHost and SiteLock have pointed to an outdated Joomla installation as being a weakness. While looking around at things we found that JustHost is currently offering to install that version of Joomla, despite it having not been supported for over two years.

From the JustHost cPanel control panel clicking the One-Click Installs button took us to https://www.mojomarketplace.com/scripts. The company behind that website, MOJO Marketplace, is another EIG company, which among other things provides the ability to install various software on websites. Looking over that page we found that not only were they offering to install the version of Joomla, 2.5.28, that JustHost and SiteLock were pointing to as being a weakness, but they are offering plenty of other outdated and insecure software. Below we have highlighted some of those.

If we were not already well aware of what SiteLock is really about, we would asking why SiteLock would be partnered with a web hosting company putting their customer at risk like this. It is worth noting that as far as we are aware none of SiteLock’s protection services include updating software, despite that being an important measure (and them seeming to be aware of the risk of outdated software).

Joomla

First up MOJO Marketplace is still offering Joomla 2.5.x despite that reaching end of life (EOL) on December 31st, 2014.

The next release of 3.x, 3.6.5, was released on December 13 of last year and included security fixes.

Drupal

Not only has Drupal 6 been EOL over year ago, but there were five security updates after 6.33: 6.34, 6.35, 6.36, 6.37 and 6.38.

The next release of Drupal 7, 7.44, was released 11 months ago. Not only did that include security fixes, but so did the subsequent 7.52.

The next release of Drupal 8, 8.1.1 was released a year ago. Subsequent to that there have three releases with security fixes: 8.1.3 8.1.7, and 8.3.1.

Magento

That version is two years out of date, with 1.9.1.1 being released in May, 2015. That version included security fixes, as did 7 subsequent versions: 1.9.2.0, 1.9.2.1, 1.9.2.2, 1.9.2.3, 1.9.3.0, 1.9.3.1, and 1.9.3.2.

PrestaShop

The PrestaShop version is more than a year out of date, 1.6.1.5 was released last April, and a security fix was released in the subsequent 1.6.1.12.

Moodle

Moodle 3.0.x was replaced as the most recent major version of Moodle just about a year ago. Support for 3.0.x ended a week ago. Not surprisingly the version of 3.0.x being offered isn’t recent, with the next version 3.0.5, being released 11 months ago. That version included security fixes as well five subsequent releases: 3.0.6, 3.0.7, 3.0.8, 3.0.9, and 3.0.10.

MediaWiki

MOJO Marketplace isn’t offering the latest major version of MediaWiki, but at least you could explain providing 1.23.x as it long term support release in they were keeping it up to date. But as with the other software they are not doing that. The next release of 1.23.x, 1.23.7, was released in November of 2014. That was a security release, as were 8 subsequent releases: 1.23.8, 1.23.9, 1.23.10, 1.23.11, 1.23.12, 1.23.14, 1.23.15, and 1.23.16. Version 1.23.x reaches EOL this month.

SiteLock Unintentionally Provides Reminder That They Don’t Keep WordPress Websites Secure

One of our long time concerns with the security industry is that that their efforts to sell more advanced security measures make it less likely that people will take more basic security measures. Right now even many security companies are not doing the basics when it comes to security and as a hacking of one of Trend Micro’s websites earlier this year showed, more advanced security measures are not necessarily even as effective as the basics.

Another example of this comes from a recent case study from the security company SiteLock where they highlight a website that is using a version of a WordPress plugin with known vulnerabilities while they falsely claim one of their services is insuring the website is “safe and secure at all times.”

The Unmentioned Business Relationship

Before we get the details of that it is worth noting that SiteLock isn’t being upfront about how they came to be involved with the website mentioned in the case study, which seems important when you consider they are leaving it insecure.

Here is their explanation:

One day Kasal unexpectedly received an email from his hosting provider alerting him that his blog had been infected with malware. Due to the stealthy nature of the attack, there were no obvious signs that his blog had been compromised. “I was unaware that my site had been hacked and at a total loss as to how to find or fix the problem,” he recounts.

Kasal’s hosting provider informed him that his blog would be taken offline unless he removed the malicious code that was inserted on his website. His host recommended he contact SiteLock_® to remove the malware and help prevent future attacks.

What they don’t mention is who the web host is or why they recommended SiteLock. Looking at the DNS records the web host is IPOWER. That is one of the many brands names that the Endurance International Group (EIG) does business under. That is rather important in explaining the recommendation, as it turns out that SiteLock’s owners are the CEO and a board member of the company and the company has disclosed that they get 55 percent of revenue coming from the sales of SiteLock’s services through a partnership they have. If there were not those connections we doubt the web host would be recommending SiteLock, considering the many problems with SiteLock (one the reoccurring complaints is that they sell protection services that don’t actually protect websites).

SiteLock Doesn’t Detect Vulnerabilities

The case study doesn’t go in to details as to how the website was cleaned, but no mention was made of doing two important parts of cleanup, making the website secure as possible (which usually mainly involves getting the software up to date) and trying to determine how the website was hacked. Based on our own experience being brought in after them to re-clean websites and everything else we have seen, it is likely those things were not done.

Without knowing what caused the website to be hacked you can’t say what would have prevented it from happening, but we can be fairly sure that SiteLock’s idea of a “proactive approach” isn’t the best way to secure the website going forward:

Once his website was clean, Kasal decided to take a proactive approach to website security by implementing SiteLock_® SMART^™, a daily scanner to help protect his blog from future attacks. SMART provides continuous file scanning to detect vulnerabilities and malware, including backdoor files and malicious code. If malware is identified, it is automatically removed and Kasal is immediately notified.

SMART also provides a full website analysis of each scan, ensuring Kasal’s site is safe and secure at all times.

It is strange that they are describing that as being proactive, since it is clearly reactive. If you are detecting malware on a website, it means it has been hacked and it wasn’t protected. There are further problems with that approach, like the inability to undo the compromise of a website’s data and that SiteLock has a limited ability to remove malicious code automatically (when they are even successful at detecting it).

A quick look at the website shows that is a couple of vulnerabilities that SiteLock must not have detected. Looking at the source code of the website’s pages you scan see that the version 2.9.45 of the plugin WordPress Download Manager is in use:

The plugin is several versions and a couple months out of date, with the next version, 2.9.46, having been released on April 17. That version fixed two vulnerabilities in the plugin, which is somewhat obliquely mentioned in the changelog with these two entries:

Added nonce check with settings form
Blocked unwanted file type upload

This is a perfect example of where doing the basics would be better, because if the website’s owner was keeping their plugins up to date they would actually be protected against those vulnerabilities. They wouldn’t even have to take manual action do that as there are a number of options available, including our Automatic Plugin Updates plugin, to have plugin updates happen automatically.

Keeping plugins up to date is free, unlike SiteLock’s service, but would another paid service actual have warned about those vulnerabilities? We know of one, our Plugin Vulnerabilities service, which warned about both vulnerabilities even before they were fixed (we also were the ones that discovered one of the vulnerabilities).

One last thing to note is that instead of SiteLock being able to tout that it actually detected those vulnerabilities or any other issue, they instead point to the number items checked:

SiteLock captured billkasal.com’s SMART scan results from a 30-day time frame. During the given 30 days, over 170,000 files, 120,000 links and 15,000 pages were thoroughly scanned for malware.

Sheer numbers clearly don’t equal quality.

Site5 Referring to SiteLock as a Third Party Seems Disingenuous At Best

As we have looked closer at the web security company SiteLock over the last year one of the things that has stuck out is how their web hosting partners are not being upfront about the nature of their partnership with SiteLock.

As we have mentioned before when it comes to one of their biggest web hosting partners, Endurance International Group (EIG), the company has disclosed to investors that SiteLock not only pays them more than half fees for services sold through their partnership, but the CEO and a board of EIG also are the major owners of SiteLock. Those seem like things that should be disclosed to their customers as well since there is an obvious potential for conflict of interest with that relationship, for which their customers should be aware of when considering their recommendations regarding SiteLock. Instead we have found previously that one EIG brand, HostGator, wouldn’t even publicly acknowledge those connections. In that instance they referred to SiteLock simply as a “trusted partner”.

We are frequently contacted by people that have had their web host shut down access to the website based on a claim that the website is hacked and recommend that they hire SiteLock to handle resolve the situation. While in many instances the websites are in fact hacked, there are some serious issues with false claims that websites are hacked. So when we are contacted in those situations we want to find out what evidence there is that the website is hacked first, so that we can double check if the website is in fact hacked before starting on a cleanup. Through that we were recently forwarded a report from the web host Site5 (about a website that was actually hacked), which referred to SiteLock is this way:

If you don’t feel comfortable removing the infected files yourself, we recommend contacting a third party professional who can assist with removing malware, such as SiteLock.

Considering that Site5 has been part of EIG for nearly a year and the connection between EIG and SiteLock, calling them a third party, while maybe technically accurate, clearly doesn’t provide their customers a honest understanding of the connection between the companies. (Not surprisingly from everything else we have seen related to EIG, the quality of Site5 service and support looks to have gone downhill since becoming part of EIG, just look at the number of negative reviews they have received on their BBB page since the purchase).

SC Magazine Is Arming Their Readers With False Information

When it comes to the poor state of security these days, two of the important players to get us where we are, are security companies and the security journalists that are covering them. Security companies have shown for years that don’t know and or care much about security. You would think that with the high profile nature of security today and how bad things are, that journalist would be covering that aspect. It wouldn’t take digging very deep to find lots of material. Instead when it comes to journalists covering security they seem to be more interested parroting the claims of security companies instead of doing any actual journalism.

Take the company SiteLock, which you only have to look what Google suggests when you do a search on them to know about their well earned reputation:

Despite that, instead of any coverage of how they and their web hosting partners take advantage of people, journalists would rather parrot false claims they make. Last week looked at a recent example where journalists hadn’t bothered to do any fact checking before running with a SiteLock claim of a trending threat, which if they had likely would have warned them about the veracity of their claims.

Earlier this week we looked at another one of SiteLock’s claims of trending threat, which once again was based on falsehoods. Most notable claiming that a backdoor script with incredibly well known malicious code was not widely recognized:

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

In the case of both of SiteLock’s claimed trending threats SC Magazine provided parroted coverage. With the more recent article we left a comment that pointed to a number of the problems in their reporting, but so far it hasn’t been approved, so anyone reading the article is left without a possible counterpoint to the inaccurate information in it.

Providing their readers with false information isn’t in line with how SC Magazine describes themselves in the footer of their website:

SC Media arms cybersecurity professionals with the in-depth, unbiased business and technical information they need to tackle the countless security challenges they face and establish risk management and compliance postures that underpin overall business strategies.

To give some idea of the problems with just that one article, let’s take a look at a few issues with the article.

Here is paragraph that has the false claim that code stays hidden from security programs:

The code manages to stay hidden from many security programs, Kipp noted, suggesting cybersecurity teams manually add this piece of code to their security programs so it can identify an attack.

SiteLock didn’t provide any evidence to back this up and from our years of experience we can say that it either isn’t true or the web security industry is in much, much worse shape than even we think it is in. What is also worth noting there is the link in that sentence, which goes to https://wpdistrict.sitelock.com/products/?prod=malwareScanning. Looking at that you can probably tell that that page doesn’t actual contain any code, instead it is a sales page. It isn’t clear what they could have been intending to link to because there is no link to any code in SiteLock’s post.

The following paragraph refers to taking control of a computer, but the claimed threat involves taking over websites not computers:

The malware not only enables an attacker to obtain administrative control of a computer, but it also makes the computer’s information publicly available on the web. The reason for this is oddly practical, from the cybercriminals point of view.

SiteLock Services Don’t Update Web Software

We also found the final paragraphs of the article interesting:

Because the malware only goes after known issues with these CMS programs Kipp said it is imperative that those using this software are up to date with their security patches.

“This should really drive home the importance of patching your CMS platform to website owners. Automated campaigns like these are run on an ongoing basis, which attack websites on an almost indiscriminate basis. The majority of web attacks aren’t targeting websites based on their content or popularity, but based on their use of vulnerable outdated software. These are the low-hanging fruit of the web, he said.

First off SiteLock’s report makes no mention of the need to update software, but more importantly as far as we aware SiteLock’s security services don’t involve keeping software on a website up to date, as can be seen in a previous post we did specifically mentioning they don’t do that and one about websites they included in case studies that were running outdated software. That discrepancy between what they say is important here and what they are selling to their customers seems like something a journalist might want to ask them about.

It is also worth noting that SiteLock doesn’t cite any specific vulnerabilities being exploited, which would lead us, based on plenty of experience with that type of claim, to believe that they likely don’t know how the websites were being exploited. We have often seen outdated software blamed as the source of hacks in cases where the person making the claim hadn’t reviewed any evidence that would actually support the claim and in some cases where the software was actually being kept up to date.

A Security Service That Doesn’t Determine How a Hack Happened Isn’t Actually That Helpful

We are frequently brought in to re-clean hacked websites after another company had cleaned it and then it got hacked again. While the re-hacking is not always the fault of whoever did the first cleanup, we have found that companies doing those cleanups are cutting corners. The first thing that we ask after it is brought up that someone previously cleaned up the website, is if they determined how the website was hacked and gotten that fixed. If that hasn’t happened it obviously leaves open the possibility of the website being hacked again. The answer is almost universally that doing that never even came up. It shouldn’t be that way since trying to determine that is one of the three basic parts of a proper cleanup. So either these companies (we have heard it about a lot of different companies over the years) don’t know what they are doing or are intentionally cutting corners.

We recently ran across a reminder that the web security company SiteLock either doesn’t understand the importance of doing that or doesn’t want to have to do the work required to things properly, as they didn’t tell truth about needing to do this. In a thread on the WordPress support forum, which came up in our monitoring for discussions of vulnerabilities in WordPress plugins that we do for our Plugin Vulnerabilities service, a SiteLock customer had been notified their website had been hacked:

We signed up for SiteLock which was helpful and told us this morning that we had a malware warning for “defaced pages” – sure enough, the list they provided was full of similar material to the last one. This time it said “just for fun” and “hacked by GeNeRaL.” Since we’re on the latest version of WP, and we had updated our password to one of the long, random, extra-complex ones that WP suggests, I don’t know what to do to prevent this. I deleted all of the blog posts, but is there anything better we should be doing?

There are a lot of things that could be focused on there. The fact that they received a malware warning for “defaced pages”, despite that not being a malware issue (that lack of clarity is even more problematic when they are falsely claiming that a website has an issue identified by their scanner). The fact their customer either is not be able to or not feeling they can get in touch with the people they are paying to protect their website about a concern they have. But will focus on the claim that SiteLock was helpful despite clearly leaving this person unaware of what caused the issue, which is in fact the most important part here.

Before we get to that though, we have to mention an example of the poor quality responses from moderators when you post about security issues on the WordPress Support Forum in this thread. As is often the case this person did not get relevant advice from a moderator:

Take a deep breath and carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures.

If you’re unable to clean your site(s) successfully, there are reputable organizations that can clean your sites for you. Sucuri and Wordfence are a couple.

Not only did they not address the specifics of the poster question, they promoted two security companies. Neither of those companies are ones that we would refer to as reputable. We just had a post on Sucuri claiming one of their customers website that had malicious code to compromise credit card info entered on it was clean and recently had one on their scanner producing a rather bad false positive that lead to them claiming our website was defaced (we also frequently see moderator pointing to people to their poor quality scanner). With Wordfence, they don’t seem to understand the basics of security and spreads falsehoods about the security of WordPress. Why someone connected with WordPress would be promoting a company spreading falsehoods about the security of WordPress is as baffling as it is troubling.

The response from someone at SiteLock in the thread didn’t raise the need to determine how the website was hacked, instead they stated:

The bottom line is that you’re most likely in the clear regarding that particular incursion, but continuing to run malware scans on an ongoing basis is your best way to be certain.

Even if a malware scanner is good at what it does (and SiteLock’s doesn’t seem to be) from a technical perspective it simply cannot detect everything. Of course doing things right would increase SiteLock’s costs, whereas telling someone to continuing to use their service to have scans continue would make them more money.

The thread went on for a bit and ended with the person not being able to get in touch with someone at SiteLock that would actually determine how the website was hacked:

I tried to ask for you when I called, but it sounds like they couldn’t find you at the time. The rep I spoke with checked the site in question and said there are only 95 pages. Do you think it’s an issue with SiteLock not noticing it, or is it more likely that this more recent hack cropped up as a result of some other vulnerability (a plugin, theme, something else)?

Despite the service not doing what should be done they thought they had been helpful and were open to possibly giving more money to SiteLock:

We’ll most likely want to add on several other domains to this account and possibly upgrade. Thanks for your help!

Every time someone does something like that it hurts everybody because it helps bad security companies like SiteLock spread, which means that he needed improvements to security are less likely to happen because those companies keep pushing people away from focusing on the things that would actually improve security.

SiteLock Threat Intercept Falsely Claims That Widely Known Backdoor Code isn’t Recognized as a Threat

Last week we looked at the fact that web security company SiteLock’s recent claim of a trending threat had an obvious falsehood in it, which was that a malicious WordPress plugin was a forgery of legitimate plugin despite the supposed legitimate plugin not existing. The rest of their post on the issue lacked evidence to back up their claims and it seemed that the malicious plugin might be rather old and not a new trend. Unfortunately a number of security news source repeated their claims verbatim instead of doing any fact checking (with two of them we left comments on their posts mentioning that the legitimate plugin didn’t exist, but neither of them have approved our comment to show on the posts yet)

Based on that and everything else we have seen from SiteLock isn’t really surprising to see that they made an obviously false claim with their next claimed trend as well.

Before you even get to the contents of the post there already is something that looks us to be a good red-flag that the post isn’t something that should be taken seriously, it’s this graphic:

It reminds of the overused breaking news graphics on cable news, which seem to be used for things that don’t seem to qualify far too often.

The main portion of the post is a good example of the poor quality content put out by security companies. Frequently they will dress things up to make something trivial or in some cases made up, seem more serious. In this case with this infographic:

They even give the claimed trend a name (because trying to brand vulnerabilities was not enough).

At the heart of the claimed trending threat is that websites running outdated software can be hacked:

The vectors used to infect websites appear to be well-documented vulnerabilities in older versions of website platforms.

Which isn’t anything new. It is worth noting that SiteLock doesn’t cite any specific vulnerabilities, which would leave us to believe they don’t actual know the source of hacks. We have often found security companies and web hosts will claim that website have been hacked through outdated software based on zero evidence (in some cases we have seen this claimed when the software of the website was actually being kept up to date). From everything we have seen SiteLock usually doesn’t determine how websites are hacked when cleaning them up, despite that being one three main pieces of doing that correctly, which increases the chances that they don’t actually know in this instance either.

If there was something worth noting here it relates to the possible compromise of cPanel login credentials, not CMS credentials, through the hack. SiteLock make no direct mention of that, only mentioning to change the cPanel password if using that, which is another indication that SiteLock doesn’t have much security expertise and experience.

SiteLock Doesn’t Suggest Taking the Action to Prevent the Real Threat

The last section the post is what seems to be the real point of their post, to promote one of their products, which doesn’t actually fix the claimed root of this, which is outdated and vulnerable software. It starts this way:

Here’s what you need to do

As this trend both provides administrator-level control over the target website environment as well as publicly discloses credentials, action must be taken to counter both threats.

Since again, the important threat is the vulnerability being exploited to allow the hacker access to the website in the first place, not what could be done if it is exploited since that can be stopped from happening, you would expect the first action they suggest be to make sure the software on a website up to date, instead it is:

Run a malware scan to locate the presence of any shell files. (see: SiteLock Malware Scanners)

In fact updating the software on the website isn’t listed at all. Do they want websites to remain vulnerable to being hacked? It is worth noting that we are not aware of any SiteLock ongoing security services that include them keeping a website’s software up to date (not surprisingly we have seen numerous instances of their customers using those services getting hacked.)

False Claim

Finally let’s look at the false claim, which is this:

The code within the shell used to gain the initial foothold is currently listed in the SiteLock malware database, but does not appear to be widely recognized as a threat by many website security vendors at this time. You may use the code snippet below to manually add the shell to your security mechanisms.

Looking at the screenshot they provided of the backdoor script, there is a line code that would immediately stick out to anyone that regularly deals with hacked websites:

That would be this part “$default_action = ‘filesman'”. Looking back it looks like backdoor scripts with that line of code have been in existence at least since 2010.

The idea that the code wouldn’t be “widely recognized as a threat by many website security vendors at this time” indicates SiteLock is clueless, is lying, or thinks the rest of web security industry is even worse than them (which might explain their laughable claim to be the global leaders in website security). None of those possibilities is something that should be able to be said about a security company.