This Looks Like It Might Be Another Instance of SiteLock Partnered EIG’s Apparent Security Issue

A week and half ago we discussed a situation where there looked to be at least a hacker specifically targeting websites hosted with web hosting company EIG, which does business under the brands including A Small Orange, Bluehost, FatCow, HostGator, iPage, IPOWER, JustHost and quite a few others. The more concerning possibility is that the hacker wasn’t just targeting websites hosted with EIG but taking advantage of some security issue within their systems to breach the websites. Due to their relationship with a web security company, SiteLock, they don’t seem to have an interested in investigating this type of situation (and neither does SiteLock).

That wasn’t the first time we had run across the possibility of such a situation occurring with EIG, back in July of last year we discussed another instance, but in that case we were not brought in to clean up any websites targeted, so we had a very limited ability to assess what was going on.

We have now run across yet another instance that lines up with the others.

We were contacted about a hacked website after the person handling a replacement of that website was in contact with SiteLock (due to the website being hosted with HostGator) and then they found our blog posts about SiteLock.

What they had been told by SiteLock was the same kind of stuff we hear a lot. That included that they were told that if the website was cleaned up of the “malware”, but not protected by SiteLock going forward, it would just get infected again. Because the website was for a church, the SiteLock representative said they could provide a discounted rate of $400-600 a year (which doesn’t seem to actually be a discounted rate). Instead they hired us to clean it up for a lot less than that.

What we knew before we started working on the cleanup was that the main website in the account was serving up Japanese language spam when crawled by Google and other search engines, which lead to the search results for the website to also show that. That website was running Joomla 1.5, which was EOL’d in September 2012. There was a recently set up WordPress installation, which was being prepared to replace that website, and that website was not serving that spam content to search engines.

What would seem to be the obvious security concern there would be the Joomla installation, since it is using software that hasn’t been supported in 5 and half years. We haven’t seen evidence that Joomla installations of that vintage are currently exploitable in some mass fashion, so that seemed less likely to us. There was also the possibility of an extension installed in the Joomla installation being a security concern since those would be equally out of date.

The code causing the Japanese language spam wasn’t hard to find, it was obfuscated code added to the top of the index.php file in the root directory of the Joomla installation, which is also the root directory of the website. The last modified date for that file was years ago, which probably meant the hacker had changed it to hide that they had modified the file (which is very common).

As we started more thoroughly reviewing the files to look for any other malicious code on the website, the only place we found them was in multiple files that were located in a directory for a plugin, /wp-content/plugins/html404/, in another WordPress installation on the website. That additional WordPress installation hadn’t been mentioned to us.

That plugin contained files from version 2.5.6 of the plugin Akismet as well as files with malicious code in them. Those files were named:

  • 404.php
  • idx.php
  • jembud.php
  • wso25.php
  • xccc.php

That WordPress installation was running WordPress 4.7.9, which is an outdated major version, but should be secure due to WordPress releasing security updates for older major versions. The website was using a customized version of a popular theme and only one other plugin installed, neither of those things look like a likely source of a security issue.

In looking over the WordPress accounts for that website we found that the first account, which normally be the one created when WordPress was installed was named “html404”, which considering it matched the name of plugin’s directory, seemed like it was probably changed by a hacker (likely with the password also being changed).

In the looking at the session_tokens for that user in the wp_usermeta table of the database for that WordPress installation we could see that at nearly the same time that plugin’s files were listed as last being modified on January 25 someone had logged in to that account from an IP address in Indonesia (which isn’t where the website is located).

A non malicious file in the root directory of the website connected with the code added to the index.php file was also listed as last being modified at the same time, so it looks like the breach of the WordPress installation lead to the Joomla website being modified.

Because the web host for the website, HostGator, did not have any log archiving enabled we could only see the HTTP logging from the day we were cleaning up the hack limiting what we could gleam from that. The FTP logging didn’t show any access that shouldn’t have happened.

Looking around for any other mentions of this that might allow us to give the client better information on what could allowed what had occurred to happen, we came across a thread on the website for WordPress with other people that had been impacted. That provided further confirmation of what we had been piecing together, but nothing that shed any light on the cause.

At that point the possibility that this could be another example of whatever security issue might be going on at EIG was at top of mind. Since a hacker with either direct access to the databases on the server or access to files on it, which would give access to the configuration files with database credentials in them need to access the databases, could change a WordPress username/password like this. There was no direct mention of what web hosts the websites mentioned in that thread were using, but one of the participants username pointed to the website impacted and the website was hosted with Bluehost, another EIG brand.

In the previous instances where we found an EIG connection there was a defacement involved that had showed up on the website Zone-H. That allowed us to easily check over numerous websites to see what the host were. That isn’t the case with this hack, but we did check over a number of websites we could find that were involved and what we found was they all were hosted with EIG brands. Here are the IP addresses along with the EIG brands of websites we found reference to being impacted:

While the sample set we have is smaller in the previous instances the chances that all of the website we checked would all happen to be at one hosting company is not what you would expect if the hacking was caused by something unrelated to the web host. At best it looks like we have now run across multiple hackers that look like they are only targeting this one company, but what seems to be a reasonable possibility is that there is a security issue in EIG systems that is allow hackers to exploit them.

Several of those are from the same IP address, which would likely mean they are on the same server.

SiteLock’s Idea of Protection Doesn’t Seem to Involve Real Protection

Considering that EIG brands heavily push people to hire SiteLock to clean up websites, it seem incredibly hard to believe that SiteLock could have missed what we have picked by just dealing with a couple of websites, if they were properly dealing with hacked websites. But from what we know they don’t usually properly clean up hacked websites. Instead of doing proper cleanups they sell people on services that claim to protect websites, as what was attempted to be sold in this instance, that don’t even attempt to do that.

If you are not determining how websites are being hacked, it would be difficult to be able to protect them. If there is an issue with EIG’s system, it would unlikely that such a service could protect against it, so spotting that type of situation would be really important.

SiteLock’s lack of interest in true protection is even worse in the light of the fact that SiteLock has “partnered” with a web host that seems at best uninterested that hackers are specifically targeting their customers or worse, their customers are getting hacked due to a security issue in the web host’s systems. But it gets even worse, when you know that while the relationship between EIG and SiteLock is promoted as partnership, the reality is that the two companies are very closely connected then they let on publicly. The majority owners of SiteLock also are the CEO and board member of EIG, which neither side mentions publicly. So you have the owners of a security company that seems to be uninterested in security of websites it is supposed to be protecting also looking to be leaving websites they host insecure. On top of that both sides would profit from this insecurity as EIG disclosed that they get 55% of revenue for SiteLock services sold through their partnership, so both companies have a financial incentive to not find and fix something like this as long as their customers doesn’t become aware of what is going on and leave in mass. That seems like a good argument for keeping security companies and web hosts at arm’s length (maybe not surprisingly with the other instance of a security company closely tied with a web host the security company doesn’t seem to be interested in security either).

Wordfence Has Missed This As Well

SiteLock isn’t the only security company that seems to not be on the ball here. In the previously mentioned thread on the WordPress website one of the participants mentioned they were going to have the security company Wordfence “perform a comprehensive security review and if necessary, final clean-up” after being impacted by this. In the follow up there is no mention at all of Wordfence having made any attempt to determine how this occurred, just that “I am happy to report that the Wordfence security analyst found no evidence of malware on the website.”. Considering that trying to determine how a website was hacked is one of three basic parts of a cleanup, it seems a bit odd that there wouldn’t be a mention of Wordfence not figuring out the source if Wordfence had done things right and mentioned that they were unable to determine the source of the hack

The follow up response to that was from a Wordfence employee, who instead of being concerned about the source of hack being a mystery, just promotes a post on the Wordfence website that wouldn’t have any impact on resolving the underlying cause of these hacks. So it would seem they are unconcerned about this as well.

Wordfence Employee Ridiculously Claims You Can Make Sites “invincible against all the attack methods that are associated with WordPress sites”

While we have seen the bad side of the security industry for a long time, certain things continue to be surprising to us despite having seen them many times before. One of those is sheer amount of lying that goes on (that is on top of the amount of the massive amount false and misleading claims that are not clearly lies), despite trust being an important part of security. One area we frequently see that with is claims that products and services can provide a level protection that they can’t possibly provide.

When it comes to WordPress security plugins two are tied for the most popular in terms of active installations according to WordPress.org. One of them, Limit Login Attempts, is focused on a threat that isn’t of real concern and the current version contains a security we discovered and disclosed through our Plugin Vulnerabilities service last week (that security plugins frequently are found to have security vulnerabilities is a good indication of the poor state of the security industry). The other, Wordfence Security, owes at least some of its popularity and maybe a lot of it to marketing it with the unqualified claim that it “stops you from getting hacked”:

The WordPress security plugin provides the best protection available for your website. Powered by the constantly updated Threat Defense Feed, WordFence Firewall stops you from getting hacked.

That claim used to be the second sentence of description of the plugin on the page for it on the Plugin Directory and more recently has been found in the answer to the second FAQ question on that page.

The reality is that security plugins can’t possibly stop a lot of hacks, Wordfence intentionally leaves websites not using their service as well as the plugin vulnerable to being hacked, and in testing over at our Plugin Vulnerabilities service we found that the plugin provided no protection or the protection was easily bypassed when attempting to exploit real vulnerabilities in other plugins.

Once again in our monitoring of the WordPress.org Support Forum to keep track of information vulnerabilities in WordPress plugins for our Plugin Vulnerabilities service we ran across a Wordfence employee admitting that the plugin doesn’t do what they claim. This time it had the added element that even while admitting to that, they were still claiming a level of protection that is contradicted by what they were responding to.

The Wordfence employee wrote this:

Sorry we didn’t get back to you sooner! Unfortunately, there are many attack vectors associated with WordPress sites that lie outside of your WordPress installation like insecure servers, insecure passwords, encryption flaws, shared hosting, and many others; all these things combined make your site vulnerable to attacks. Wordfence helps protect and secure the WordPress installation side of your site and it does quite an excellent job at that. No security plugin can help protect your site against every vulnerability that lives there out in the wild, we can only help mitigate the risks associated with a vast majority of them. I recommend taking some time to go through these articles that will help you better understand WordPress security and how you can make your site invincible against all the attack methods that are associated with WordPress sites.

One of the problems with that is that the failure of Wordfence Security in this instance related to the WordPress installation:

I found this morning that someone from India logged into my WordPress admin panel on Jan. 11th using by login.
I am surprised that Wordfence did not stop this since it had been blocking the ip address range this login occurred from.

That seems like something it should have been able to protect against if it truly “does quite an excellent job at” security of the “WordPress installation side of your site”.

Something else that stood out in the Wordfence employee’s statement is this:

go through these articles that will help you better understand WordPress security and how you can make your site invincible against all the attack methods that are associated with WordPress sites

Below that were links to several pages on Wordfence’s website. Nobody that knows and or cares much about WordPress security would possibly make a claim of invincibility like that, but Wordfence seems to have no qualms about telling lies to public to promote themselves. That unfortunately comes at the expense of the security of websites since people are being mislead about the security Wordfence can provide versus other solutions like our Plugin Vulnerabilities service, which provides real protection that Wordfence doesn’t provide, and our service helps to actually make the WordPress ecosystem more secure even for those not using it.

Unlike Wordfence, We Fully Guarantee Our Hack Cleanups of WordPress Websites

One of the things that we often get asked about when it comes to hack cleanups, is how long we guarantee them. The answer is quite simple, if the issue comes back that means that we didn’t do something right and we wouldn’t charge anything additional to get it properly resolved. We would think that would be true of any upstanding company, but clearly most of the web security industry doesn’t feel that way, as we recently noticed with Wordfence.

When we discuss cleaning up hacked websites on our blog we don’t say that you should hire us, but that should hire someone that does things properly. That isn’t the case with Wordfence, which probably tells you a lot about them, as we saw recently with a blog post they wrote:

The most reliable way to recover if your website is hacked is to use our site cleaning service. Our team of experts will clean your site and get it back online as quickly as possible, and the service includes a detailed report and a 90-day guarantee.

What also stood out was there was their 90-day guarantee.

Looking at the page for that service, the backing they offer for their service is even more limited, as they say:

Work guaranteed for 90 days from service only if post-service recommendations are followed.

Who knows what those recommendations are, but that sounds like a way for them to weasel out of making things right if things went wrong.

There is another problem with a guarantee like this, based on what we have seen in often being brought in re-clean up hacked websites after someone else didn’t do it properly. Often times people haven’t realized that the issue hasn’t been properly fixed until after 90 days. When we are contacted about re-cleaning a website we always suggest that people go back to the people that originally did the cleanup and get them to do it right (even though if the previous company does that, it means less money for us), since if it was us, we would want to make things right . But with Wordfence if you noticed the issue outside of 90 days, you would be stuck paying them again if you did that (or needing to hire someone else to do it again).

Something else about how they promote their service really needs to be noted:

As the creators of the most popular WordPress security plugin, we have the most expertise in the industry.

Having the most popular security plugin doesn’t mean that they have the most expertise, it just means they have the most popular plugin. As we have mentioned in the past, the reality is that Wordfence has a scary lack of security knowledge. So how do they have the most popular security plugin? Part of the answer is to just blatantly lie. For example, the second sentence of the description of the plugin on wordpress.org until two weeks ago (and is now in the answer to the FAQ question “How does Wordfence Security protect sites from attackers?”) was this unqualified claim that it will protect your website from being hacked:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

The reality is that a WordPress plugin couldn’t possibly stop websites from being hacked in some ways (which Wordfence is well aware of) and Wordfence actually promotes their paid service as leaving people relying only on their plugin insecure. It seems like a bad idea to trust a company to clean up a hack when they have show that they have no qualms about lying to you and everyone else.

The second most popular plugin indicates that plugin popularity is not necessarily synonymous with a company that you want have anything to do with as that plugin uses a non-existent threat to collect users’ email addresses and had a “One-Click Secure” Button that did nothing except claim the website has been “Secured”.

Another element of Wordfence’s marketing stood out to us as well:

By work with them, they really mean they request a review through the same automated process as you or anyone else can use to do that.

A Better Cleanup

When we do a hack cleanup of a WordPress website not only do we do it properly, which based on some of stuff we have seen from Wordfence seems less likely. But we also include a free lifetime subscription to Plugin Vulnerabilities service, which will warn you if any of the plugins you use have disclosed vulnerabilities (with Wordfence you get widely inaccurate data on plugin vulnerabilities). We will also review all of your installed plugins for serious vulnerabilities using the same technique that we have used to catch numerous serious vulnerabilities in other plugins.

Wordfence Employee Admits the Company Knows Wordfence Security Won’t Stop All Hacks as They Continue To Claim Otherwise

What we have been noticing more and more is how much lying is done by the security industry. Considering that trust is an important part of security and you often have to rely on their claims about what protection their products and services might provide, that is a big issue.

One glaring example of this when it comes to WordPress related security, is a prominent claim made about the most popular security plugin, Wordfence Security. The second sentence of the description on its page on wordpress.org is:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

Could a WordPress security plugin stop some hacks? Sure. Can it stop all them, as this unqualified statement by the makers of the plugin would lead to you believe? No.

People do believe that claim though, as we were recently reminded by a topic on the WordPress Support Forum that we ran across while doing monitoring for our Plugin Vulnerabilities service. The topic is titled “Hacked anyway!” and the message reads:

Well.
I installed Wordfence, and got hacked anyway.
Not sure whether or not to trust it anymore.
A defacement hack by the look of it.
Yet, when I run a full scan, it tells me all is OK.
WTF?
Any suggetions?

The reply from a Wordfence employee reads in part:

Often when we see sites get hacked despite having Wordfence, or we see them getting hacked repeatedly it’s because of a vulnerability on the server.

So they know how they promote the plugin isn’t accurate, but they continue to market it that way anyway. This is far from the only lie that we have seen from the company behind Wordfence Security. We wonder if and when the public will realize that the company behind it isn’t trustworthy?

The other thing worth noting about this situation is that it is also a reminder that Wordfence Security isn’t all that great at detecting that websites are hacked, which is also contrary to what people have been lead to believe. If it was better at that, someone could try to make an argument that while the plugin can’t stop a number of types of hack, it could provide effective mitigation against the damage caused by those hacks.

If Wordfence Security Doesn’t Find Any Malicious Files on Your Website It Doesn’t Mean That It Isn’t Hacked

When it comes to WordPress security plugins, one is by far the most popular. That plugin being Wordfence Security, which has over 2+ million active installs according to wordpress.org (the next most popular one has 800,00+ active installs). At least some of its popularity is based on people believing that the plugins is much more capable than it really is.

Some of that belief is based on the company behind the plugins simply lying about its capabilities. For example, here is the second sentence of their description of the plugin on wordpress.org:

Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

Would it be possible for the plugin to stop some hacks? Sure, but it can’t possibly stop all hacks. For example, if the website is hacked through a compromise of the FTP login details or a server level breach, that is occurring below the level the plugin is operating, so it can’t stop that. While a security plugin could try to detect a change made by that hack, the hacker would also likely have the ability to remove, disable, or modify the plugin with the access they have as well. It isn’t hard to understand why Wordfence would lie about this, since people will believe it and other false claims they make.

Even in situations where the plugin might be able to provide protection, unless you are paying for their premium service, they will leave you vulnerable for 30 days or more after they add protection (their ability to do that would require them knowing about the vulnerability, which isn’t a given), so Wordfence knows that a blanket claim that the plugin will stop you from being hacked isn’t true.

The claims being made don’t always come from the makers of Wordfence. For example, last year we noted an instance when someone posted on the wordpress.org support forum looking for help with hacked website they were told by two people that Wordfence Security would fix it, despite the person looking for help having already said that they had tried to use it to fix the website.

The latest incident of a belief that Wordfence Security is more capable than it really is, involved someone who came to us looking for advice on a claim from their web host that their website had been hacked. They believed that their web host’s claim was false in part because Wordfence Security couldn’t find any malicious files on the website.

Our experience from people presenting us results from numerous different automated tools for detecting malicious code over the years, is that they miss a lot of malicious code and can produce some bad false positives. So you can’t rely on them to determine that a website isn’t hacked. Due to the false positives you can’t totally trust them to determine that a website is hacked, though we would have more confidence of a claim that a website is hacked than it isn’t based on their results.

In this case what the website’s owner hadn’t done was to ask the web host for evidence to back up their claim that the website was hacked. Instead of looking to Wordfence Security or another plugin/service to try to determine if a website is hacked in this type of situation that should be the first thing done. Once you have that evidence, if you are unable to determine if the evidence backs up the claim we would recommend that you get a second opinion from a company that deals with hacked websites. We are always happy to do that for free and we would hope that other would as well.

When we were sent one of the files from the website, we not only immediately recognized it contained malicious code, but it was something that would have been picked by our partially automated scanning for malicious code (a human reviews all the results this scanning produces to determine if the code is actually malicious code). So the website was actually hacked and Wordfence Security had just missed malicious files, despite containing fairly common malicious code.

Since Wordfence Security couldn’t even detect the malicious code, it also wouldn’t have been able to clean it up, a further reminder that Wordfence Security’s ability to clean up hacked websites is also limited.

Wordfence Pushes Their Less Effective Products and Services Over Doing a Security Basic

From dealing with a lot of hacked website we see the damage the security industry often causes. One of the problems we have run into over and over is that people are not interested in doing the basics of security and instead trying to rely on security products and services to protect them. Doing that has leads to website being hacked that shouldn’t, that even includes the website of a security company. It isn’t hard to understand why this happens since these security products and services are often promoted as being a magical bullet, while in reality some are somewhat useful and others are of little use to no use.

In some cases security companies are explicitly promoting using their products instead of doing the basics even when they would have provided better results. Case in point a post by the WordPress focused security company Wordfence today.

They claim that websites are being infected with a particular malware through two vectors:

So far the Wordfence Security Services Team has seen two infection vectors (methods of infection). The first is websites that are infected because they left the searchreplacedb2.php script lying around. This is a relatively uncommon infection vector. We wrote about this risk a few weeks ago.

The second vector is by far the most common. The attackers are exploiting a vulnerability in the WordPress ‘Newspaper’ theme. This vulnerability allows them to inject malicious code into the WordPress ‘wp_options’ table which then redirects your traffic to malicious websites or ad campaigns. Our Security Services Team has seen several other themes that are based on the Newspaper WordPress theme that suffer from the same vulnerability.

What isn’t noted in their post is that according to discoverer of the vulnerability in the theme, the vulnerability was fixed four days after the developer was notified and the fix was put on in April of last year. Why not note that, well one reason might be the next paragraph in their post:

Wordfence released a Premium firewall rule about 40 days ago which prevents these attackers from exploiting the Newspaper theme. Even if you had a vulnerable theme, you would have been protected. About 10 days ago, that rule became available to our free customers too.

So simply keeping the theme up to date would have protected those using it long before Wordfence ever got around to protecting against the vulnerability. Wordfence didn’t mention the importance of keeping software updated in those parts of the post, but surely they would do that in a section “What to Do To Protect Yourself” since updating the theme would in fact be the best protection against the vulnerability in the older version from being exploited. It turns otu that isn’t the case:

What to Do To Protect Yourself

As always we recommend running Wordfence Premium. In this case, our Premium customers have been protected for over 40 days from TrafficTrade by a Premium firewall rule that was deployed by our team in real-time.

The firewall rule became available to our free community users about 10 days ago. Both Wordfence free and Premium are now protecting your sites from these attacks.

Because this infection is so wide-spread, we have released additional detection in the Wordfence malware scan to detect a newer variant of TrafficTrade. We are seeing attackers modify your wp_options table to inject the malicious code into that table. A Wordfence scan will now detect this.

This new feature is immediately available for free and Premium Wordfence customerswith Wordfence version 6.3.16 which was released this morning. Simply install Wordfence or update to 6.3.16 and run a scan.

We mentioned earlier that security companies promote their products as being magic bullets, Wordfence is a perfect example. They promote their plugin with the blanket claim that its “Web Application Firewall stops you from getting hacked” despite the obvious counter example here that they only started protecting against the theme vulnerability more than a year after it was disclosed.

Unreliable Claim That 1.5 Million WordPress Pages Defaced Is Reminder of the Terribleness of Security Companies/Journalists

In the last day there have been quite a few security journalists writing articles claiming that 1.5 million pages on WordPress websites have been defaced due to a vulnerability that existed in WordPress 4.7.0 and 4.7.1. In looking over those articles we have found that in some cases the claim isn’t actually sourced at all and what appears be the original source for the figure in the others, which came from a security company, isn’t reliable at all and that the journalists ignored a huge red flag that should have warned them that the claimed figure and the source of should not have been relied on.

First let’s look at a couple of the articles with unsourced claims. The Inquirer’s article is titled “WordPress hacking spree sees 1.5 million web pages defaced“; nowhere in the article is a citation for that claim provided. The closest the article gets is this:

According to a report on the BBCthere are millions of pages that have already been defaced thanks to the vulnerability.

In that BBC article the claim is not sourced either:

One estimate suggests more than 1.5 million pages on blogs have been defaced.

In ITworld’s article “Recent WordPress vulnerability used to deface 1.5 million pages” you get a source, but no explanation as to how the number was calculated, which seems like important information to provide:

Since then the number of defaced pages has grown to over 1.5 million and there are 20 different attack signatures, according to statistics from Feedjit, the company behind the Wordfence security plug-in for WordPress. The number of unique affected websites is estimated at around 40,000, as a site can have multiple defaced pages.

Also worth noting here is that there is an estimate of the number of websites impacted, which seems to be the more relevant number to be the headline number, assuming either was accurate. We don’t think there is much question as to why they went with the pages number, with the current state of security journalism click-baitness is more important than providing high quality reporting.

The Bleeping Computer’s article, “Attacks on WordPress Sites Intensify as Hackers Deface Over 1.5 Million Pages” cites nearly identical numbers as to the number of pages and websites:

Attacks on WordPress sites using a vulnerability in the REST API, patched in WordPress version 4.7.2, have intensified over the past two days, as attackers have now defaced over 1.5 million pages, spread across 39,000 unique domains.

It also looks like they are citing Wordfence for their number of web pages defaced as well:

The number grew to over 100,000 pages the next day, but according to a report from fellow web security firm WordFence, these numbers have skyrocketed today to over 1.5 million pages, as there are now 20 hacking groups involved in a defacement turf war.

When you look at Wordfence’s post the claim of 1.5 million pages is based on Google’s estimate of how many pages contain certain “hacked by” phrases:

On the far right we also include the number of defaced pages for each campaign, according to this morning’s Google results.

Are those reliable? The answer seems to be no. Here is how a BBC article from 2012, “Are search engine result figures accurate?“, starts out:

Enter the name Tim Harford into Google and you get 835,000 results.

Or 325,000, or 285,000… I got these widely differing results on computers within metres of each other in the same office at the same time.

So using those as headline number and not disclosing that it is the source (along with a disclaimer as to the questionable accuracy) seems quite inappropriate. It gets worse though, because in Wordfence’s post they take this misleading number and stretch in even further. In their chart they labeled the 1.5 million page estimate as being the number of “Hacked Sites”, not web pages:

That seems like the sort of thing that should have warned journalists away from that, but security journalists don’t seem to care much for accuracy.

The 39,000 unique domains or around 40,000 websites figure also looks to come from the same chart. The problem that appears to be a measure of websites where Wordfence saw an attempt to exploit this on, not the number of websites hacked:

Considering that any WordPress websites running 4.7.1 when 4.7.2 was released would have been automatically updated to 4.7.2 and protected against the exploit long before the attacks started, unless the automatic updates feature wasn’t working on the website (which we don’t see being the case with many websites) or it was disabled (which people sometimes foolishly do), the number of attacks that could have been successful was probably a small portion of the 39,000 attacked.

Unfortunately what has happened here with these inaccurate claims of the size of exploitation are all too common these days due to the poor state of security companies and security journalists.

Wordfence Spreads Falsehood on Database Prefix Security Hardening to Push Their Plugin

In the past we have written about how the WordPress focused security company Wordfence is making up threats in an effort to promote their plugin (and therefore their paid service). We have received pushback on that, some of which can be summed in that even if Wordfence isn’t telling the truth, their plugin might provide protection against what is really going on. Or as one of the comments reads less gracefully:

To the layperson, they don’t give a crap if it’s a dictionary attack or a brute force attack. An attack is an attack is an attack. If they happen to have some passwords in that dictionary and wordfence does stop it, is there not value in that?

That might be a reasonable argument if Wordfence was just telling people to use their plugin in addition to taking other steps. Ignoring the fact that their plugin has actually introduced additional vulnerabilities on websites due to the vulnerabilities that have existed in it, taking an extra step shouldn’t hurt the websites security, so it wouldn’t be that big of an issue.

The problem with that is that Wordfence intent in making these claims is pretty clearly to promote their plugin instead of actually promoting better security. A recent post of theirs shows this, as they make the claim that a common security hardening step of WordPress provides no protection and then quickly turn to promoting their plugin as an alternative. The truth though is they are wrong about this, probably because of their lack of security knowledge, which would be a good reason for them not to be handing out this type advice in the first place (or using it to promote their plugin).

No Protection

In the post on December 28 blog post, titled “WordPress Table Prefix: Changing It Does Nothing to Improve Security“, Wordfence claims (emphasis theirs):

Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security.

A little later they state this (emphasis theirs):

An idea became popular a few years ago that went something like this: If an attacker has access to your database via SQL injection, you can prevent them from accessing your data by renaming your tables to some unique prefix.

What Wordfence seems to have missed entirely is that a SQL injection isn’t the only way an attacker can get access to a database, which we will come back to in a bit.

Past their details that are supposed to back their claim up you get to real reason for the post, to promote their plugin:

Changing the WordPress Database Table Prefix is ‘Security Theater’

Changing the WordPress table prefix is what we refer to in the industry as ‘security theater’. In other words, it is busy-work that makes you feel more secure but does nothing to make you more secure. It only adds risk and complexity.

We have another cool sounding phrase that describes this: ‘Security through obscurity’. What this means is that you’re trying to secure yourself by making things harder for an attacker to find. In the security industry this is widely accepted as a pointless exercise.

Things that do actually make you more secure against attacks are a WordPress Firewall, like the one included free with Wordfence. This actually blocks SQL injection attacks before an attacker can gain access to your database.

The Wordfence firewall includes rules to block SQL injection attacks. It even includes a sophisticated SQL parsing engine that understands SQL the same way a database does. When we see incoming SQL, we intelligently parse it to determine if the intent is malicious or not. If it’s a SQL injection attack, we block it. If we detect it’s a site user or administrator doing something safe like posting a blog post, we allow it through.

(The claim made there that “Security through obscurity” “is widely accepted as a pointless exercise” in the “security industry” is not actually true, as a quick look through the results a Internet search for the term would show, but as usual it looks like Wordfence doesn’t know what they are talking about.)

Wordfence’s Firewall is a Defective Hammer

There is common saying, of which one variation is “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” The problem with that is not everything is a nail. Even when something is a nail, if your hammer is defective, it won’t necessarily be able to hammer the nail. Wordfence pretty clearly sees their firewall as a hammer and ignores the fact that it is often not effective.

We have done six tests of Wordfence’s plugin against real vulnerabilities in other plugins over at our Plugin Vulnerabilities service (four of them done as part of testing multiple security plugins). The results for their plugin and therefore its firewall haven’t been good. In four of them no protection was provided. In the other two the protection was easily bypassed. It turns out that Wordfence is actually aware to at least to a certain of the limitations of their firewall, but instead of being realistic about it, they spin the issue, apparently hoping (so far correctly) that they can get away with that.

Wordfence’s plugin isn’t an outlier, as in the four tests that involved multiple security plugins only one of them provide non-bypassable protection in one test and that came the tradeoff that Editor-level and below users wouldn’t be able to upload media. The obvious take away from that testing is that security plugins don’t provide much protection. Another take away we have had from that testing that is relevant here.

In a test of a vulnerability that allowed a file included with an attackers request to be uploaded to the website, we found that Wordfence prevented exploitation in our basic test. That was due to Wordfence seeing that a file being sent with the request had a PHP extension. That was easily bypassed though because one of the other items sent with the request was the name you wanted the file being uploaded to be saved as. So for example, you could upload the file as “malicious.txt” instead “malicious.php” and then specify the file be named “malicious.php” when saved to the file system. Wordfence wouldn’t stop the request without the PHP extension, but the file would still have a PHP extension after being uploaded on the website due to the name specified. Our take away from that is that vulnerabilities don’t always play nicely with assumptions made by security products.

Updating the Database

Recently for our Plugin Vulnerabilities service we were reviewing a report of a SQL injection vulnerability in the plugin ZX_CSV Upload, which allows “simple upload & update data from CSV to DB plugins”. The report noted that you had to be logged in as an Administrator to exploit. Seeing as an Administrator can normally do almost anything, they would normally have the ability to do the equivalent of SQL injection. So there wouldn’t really be a security vulnerability there unless this could be used to do something malicious using cross-site request forgery (CSRF). CSRF involves causing someone to take an action they didn’t intend. When we went to look to see if that was the case with this plugin we noticed a more obvious issues, the intended functionality of the plugin was susceptible to CSRF.

In practical terms this vulnerability could be used to update the database to add a new Administrator user controlled by an attacker, if they could get a logged in Administrator to access a page they control.

In our post on the issue we noted:

You would need to know what the prefix for the database is, so changing that would actually come in to play with a vulnerability (which it rarely does despite the big deal made about changing it in various security plugins and tutorials).

That post was put out on December 19, so if Wordfence was following sources putting out good information they could have avoided their false claim changing the database prefix “does absolutely nothing to enhance your site security”.

Making this even worse in our testing Wordfence’s plugin (and therefore firewall) doesn’t protect against exploitation of this vulnerability, while changing the prefix actually could.

It is worth noting that this plugin only had 10+ installs, so any exploitation of it is unlikely, but another vulnerability could open a similar possibility on a wider scale. Wordfence assumed incorrectly that the only time that the prefix comes in to play is with SQL injection, which this vulnerability makes clear isn’t the case.

Guessing the Prefix

If the database prefix hasn’t been changed the only limitation to exploiting it on a website using the plugin would be getting a logged in Administrator to access a page you control, which isn’t necessarily easy (at this point we don’t see any evidence of any wide scale attempt to exploit vulnerabilities that require getting that to happen, so you would only likely to be at risk in a targeted attack). But what if the prefix had been changed, you would need to make enough requests to guess the right one as well. So how many possibilities would there be?

MySQL database table names (and therefore the prefix) permit the following characters “0-9”, “a-z” , “A-Z”, “$”, “_”.  Depending on the operating system the table name will or won’t be case sensitive. For our purposes then let’s assume that the prefix is all lower case and the dollar sign isn’t used.

If you only letters are used you have the following number of combinations depending on prefix length:

  • 1 character prefix: 26 combinations
  • 2: 676
  • 3: 17,576
  • 4: 456,976
  • 5: 11,881,376
  • 6: 308,915,776
  • 7: 8,031,810,176

If you also include numbers you have the following number of combinations:

  • 1 character prefix: 36 combinations
  • 2: 1,296
  • 3: 46,656
  • 4: 1,679,616
  • 5: 60,466,176
  • 6: 2,176,782,336
  • 7: 78,364,164,096

The chances that you could cause the logged in Administrator’s web browser make enough completed requests to be successful in guessing the right prefix seems would depend on the prefix length. Maybe it could work with a short one, but once you are talking about the possibility of billions requests per table you are updating, the websites likely couldn’t handle the load if the computer and the network between them could before the user closed the web page causing the request to be sent.

So how long does a WordPress security plugin make it when changing it? The iThemes Security plugin, which has 800,000+ active installs according to wordpress.org, created one for us that was 7 characters and included numbers when we tried it features to change it, “ej952ng”.

Layered Security

Based on that, changing the database prefix has the possibility of being useful additional security step for a website at risk of targeted hacking as part of a layered approach to security (whether emphasizing that that type of action while even security companies, including Wordfence, are failing to do more basic security measures is its own issue).

So does Wordfence not believe in layered security? Actually they do, but when it involves it is a chance to push their plugin with a made up claim:

On some sites it’s a disaster if they’re compromised. The data theft can never be undone even if they recover from a hack. They want to employ every measure they can to be secure – and in our industry that’s a standard approach: We refer to it as a layered approach to security.

On others sites, it’s just a case of restoring from backups if you get hacked and moving on.

That is why we offer options like these that are configurable.

Wordfence and Security Concern Trolling

When it comes to the security of WordPress websites one of the impediments to improving it is that security industry likes to make up threats and then claim they will protect against them, which makes it harder to get people to focus on things that would actually improve security of their websites.

One example of this that was fairly popular for a while was to claim that WordPress listing what version of WordPress was in use in the HTML code of the website was a security risk and that they had a solution. It didn’t really make any sense for a number of reasons.

First, if the developers of software were really doing something that intentionally puts you at risk, the solution seems like it should be to use different software not try to undo them putting you at risk.

Second, hackers usually wouldn’t bother checking if a website was running WordPress, much less what version was in use, before trying to exploit a vulnerability. So if you were using an outdated version of WordPress with a vulnerability that could be exploited (we haven’t have seen a vulnerability in WordPress be the cause of a large scale hacking for maybe a decade at this point), no matter how hard you tried to hide the version it wouldn’t impact whether the vulnerability would get exploited. The real way to prevent the exploitation would be to keep WordPress up to date.

Third, if a hacker wanted to know what version of WordPress was in use, then hiding the listing of version number wasn’t actual effective at the time as they could simply check for changes in JavaScript or CSS files to determine the version in use. That wasn’t a secret, but either the people promoting this either never bothered to a search to see it had been pointed out or they ignored it.

A Strong Password Is The Real Solution

The latest example of this type of thing involves a new feature introduced in WordPress 4.7, which was release earlier this month. The REST API added in this version provides “machine-readable external access to your WordPress site with a clear, standards-driven interface”.

Cue that being claimed to be a security issue, in particular the user portion of it, which the plugin Wordfence Security, used on 1+ million websites according to wordpress.org, started blocking access to shortly after. In a discussion on that the WordPress.org Tech Guy, who we have had a bit of interaction in dealing with WordPress on vulnerabilities in WordPress plugins, he responded to it this way:

Why do people still think this a real issue? Your Twitter username is exposed to everybody. Is that a real problem?

What really happened here is that WordFence added code to break the API. Simple as that. Usernames are not private information, in any sane system. Use good passwords. Then it doesn’t make any difference what your username is.

My username on my site is “otto”. Best of luck to ya.

That all sounds reasonable and he expanded on that in a follow-up response.

Here is part of the response from Wordfence:

Security is all we do. The WordPress.org core team and contributors have a different focus and a different world-view. Many of our team spend all day fixing hacked WordPress sites and working directly with traumatized customers who are incredibly stressed because their business has stalled and their data has been stolen.

We don’t arbitrarily implement features. Our design decisions are based on thousands of hours of human experience working with hacked sites, looking at attack data and understanding the wide variety of our customer’s needs.

While they claim they don’t “arbitrarily implement features” and “decisions are based on thousands of hours of human experience working with hacked sites”, no where in their response do they even make a claim that the feature would likely lead to websites being hacked. There is a good reason for that, it wouldn’t.

In the post announcing the feature they do give a reason for doing it, but it is even worse than none:

This can be exploited by bots that are launching brute-force password guessing attacks on WordPress websites. They can use this API to list the usernames of anyone who has published a post on a WordPress site. The list of users displayed via this API almost always includes a user with admin level access.

Despite Wordfence repeatedly pushing the idea that brute force attacks against WordPress admin passwords are happening (and that their plugin is the solution), they simply are not happening. At best Wordfence doesn’t understand what is actually going, which are dictionary attacks, not brute force attacks. Those involve a hacker trying to log in using common password and there is a really simple way to protect against them, use a strong password. It doesn’t matter if someone has your username, those attacks will fail as long as you use a strong password. If Wordfence told the truth about what is happening it would also remove a reason to use their plugin, which might also explain why they keeping pushing that falsehood.

WordPress does a good job on helping people to use a strong password. When setting up WordPress it will pre-populate a strong password for you:

Let’s say you decide to use a weak password instead. Not only will the password strength indicator tell you it is “Very weak”, but you will need to check a box to “Confirm use of weak password”:

About the only other thing they could do in terms of make sure a strong password is used is making its usage mandatory, which has some downsides.

Wordfence Lack of Concern For a Real Source of Hacked Websites

Going back to Wordfence’s explanation for creating an issue where there isn’t one, it read in part:

Security is all we do. The WordPress.org core team and contributors have a different focus and a different world-view. Many of our team spend all day fixing hacked WordPress sites and working directly with traumatized customers who are incredibly stressed because their business has stalled and their data has been stolen.

At the same time it turns out they are actually okay with people using their plugin being hacked. Before we get to that let’s look at how their plugin is described on the Plugin Directory:

Secure your website with Wordfence. Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

and

Wordfence Security is 100% free and open source. We also offer a Premium API key that gives you Premium Support, Country Blocking, Scheduled Scans, Password Auditing and we even check if your website IP address is being used to Spamvertize.

So it is free and will stop you from being hacked right? Well not always.

On November 20 the security company NinTechNet, makers of the security plugin NinjaFirewall, were cleaning up a hacked website and discovered that the source of the hacking was a arbitrary file upload vulnerability in the plugin Delete All Comments, which recently had 30,000+ active installs according to wordpress.org. They contacted the developer and didn’t receive a response, they later notified the Plugin Directory and it was removed. On December 10, they disclosed the issue publicly.

On December 11 it was added to a public database of WordPress vulnerabilities, the WPScan Vulnerability Database. On December 12 it was added to the free data that comes with the companion plugin for our Plugin Vulnerabilities service.

Also on December 12 we saw the first interest in the plugin by hackers with the data we monitor for Plugin Vulnerabilities service, which probably also indicates that widespread exploitation would have begun then as well.

On December 16 we did a test to see if security plugin could prevent exploitation of these over at our Plugin Vulnerabilities service. Seeing as the vulnerability had not been fixed (and still hasn’t), so keeping your plugins up to date would not protect you, this is situation where a security plugin could provide some. Unfortunately none of the 15 plugins we tested prevented the vulnerability from being exploited.

One of the plugins tested was Wordfence, so here is a situation where websites are being hacked, the plugin didn’t stop it from happening and you have people that are going to be, to use Wordfence phrasing, “traumatized customers who are incredibly stressed because their business has stalled and their data has been stolen”.

Only on December 16 did Wordfence take any action on this:

We developed a firewall rule for that exploit and released it into production on December 16th, the moment we heard about it from our users.

And only because their users notified them. And it turns out that was only because of us:

In the case of the vulnerability above, we heard about it because you were making some noise about it. Our users alerted us.

That is quite a poor response, when you consider that simply monitoring one of two publicly available sources of information of vulnerabilities could have lead to a response days sooner, instead of relying on their users to do it for their work for them. But at least people using the plugin are safe now, right? Wrong.

Instead only websites using their paid service will get protected for a month:

The rule is now in production for Wordfence Premium. It will only be available in the free Threat Defense Feed 30 days after release, so around Jan 15th.

So everyone else will be open to being hacked for a month, with a vulnerability that Wordfence knows is already being exploited, since that was how it was discovered.

While leaving people using their plugin vulnerable to be exploited is bad for them, it could actually pay off for Wordfence since they also do hack cleanups.

Even the people with the paid service are getting poor service, as Wordfence wasn’t proactive in protecting them, instead relying on users to let them know of the issue, after the exploitation looks to have taken off. What is particularly striking about that is they market their paid service very differently. In promoting the Real-Time Threat Defense Feed that is part of that, they say:

Wordfence protects over 1 million WordPress websites, giving us unmatched access to information about how hackers compromise sites

The unmatched access could actually be outmatched by simply monitoring public sources. It isn’t just this vulnerability, through our Plugin Vulnerabilities service we repeatedly found apparent zero-day vulnerabilities, which are vulnerabilities being exploited before the developer is aware of them, in WordPress plugins and every indication is that Wordfence was not aware of them (that also makes you wonder about their claim that they have “thousands of hours of human experience working with hacked sites, looking at attack data”). In some cases it looks like hackers were exploiting those vulnerabilities for more than a year before we had started monitoring the data that helped us to identify them and take further action.

Wordfence Should Stop Misleading The Public

If Wordfence wants to leave people relying on their plugin vulnerable like they have with the vulnerability in Delete All Comments, they have a right to do that, but they should be honest with people about what is going on and not say things like that they put the community first, when the actually put profits before them.

It would also be good if they stop making up threats as well.

Wordfence Continues To Peddle False Claim of Brute Force Attacks To Push Plugin That Doesn’t Protect Against Real Threat

When it comes to improving security of websites one of the problems we see is that real issues do not receive the attention they should, while other issues, that are of little to no concern, do get attention. Often times it is security companies that play an important role in this happening, when they should be helping to push against this.

When it comes the security of WordPress websites one of the big problems that exists is that vulnerabilities in plugins that are being exploited do not always get fixed in a timely manner or in some cases ever. A recent example of that comes with an arbitrary file upload vulnerability that exist in the most recent version in the plugin Delete All Comments. Through that vulnerability a hacker could upload files of their choosing and then do almost anything they want with the website. The security company NinTechNet spotted the vulnerability while cleaning up a website was hacked through it on November 20. They notified the developer, but received no response from them (one possible explanation for the vulnerability being in the plugin is that it was actually intentional put in the plugin, though it could just as easily be unintentional).

NinTechNet then notified the Plugin Directory and the plugin was removed from that. That prevents anyone not using the plugin already from installing and making themselves vulnerable, but what happens for the 30,000+ websites that already were using it according to wordpress.org? Nothing. The people running those websites are left unaware that their website is open to be exploited. Amazingly this isn’t because no one had brought up this issue. We raised it back in March of 2012. Shortly after that we proposed on the Ideas section of the WordPress website that people be alerted people when their websites are using plugins that have been removed from the Plugin Directory and providing at least general reason why it was removed. Shortly afterwords it was marked as “Good idea! We’re working on it” and it was stated that it was being worked on. By six months ago the same person said:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

Strangely the idea is still marked as “Good idea! We’re working on it”, which keeps it from being listed on prominently on front page of Ideas section (where it would be tied for the second most popular idea that hasn’t been greenlit and where more people would see that the issue is being left unaddressed).

There is another option, the Plugin Directory can put out a fixed version when the developers doesn’t do that, but they rarely do that, don’t seem to have provided any sort of public criteria on when they would do that, and someone on the WordPress side even deleted a comment we made in regards to the issue at one point.

In the meantime if you install the companion plugin for our Plugin Vulnerabilities service you get warned in situation like this as we include information on vulnerabilities that looked to be being exploited to the free data included with that (last week we also added data on vulnerabilities that look to being exploited in the current version of a plugin with 40,000+ installs and another with 20,000+ active installs).

If these got more public attention we have hard time believing that WordPress would continue to leave people vulnerable, but that is the situation we and everyone else is dealing with until such time.

If you are thinking that a security plugin would protect against this type of thing, think again. We tested the ability of 15 security plugins to prevent exploitation of the vulnerability in Delete All Comments last week and found that none of them stopped it.

One of those plugins that didn’t stop it was Wordfence, a plugin with 1+ million active installs, which is describe on the its main page on the Plugin Directory thusly:

Secure your website with Wordfence. Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

That unqualified claim is that it stops from you getting hacked is clearly false as not only that test against the vulnerability in Delete All Comments shows. In three other tests we have done, in either Wordfence provided no protection or the protection was easily bypassed. It is also worth noting that from everything we have seen Wordfence’s Threat Defense Feed misses many plugin vulnerabilities.

So how do you get over 1 million installations of plugin that doesn’t actually do what it claims to do. Well what appears to be an important role in that is that Wordfence simply makes up threats and then claims to protect against them.

Brute Force Attacks Are Not Happening

Take for instance last Friday when they put out a post “Huge Increase in Brute Force Attacks in December and What to Do“, which claimed:

At Wordfence we constantly monitor the WordPress attack landscape in real-time. Three weeks ago, on November 24th, we started seeing a rise in brute force attacks. As a reminder, a brute force attack is one that tries to guess your username and password to sign into your WordPress website.

Of course they have the solution for this:

If you install the free version of Wordfence, you are automatically protected against brute force attacks. It’s that simple. We also automatically block the worst offenders completely, and we share some information below on who those are.

There is just one problem with all of that, brute force attacks against WordPress admin logins are not actually happening. Back when we originally discussed the fact that security companies are falsely telling people brute force attacks are happening in August we used as an example from Wordfence in January, so Wordfence has been using this falsehood to push their product for some time.

We wrote in that post:

To understand how you can tell that these brute force attacks are not happening, it helps to start by looking at what a brute force attack involves. A brute force attack does not refer to just any malicious login attempt, it involves trying to login by trying all possible passwords until the correct one is found, hence the “brute force” portion of the name. To give you an idea how many login attempts that would take, let’s use the example of a password made up of numbers and letters (upper case and lower case), but no special characters. Below are the number of possible passwords with passwords of various lengths:

  • 6 characters long: Over 56 billion possible combinations (or exactly 56,800,235,584)
  • 8 characters long: Over 218 trillion possible combinations (218,340,105,584,896)
  • 10 characters long: Over 839 quadrillion possible combinations  (839,299,365,868,340,224)
  • 12 characters long: Over 3 sextillion possible combinations  (3,226,266,762,397,899,821,056)

The chart of login attempts in Wordfence post from last week show only millions of login attempts per day:

It would take a long time for that to get to the amount needed for a brute force attack, but wait, those are not against one website, those are across hundreds of thousands of websites:

So we are talking about an average of 10s of attempts per website, which is never going to amount to a brute force attack.

So what is actually going on? Well based on the number of attempts and by looking at what username/password combinations were used in actual malicious login attempts it looks like most of these are actually dictionary attacks. A dictionary attack involves trying to log in using common passwords.

Knowing what type of attack is important because how you prevent them and the level concern you should have is very different for different types. With what is actually happening, dictionary attacks, all you need to protect yourself is to use a strong password, otherwise you can simply ignore this.

That might explain why Wordfence is misleading people, if they told people the truth they wouldn’t be a need for them to install their plugin (and then possibly sign up for Wordfence’s paid service). The other possibility, which seems just as likely based on what else we have seen, is Wordfence simply doesn’t have a good understanding of security. That could also explain why they don’t understand why it is inappropriate to make an unqualified claim that their plugin “stops you from getting hacked” when that would that would be able to truly stop any hack is next to impossible.

If you look at the comments on Wordfence’s recent post you can see they have successfully mislead a lot of people into believing their false claim, which makes it even harder to get people to focus on real issues and that means more websites are going to get hacked that should not have.