WordPress Plugins

Just Because a WordPress Plugin You Use Has a Vulnerability It Doesn’t Mean It Got Your Website Hacked

As we have talked about recently, there is often confusion over how websites have been hacked. One issue that comes up from time to time is the claim that a WordPress plugin that contains an unfixed minor vulnerability is the source of a hack. Here is one recent claim of that:

i would strongly urge you to remove it now. My site was hacked several times before I realized it was because of this plug in. It sucks because I was unable to find a replacement and have to do it by hand.

The vulnerability that is known to exist in that plugin would allow someone logged in to WordPress with the Contributor or Author role to cause malicious JavaScript code to be included on frontend pages on the website. (Higher level-users already have the capability to do the equivalent of that.)

Unless you have an untrusted individual with access to WordPress with the Contributor or Author role, either intentionally or because someone with that level of access had their account breached, you don’t have to worry about that. So the chances of that being exploited are slim.

It’s possible that the quoted individual had that situation, but almost no websites will, so the chances of the plugin being the cause of hacks on websites is very small.

Trying to figure out how a hacked WordPress website was really hacked is a standard part of our hack cleanup process for WordPress websites. Our hack cleanups include a free lifetime subscription to our Plugin Vulnerabilities service, which includes providing fixes for unfixed plugin vulnerabilities.

Bad False Positives from Wordfence Security and Quttera Web Malware Scanner WordPress Plugins

We often have people contact us that believe that a claim that their website has been hacked is false because they ran a scanner over and it didn’t find anything. We are not really sure why they don’t ask for the evidence behind the claim and try to see if they can confirm if that is accurate or not instead of running a scanner over the website, but considering they are not doing that it might not be surprising that they are instead doing something that is likely to not produce great results.

One problem is that the even if the scanner is effective at what is attempting to scan for, it may not be able to detect the type of issue that lead to claim that the website is hacked. Let’s say a web host detects a malicious file on the website, well that probably would be be something that a scan of the website’s pages from the outside would never detect.

Another problem is lack of evidence that various scanners are actually effective at what they are attempting to scan for and from our own experience, plenty of evidence that they are not effective. One area where we have seen evidence of that going back many years is with really bad false positives that indicate that these scanners are incredibly crude, so crude in fact that if we weren’t well aware of how bad the security industry is, we would have a hard time believing that they were even occurring. Below are a couple of them in WordPress plugins that we recently ran across that show the current poor state of such tools.

Quttera Web Malware Scanner

The first comes from the plugin Quttera Web Malware Scanner, which has 10,000+ active install according to wordpress.org. In recent thread on the support forum for that someone mentioned getting a false positive for what is quite common code. The plugin will warn when matching “RewriteRule ^(.*)$ h” in a .htaccess file, which would match when do some fairly common rewriting of URLs. Just doing that rewriting is not in any way malicious. The developer’s explanation for that wasn’t that this was a mistake, but that:

We mark it as suspicious because there are multiple malware instances utilizing this technique to steal/redirect traffic from infected websites.

Simply because malware uses common coding isn’t a good reason to flag any usage of it and that will necessarily cause the results of a scanner to be of limited use.

Making it seem like the developer really doesn’t know what they are doing in general, the description for that detection is “Detected suspicious JavaScript redirection”, which makes no sense considering that type of code has nothing to do with JavaScript.

Wordfence Security

The second instance of this involves a much more popular plugin Wordfence Security, which has 2+ million active installs according to wordpress.org, that we have frequently seen people believe is much more capable than it really is (sometimes they ignored evidence right before their eyes to continue to believe that).

A thread on the support forum of the plugin Ultimate Member was recently started with:

Wordfence seems to think there is a malware URL somewhere in the file class-um-mobile-detect.php:

* File contains suspected malware URL: wp-content/plugins/ultimate-member/includes/lib/mobiledetect/class-um-mobile-detect.php

but on comparison, the file’s contents are exactly the same as the latest file offered on https://ultimatemember.com

Can someone comment?

In follow to a question by the developer of the mentioned plugin, the original poster wrote:

I’m using 2.0.23 but as I’ve said the file in question is identical to the one found in the latest version. So as I thought it is a false positive. Maybe Wordfence doubled up on UM after the latest malware exploit.

In reality it was just that Wordfence’s scanner incredibly crude as hinted at by another reply in the thread:

It is caused by the URL: “http://www.vonino.eu/tablets” which was reported to contain malware.

In my file, it’s only mentioned in a comment so I guess it’s safe.

What that is referring to is the following line in the file /wp-content/plugins/ultimate-member/includes/lib/mobiledetect/class-um-mobile-detect.php:

340	// Vonino Tablets - http://www.vonino.eu/tablets

Currently the domain vonino.eu is being flagged by Google as malicious:

That doesn’t in any way make a file that includes the domain in a commented out line in the code, which can’t run, in any way malicious. If the developer’s of Wordfence Security cared at all they could easily avoid that false positive, but considering they can get away with much worse it isn’t surprising they wouldn’t care about that. That also leaves more responsible plugin developers to have to deal with the fallout from those false claims.

The Developer of Cerber Security, Antispam & Malware Scan Gives Out Bad Advice To Push Their Plugin

When it comes the security industry around WordPress unfortunately there are many people that either don’t know what they are talking about or are intentionally peddling bad information to push products and services that provide little to no protection, while making things harder for companies that are actually doing the hard work to actually improve security.

We often run into examples of this even when we aren’t looking for them. We ran into another example just the other day when we went to look around for some information while working on a post about running into a problem with contact form due to WordPress’ REST API being disabled. That lead us to an example of someone at best not knowing what they are talking about when it comes to the basics of WordPress security while being the developer a security plugin, Cerber Security, Antispam & Malware Scan, that currently has 90,000+ active installs according to WordPress.org.

A big tell that developer doesn’t have a basic clue as to security surrounding WordPress is that a main feature of their plugin is blocking brute force attacks despite the fact that those are not happening. They also make this brute force related claim in the marketing materials for plugin:

By default, WordPress allows unlimited login attempts through the login form, XML-RPC or by sending special cookies. This allows passwords to be cracked with relative ease via brute force attack.

Saying that brute force attacks could crack a password relative ease is belied by the number of login attempts needed to actually test out all of the password combinations. Here is what we wrote about that previously:

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 post that we had run across was “Why it’s important to restrict access to the WP REST API”. The post is riddled with errors, for example citing someone as having discovered a vulnerability they didn’t.

The general problem was that they were suggesting disabling the REST API, which not at all coincidentally they touted their plugin did, because there could be security issues with it since it is new. But that is true of anything. In reality the vulnerability they discussed in the post actually showed how WordPress does a good job in handling security in one important way, since the auto update mechanism that has been in WordPress 3.7 allows the vast majority of WordPress website to be updated to a new security release in a very short time. Normally WordPress checks for updates every 12 hours and that can be shortened when a security update is being released, so most of the websites would likely have been updated in around 12 hours. With this vulnerability there was no evidence of it being exploited until after it was disclosed that it had been fixed a week after the version that fixed it was released (while the information on this vulnerability was held back for a week, other security updates were mentioned when it was released).

The developer though put forward a very different impression:

Unfortunately, the REST API bug had not yet been fixed. That leaves unprotected millions of websites around the world. It’s hard to believe but updating WordPress on shared hostings may take up to several weeks. How many websites have been hacked and infected?

That it may take several weeks to for WordPress on shared hosting to update is actually hard to believe, since it doesn’t appear to be true and no evidence was presented to back up a claim even they claim is counter-intuitive. The developer provides no evidence that any websites were hacked before the vulnerability was disclosed as having been fixed a week before, which as far as we are aware they couldn’t have since it doesn’t appear any were. That all probably shouldn’t be surprising since the developer apparently had never checked to see if brute force attacks were actually happening before building a plugin to protect against that.

For website where the auto update mechanism was disabled or didn’t work they did get mildy hacked due to this vulnerability, but that is the only vulnerability in more than a decade that we are aware of where there was any sizable number of websites hacked (in that time outdated WordPress installation have been frequently falsely blamed for the hacking of websites by security companies that either didn’t know what they were talking about or intentionally lying to get themselves press coverage). So disabling the REST API subsequent to this vulnerability being fixed has not actually improve the security of websites in any meaningful way.

There also was the issue of the developer conflating bugs and security vulnerabilities, which is important since having a lot of bugs fixed in something doesn’t mean that there was security risk.

The downside of disabling the REST API can be seen in that, like with the other plugin we mentioned in the post from earlier this week, this plugin can cause Contact Form 7 based forms to stop functioning. This exactly the kind of downside that often isn’t considered when people indiscriminately use WordPress security plugins and services without finding out first if there is any evidence that they provide effective protection. In this case what makes this stand out more to us is that our Plugin Vulnerabilities plugin, which is designed to help protect against a real issue, is much less popular than this plugin. It could be worse though, as another security plugin just designed to protect against brute force attacks has 2+ million active installs according to wordpress.org and it not only doesn’t protect against a real threat, but contains a security vulnerability of its own.

Disabling WordPress’ REST API Can Cause Contact Form 7 to Not Work

In our work for our Plugin Vulnerabilities service we frequently need to contact developers of WordPress plugins to let them know about security vulnerabilities in their plugins (either that we have discovered or that others have disclosed) and that often means submitting messages through contact forms (not surprisingly these are often handled by WordPress plugins). We have all too frequently run into situations where the contact forms didn’t work, which seems like a good reason for people managing websites with a low volume of contacts to periodically make sure that contact forms work, otherwise you could be missing out on messages.

In a recent instance of this, a loading graphic showed up after hitting Send and then that didn’t change to a message about the form being successfully sent. Pulling up the web browser’s console showed an error:

Failed to load resource: the server responded with a status of 401 (Unauthorized)

The page that related to was /wp-json/contact-form-7/v1/contact-forms/193/feedback, which would indicate the Contact Form 7 plugin was being used to handle the contact form. Visiting that page showed the following message:

{“code”:”rest_cannot_access”,”message”:”DRA: Only authenticated users can access the REST API.”,”data”:{“status”:401}}

Based on that it seems that disabling of WordPress’ REST API for those not logged in to WordPress caused the contact form to not work. A quick search showed that message was generated by another plugin, Disable REST API, which as the name suggest disables WordPress’ REST API.

As this shows, using something like that that disables the REST API can have some serious downsides. Not surprisingly for us, while looking into this we found someone in the WordPress security industry that doesn’t seem to have a clue about WordPress security pushing disabling it (and promoting using their plugin to do it), which we will discuss in a follow up post.

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”

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.