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:

Journalists Spread SiteLock’s Fake Claim Involving Nonexistent Legitimate Plugin

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

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

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

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

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

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

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

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

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

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

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

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

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

The Obviousness of Unnatural Reviews for a WordPress Security Plugin

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

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

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

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

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

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

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

Prevent hackers to sabotage your rankings in search engines.

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

When a WordPress Security Plugin Gets Praised for Creating a Problem

When it comes to the poor state of security information surrounding WordPress one of problems we see is security companies making up threats and then claiming that their product or services can fix them. One example of that we have discussed in the past is the widely peddled falsehood that there are a lot of brute force attacks against WordPress admin password. What is actually happening looks to be mainly dictionary attacks, which involves a hacker trying to log in using common passwords. The simple solution to prevent these from being successful is to use a strong password, something that WordPress is already good at helping you accomplish.

One of the problems with not addressing the real issue here, is that a solution not designed for the actual threat can actually cause more problems. For example, if you limit the number of failed logins attempts that can be made to try prevent a brute force attack (since that would involve trying every possible password), not only can it cause problems getting back in to the website if you have trouble remembering your password, but it can make it easy for someone to lock you out of your own website depending on how the lockout is handled (a form of a denial of service (DOS) attack).

That brings us to another problem when it comes to WordPress security information, which is that public often is providing reviews and recommendations that lead others in the wrong direction security wise. Take a review for the security plugin BulletProof Security we came across while working on another post. The review is title “Saved My Site”, but what it actually describes is the plugin creating a problem:

Got slammed by hackers who discovered my username. I was locked out of my admin area due to multiple attempts at login which I did not do.
I deleted the plugin, then I created a couple of new strangely spelled admin usernames names and long passwords, reinstalled the plugin and I am good to go.

The WordPress username is not intended to be secret, so someone discovering it shouldn’t be an issue. The issue here is that a plugin is locking the person out due to actions they didn’t take, which had obvious negative consequence. At the same time it wouldn’t necessarily protect against a dictionary attack if the hacker simple slowed their login attempts to below where it would be stopped by such a plugin.

Considering that the plugin is named BulletProof Security and it has overwhelmingly received 5 star reviews (and an average 4.7 stars), you might be surprised to hear the plugin is far from bulletproof. In testing over at our Plugin Vulnerabilities service it has failed to provide any protection against exploitation of four real vulnerabilities that existed in other plugins. Unfortunately highly positive reviews for a plugin that fails to provide the protection it promises is not limited to this plugin, but is a widespread issue.

Anti-Malware Security and Brute-Force Firewall Plugin Uses Non-Existent Brute Force Attacks To Get Registrations and Donations

When it comes to WordPress security, one thing we can’t emphasis enough is that people putting out security products and services for it don’t seem to have a good grasp of security. One of the most glaring examples of this is how often the falsehood that there are lots of brute force attacks against WordPress admin passwords happening, despite the evidence presented that they are happening actually showing the exact opposite.

Recently, while doing testing on how WordPress security plugins did in protecting against real world plugin vulnerabilities (short version, they haven’t done well in the testing so far) for our Plugin Vulnerabilities service we ran across the plugin Anti-Malware Security and Brute-Force Firewall. The plugin is one of the most popular security plugins, with 100,000+ active installs according to wordpress.org.

On the Firewalls Options page you will find that they have an option for Brute-force Protection:

anti-malware-security-and-brute-force-firewall-brute-force-protection

So they are using a non-existent threat to try to get people to register and donate. On top of that, the protection seems to involving modify a core file, which isn’t a very good idea.

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”

New! Take your site security to the next level by activating iThemes Brute Force Network Protection. Get Free API Key

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

Network Brute Force Protection If one had unlimited time and wanted to try an unlimited number of password combinations to get into your site they eventually would, right? This method of attack, known as a brute force attack, is something that WordPress is acutely susceptible to as, by default, the system doesn't care how many attempts a user makes to login. It will always let you try again. Enabling login limits will ban the host user from attempting to login again after the specified bad login threshold has been reached. Network vs Local Brute Force Protection Local brute force protection looks only at attempts to access your site and bans users per the lockout rules specified locally. Network brute force protection takes this a step further by banning users who have tried to break into other sites from breaking into yours. The network protection will automatically report the IP addresses of failed login attempts to iThemes and will block them for a length of time necessary to protect your site based on the number of other sites that have seen a similar attack. To get started with iThemes Network Brute Force Protection, please supply your email address and save the settings. This will provide this site with an API key and starts the site protection. Email Address test@example.com Receive Email Updates Receive email updates about WordPress Security from iThemes.

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.

A Good Example of What is Wrong With The Management of the WordPress.org Plugin Directory

Through the work we do for our Plugin Vulnerabilities service we spend a lot of time on the Plugin Directory, dealing with issues in plugins on it (mostly security issues), and interacting with the people running it. Our experience is that things are not really handled well by the people running it. Something we ran across today seems like a good example of the poor state of the people managing it, which we thought would be good to share to help expose the bad state of things.

Since we have several plugins in the Plugin Directory, prior to the release of a new version of WordPress we get an email asking us to test our plugins with compatibility with the new version of WordPress and then update them to indicate they are compatible with the new version. Here is the email we got prior to 4.5 (the plugin listed as only being tested up to 3.6 is due to the fact that the plugin’s functionality was integrated into the next version of WordPress):

Hello, WhiteFirDesign!

WordPress 4.5 is scheduled to be released on April 12. 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.5. This information provides peace of mind to users and helps encourage them to update to the latest version.

Here are the current “tested” values for each of your plugins:

* https://wordpress.org/plugins/automatic-plugin-updates/ (tested up to 4.5)
* https://wordpress.org/plugins/https-updates/ (tested up to 3.6)
* https://wordpress.org/plugins/no-longer-in-directory/ (tested up to 4.4)
* https://wordpress.org/plugins/plugin-vulnerabilities/ (tested up to 4.5)

For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.

Looking to get more familiar with 4.5? Check out this roundup post on the core development blog: https://make.wordpress.org/core/2016/03/30/wordpress-4-5-field-guide/

Thank you for all you do for the WordPress community, and we hope you will enjoy 4.5 as much as we do.
WordPress core contributors

So clearly the Plugin Directory wants people to be testing their plugins for compatibility and then updating the compatibility information.

Based on that you would think that the person described as the “WordPress.org Tech Dude”, who is involved in managing the Plugin Directory, would be setting an example by making sure to do that, but as we noticed today that isn’t the case. For one of their plugins PHP Code Widget, which has 100,000+ active installs, it is still only listed as being compatible up to WordPress 4.4. WordPress 4.5 was released in April and WordPress 4.6 getting closer to release, with the third beta released a week ago.

It isn’t a situation where the plugin is no longer supported, hasn’t been tested, or the developer just forgot to update the compatibility. As a couple of forum threads show, the developer is instead just refusing to update the compatibility listing. If that sounds strange to you, you are no alone, but that is inline with the type of attitude we have seen when dealing with those people.

SiteGuarding.com’s WordPress Security Plugin Touts Its Use For Those That Pirate Software, While Charging For Its Services

When it comes to security plugins for WordPress, we don’t think to highly of most of them. But we have continued to be surprised how low things can go with them. Take for example the WP Antivirus Site Protection (by SiteGuarding.com) plugin, which on it’s description page on the Plugin Directory it states near the top:

This plugin will be especially useful for everybody who downloads WP themes and plugins from torrents and websites with free stuff instead of purchase the original copies from the developers. You will be shocked, how many free gifts they have inside 🙂

Their touting its use for those that pirate WordPress themes and plugins is kind of incredible on its own (note the lack of past tense in terms of downloading that software or lack of suggestion not to do that). But more incredible is the fact that at the same time the plugin is really just a connection for a mostly paid service, so they think you should pay them, but are okay with people not paying the developers of software.

What makes that dichotomy more striking is the comments from the developer on some of the negative reviews of the plugins.

One review reads:

If your website contains a file larger than 25MB, the plugin will abort and ask you to upgrade rather than just skipping it and warning you. The plugin is just a leadgen ploy. Uninstalled. Further more, of all the wordpress hacks I’ve ever seen, files affected are NEVER large or over a few kb.

That seems like reasonable complaint, which gets this response from the developer:

free version has limits. if you are not ready to pay for the security enjoy and live with the viruses.

As part of their response to another review the developer wrote in part:

If you installed it again. It means plugin is good, you just dont want to pay for good plugins and services and want everything for free.

It is also worth noting that there are a lot of rather fake looking reviews for the plugin.

The Fact That Wordfence Couldn’t Clean Up a Hacked Website Doesn’t Stop People From Suggesting That It Will Clean It

When it comes to improving the security of websites one of the biggest problems we see if the shear amount of bad information, including lots of bad advice, that is being put out there. We frequently see people suggesting using the Wordfence plugin for WordPress, which we have hard time believing somebody who is knowledgable about security would recommend due to a number of issues. Those issues include the fact that broad based security plugins like that are not all that useful against real threats, that more than a few security vulnerabilities have been found in the Wordfence plugin itself, that the developers don’t seem to have a good grasp of security, and that the plugin produces some really bad false positives. Usually you have no way of knowing if somebody giving out that advice has a different opinion in regards to those types of things or they are giving advice without really being informed about the situation. In some cases you can see that advice is being handed out uniformed, though.

As part of keeping track of security issues in WordPress plugins for our Plugin Vulnerabilities service, we monitor the wordpress.org forum for threads related to plugin vulnerabilities. In addition to helping to find some more vulnerabilities to include in our data, we run across threads about other security issues related to WordPress and WordPress plugins. In one of those we saw when the use of Wordfence being suggested as a solution, when that clearly wasn’t helpful advice.

The original poster in the thread described the problem they were having cleaning up a hacked website. After trying numerous things, including reverting to a backup copy, malicious files were continuing to be added to the website. At the end of the post they mentioned that they have three WordPress security plugins installed, but that they hadn’t been any help:

Protections plugins I’m currently using (and which can’t find anything wrong with the website)

Despite that one those plugins was Wordfence, the second and third responses suggested that Wordfence could deal with the issue:

Yes, those are not default files. WordFence is the best for scanning once you are already infected.

and

I had the same issue, so far WordFence has done a great job. Two days and no wp-checking.php has showed up. Yet!

In this type of situation what we would recommend, and did later in the thread, is to see if you can determine if the hacker still has some sort of access to the website, which is allowing them to continue to modify the website, and if that is the case, close off that access.

Incidentally, one of the other plugins they were using, AntiVirus, was one that we found was flagging a fresh install of WordPress as having virus back in 2012.

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.