iThemes Security

Security Plugins and Plugins by Automattic Haven’t Been Updated To List Them as Compatible With WordPress 4.8

Back on May 31 we received an email from WordPress.org asking us, as developers of several plugins, to make sure that the plugin were listed as being compatible with the then upcoming WordPress 4.8. The beginning of the message reads:

Hello, White Fir Design!

WordPress 4.8 is scheduled to be released on June 8. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.8. This information provides peace of mind to users and helps encourage them to update to the latest version.

As scheduled, that version was released on June 8.

While looking at something the other day we noticed that a security plugin had not been updated to list as being compatible with the new version. Looking at the plugins tagged security it turns out that many haven’t been two weeks after the release of that new version of WordPress. That doesn’t seem to be a great indication as to the state of security plugins, but more striking was that several of the most popular plugins tagged security that have not been updated come from the company Automattic, which is closely associated with WordPress.

First up being Jetpack by WordPress.com, which is tied with 6 other plugins for having the most active installs, 3+ million:

One of those other plugins with the most active installs is another Automattic plugin, which despite shipping with WordPress also isn’t listed with WordPress 4.8:

Getting back to the security tagged plugins, another Automattic plugin not listed as being compatible is VaultPress:

Among the other security tagged plugin that haven’t been updated to be listed as being compatible, you have iThemes Security:

You also have Sucuri Security, which still hasn’t even been listed as being compatible with WordPress 4.7, despite that being released in December:

The parent company of that plugin GoDaddy also hasn’t updated their other plugins to list them as compatible:

Also worth noting, considering SiteLock’s questionable involvement with WordPress, is the SiteLock Security plugin:

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”.

iThemes Security Uses Non-Existent Threat of Brute Force Attacks To Collect Users’ Email Addresses

When it comes to security companies, trustworthiness is critical, since the average person isn’t going to have the knowledge and skills to understand if the security company is actually doing (or could even possibly do) what they are claiming to do to protect them. Any upstanding security company would therefore be very careful in what they say and do, so if you see a company being less than honest it should be a major red flag when it comes to using their products and services.

That brings us to something we noticed in the WordPress security plugin iThemes Security. When you install the plugin a notice is displayed at the top of pages in the admin area that read “New! Take your site security to the next level by activating iThemes Brute Force Network Protection”

If you get click the “Get Free API Key” button in that notice you get shown the following page:

On that page they accurately describe what a brute force attack is, so clearly they know what it is. What they either don’t know or they are intentionally not telling people is that brute force attacks against WordPress admin passwords are not happening, so you are not taking your site security to the next level by enabling that feature as they claim.

What makes this more troubling is that they are using the non-existent threat of brute force attacks to try to collect users’ email addresses. By default permission to send “email updates about WordPress Security” is also included when doing that and considering in the best case here they are not aware of it pretty basic security fact that brute force attacks are not happening, the quality of the security information they would provide in those email is likely to be poor.

Just based on this it would seem like a good idea to avoid this company and their plugin, but it isn’t the only issue we found with the plugin recently. Back in April we ran across the fact that the plugin had button labeled “One-Click Secure” that didn’t do anything.

iThemes Security Plugin Has “One-Click Secure” Button That Does Nothing Except Claim The Website Has Been “Secured”

We are frequently asked what about various broad based WordPress security plugins and which ones should be used. Our answer to the second part of that is none of them. These plugins generally provide little protection against actual threats and have been found to have security vulnerabilities themselves fairly often. That second part might sound odd, you would think that someone developing a security related plugin would be very careful about the security of their plugin, but people that actually know about security would be unlikely to be involved in developing one of these due to the first part of that, that they don’t provide much protection against actual threats.

So what you are left with is products generally developed by people that don’t have much concern for real security and in a lot of cases seem to be mainly interested in making money by taking advantage of the public that understandably lacks strong security knowledge. That results in lots of plugins and related services that end up scaring people based on bad or false information and that collect information from users under false pretense.

If you are looking for some particular security feature you would be better off finding a plugin that doesn’t also include a kitchen sink of other features with it, since that reduces amount of code that could be harboring security vulnerabilities. The important things you need to do to keep your website secure are listed here.

The iThemes Security Plugin And Trust

That all brings us to something we just ran across with one of those plugins, iThemes Security (formerly Better WP Security), which is listed as having 700,000+ active installs.

One important element of any security product is trust, since the average user can’t verify that a product does what it says, they are trusting the developers in a major way. Any abuse of that trust should be a major red flag. That trust is something the developers of the iThemes Security plugin don’t seem to care about.

When you install and activate the iThemes Security plugin a notice is displayed at the top of the page with a button to “Secure Your Site Now”:

ithemes-security-1

Clicking on that brings up this page:

ithemes-security-2

The most important part of that would seem to be the section Titled “Secure Your Site”:

Use the button below to enable default settings. This feature will enable all settings that cannot conflict with other plugins or themes.

When you click on the One-Click Secure button, you get a message that it is “Working…” for a moment:

ithemes-security-4

Then it will tell you that “Site Secured. Check the dashboard for further suggestions on securing your site.”:

ithemes-security-5

Based on that you would think that the website has been secured in some way after doing that. It turns out that nothing actually has happened, something we found about when ran across a post on a thread on the WordPress.org support forum for the plugin that stated

Please note that since the 5.2.0 release (5.2.1 included) clicking on the One-Click Secure button in the First Important Steps modal window will not do anything despite the fact that it still reports:

Site Secured. Check the dashboard for further suggestions on securing your site.

which is also kind of lame as there is no longer a Security Status section on the Dashboard page …

Note this is not a bug, since iThemes knowingly removed the code that was normally executed behind this button …

If you want to see that for yourself you can see the changes made in version 5.2.o here (doing a search on the page for “Register one-click settings” will take you to parts of the page where that is shown). What makes this even more incredible is how long ago this happened, version 5.2.0 was release on January 18 and the post pointing that out is now two months old, and yet it is still that way now.

When they don’t care about misleading people with something that visible, then you have to wonder what else they might be misleading people about. We already spotted one other thing, but you will have to wait for a future post to hear about that.