Category: Bad 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.

SiteLock Will Try To Sell You Services You Don’t Need and Can’t Use

Over the last year or so, as we have seen and heard more about the web security company SiteLock’s practices, it has become more clear that a lot of what they are doing can reasonably described as scamming. Take for example a recent issue brought up on the customer complaints section of their BBB page, which starts with the complainant being contacted by one of SiteLock’s sales people (who are commissioned, which will be relevant in a moment):

The… details are as follows: I spoke to someone back in October after Sitelock called me warning that I needed more security on my websites. Sitelock was very persistent, with an employee calling me and leaving messages daily until I finally agreed to speak with him. After being convinced that there was a danger to my domain during a very long conversation with one of the employees, I agreed to move forward although the price seemed outrageous, and was then passed on to the billing department.

All of this sounds like numerous other stories we have heard when people contact us after interacting with SiteLock (most of them have luckily avoided signing up for something from SiteLock before contacting us to get a second opinion) and we have read online. A legitimate security company wouldn’t keep calling someone like this, but a commissioned sales person is likely mainly interested in getting a commission, not in what a legitimate security company would do.

Based on that what comes next isn’t surprising, but it is interesting that others at SiteLock are clearly aware that something wrong is going on:

The woman at the billing department actually pointed out to me that my sites were hosted on Shopify, and therefor would not be eligable for Sitelock security as they were being hosted by Shopify’s own very protected servers and were actually not at risk in any way, nor could Sitelock be of use to me. She told me I did not need the service I was sold.

There is something quite wrong when the billing department seems to be more aware of whether some can use services than the sales people that are selling them, which gets back to the issue of scamming going on (the sales person gets a commission whether the service is used or not).

Unfortunately, that didn’t end their interaction with SiteLock:

I chose to believe that the original employee who called me telling me my sites were in danger was not intending anything dishonest, but that he didn’t realize where my sites were hosted and gave me the wrong information. I no longer think this was an honest mistake after being repeatedly charged. I told the woman in billing that, obviously, I agreed that I did not need to go through with the subscription, and it was cancelled. Since that time, I have been repeatedly billed, totalling $1023.99, and I’m sure I will again be billed next month as Sitelock has not responded to my requests for refunds and termination of any services.

This isn’t the first time we have heard of how hard SiteLock makes it to cancel services once they have gotten you signed up, which seems quite intentional at this point.

Part of SiteLock’s response to this is rather incredible:

We always put our customers first, and strive to deliver exceptional customer satisfaction.

Do they think that people will believe that selling a very expensive service that someone didn’t need based on what seem to be lies, is in anyway putting customers first?

It appears this customer was able to get the situation resolved to their satisfaction, so if you are in the same situation it looks like filing a complaint with the BBB could resolve the issue (if it does, please let us know in the comments section below). You should also make sure to leave a review there as well, so people looking into their service know what is really going on.

Security Companies That Deal With WordPress Websites Should Understand That Usernames Are Not Considered a Secret

When it comes to improving the poor state of security one of the major impediments is security companies. Far too often they either don’t seem to understand the basics of security themselves or are intentionally telling people things that are false as means to push products that are not needed.

While looking into something related to another post we ran into the security company WeWatchYourWebsite again. The last time we did that, we found them providing what was claimed to be an example of hacker looking for infected websites, but was in fact something very different, a hacker trying to exploit a vulnerability in a plugin that was never on a website. Amazingly they claim to “specialize in root cause analysis” despite not having a basic understanding of the topic.

Since then they put out a post showing they didn’t understand the difference between brute force attacks, which are not happening, and dictionary attacks. And a post with this troubling line in reference to a WordPress website:

In this instance the hackers were able to find the admin username and guess the password. So, even though the owner took the step of changing the admin username, using an easily guessed password negates that.

We really can’t emphasize this enough, WordPress usernames are not considered a secret and therefore changing them is not a security step that could be negated.

What makes that mention seems so odd, is they seemed to understand how easy it can be to get the username on a WordPress website currently:

First, the hackers worked at finding out the name of the admin user. There were a number of these in the logs:

“GET /?author=1 HTTP/1.1”

“GET /?author=2 HTTP/1.1”

“GET /?author=3 HTTP/1.1”

“GET /?author=4 HTTP/1.1”

…and continued on by incrementing the integer after “author=”

Apparently it worked as the customer had changed their username for admin.

So either they had seen that WordPress has a major security issue (if the usernames were meant to be a secret) or they should have realized that it isn’t meant to be secret and not made a statement implying otherwise.

Journalists Spread SiteLock’s Fake Claim Involving Nonexistent Legitimate Plugin

When it comes to security journalism, there doesn’t seem to be much actual journalism going on. Instead much of what passes for news coverage these days simply involves repeating the claims of security companies, without doing any fact checking of those claims. This would be a problem just based on the low quality of information coming from security companies, but it looks to us that security companies have realized that in getting coverage what matters is not the truth but saying something that a journalist think they can get clicks by repeating.

A good case in point of journalist simply repeating a security company’s claims we ran across recently was a claimed trending WordPress security issue. Beyond the fact that no evidence was presented that actually backs up the claim that the issue was trending or that the issue was is some way actually significant (and deserved to be covered instead of another issue), something else stood out to us. In the security companies SiteLock’s post on this issue, they claim a “fake” plugin involved in the issue is a forgery of a legitimate plugin:

It is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

In coverage of the issue, that claim was repeated by journalists. Here is how it was reported in the Threatpost’s article:

The fake WP-Base-SEO plugin is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools.

Here is how it was reported in Infosecurity Magazine’s article:

Dubbed WP-Base-SEO, the plugin is a forgery of a legitimate search engine optimization plugin, called WordPress SEO Tools, according to SiteLock, the firm that originally uncovered the threat.

Finally here how it was reported in SC Magazine’s article, this time without naming the claimed legitimate plugin:

The fake plugin is called WP-Base-SEO and is based on a legitimate SEO module so it is easily overlooked during security scans and seems to be a viable tool by a web team intent on boosting its traffic, said a research team at SiteLock.

The problem with all this is that the supposed legitimate plugin WordPress SEO Tools doesn’t exist. If you do a Google search on the name or on WP SEO Tools it doesn’t bring up results for a plugin with that name. Looking at the Subversion repository that underlies the Plugin Directory, where most plugins are found, there are not entries for a plugin with the slug wordpress-seo-tools or wp-seo-tools.

This should have been something that journalists could have easily checked and if they had look into that they might have realized something was amiss here.

In a quick check over this, something else also stands out to us. While the reason for this issue getting covered is that the “fake” plugin is supposed to be trending, it looks as it might be rather old (or at least based on something that hasn’t been updated in a long time). That is particular noticeable in the screenshot provided by SiteLock of the plugin’s header comments:

The copyright there is 2013, though on its own wouldn’t mean much, what is more noticeable in dating this is this the Plugin URI, which is http://wordpress.org/extend/plugins/. If you visit that URL now you are redirected to https://wordpress.org/plugins/, which is the address of the Plugin Directory. So why would the URL include “extend” when it doesn’t exist the URL you are redirected to? The answer is that the “extend” used to be part of the URL, but that was removed on May 22, 2013 (the switch to HTTPs occurred in 2014). Based on that it is entirely possible this malicious plugin isn’t a new issue, just being promoted that way so that a security company could get coverage.

The Obviousness of Unnatural Reviews for a WordPress Security Plugin

An important element of security is trust, seeing as most people are not going to have ability to independently verify what a security product or service is doing what it is claimed to do and instead have rely on the those behind it to be truthful. What we have seen in our experience with the industry is that they don’t even really attempt to be honest with the public, instead correctly seeing that they can get away with misleading and outright lying because the checks that should exist against that are not working. The end result of this is current poor state of security.

Over at the blog for our Plugin Vulnerabilities service today we looked at a security plugin that fails to actually do its most important function. We also noted that most of the reviews for the plugin look like they came from people that were connected to the plugin, which provided a distorted view of the plugin.

That plugin certainly isn’t alone among WordPress security plugins having many reviews that don’t look to have come naturally. Another plugin we came across within the last few days pretty obviously has unnatural reviews. The plugin WP Security Optimizer has 4 reviews despite having less than 10 active installs:

That is well beyond even an extremely high number of reviews for the amount of active installs. By comparison our plugins have the following mix of reviews to installs:

  • Automatic Plugin Updates: 9 reviews / 10,0000+ active installs
  • Plugin Vulnerabilities: 14 reviews / 5,000+ active installs
  • No Longer in Directory 10 reviews / 1,000 active installs

Not only are the reviews out of line with the number active installs, but three of the four accounts used for the reviews were created on the same day as the review and have not been used for anything else (the fourth was created several days before the review).

Also like many other plugins it is promoted in a way that is likely far from reasonable, considering that the description of the plugin begins:

Prevent hackers to sabotage your rankings in search engines.

While we haven’t tested the plugin against real vulnerabilities yet, it looks like it is mainly focused on trying to hide the fact that a website contains vulnerable software instead of doing anything that could resolve the website being vulnerable. Considering many times hackers don’t do any checks before trying to exploit a vulnerabilities, it wouldn’t do much to prevent hackers from succeeding.

The SiteLock 911 Service Offered by GoDaddy Leaves Websites Open to Being Hacked Again

When it comes to cleaning up hacked websites, we are frequently brought in to re-clean websites after another company has previously been brought in and then the website gets hacked again. While it is not always the other company’s fault, what we have found is that almost always it involves a situation where the other company unintentionally or intentionally cut corners with the cleanup.

There are three basic components of a proper cleanup: removing the malicious content, getting the website secure as possible, and trying to determine how the website was hacked. We frequently see that only the first item, removing the malicious content, is done. That can leave the website open to being hacked again (and skipping over trying to determine how the website was hacked can also lead to not finding some of the malicious content that needs to be removed).

All of that brings us to the SiteLock 911 service that GoDaddy offers in conjunction with SiteLock. From what we have seen being brought to get things properly cleaned after this service has been used, corners are cut, leaving websites vulnerable. What isn’t clear if you were to look at the description of the service, is that is the case, so let’s take a closer at how the service is presented.

In describing how the service works they make it sounds like all of the components are happening:

Next we remove every bit of malware from your code. We also close security gaps and the backdoors that hackers use to break into your site.

There are a couple of fairly glaring issues with that. First backdoors would normally not be how hackers break into the website; instead backdoors are placed on the website through a vulnerability and then used to take further actions. If you remove the backdoor, but don’t fix the vulnerability it can just be placed there again. The other problem is that all of that fixing is supposed to happen with files that they copied of off the server and then placed back on the server, but that wouldn’t actually be how you would do much of the securing or determining the source of the hack. The securing usually involves getting the software up to date, which wouldn’t be done by just copying files (and based on what we have seen, isn’t something they do). The determining of the source involves reviewing the log files, which are stored separately on GoDaddy’ servers or in the case at least one type of account are not even stored.

In the FAQ, there is a rather odd answer to the question “Is the cleanup permanent?”:

Unfortunately, no. If the hacker automated the attack, it could keep happening. And SiteLock911 doesn’t protect against future attacks, so your site could get infected again. We offer preventive SiteLock plans with daily scans to keep your website malware-free.

This doesn’t really make any sense, as most hacks are automated and whether it could happen again depends on if the vulnerability that was exploited has been fixed. This answer alone should be a good indication that neither of the companies involved with this service have any idea about the basics of hacked websites (this isn’t the first time we have seen that coming from SiteLock). (The preventative SiteLock plans don’t actually do much, if anything, to protect websites from being hacked either.)

Another FAQ is also rather odd. In response to the question “Is it guaranteed to work?” it is stated that:

SiteLock911 malware cleaner handles most websites with ease but with new malware appearing all the time, there are no guarantees. If you happen to be afflicted with a brand new infection or hack, SiteLock will work with you to make sure your website is restored.

Whether the malware is new or old shouldn’t have any impact on being able to restore a website, instead the only limitation in the ability for a cleanup to restore a website to its previous form is if the hacker has removed or damage files or other content from the website. You can’t restore something that doesn’t exist, so either there would need to be another way to get a copy of the files/content or you can’t restore it. Something being new shouldn’t make a difference.

This seems like it may be a cover for SiteLock’s ongoing issues with damaging websites that they are supposed to be cleaning up at GoDaddy. That seems to be a fairly common issue based on the complaints we have seen on the web and the times we have been brought in to fix things up after them. While we frequently are brought in to re-clean websites after other companies have done a poor job, SiteLock is the only one where we have seen other company leaving behind broken websites. That is one of the many reasons we say that they are by far the worst company in the field.

Sucuri SiteCheck Scanner Falsely Claims Our Website is Defaced

In the past we have discussed the fact that the web security company Sucuri’s scanner SiteCheck is rather poor at what it does, including falsely claiming that a website was infected with malware due to a bad false positive and claiming that a website was running on outdated software without knowing if that was true.

We just ran across another example, which this time involves our own website. On a post about them astroturfing from four years ago, we recently got this comment:

The Scam is strong with this one

https://sitecheck.sucuri.net/results/www.whitefirdesign.com

If you follow that link as of us writing this you will see that the status of our website is “Website Defaced (hacked)”:

Not only is it not actually defaced, but there reason for claiming that is just baffling, as the claim is based on the title of one of the pages on our website being “Hacked Website Cleanup – White Fir Design”:

It would appear they are claiming that a website is defaced just due to the words “hacked” and “website” in the title of a page, which clearly isn’t reliable to determine if a website is defaced. On top of that they are claiming an issue that doesn’t actually exist is of “Critical” severity.

We of course can spot that their claim was wrong since we deal with websites that are actually hacked all the time (and it was quite obvious at least in this case), but based on plenty of experience dealing with people that think that their websites have been hacked, we would guess that a lot of webmasters and owners could be mislead by this type of thing, leading to some of them paying Sucuri to clean up a hack that didn’t exist.

Sucuri Also Misrepresents Other Companies Data

The problems with their scanner don’t end there as the results for our website show. They also mention that our website is “Blacklisted”:

Looking into the details of that they claim the website is blacklisted by Norton Safe Web:

The reality is lot less alarming then they claim. Here are the Norton results:

What seems rather relevant to that is this part:

Web sites rated “Caution” may have a small number of threats and annoyances, but are not considered dangerous enough to warrant a red “Warning”.

So unlike Sucuri they don’t think that it should get a red warning.

So what are the threats on our website? There are not any, instead Norton’s scanner doesn’t understand the difference between showing malicious code in harmless form on one of our website’s pages, with actual malicious code on a website (the poor quality of website scanners isn’t limited to Sucuri):

While Sucuri warning if websites are actually blacklisted by other services would be useful, it should be accompanied by a disclaimer that the other services results may not be accurate instead of overhyping the issue to try to sell their services.

A Better Way to Get Your Website Check to Confirm if it is Hacked

Based on all that there is plenty of reason to avoid Sucuri’s SiteCheck, but what is a better way to confirm whether your website is hacked if you believe it is? The simple answer is to contact us, as we are happy to do a free check to confirm whether a website is hacked or not. We don’t rely on low quality automated tools to do that, since they produce poor results as was shown above. Instead we will discuss the situation with you and then do any necessary checking to look into the possible issue. For websites that are hacked we will also provide a free consultation on how best to deal with the issue, instead of trying to scare you into using our services, unlike Sucuri.

Another Reason Why SiteLock’s Lying About Incapsula Being The True Source of Their WAF and CDN is a Problem

When it comes to the numerous issues with the web security company SiteLock one of the ones we found to be the strangest is their continued lying about the true provider of their content delivery network (CDN) and web application firewall (WAF) services. While they make it sound like they are providing themselves when mentioning the services, using phrases like “our IP addresses“, “SiteLock servers“, and even “SiteLock patent-pending technology” what we found was that services are actually provided by another company, Incapsula.

We can’t think of a good reason of for lying about who provides these services, but when mentioning this previously we mentioned a couple of reason why being dishonest about that is a troubling thing. First, trust is an important part of security, if SiteLock is willing to lie about this then what else might they lie about. Second, since both of these services involve sending a website’s traffic through the provider of the service’s systems, having a website’s traffic go through a company that the website’s owner doesn’t have a relationship with raises some serious security and privacy issues.

While helping someone resolve an issue with a website recently we ran across another issue caused by this. They were having a problem caused in part by the Incapsula WAF. While they were getting an error page from Incapsula served as part of the problem, they didn’t know where that was coming from or how they could remove Incapsula’s WAF since they didn’t know that the SiteLock service being used was actually Incapsula or even that they were was a connection between the two. If SiteLock was upfront about who really provides that service then it shouldn’t have been a mystery as to the source of the error page and the issue could have been more easily resolved.

Don’t Assume Your Web Host’s Security Claims Are True

When people ask us about web hosting recommendations we tell them that we don’t provide any since we can’t independently verify a web host’s security practices. Unfortunately what web hosts say about their security isn’t necessarily true, even when it involves things that can easily be double-checked. Something we ran in to recently was a reminder of that.

After we had started making a copy of website’s files over FTP while beginning to work on a hack cleanup recently, the client told us they would need out IP address to whitelist it so that we could connect via FTP. Seeing as we were already connected via FTP, either they had just turned on the whitelisting or it wasn’t working. When we explained that we were already connected, they told us that they hadn’t just turned on whitelisting (in looking over the web host’s documentation, it isn’t even something you can turn on and off), so it wasn’t working.

Later on we asked the client to see if their web host could provide the log of FTP activity so we could see if that could have been the cause of the hack. Right at the beginning of the response from the web host, Nexcess, they claimed that IP addresses would need to be whitelisted to be able to connect, despite that not being true:

You have to whitelist your IP for FTP or you cannot login. This is done by logging into SiteWorx -> Hosting Features -> Firewall Rules.
You’ll need to add your IP and then choose the FTP service. Your IP may have changed or maybe you have never added it.
If your site was compromised, finding the IP’s that did it is likely a useless effort unless you suspect something like foul play from within your own organization or something. Otherwise, It’s likely caused by another compromised by another hacked machine or hacked hosting account as normally seems to be the case.
Compromises happen when security patches are neglected, or plugins are not kept routinely updated. Without these patches or plugin updates, any exploits located within them are not patched when the developers learn of them and release a new version to patch and close these vulnerabilities.

The rest of that response doesn’t really give us a sense they are very knowledgeable about security as they don’t seem to understand that knowing whether or not the hack came through FTP would be useful.

The takeaway from this seems to be that you shouldn’t assume that security claims made by your web hosts are true and if you want to be as secure as possible you should double check that security features are working when you can.

Manual Website Malware Removal Doesn’t Involve Manually Scanning Every File

In looking over a company’s marketing material about why they were a better alternative to SiteLock (which isn’t really difficult considering the many ways that SiteLock is a terrible company), there was a rather absurd claim made:

SiteLock likes to push their “manual” malware removal. However, with the average WordPress having about 1,900 files, can you imagine trying to manually scan that many files and have any kind of accuracy? I believe it’s a strategy for them to have such high prices.

In reality manual website malware removal doesn’t involve someone manually looking over every file on a website, which would be a waste of time. Instead it means that a human is involved in the process of reviewing the files and deciding what needs to be cleaned. One of the important reasons you don’t want a cleanup done with a fully automated process (as this company is promoting that they do and which SiteLock actually makes a big deal of doing as well), is that malicious code added to the website can provide important information on the source of the hack. Cleaning up the malicious code on a website, but not fixing the source of the hack, leaves the website open to being hacked again. We would guess that most people with hacked websites don’t want to have their website needing to be repeatedly cleaned, so they would want to have someone do a cleanup that actual does the work to determine how the website was hacked and then fixes it, instead of paying less upfront and then needing repeated cleanups.

To a large degree reviewing files on a WordPress website involves comparing the files to a clean copy of the files. In the download for the current version of WordPress, 4.7.3, there are 1473 files, so for a WordPress website with 1900 files, a large majority would be checked by simply doing a file comparison of those core WordPress files.

It also worth mentioning that the a major reason why SiteLock’s prices are so high has to do with them paying their web hosting “partners” large portion of the service’s fee, not how they do cleanups (which involves them cutting corners).