Year: 2016

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.

Two of The Top Three Reasons SiteLock Promotes For Web Hosts To Partner With Them Are Revenue Related

When it comes to people being taken advantage of by the web security company SiteLock, their web hosting partners seem to play a critical role, as it looks like a lot of their business comes through them instead of people going directly to SiteLock. What seemed to us to be the likely explanation of why the web hosts would partner with SiteLock despite them being quite bad at being a security company and their sales practices, was the web hosts getting paid to push their services.

What was surprising to us when we ran across it is how much money they are getting, one of SiteLock’s web hosting partners, the Endurance International Group, disclosed to investors that they get 55% of the revenue from the SiteLock partnership (it also turns out that the web hosting company is also run by one SiteLock’s majority owners). So people that get pushed to their service end up paying at least twice as much as the service they are really getting costs.

That obviously raises some serious questions about the arrangement, but what seems of more concern is that from what we have seen their web hosting partners don’t disclose the financial arrangement. (What they will sometimes say instead is that SiteLock is a trusted partner, which doesn’t point to the web host being someone you can trust.)

When a web host tells their customer that should hire a certain company to clean up your website, we don’t think it is unreasonable that they should be told the truth about why that recommendation is being made.

With one of the web hosts owned by the Endurance International Group, HostGator, we found that the wouldn’t even acknowledge that they are getting any money out of the partnership when it was pointed out their parent company has already disclosed this fact to investors.

While the web hosts are not upfront about this, when SiteLock is promoting the partnerships program to web host they are. Here is the list of the “Top Three Reasons to Partner with SiteLock” from the page about their program:

The first two items listed are revenue related:

Generated $20
Million in Partner
Revenue

and

Dedicated SecurePartner
Support on Sales and
Marketing Efforts

So that gives a pretty good idea of what these partnerships are really about, if it wasn’t clear already.

What the third one is supposed to refer isn’t entirely clear, SiteLock does refer to itself as the Global Leader in Website Security (which is far from the truth):

Partner with the
Global Leaders Across
the Industry

We think that web hosts getting involved in this is a good sign that you should avoid them (you can check out our list of web hosts who partnered with SiteLock if you want to to that).

If you are unfortunately at the point where your web host is pushing you to SiteLock, you should take a look at our post on what you should know in that situation before doing anything else.

WP Fix It Markets Their WordPress Infection Malware Virus Removal Service With Falsehoods

Of the people that hire us to clean up their hacked website maybe close to half of them bring up the fact that they previously hired someone else to clean up the website and then it got hacked again. While that is not always the previous cleaner’s fault, it appears that a lot of it can be explained by the fact that most companies doing hack cleanups either don’t know what they even should be doing or they are intentionally cutting corners.

The first thing we always ask after the client mentions that someone had previous cleaned things up, is whether they determined how the website was hacked. The answer is almost universally that trying to do that never even came up. That is despite that being one of the three main components of a proper hack cleanup. If you don’t do that then it is entirely possible that the vulnerability may still exist on the website, leaving the website open to being hacked again. If you are lucky after getting a subpar cleanup, the vulnerability might have been fixed without it being determined first or no one tries to exploit the vulnerability again on the website and you don’t get hacked again. If you are less lucky then you quickly end up with a hacked website again.

If you don’t want to have hire multiple companies to finally get your website cleaned you should make the sure company you are hiring in the first place actually does try to determine how the website was hacked and does the other component of a proper cleanup that we see frequently is not done, securing the website, which usually mainly involves getting the software on the website up to date.

Beyond doing that there are plenty of other red flags that a company is probably one you should avoid. To give an example of that, let’s take a look at one company we ran across recently that has service promoted with a lot of red flags. WP Fix It’s WordPress Infection Malware Virus Removal service (http://wpfixit.com/product/malware-virus-removal/). Below we look at a number of those, first quoting from their marketing materials and then discussing why it should be a red flag.

A Security Plugin Won’t Safe Guard Your Website Against Future Attack

Security Enhancements

It is critical that you have security in place at all times. Our Infection Specialist will complete the highest level of protection by installing a tried and trusted security plugin which will safe guard your site against future attacks.

While you can find a multitude of review and recommendations when it comes to WordPress security plugins what you won’t find almost any of is actually testing of these plugins to see if they can actual protect against vulnerabilities. In fact other than the testing we have been doing through our Plugin Vulnerabilities service, we only have found one other instance of someone doing that type of testing. The lack of that is a reminder of the lack of seriousness when it comes to most people claiming to be interested in the security of WordPress.

What isn’t an explanation for the lack of testing is that the plugins provide such great protection that testing to see if they don’t provide protection isn’t needed. Take for example a vulnerability we just tested them against last week. Recently the security NinTechNet discovered that the plugin Delete All Comments had an arbitrary file upload vulnerability, which allows hackers to upload malicious files to website and then do almost anything they want on the website. They discovered that while doing a hack cleanup. Since the vulnerability exists in the current version of the plugin, if they hadn’t determined that, then that website would have remained vulnerable even if the software on the website was brought up to date and would have been open to being hacked again. The plugin recently had 30,000+ active installs according to wordpress.org, so there are lot of websites that are currently vulnerable and this is where a security plugin could be useful. Unfortunately in our testing none of the 15 plugins we tested stop the vulnerability from being exploited.

Through the four tests we have done so far, most of the plugins we have tested have provided no protection whatsoever. Of the few instances where there was some protection, in all but one of them we found that the protection could be easily bypassed. The one time that we didn’t find a bypass there was a major tradeoff to get the protection, only Administrators level users were allowed to upload files. On a lot of websites where there is a single WordPress account that isn’t an issue, but for other websites lower level users are blocked from uploading media files would be an unacceptable limitation.

While WP Fix Its claim doesn’t specify what the plugin they install “will safe guard your site against future attacks” is, one review of their service from September indicates that it is Sucuri Security. In our testing that plugins has not provided any protection, which isn’t really surprising since it doesn’t even look to have any features that would prevent the vast majority of hacks. So you either have a situation where WP Fix It doesn’t have any clue as to whether the plugin can do what they claim or they are lying about what it can do, neither of which seems like something that you would want in someone doing a hack cleanup.

Brute Force Attacks Are Not Happening

Brute Force Attack Prevention

A common attack point on WordPress is to hammer the wp-login.php file over and over until they get in or the server dies. Each tried attempt is a request to the server which slows things down. Our Infection Specialist will guard your site against this.

When it comes to glaringly bad information about WordPress security the false claim that there are a lot of attempts to brute force WordPress admin passwords is probably the most widespread. As we discussed back in August, the evidence provided by security companies actual shows that these attacks are not happening. If you see someone claiming that they are they are, the either don’t understand security or they are lying to you. What does occur in some instances our dictionary attacks, which involve an attacker trying to log in using common passwords. As long as you are using a strong password these are not a threat to you. Unless you are an overloaded server they also shouldn’t cause the server to die or cause a noticeable slowdown.

Security Companies Can’t Speed Up Getting Security Warnings Removed

Blacklist Removal

Some infections may trigger a blacklist of your website online. This means that when people try to visit your site they are warned that the content in harmful and urges them not to proceed. We will take the needed steps to remove all these warnings right away and allow visitors to surf your site without issues.

Getting Google or someone else’s malware or hack warning removed for your website is usually a fully automated process, which is easy to request and which a security company has no control over how long it takes. Where a security company can probably best help out, if they handle a lot of these, is with understanding why the review is taking so long or the odd information being returned during that, as we have found with Google’s warning that “This site may be hacked”. Of course if they mentioned that, they would also be disclosing that the warning doesn’t always get removed “right away” as this company claims and they don’t have any ability to control that timing.

Unrelated Work Isn’t A Sign of Competency

Database Optimization & Cleanup

Your database is the sweet spot of all your saved website content and data. Over time databases can become very bloated storing tons of information that you site does not need anymore. Our Infection Specialist will optimize your entire database.

Optimizing a database has nothing to do with a hack cleanup, even if the small percentage of hacks that involve the hacker making some change to the database, so it is really odd that they would doing that during hack cleanup.

A Low Quality Cleanup

Based on all that it doesn’t look these guys have much security knowledge, so you might wonder how they can actually handle doing a cleanup. The answer it seems is that they are not actually doing much themselves, in one of their blog posts (http://wpfixit.com/remove-a-wordpress-infection/) they include steps to do a cleanup, which at the end they state “We also can do all this for you”, and they state that the actual detection of malicious code is done by the plugin Anti-Malware Security and Brute-Force Firewall. Our experience is that automated detection like this is able to spot some malicious code, but won’t get better hidden stuff, so relying on something like that isn’t going to provide the best cleanup.

Using a Common Password Doesn’t Welcome a Brute Force Attack

When it comes to WordPress security, a frequently falsehood we see out there is that there are a lot attempts to brute force WordPress admin passwords. As we discussed before looking at the supposed evidence of this provide by security companies actually shows they are not happening.

In pointing out instances where the security industry is peddling this falsehood to get the public to use their products or provide them something of value we have repeatedly receive complaints that we are the ones in the wrong about this. For example, on a post how the developer of the plugin Anti-Malware Security and Brute-Force Firewall was using the claim to get people to register and provide them donations we received a comment that reads in part:

Your insistence that “brute force” means a full scale attack of tens of thousands of attempts is completely lost in the wind. You are probably the only person in the universe adhering to that definition.

and

Trying to get an entire industry to adhere to your definition of “brute force” is like urinating into the wind. At one end of the scale, you get wet and look silly. At the other end of the scale, you sound tyrannical.

It is rather strange comment as we are using the standard definition, which we had no hand in creating, so we really don’t know where the idea that we are the only ones using it could come from.

It isn’t hard to see that we are not along in that, if you go to the entry for brute force attack on the WikiPedia you will find that it states:

The attacker systematically checks all possible passwords and passphrases until the correct one is found.

And it also makes clear that dictionary attacks, which are actually happening against WordPress websites (and are best prevented differently then brute force attacks), are different:

When password guessing, this method is very fast when used to check all short passwords, but for longer passwords other methods such as the dictionary attack are used because a brute-force search takes too long.

If someone doesn’t want to believe that either, how about one of the security companies that we previously mentioned as misleading people, iThemes security:

The brute force attack process is often referred to as exhaustive search. An attacker will systematically check unlimited passwords until the correct one is found.

The post where that is mentioned though is good example of the mess that people run into when looking for security information these days. The post is titled “Brute Force Attacks: What They Are & How to Prevent Them”, but much of much of incorrectly conflates real password related threats with brute force attacks, which are not actually happening. Like so much of the bad information we see on security, it looks to just be a means to promote their security product, where providing accurate information isn’t important.

Under the heading of “Ways to Prevent Brute Force Attacks” one of their tips is:

Make a habit of using a different password for every site you use.

While using different passwords at every site will prevent a breach of password information on one website (particularly one not storing passwords in a secure manner) from allowing an attacker access to your account at other websites it has nothing to do with preventing a brute force attack.

Stranger is this portion:

Top 7 Passwords of 2016

123456

password

12345678

qwerty

12345

123456789

football

If you have one of these passwords, you are welcoming brute force attacks. You should change your password ASAP.

An attacker isn’t going to know ahead time what your password is when doing a brute force attack (otherwise they wouldn’t be doing it), so using a weak password isn’t going to welcome them to do a brute force attack. More importantly using a common password opens you up to a dictionary attack, which involves tries common passwords, being successful. A brute force attack would eventually be successful no matter the whether you used a common password, since as they said earlier in the post, “systematically check unlimited passwords until the correct one is found”.

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.

The New WordPress Plugin Directory Gives Prominent Placement to False Claims About Plugins

If you visit a page on the WordPress Plugin Directory currently there is a message asking you to “Test out the new Plugin Directory and let us know what you think.”. The new Plugin Directory still seems to be a work in progress, for example, until very recently if you did a search for our plugin “Plugin Vulnerabilities” by its name it wouldn’t show up on the first page of results (the rest of the results didn’t look relevant either). What looks to be a more permanent change with new version is that reviews of plugins will be featured prominently on the main page for each plugin. That could be useful, but also allows for inaccurate or outright false information to receive prominent placement.

Reviews do not always provide useful information, for example with security plugins what we see is that there are a lot of claims made about the supposed security that they provide that don’t appear to be based on actual evidence. It looks like the testing we have done over at our Plugin Vulnerabilities service is just about the only time anyone has actually tested to see if they provide any protection against real world threats. The results of that has been that most of them provide no protection against any of the vulnerabilities tested and the ones that provided any protection were almost always easily bypassable (that may be in why providers focus so much on making up threats and then claiming they protect against them).

While inaccurate positive reviews are problematic, something else we looked at recently over at blog for the Plugin Vulnerabilities has the potential be much troubling when giving such prominently placement, baseless claims that plugins contain exploits that lead to website being hacked. With both plugins we discussed not only was there no evidence provided to support the claim, but when we looked over the plugins we didn’t find code that even look to have the possibility of allowing the claimed exploit.

Unfortunately in the new Plugin Directory both plugins currently have those claims prominently on the main page for the plugin:

In both cases we left replies mentioning that we didn’t find anything that looks like it could have allowed this, so adding a mention that there are replies to the review might improve this bad situation to some extent.

Wordfence Using Outdated and Insecure Software on Their Website

When it comes to the security of websites what we see is that basic security measures are often not being taken with websites, while security companies push additional security measures without evidence that they provide better protection than doing the basics or in addition to doing the basics. Considering how bad the security industry is, it probably isn’t surprising to hear that we have repeatedly found that security companies themselves are not doing the basics, while pushing additional security measures.

Back in October we looked at one cyber security company that claimed to have “clients in the intelligence community, DoD and nearly every cabinet agency” that wasn’t keeping the WordPress and Drupal installations on their websites up to date, while telling people that they doing the additional security step of vulnerability scanning isn’t enough and that they need penetration testing done as well (which not surprisingly they offer). From what we have seen it looks like a lot of penetration testing largely involves running automated tools that try exploit known vulnerabilities in software, which usually would not exist if you are keeping your software up to date.

In November we looked at a couple of other cyber security companies that had been in news that were also running outdated software on their websites.

Today let’s look at example of this from the WordPress security world, which shouldn’t be all that surprising if you follow our blog. In the past we have mentioned the security company Wordfence in regards to their scary lack of security knowledge and pushing the falsehood of of brute force attacks against WordPress admin logins (which they are still pushing).

Over at the blog for our Plugin Vulnerabilities service today we looked another instance where Wordfence’s very popular security plugin failed to prevent exploitation of a plugin vulnerability (the 14 other security plugins we tested also failed to prevent exploitation), this vulnerability is one that you can’t protect yourself against by keeping your plugins up to date, so it would be something where an additional security measure could actually be useful (the companion plugin for our service has been warning webmasters of that vulnerability since Monday).

While working on that we ran across the Wordfence Official Documentation portion of Wordfence’s website and noticed they are running an outdated and insecure version of MediaWiki on that:

Both versions 1.23.14, release in May, and 1.23.15, released in August, contain a number of security fixes.

SiteLock Uses The Fact That They Cut Corners With Their Hack Cleanups To Try To Upsell Customers

Over two years ago we noted that SiteLock wasn’t doing a basic part of a proper hack cleanup, properly securing the website, which usually mainly involves making all of the software of the website is brought up to date. That situation hasn’t changed, as just about three months ago we were brought in to fix a website after SiteLock cleanup had broken it. In that case not only had the software not been updated, but SiteLock had also failed to attempt to determine how the website was hacked. If they had done that they would have spotted part of the cause of the hack was one of their web hosting partners, GoDaddy, allowed remote access databases that were set not to allow it. When you consider that SiteLock often charges $300 for a cleanup, which is more than we charge for many cleanups where we do those things, their customers are really getting ripped off.

It turns out that SiteLock doesn’t recommend using their one time hack cleanup service, not because they are not doing things properly, but so they can charge customers even more money and keep charging for something that should have a one time cost.

In a complaint with BBB (https://www.bbb.org/phoenix/business-reviews/internet-services/sitelock-llc-in-scottsdale-az-1000018625/reviews-and-complaints) one of their customers describe the situation:

After my business website was hacked on or before December 29, 2015, I was advised by my web hosting company to contact its security partner, Sitelock. Sitelock offered me two options: a one-time cleaning for $300, or cleaning plus monitoring for $90/month.

I was again told I chose the wrong product (he said they don’t recommend the $300 cleaning to anyone).

So instead of paying $300 for a low quality cleanup they wanted them to pay $1080 a year for monitoring and continuous cleanups. There are multiple issues with that. Some of those revolve around the reason they recommended against the one time cleanup:

I was then told I chose the wrong product (the $300 cleaning) because I had an active hacker who went right back to work on my site.

A proper one-time cleanup should prevent the active hacker from getting “right back to work on my site”. But if you don’t determine how the website was hacked and fix that (as websites don’t just get hacked, something had to have gone wrong for that to occur), as well as making sure the website is otherwise secured, then it isn’t surprising that a hacker could get back in.

Since SiteLock’s continuing service doesn’t do those things either, the best they can do is to keep detecting the hacker has accessed the website and clean things up after the fact. Having a hacker repeatedly get access to your website is not something that should be happening, even if it could be quickly cleaned up each time. What if a hacker gets access to customer data, once that has been taken a SiteLock clean up won’t undo that. There is also the issue that SiteLock doesn’t exactly have the best track record of detecting hacks, so they might not even spot was is going on to clean it up.

If you are spending $1080 a year on security it would be spent doing things that would actual prevent the website from being hacked, SiteLock doesn’t provide a service that does those things (probably because it would require actually doing a lot of work).

Based on all that you might not be surprised to hear that the one time cleanup done on that website had another problem. The website was messed up, which SiteLock excused based on this:

The hack affected many of the core platform and theme files (985 files total – attached). The site’s appearance after the… clean had been completed was due to the compromised core and theme files.

A proper hack cleanup would have properly fixed the compromised files so you wouldn’t be left a website with appearance issues (that was also one of the issues with the website hosted with GoDaddy earlier and earlier instance with a GoDaddy hosted website).

At this point you might be wondering why this person’s web host had a security partnership SiteLock considering how bad they are. The reason at some web hosts is in part that SiteLock’s owners also run the web hosts (something that web hosts don’t acknowledge publicly) and the other big reason is that the web hosts get a significant amount of money pushing SiteLock services. In the case of one of them, the web hosts disclosed that they get 55% of the revenue from SiteLock services sold through the partnership. Which in the case of that ongoing service, would work out to $594 a year, without requiring them to do any work. The one time cleanup would get them $165. If you do have a hacked website and are getting pushed to SiteLock, beyond obviously avoiding them, you should take a look at a previous post we wrote that goes into more detail as to what you should know in that situation.

Is SiteLock’s Vulnerability Scanner Anything More Than Them Running Nessus on Websites?

As we have looked closer at the web security company SiteLock a reoccurring theme has been finding that their services are actually provided by others and that they don’t disclose the true source (in some cases they make claims that would reasonable lead you to believe they are in fact provided by them directly). That can have some pretty serious implications. For example, we found that their content data network (CDN) and web application firewall (WAF) are actually provided by another company, Incapsula. As both of those services involve sending your website’s traffic through the provider’s systems, not knowing the true provider of the service means you don’t actually know who has access to all of that traffic. In another case we found that due to SiteLock’s lack of understanding of WordPress security they were (and maybe still are) incorrectly using third-party data on WordPress vulnerabilities to falsely claim that websites are insecure. It also does more to undercut their claim to be the “global leader” in website security.

Back in September we discussed that while SiteLock’s vulnerability scanner is frequently promoted by their web hosting partners there didn’t appear to be any evidence that the vulnerability scanner was actually effective in finding vulnerabilities on websites. Recently we ran across a thread on the WordPress Support Forum from earlier this year about an instance where their scanner had claimed to find a couple of potential SQL injection vulnerabilities in the WordPress portion of a website.

Without having access to the website’s files as of the time the scan was done we can’t tell if these were false positives or not, but unless the website contained plugins that were changing the normal way the relevant files were operating, the results would have involved falsely labeling the core WordPress software as having vulnerabilities.

We were curious to see if we could find other examples of SiteLocks’s vulnerability scanner results and so we did a Google search for “The following resources may be vulnerable to blind SQL injection”, which is phrasing used in their message mentioned in that thread.

One thing that is pulled up was more indication that the scanning isn’t very good, as it was taking Joomla simply returning a different result when malicious code was added to URL parameters with their being a potential prone to SQL injection. The crude level of their scanning might provide some useful information for an experienced developer or a security professional, but for the average webmaster it is likely lead to a lot of unneeded confusion.

More interesting was something else that it showed. Here is how one SiteLock’s results began:

Using the GET HTTP method, SiteLock found that :

+ The following resources may be vulnerable to blind SQL injection :

+ The ‘rp_subject’ parameter of the /index.php/index.php/help/suggestion-about-website CGI :

The Google search results also pulled up result from the Nessus vulnerability scanner, that look like this:

Using the GET HTTP method, Nessus found that :

+ The following resources may be vulnerable to blind SQL injection (time based) :

+ The ‘LinkedGroup’ parameter of the /cgi-bin/vendx/forgotpasswd.cgi CGI :

Other than specifics of each potential vulnerability the only difference between those to is the Company name and the phrase of “(time based)” in the Nessus message.

So pretty clearly SiteLock’s vulnerability scanner at least in part involves them running Nessus over websites. Not surprisingly, based on the other examples, they don’t disclose that fact. The page for the service makes no mention of it involving a Nessus scan and a Google site search shows no mention of Nessus at all on their website. Considering that Nessus doesn’t really seem like a tool designed for end user as it is promoted by SiteLock’s web host partners (which also are in some instances run by SiteLock’s owners), it doesn’t seem like a good fit for the service.

What isn’t clear if the vulnerability scanning involves anything more than a Nessus scan. If you have any more information on the vulnerability scanner please leave a comment on the post.

GoDaddy Doesn’t Disclose The True Source of SiteLock’s CDN and WAF Services

The last time we discussed GoDaddy’s partnership with SiteLock back in September it involved a situation where SiteLock managed to break a website they were supposed to be cleaning, GoDaddy was partly responsible for the website being hacked, and SiteLock failed to detect that GoDaddy issue due to their failure to do a basic part of a hack cleanup. Based on that an expansion of their partnership doesn’t seem like a good thing, but it is happening.

Today GoDaddy announced that they would now be offering SiteLock’s content data network (CDN) and web application firewall services (WAF) services. What they neglected to mention is that these services are not actually provided by SiteLock, but as we recently discovered, by another company, Incapsula. That is a rather important item to disclose since both of those services involve sending your website’s traffic through someone else’s systems. Having a company you have no involvement with having access to all of your website’s traffic obviously raises some serious issues. Even if you are not concerned with Incapsula having access to your traffic, it looks like SiteLock could switch to another provider at any time without you being aware of it.

Also missing from the press release is any evidence that SiteLock’s WAF actually provides any protection (which we haven’t seen provide elsewhere either). Instead you get unsupported claims as to the protection it supposedly provides. One claim included has actually been indirectly disputed by SiteLock. That claim being that it prevents backdoor access:

Trust that website content will be protected from potentially harmful spam comments, and backdoor access to website files will be blocked.

In previous post we looked at situation where a SiteLock customer using their firewall got hacked again and said that “SiteLock assures me that everything is set up correctly, and that the hacker must have a back door access point. They don’t cover that.”.

If you are actually looking to keep your website then these are things you should focus on, which are not things that any SiteLock services provides. You also would probably be best off not using a web host, like GoDaddy, that partners with SiteLock.