17 Nov

Wordfence’s Idea of Keeping “site owners safe from exploitation” Actually Puts Them At Risk

When it comes to improving the poor state of security, what can be seen over and over is that the focus needs to be on the basics. Take for instance the widely covered breach of Equifax, which was a situation where simply keeping their software up to date would have prevented the breach from happening. But the security industry isn’t focused on that and doesn’t seem to ever consider that what they are doing is far too often part of the problem, even when it impacts them.

That type of issue applies with WordPress plugins, where many hacks involve exploitation of vulnerabilities that have already been fixed. So what is probably going to provide you better protection then any security product or service would be to simply keep your plugins update at all times (many of the security plugins don’t seem to provide any protection against those vulnerabilities), which can be done with things like our Automatic Plugin Updates plugin. But telling you that doesn’t help the security industry to sell their products and services, so you don’t often here that from them.

As example let’s take a look at a post from yesterday from Wordfence about vulnerabilities in several plugins, which ends:

We encourage you to share these vulnerabilities with the larger WordPress community to help keep site owners safe from exploitation.

If you read through the rest of the post they don’t ever say that you should be keeping your plugins up to date at all times, which is actually the best advice when it comes to the vulnerabilities mentioned there. Instead they tell you the plugins they are mentioning now should be updated “immediately”, which for one of the plugins is well after a hacker had started trying to exploit one of the vulnerabilities that had been in it. The three plugins they mention are far from the only recent updated plugins that had updates that fixed security vulnerabilities, so only mentioning that people should update those isn’t all that helpful.

The rest of the post is like so much from Wordfence, mainly an ad for their services, which seems to be the real reason they want people to share it. As well get to in a moment one of the vulnerabilities in the plugins they mention is an example of the poor quality of what Wordfence paid service provides over doing the basics and the post shows again that Wordfence has very limited security knowledge, despite claims to the contrary.

A Week Behind

A week ago Thursday we discussed the details of a vulnerability that had been fixed in Formidable Forms, after Robert Mathews disclosure that it was being used to exploit vulnerability in another plugin (it is probably worth another post discussing how it was being exploited after it was fixed but before the discoverer had disclosed it). Since it was being exploited, we also added the vulnerability to the free data that comes with the companion plugin for our service, so that anyone that hadn’t updated the plugin already could have been warned about the issue last Thursday if they used our plugin. The update that fixed the vulnerability had been released a couple weeks before all that happened.

According Wordfence’s post they only got around to adding to protection against that to their paid service yesterday:

We released a firewall rule today, protecting Wordfence Premium customers from attempts to exploit this vulnerability.

That paid service is promoted by the claim that Wordfence has “unmatched access to information about how hackers compromise sites”. We would love to hear how Wordfence would try to justify that claim when they are a week behind the information that someone simply following our blog would have. That is far from the first time they have been well behind our blog, in another instances they only became aware of a vulnerability that was already being exploited because we were “making some noise about it” on this blog.

That was not the only thing that points to Wordfence not having the expertise they promote themselves as having (they claim to have a “large team dedicated exclusively to WordPress security”), take their mention of the vulnerability:

  • A preview function allowed unauthenticated users to execute an arbitrary shortcode. Normally, the use of shortcodes is restricted to site authors or administrators, as many of them could be used to exploit a site.

If they had simply read another recent post of ours they would have known that normally any one logged in to WordPress can access shortcodes, not just “site authors or administrators”:

In that access had not been there, then the vulnerability wouldn’t have existed, as those logged in to WordPress are already allowed to execute shortcodes through AJAX.

A Lack of Due Diligence or Worse

For another one of the vulnerabilities mentioned by Wordfence, they either didn’t do any due diligence or they don’t understand an even more basics element of web security:

WPVulnDB also reports that the Duplicator, running on over 1 million active sites, fixed a stored cross site scripting vulnerability affecting versions 1.2.28 and older. This report also included the code changes.

For some reason Wordfence didn’t actually link to the report on the vulnerability or credit the discoverer Ricardo Sanchez (though they managed to link to another page on their own website in that). If you look at that report you would not see any mention that this is a stored (or as we refer to them, persistent) cross-site scripting (XSS) issue, instead it indicates that it is a reflected XSS:

The XSS reflected because the values are not filter correctly:

The security implications of those two types of vulnerabilities are very different, so you would hope anyone in the security industry that provides a service related to dealing with them understands the difference.

It is possible that Wordfence doesn’t understand what they are talking about here (considering they link to changes in the code that don’t show the vulnerability they claimed), but a simpler explanation is that they just repeated the labeling of it by the WPScan Vulnerability Database:

That would be a bad idea as their data is well known to have accuracy issues, one of them lead to Wordfence recently falsely claim that the current version of a plugin contained a vulnerability that had been fixed six years ago. Does Wordfence with their “large team dedicated exclusively to WordPress security” not know this or do they not care enough to make sure they are presenting accurate information to their customers and the wider public?

A Paid Service That Really Helps

While Wordfence just got around to mentioning to people about Duplicator’s vulnerability yesterday we started notifying our customers about the issue last week when it was originally disclosed and before it was fixed. We also notified the developer that this unfixed vulnerability had been disclosed. That type of notification is something that we frequently do (we seem to be about the only ones) and can lead to unfixed vulnerabilities getting fixed within hours, which helps to protect everyone, not just our customers.

That is far from the only thing we do that others don’t, that helps everyone, one of the other things that we do that we have seen no evidence that anyone else does is that we monitor changes being made to plugins in the Plugin Directory to detect serious vulnerabilities.

Help Site Owners by Getting the Word out on Wordfence

This isn’t the first time Wordfence has put out type of post that is less focused on helping protect websites, than on marketing Wordfence. In other cases their posts are worse because they lie about what are security threats against WordPress and lead people believe that WordPress is insecure in ways it isn’t or they focus on making people reliant on them instead of actually improving WordPress, which would lead to  everyone being better protected then they would be by Wordfence.

Even worse they falsely promote their plugin with an unqualified claim that it “stops you from getting hacked”, despite them knowing this isn’t true. If the WordPress community would get involved in warning others about security companies that are so obviously dishonest, we think it would go a long way to helping to protect the public from companies like Wordfence that have shown they don’t have even their own customers best interest at heart, much less that of the larger WordPress community.

10 Nov

Don’t Assume Wordfence Premium (or Similar Services) Will Protect Your Website

We were recently looking back at some of our messages on the WordPress Support Forum in relation to some posts we have been writing related to the terrible moderation of that forum. In one of the topics we had started, there were a few things that we noticed that we thought were worth discussing as they relate to other things we have been looking at recently.

Eight months ago we had created a topic on the forum of a plugin, letting people know that there were some unfixed minor security issues in the plugin:

This plugin was recently selected by our customers to have a security review done by us. While there were no issues that were likely to lead to the average website being hacked found, we did find a couple of security issues with the plugin. We notified the developer of those, but as of yet they have not been resolved. Seeing as the plugin hasn’t been updated in 10 months, they might not be resolved any time soon.

After a moderator told us that we should email the Plugin Directory about this, we explained that the issues didn’t rise to the level that they would take action and therefore there wasn’t a use for doing that. In a reply to that, the head of the Plugin Directory responded:

I’m not sure what the issue is here, but we have always read, reviewed, and replied to your very welcome reports of plugin issues.

We clearly have a different view of what should be the focus of the people running the Plugin Directory, as we have never notified them in hopes they would do any of those things, but to take the action only they can take, removing the plugin until it is fixed (though we would expect they would we read and review the details of the issue before doing that). As removing unfixed plugins prevents anyone else from starting to use a known vulnerable plugin.

Due to WordPress’ continued poor handling of security we suspended notifying of them of vulnerable plugins in the Plugin Directory back in June, which has lead to there currently being plugins with over 2.3 million active installations that are known to be vulnerable that have remained in the Plugin Directory (if you were using our service and one of those plugins you would already been notified that your website contains a vulnerable plugin).

The most recent reply in the topic gets to something we have recently been thinking about more, which is when information about security issues, whether confirmed or possible, in plugins are being inaccurately cited. That is a concern with our new tool for check possible security issue in plugins, as based on past experience, we could easily see misuse of the results and we don’t want plugin developers having to deal with more inaccurate information on the security of their plugins.

Here is all but the last sentence of the reply (we will get to that sentence in a moment):

I can verify that there are serious problems with this plug-in. My hosting provider recently suspended my account temporarily because I was generating spam. We traced the problem to this particular plug-in.

We had not claimed there were serious problems with the plugin and the issues we found don’t seem like they could have lead to the issue this person had (or really had any chance of being exploited on the average website). Based on our past experience we would guess that the hacker just happened to place the malicious code in a file in the plugin’s directory, as we mentioned recently web hosts often incorrectly claim that wherever they find a malicious file is the source of the hack.

Unsupported Belief of Protection Provided by Wordfence

The final sentence of the reply is:

This problem occurred despite the fact that I had WordFence premium installed on the site.

It easy to understand why this person would have assumed that the Wordfence Premium paid service should have protected them, since Wordfence claims that just their free plugin Wordfence Security “stops you from getting hacked”. Until a week ago that claim was the second sentence in the description of the plugin in the Plugin Directory and it now exist in a FAQ answer on the page:

How does Wordfence Security protect sites from attackers?

The WordPress security plugin provides the best protection available for your website. Powered by the constantly updated Threat Defense Feed, WordFence Firewall stops you from getting hacked. Wordfence Scan leverages the same proprietary feed, alerting you quickly in the event your site is compromised. The Live Traffic view gives you real-time visibility into traffic and hack attempts on your website. A deep set of additional tools round out the most comprehensive WordPress security solution available.

That unqualified claim is a lie and Wordfence knows it (and the lie is something the public does believe, contrary to people trying to excuse Wordfence’s behavior will tell you). The reality is that a WordPress plugin cannot stop certain types of hacks from happening, including server level breaches and compromise of FTP logins. That the most popular WordPress security plugin has been prominently promoted with a blatant lie, is a good indication how bad things are currently when it comes to the WordPress security industry. Though it certainly isn’t alone, as the second most popular uses a false claim to collect users’ email addresses and one of the developers of third most popular thinks it is normal for security plugins to be insecure.

Considering that trust is an important part of security, any dishonesty from a security company seems like it should be something that leads to people avoiding doing business with them. So far it hasn’t though, but if it did, it would impact many more companies than just Wordfence.

Wordfence plugin and service can’t stop a lot of hacks for basic technical reasons, but even for the types of things that they should be able to protect against they don’t present evidence, much less evidence from independent testing, that they are effective against those hacks. The testing we have done in the past showed their plugin either didn’t protect against threats or the protection was easily evaded (that was one of the best results among the plugins we tested). So results from independent testing really are necessary before any claims are made as to the protection it provides (whether coming from Wordfence or from others).

We have had plenty of people come to us after using services that claimed to protect websites that failed to do that and everything we have seen about those services is that the claims being made are unlikely to match what the companies have the capability to provide. So you really should avoid any service that makes claims like that unless they are presenting evidence from independent testing that they are effective at protecting websites. We have yet to see any that provide that, which also probably is a good indication of those services limited ability to provide protection, as either the providers don’t know if they effective or not, or they know they are not.

You Can See What We Are Doing

With our service we don’t claim that we are going to stop your website from being hacked, only that we will help to protect you from security vulnerabilities in WordPress plugins. Being honest isn’t great for business, since so many security companies have no qualms about outright lying, but we actually care about security and being honest.

With our service you don’t have to guess if we are really providing you with anything of value as we currently put out a monthly post detailing most of what we have done during the month. That way people can compare what we are doing versus other providers, and we even sometimes provide public comparisons. We don’t just do that type of comparison for marketing purposes, but so that we can make sure that we are providing the best service possible.

One of the areas that we provide you better protection than services that make overstated claims about what they provides is that instead of simply trying to stop a vulnerability from being exploited we proactively monitor changes made to plugins to try to catch serious vulnerabilities as they are added to plugins (something we could expand to less serious issues if we had more customers) and we provide the ability for paying customers to suggest/vote for plugins to get reviews, so you can get a determination if a plugin is secure or not (and hopefully we can then work with the developers to fix any issues), before a hacker might start exploiting it. We also continue look at ways to improve the detection of vulnerabilities, including our recently introduced tool for doing some limited automated security checks of plugins and our plugin for making it easier to confirm the existence of the very serious PHP object injection vulnerabilities, which has been cited in the discovery of a couple of those vulnerabilities by others.

20 Oct

WPScan Vulnerability Database Falsely Claims WP Job Manager Contained Arbitrary File Upload Vulnerability

When it comes to getting data on vulnerabilities in WordPress plugins there are a number of companies that are interested in making it appear they are generating that type of data without having to do the work it takes to provide that. They instead of reuse data from the WPScan Vulnerability Database, sometimes without disclosing that is the source and in every instance we have seen so far, without providing a warning as the low quality of the data. As example here was what Wordfence’s plugin recently sent out to people using the plugin Sermon Browser:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:
https://wpvulndb.com/vulnerabilities/6404

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.
https://docs.wordfence.com/en/Understanding_scan_results#Plugin_has_been_removed_from_wordpress.org

As we noted previously, the vulnerability being linked there had been fixed six years ago. For whatever reason when it was added to WPScan’s data three years ago it was not listed as being fixed, so when Wordfence reused the data without checking it first they spread inaccurate information. They didn’t include a disclaimer to warn people that they hadn’t checked that data, they even make it sounds like the opposite as they said “It has unpatched security issues”, and therefore didn’t know if it there was any veracity to the claim of a vulnerability in the plugin.

The problem with WPScan’s data isn’t limited fixed vulnerabilities are not correctly labeled as being fixed. Another issue is vulnerabilities that didn’t actually exist being included and labeled as being fixed despite not existing, an example of we just ran across while preparing another post. That could be a problem if you were using WPScan’s data while working on cleaning up a hacked website, since you might believe that you have discovered a likely cause of a hacking, through an outdated plugin, only to later find that wasn’t the case when the website gets hacked again.

This isn’t the first time we have run across this, but what we found notable about this instance is that one of our blog posts is cited despite contradicting their information.

Here is the entry as it is currently:

The claim is that there was an unauthenticated arbitrary file upload vulnerability in the plugin WP Job Manager, which has been fixed. There first reference for that, an entry at Packet Storm from July of last year, makes the claim that there was a remote shell upload/arbitrary file upload vulnerability as of version 1.25. In August of last year we wrote a post detailing why that was false, as the plugin limits what types of files can be uploaded. The plugin did and still does allow anyone to upload files permitted by WordPress.

The third reference cited by WPScan states that:

 Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in.

All that indicates is that those not logged in to WordPress can no longer uploads files through WordPress AJAX functionality, but as we already mentioned the plugin did not allow arbitrary files to be uploaded, so the change does not relate to what they said was fixed.

What is the other important part of this is what was mentioned in the post of ours that was cited:

But more importantly we didn’t understand how the change made was supposed to fix the issue since by default those that didn’t already have a WordPress accounts could still upload images through the plugin.

As the title of our post indicates, “Image Upload Capability in WordPress Plugin Being Abused”, the issue with this plugin was that the ability to upload images was being abused. The change made doesn’t actually remove that capability, it just removes the ability to do that through AJAX. You don’t have to take our word from that, here is what one of the developers said:

Hi there! They shouldn’t be prevented from uploading files, just through the use of the Ajax endpoint. The forms should fallback to normal file uploads and work just fine.

So to recap, the vulnerability that WPScan lists didn’t exist, but if there was a security vulnerability in the plugin, it still exists, just the way it was being abused at the time was removed.

While we think that WPScan’s data is good source for a lot of people because it can be accessed for free, you do get what you pay for. Where its use is more problematic is when it is used by security companies without a proper disclaimer as to the sourcing and quality issues, which also extend to have a limited set of new vulnerabilities in it. If those companies were to admit to all of that, it would probably make more people understand that the inflated claims these companies often make about their expertise are far from the truth. (It would also help us, as once people realize the value of such data, getting better quality data would likely be of more interest to some of them.)

06 Oct

Wordfence Doesn’t Want You to Know We Discovered the Vulnerability in Postman SMTP

We have seen a lot sleazy stuff out of the WordPress focused security company Wordfence, including claiming that they care more about security than the WordPress team as justification for creating a fake threat, so it shouldn’t be surprising to find their post about the removal of the plugin Postman SMTP from the Plugin Directory, which people assume is due to a reflected cross-site scripting (XSS) vulnerability we discovered, doesn’t mention us or link to our post despite being about the only substantive thing mentioned in their post. They clearly are aware of who the source was as the second paragraph clearly references our post:

On June 29, an unnamed security researcher published the details of the vulnerability, including a proof of concept. A proof of concept is a demonstration that shows the plugin author (and in this case the entire internet, including potential attackers) how to exploit the security vulnerability. The security researcher had apparently attempted to reach the author but had been unable to.

It is worth noting that here that this type of vulnerability is highly unlikely to be exploited on the average website (contrary to a recent claim by Wordfence that this type of  vulnerability “will be exploited by attackers“) and the proof of concept included just reiterates what is already mentioned in detailing the vulnerability, so someone that would be exploiting this type of vulnerability shouldn’t have a problem without it. Someone looking to do a targeted attack against a website using this plugin, likely could have easily found this vulnerability on their own (and who knows, they might already have).

One of the reasons we include a proof of concept on how to exploit vulnerabilities is so that others can double check our work, as among other things we often find that vulnerabilities that are being disclosed and claimed to be fixed, haven’t actually been. If there is a proof of concept it is easier to catch that vulnerability hasn’t been fixed and then we can work with the developer to get it fixed (and usually in that situation it can be fixed very fast). It also helps to check if there are other related vulnerabilities that have been missed, as has been the case with Wordfence’s discovered vulnerabilities in the past (or more recently them missing that vulnerable code still was in a plugin, though not accessible). There also was the situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it.

It is also important to note that all major web browsers other than Firefox have XSS filtering to protect against this type of vulnerability for years, which is likely plays an important role in it not being likely to be exploited.

When we have discussed things that Wordfence has written we have properly credited them.

Advertising Over Improving Security

We wouldn’t mind them not mentioning us if they had finally decided to actually help the effort to get WordPress to properly handle removed plugins, since that is so important. Instead their post is mostly just an ad for their plugin and service, which both leave people not knowing why plugins are removed.

Wordfence clearly understands there is an issue with people not knowing why plugins are removed as the first paragraph of their posts states:

We have received a number of questions regarding the Postman SMTP plugin which was removed from the WordPress.org directory this week.

We assume it was removed because it contains a publicly known reflected cross-site scripting (XSS) vulnerability that has not been fixed.

And later they write:

Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.

They didn’t write anything about doing anything to resolve that situation, which is easily resolvable if WordPress wanted to take action, but here is all the advertising they had time to include in the post instead:

Both Wordfence Free and Premium users who have the firewall enabled have been protected against attempts to exploit this vulnerability from day one. In addition, we alerted all Wordfence users who have the plugin installed when it was removed from the plugin directory.

It should be noted they didn’t provide any evidence that their plugin actually can protect against this type of vulnerability (or for that matter do they provide evidence that it does for other types and our testing hasn’t shown it to provide much protection). As we mentioned before the major web browsers other than Firefox provide protection against this type of vulnerability as well, something Wordfence didn’t note.

Wordfence Firewall Includes Robust XSS Protection

The Wordfence firewall includes protection against new and emerging XSS attacks. Both Wordfence free and Premium users have been protected against this attack since (and before) it was made public. This is a great example of why using a firewall to protect your website is so important: you are immediately protected against most new threats.

In cases where we don’t already protect against a new threat, we develop a new firewall rule, deploying it to our Premium customers in real-time and free customers 30 days later. This ‘virtual patching’ by our security analysts and developers keeps your sites safe.

Wordfence Alerts You When Plugins Are Removed From WordPress.org

When plugins you have installed on your site are removed from WordPress.org, Wordfence alerts you. There is a long list of reasons why the plugin team at WordPress.org might remove a plugin from the directory. One common reason is that someone has discovered a security vulnerability that has not yet been fixed. Since they don’t publicly announce that plugins have been removed, nor why, it is prudent for site owners to treat the plugin as a potential security risk and take reasonable precautions.

 

If you haven’t already, we suggest that you install Wordfence on all of your WordPress websites. It will alert you when your plugins have been abandoned or removed from the the WordPress directory. Its firewall will also protect you against new and emerging attacks.

Finally, consider upgrading to Wordfence Premium if you haven’t already. The real-time firewall rule updates will protect you from the latest threats. In addition, the real-time IP blacklist will stop all attacks from the most malicious IPs, regardless of what they’re up to.

Our Advertising

Since Wordfence is going to use a vulnerability we discovered to advertise their service so garishly, we will quickly plug our service, which would have not only warned you about the vulnerability in you were using the plugin back when it was disclosed in June, but we would have also have been available to help you make the best decision as to deal with.

The more customers we have the more we are able to improve the security of WordPress plugins for everyone using them. While this vulnerability has gone unfixed, this week we help get vulnerabilities fixed in plugins with 140,200+ active installs and we have contacted developers of plugins with another 500,000+ active installs about vulnerabilities in them that need to be fixed.

Fixing the Vulnerability

As we said before the vulnerability isn’t something that is a big concern, so it wouldn’t be a big risk to keep using the plugin in its current form, but fixing the vulnerability is easy.

On line 346 of the file /Postman/Postman-Email-Log/PostmanEmailLogController.php in the plugin replace this line:

346
value="<?php echo $_REQUEST['page'] ?>" />

with

346
value="<?php echo esc_attr($_REQUEST['page']) ?>" />

The esc_attr() added will escaping the value, which prevents the possibility of reflected cross-site scripting (XSS).

03 Oct

Wordfence Still Being Irresponsible When It Comes To Disclosing Vulnerabilities

On September 22, we discussed a PHP object injection vulnerability that had been fixed in the plugin Appointments, which we had spotted being fixed due to the proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. What was somewhat concerning about the handling of the vulnerability was that the vulnerable code still was in the plugin, though not accessible through it anymore. What had happened is the code originally was contained in one file and then that file’s contents were split among several files, but the old file was never removed. After we notified the developer, that file was removed, but the version number wasn’t changed so those already running 2.2.2 still have the code.

Two companies with a security focus had missed the code was still in the plugin, the developer of the plugin, WPMU DEV, and the discoverer of the vulnerability, Wordfence. That is a good reminder of why providing the details of vulnerabilities that has been fixed is important because even security companies can miss issues related to a vulnerability. That has been the case in multiple instances with the few vulnerabilities that Wordfence has disclosed in the past, including a situation where they told people to update the plugin despite the vulnerability having existed in the most recent version of it. Making those instances more problematic was that Wordfence failed to provide the details that would have easily allowed someone else to check to make sure everything had been properly resolved. Only because we did the work to figure details of those vulnerabilities were we able to spot and help get some additional related vulnerabilities fixed in some of the plugins.

In the post on that vulnerability in Appointments we wondered if Wordfence would handle the situation better, if and when they mentioned that vulnerability:

 If they release information on this vulnerability, it will be interesting to see if they handle things better than they did last year.

We now have the answer, they didn’t. They release a post on it and couple of apparent PHP object injection vulnerabilities yesterday and it lacks the details that would have allowed someone to easily see that the same code existed elsewhere in the plugin. Since a PHP object injection vulnerability requires more than just knowing about the vulnerability (you need to be aware of code that can be accessed through the vulnerability), providing more details wouldn’t likely to have done little to increase the risk from disclosing more details.

Considering they are claiming all three vulnerabilities are zero-day vulnerabilities, which are vulnerabilities being exploited before the developer becomes aware of them, some hackers would already be aware of how to exploit them, further reducing the additional risk caused by doing that.

In that past Wordfence has referred to any vulnerability they discovered as a zero-day vulnerability and the post lacks details that would make it clear these all were really zero-day vulnerabilities, so the claim of them all being zero-days seem a bit questionable (though PHP object injection vulnerability are highly likely to be exploited).

The Missing Details Could Be Useful

For one of the other vulnerabilities, in the plugin Flickr Gallery, we also spotted it being fixed through our proactive monitoring. What isn’t mentioned in Wordfence’s post or further discussion of that post is a note added to that plugin alongside the fix for the vulnerability:

This plugin is deprecated, please remove it from your WordPress install.

With the third plugin we didn’t notice a PHP object injection being fixed in it at the time and in looking at the changes so far we haven’t figured out where there would have been a PHP object injection fixed. That vulnerability is supposed to have been fixed in version 3.7.9.3 of the plugin RegistrationMagic-Custom Registration Forms.

In looking over the changes made in that version the only change that directly involves code that could be involved in PHP object injection looks like this in version 3.7.9.2 (in the file /includes/class_rm_dbmanager.php):

681
$result = maybe_unserialize($wpdb-&gt;get_var("Select form_options FROM `$table_name` where `$primary_key` = $form_id"));

In 3.7.9.3 the code has been changed to use a prepared statement in the SQL query in it:

687
$result = maybe_unserialize($wpdb-&gt;get_var($wpdb-&gt;prepare("Select form_options FROM `$table_name` where `$primary_key` = %d",$form_id)));

There isn’t an obvious way that would prevent a PHP object injection vulnerability.

The rest of the changes mainly involve using prepared statements for SQL queries and adding a missing function.

As of version 3.7.9.3 there look to be 61 usage of the maybe_unserialize(), so it could be the change made in that version impacts code elsewhere that would have lead to PHP object injection. We are going to have to look closer at the rest of the code to try to figure out what is going on. If you have figured it out, please let us know.

Knowing where a PHP object injection would have been fixed there is important because it could help to get other vulnerabilities fixed, since it would make it more likely that others could spot similar vulnerabilities. For example, the way we noticed the other two vulnerabilities being fixed also led to us identifying 9 unfixed vulnerabilities related to PHP object injection that we disclosed just last month (we noticed additional ones through other methods):

26 Sep

Wordfence Falsely Claims Current Version of Removed Plugin Contains Vulnerability That Was Fixed Over Six Years Ago

A couple of weeks ago we noted that Wordfence was trying to make people reliant on their plugin instead of helping everyone in the WordPress community by getting behind the effort for WordPress to start alerting when websites are using plugins that have been removed from the Plugin Directory. One of the reasons we noted as to why what they were doing was problematic even for those using their plugins, is that the people on the WordPress side of things know why plugins are removed and could let people know why, while Wordfence can’t. It turns out though that Wordfence will present things in way that leads to people to believe otherwise, while in the case of at least one plugin, presenting incredibly inaccurate information about the security of it.

Through monitoring of the WordPress Support Forum we do to keep track of vulnerabilities in WordPress plugins, we came across the thread about the plugin Sermon Browser, which has been removed from the Plugin Directory. The original poster in thread wrote:

I just received a “Critical” security notice from my website last week. It stated that the plugin was removed from the WordPress repository because of critical security issue. Apparently a SQL injection vulnerability has been identified.

I am sure the owner was notified of the removal. But I would expect a “sticky” post or an update or something. Has anybody else heard of any response to this?

Below that was the message from Wordfence:

The Plugin “Sermon Browser” has been removed from wordpress.org.
Current Plugin Version: 0.45.19

Severity: Critical

Vulnerability Information:
https://wpvulndb.com/vulnerabilities/6404

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.
https://docs.wordfence.com/en/Understanding_scan_results#Plugin_has_been_removed_from_wordpress.org

Following the link to the entry on the WPScan Vulnerability Database in that message brings up this page:

The most important things to note in that is the vulnerability is not labeled as being fixed and the dates, the listing was added on “2014-08-01″ and last updated ” 2015-05-15″. From that page you can get the actual information on the vulnerability.

In looking over things we found that the vulnerability was actually fixed the same day it was disclosed, back on April 26, 2011.

That the information in the WPScan Vulnerability Database isn’t accurate isn’t a surprise. It was just back in June that we discussed their inaccurately label an unfixed vulnerability as being fixed. In April we noted another instance where they labeled fixed plugins as not being fixed. We could go because there are plenty of instances we have discussed on this blog, which certainly are not all of them.

WPScan’s accuracy issues are only part of the problem here, as Wordfence is choosing to further spread the inaccurate information. Either they haven’t done any due diligence at all on their data source on plugin vulnerabilities, which would not put them in a good light, or what seems more likely, they know and don’t care. It’s not like no one has pointed out the problem with Wordfence using that data before, we did that back in May. The other option Wordfence could use is to check the information to make sure it is correct before passing it along to those using their plugin, but what we have seen repeatedly is they either don’t have the skills to do that sort of thing or are too lazy to do that.

If you are a customer of Wordfence’s you might want stop that since you are giving money to a company that doesn’t seem to have interest in really improving security, but you should at least contact them and let them know they should get behind the effort to get WordPress to properly handle alerting for removed plugins.

If you want accurate data on vulnerabilities in WordPress plugins you can get that with our service or in more limited form with the free data on vulnerabilities that are already being exploited that comes with the companion plugin for our service.

If you are using a plugin that isn’t being supported by the developer anymore, over at our main website we offer a service for taking over abandoned WordPress plugins, which includes doing a security review of it.

22 Sep

Vulnerability Details: PHP Object Injection Vulnerability in Appointments

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

Since June we have been doing proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. So far that has lead to identifying a couple of dozen vulnerabilities. For the third time it has lead to identifying a PHP object injection vulnerability being fixed in a plugin, this time in the plugin Appointments.

In this instance though what we also noticed was that the new version of the plugin put out to fix the vulnerability still contained the vulnerable code, though it is not accessible through the plugin. What makes that situation stand out is that two companies that put out WordPress security plugins were involved in fixing this vulnerability and appear to have missed that remaining vulnerable code.

In version 2.2.2 of the plugin, two lines that pass the value of cookies to the maybe_unserialize() function, which would have permitted to PHP objection to occur, were removed. They are the following lines in the file /includes/class-app-sessions.php:

27
$apps = maybe_unserialize( stripslashes( $_COOKIE['wpmudev_appointments'] ) );
83
$data = maybe_unserialize( stripslashes( $_COOKIE['wpmudev_appointments_userdata'] ) );

Our monitoring picked up their removal, but at the same time that picked up the following two lines in the file being included in the file /includes/class_app_shortcodes.php in that version:

871
$apps = unserialize( stripslashes( $_COOKIE["wpmudev_appointments"] ) );
1699
$data = unserialize( stripslashes( $_COOKIE["wpmudev_appointments_userdata"] ) );

Those are almost exactly the same as the first two. With the only difference being use of the WordPress function maybe_unserialize() versus the PHP function unserialize() and single quotes versus double quotes.

In looking over the situation we found that the file /includes/class_app_shortcodes.php wasn’t being used, what looks to have happened is that the contents of that file were split in to different files and then that file was never removed.

This risk of that vulnerable code is limited since on its own the file can’t do anything. The risks we could think of is if someone was able to use some other code to cause this file to be loaded or that someone might reuse the vulnerable code from this file. The latter is something we recently saw happen with another plugin, though in that case the code was being utilized in the plugin it was copied from.

When the vulnerability existed in the plugin it was exploitable through several locations, including on pages using several shortcodes.

Security Companies Missed the Remaining Vulnerable Code

Normally a developer missing other instances where vulnerable code is still in the plugin isn’t something that we would be too concerned about, but in this case the developer is WPMU DEV, which also makes the Defender security plugin. We would expect that a company that provides a security plugin to be more careful about the security of their plugins.

In a look over how they promote that security plugin we didn’t get the feeling that they really have the level of concern for security that they should have when producing a security plugin. No where do they present any evidence of the effectiveness of the plugin overall or the effectiveness of its various features. One area where we know that what they are providing has limitations, is their checking for known vulnerabilities in plugins, as the source of plugin vulnerability data is WPScan Vulnerability Database, which has serious limitations, as we have discussed in previous posts. They really should be disclosing the source of the data in the marketing material and making it clear that the data they provide has serious limitations.

Something else that stuck out to us in how the plugin is promoted is this:

Brute force attacks are no match for Defender. Limit login attempts to stop users trying to guess passwords. Permanently ban IPs or trigger a timed lockout after a set number of failed login attempts.

Brute force attacks against WordPress admin passwords are not happening, what is happening, dictionary attacks, can be prevented by simply using a strong password, which WordPress does a good job of helping to people use. Protections meant to protect against brute force attacks would not always be effective against dictionary attacks and can lead to unnecessary complications.

In the changelog for version 2.2.2, one the entries seemed to be possibly referring to this vulnerability:

  • Fixed security issue (vulnerability) with data stored on a browser. Thanks to Matt Barry @ Wordfence

When we contacted the developer of the plugin about the remaining vulnerable code, they confirmed that did in fact refer to this vulnerability.

That Wordfence missed the remaining vulnerable code isn’t all that surprising based on their track record. Last year they disclosed several vulnerabilities in plugins and we found that three related vulnerabilities had not been fixed. The problem then wasn’t as much that they missed them, but that they were not providing the normal level of detail on the vulnerabilities they found that would have allowed someone to check things over and spot those related issues easily. Their providing limited details was not due to a concern about that being misused, but so they could market that they provided protection against the vulnerabilities that other firewall providers did not. In explaining why they were handling things they way they did they claimed that “At Wordfence the security of our customers and the greater WordPress community is of paramount importance to us.”,  which seems untrue when you consider that it was only because we figured out the details they didn’t provide that we could work to get the other vulnerabilities fixed. If they release information on this vulnerability, it will be interesting to see if they handle things better than they did last year.

File Removed

After we notified the developer of the remaining issue, the file /includes/class_app_shortcodes.php was removed. If you already updated to version 2.2.2 though you will still have the file. In normal circumstances that is harmless, but if you want to be extra careful you could delete the file or reinstall the plugin to get rid of the file.

Proof of Concept

With our plugin for testing for PHP object injection installed and activated, set the value of the cookie “wpmudev_appointments_userdata” to “O:20:”php_object_injection”:0:{}” and then when you visit a page with the shortcode “app_confirmation” (with a “title” attribute) the message “PHP object injection has occurred.” will be shown.

15 Sep

Wordfence Security Causing Full Path Disclosure Security Issue on Some Websites

Earlier this week we mentioned our concern over Wordfence promoting being reliant on their plugin instead of getting behind an effort to make WordPress more secure for everyone that uses it. We also noted that the average WordPress website shouldn’t even need a security plugin if security of WordPress was being handled properly, which should be the goal. The most important reason that the average WordPress websites shouldn’t need a security plugin is because WordPress should be secure out of the box for most usage of it, but there are additional reasons. One other reason is that security plugins, as is true of any plugin, can introduce security issues of their own, so if you add one (or more than one) you are introducing additional risk.

That isn’t a theoretical threat, last year we found that a security vulnerability in the current version of security plugin was being exploited. We recently disclosed that there is a PHP object injection vulnerability, which is a type of vulnerability that has been widely exploited in WordPress plugins, in the current version of another security plugin.

As part of our monitoring the WordPress Support Forum for information on vulnerabilities in plugins we came across a mention of a less serious issue that involves the most popular security plugin, Wordfence Security.

A forum poster by the name of David wrote:

See: https://www.exploit-db.com/ghdb/4544/

By default a user.ini file is created and contains the root path of the site on the server. This could allow hackers to more easily attempt a directory traversal type attack.

We checked and confirmed that there are websites where the full path for the website is disclosed in that file in a line added it to by Wordfence Security. The linked page includes a Google Dork for searching for impacted websites. Using that we got 13 pages of results (with up to 10 results per page) and with omitted results included 24 pages. Since Google could only show files where they somehow found a link to the file, there are probably many more websites where this file is viewable.

The full path alone won’t allow you to hack a website, but it could assist in some types of attacks. For example, certain vulnerabilities require knowing the full path to a file to take an action with the file, so the full path would assist in exploiting that. Also, for cPanel based websites the path contains the cPanel username, which could assist an attacker in certain instances, say if someone uses the same password across various websites.

What concerned us more was part of the response from a WordPress Wordfence representative:

The .user.ini file is created during the Firewall Optimization process. At the same time as the .user.ini is created code is added in .htaccess which prevents access to the .user.ini.

WordPress is supported on web servers that don’t use .htaccess files, which is something a company focused on WordPress security should know. But in reviewing things we found that Wordfence is aware of this. Looking over the plugin’s code, it has a warning for NGINX users that they should add code to the nginx.conf file to prevent the file in question from being viewable. We didn’t see anything similar for IIS in the code, but that is not officially supported by Wordfence.

In looking over the first 20 results in Google for the Google Dork provided in the link in the first message, we found that 11 of the websites were on NGINX servers, 7 on Apache HTTP servers, and 2 were on servers that were not accessible. Considering that NGINX is used on less websites than Apache HTTP server that seems to indicate that some of the issue is caused by people not adding the code to the nginx.conf file.

If you are using Wordfence Security you can easily check if you are impacted by this by requesting the file .user.ini at the root of your WordPress installation. So for example, if the homepage of your WordPress installation was at http://www.example.com, you would request http://www.example.com/.user.ini .

13 Sep

Wordfence Would Rather Promote Their Plugin Than Address Important Issues Putting WordPress Websites at Risk

When it comes to improving the security of WordPress it often times seems that security companies more interested in promoting themselves than actually improving security. One company that comes to mind is Wordfence, so it wasn’t surprising to see when they discussed the recent malicious takeover of the Display Widgets plugin it was devoid of any discussion of the real problems this situation highlighted and that need to be fixed, instead it was largely a rather explicit ad for people being reliant on their plugin, when the average WordPress website shouldn’t even need any security plugin if security was being handled right.

Advertising over Proper Security of WordPress

It only takes getting to third paragraph to get to them promoting their plugin:

Wordfence warns you if you are using a plugin that has been removed from the repository. During the past months you would have been warned several times that this plugin has been removed with a ‘critical’ level warning that looks like this:

Further in the post is a whole section promoting how they warn:

The last part of that stands out:

I’m incredibly proud that our team took the initiative and got this feature released in June of this year, just in time to save many of our free and paid customers from being affected by this malicious plugin.

What is striking is while they believe that is so important, they don’t even suggest that this capability should be in WordPress itself. That is something that we have been trying to get to happen for over 5 years. It would be great if Wordfence would get behind that effort instead trying to get people reliant on their plugin. If a security feature is truly needed for the average website, it shouldn’t require an additional plugin or service since that will leave a lot of websites insecure. Of course if your plugin already has 2+ million active installs, you probably don’t have an incentive to make sure WordPress is properly secured since it would negate a lot of the people needing your plugin.

You don’t have to take our word that they want people reliant on their plugin, here is another part of the post where they explicitly say this:

As I mentioned in the introduction, Wordfence would have warned you each time this plugin was removed from the repository. It is important that you have Wordfence installed and have your email alerts configured.

In another section they say knowing that plugins have been removed is part of being “on top of security”:

I would also ask you to not start any witch hunts. I’m sure some folks are angry about what transpired here, but things happen and if you were on top of security, you would have been notified that the plugin was removed from the repository and you would have removed it from your site.

Getting back to that previous section, not surprisingly coming from Wordfence, the rest of what they are saying isn’t really true. The users of their plugin were only warned that the plugin had been removed after it was removed from the Plugin Directory, which means even if they removed it immediately they would have still been affected. But it you look at the second quote there, that person had kept the plugin installed after Wordfence warned about it being removed multiple times.

Seeing as plugins are removed from the Plugin Directory for various reasons, removing a plugin from a website immediately just because it was removed from the Plugin Directory is less than ideal. For example, if a plugin is removed because the developer is no longer supporting it, while you would probably want to move away from it, you wouldn’t have need to do that immediately. This would be another reason for having WordPress notify people, as they would know why it was removed.

Any protection that Wordfence provided was not based on anything they did beyond adding a feature (years after they should have), which brings us to what else is missing from their post.

Those Who Don’t Learn From History are Doomed to Repeat it

One constant in security is change; you have to continually review what is happening and adjust. For example, with our service that has meant an increasing focus of PHP objection vulnerabilities as those became a popular target for hackers. That has lead to us identifying and helping to get many of those fixed before they are exploited on a large scale (and hopefully before they were ever exploited).

When it comes to this situation, Wordfence doesn’t take anything close to a critical look as to what happened on the WordPress side of things. That is particularity striking since they are claiming that how you would have protected yourself from this would be by removing the plugin after it was removed from the Plugin Directory, which has to be done by someone on the WordPress side of things.

The reality here is things did not go right and there isn’t good reason to believe that they will get corrected when they involve issues that have been known for some time and when those in the security industry are more interested in promoting their products and services over even touching on them.

The start of the problems with this plugin are not something we would fault anyone other than the person that took it over. Unlike Wordfence we never mentioned who previously owned it, because that seemed rather irrelevant to what happened after they sold it.

Depending on how ownership is transferred it isn’t necessarily possible to determine if it has been transferred without someone involved publicly disclosing it. It might make sense to provide a process where people could indicate they are transferring ownership, which could provide better insight if something goes wrong, but it would be limited, since someone with malicious intentions would probably try to avoid that happening.

It also is would be very difficult to spot someone first adding malicious code to a plugin if they want to hide what they are doing. The proactive monitoring of changes made to plugins that we do uses checks based in part on previous instances of intentionally (and possibly intentionally) malicious code, but so far we haven’t found anything added this time that we think it would make sense to look for.

Where the fault starts is after the first version by the new owner, which would request a zip file from a remote location and loads code from it on the website. That not only violated the developer guidelines for WordPress plugins, but should have raised serious red flags because even what was presented as the legitimate usage of the files added, which was tracking anyone accessing a website using the plugin, has been the kind of thing that has been done with other software when it has been taken over by bad actors.

Let’s go the timeline included in the Wordfence post for what happened with the next release of the plugin following that occurring:

Then on June 30th, 7 days later, the developer released version 2.6.1 of the plugin. This release contained a file called geolocation.php which, no one realized at the time, contained malicious code

The last part is in red in original, so it is really being highlighted. What is never addressed in the Wordfence post is if someone should realized that it contained malicious code. In our looking over the code in that version, based on what was in the previous version it seems like it should have at least raised questions about what is going on. We believe if those questions were asked of the developer the plugin would not have returned. This incident seems like it should be a wakeup call that how things have been has not been working, but if security companies won’t say that, it is less likely to happen.

Changes don’t have to just rely on people on the WordPress side of things. One idea we had mentioned in that post, is that when a vulnerability is fixed in a plugin that there should be a capability for others outside of the WordPress team to be provided information needed to look over what happened and what the fix was, which could also apply for other security issues. That would provide a better chance of things like what happened here being caught. That seems like a really good idea especially when you consider that not only do we frequently find that vulnerability that were supposed to have been fixed haven’t been, but we have specifically found that has occurred with plugins that have been removed from the Plugin Directory.

On July 23rd, Calvin Ngan opened a Trac ticket reporting that Display Widgets was injecting spammy content into his website. He included a link to Google results that had indexed the spam and said the malicious code is in geolocation.php.

On the 24th of July the WordPress.org plugin team removed Display Widgets from the plugin repository for a third time.

On the 2nd of September version 2.6.3 of the plugin was released and it included the same malicious code. Line 117 of geolocation.php in version 2.6.3 even contains a minor bug fix to the malicious code, which makes it clear that the authors themselves are maintaining the malicious code and understand its operation.

On September 7th a forum user on WordPress.org reports that spam has been injected into their website on the Display Widgets plugin support forum.

There is something missing in the timeline that seems important. As we mentioned in one of our posts the information provided in what is linked to for July 23 shows what the malicious code in the plugin was being used for, but also where the malicious code was. Yet the plugin returned at some point before September 7th (Google caching shows it had been returned by at least September 5, but it could have occurred long before that). How did the plugin get returned when it should have been clear that there was malicious code in it?

Accuracy Issues

One of the other problems we often see with things put out by Wordfence is they make claims that are not accurate, which hasn’t so far caused others to have the level of scrutiny of their claims they should receive. The claims are sometimes rather serious, such as a recent claim that a plugin was under attack. There is a glaring one in the timeline, though less serious one, in this post, which we mention, because, as we just said, people should be much more careful before believing or repeating claims made by Wordfence. Here is the first mention of it:

On the 2nd of September version 2.6.3 of the plugin was released and it included the same malicious code. Line 117 of geolocation.php in version 2.6.3 even contains a minor bug fix to the malicious code, which makes it clear that the authors themselves are maintaining the malicious code and understand its operation.

That links doesn’t work anymore; here is a link to the same thing that still works.

They make it again here:

The 2.6.3 release of their plugin makes a minor modification to the malicious code in geolocation.php to fix a bug in the code that lets the plugin author list the malicious posts they have published on your site.

The change they are referring to occurred in version 2.6.2.1, not 2.6.3. The only change made in version 2.6.3 was to fix a supposed vulnerability, which didn’t exist. That seems like it could be an important element to what happened here, but goes unmentioned in Wordfence’s post for some reason.

Update 9/18: After looking at an article at the Threatpost that sourced most of its information from Wordfence’s post, we noticed a more problematic issue related to this inaccuracy. Wordfence inaccurately stated the that versions up to 2.6.3 were contained malicious code:

Actually, the backdoor exists on any site running versions 2.6.1 to version 2.6.3 of the plugin.

Version 2.6.3.1, which Worfdence never mentioned, also contained malicious code.

01 Sep

SiteLock, Kasperky Lab, and Wordfence Mislead Public on Threat from Vulnerability in WordPress Plugin

Yesterday over at our main blog we noted how the web security company SiteLock and their web hosting partner 123 Reg, a GoDaddy brand, are making baseless claims as to the likelihood of websites being hacked to try scare customers in to purchasing SiteLock security services. In the meantime they and others in the security industry were also taking a minor security vulnerability discovered by SiteLock in a WordPress plugin that is used with WooCommerce and using misleading information to make it sound like a much bigger threat.

To see what happened let’s start with an article on the Threatpost, which is Kaspersky Lab’s news website. The article is titled Reflected XSS Bug Patched in Popular WooCommerce WordPress Plugin. No where in the post is there anything to backup up the claim this plugin is all that popular, instead the article makes a confusing mention of the claimed usage of WooCommerce:

An extension of the WooCommerce WordPress plugin, used by 28 percent of all online stores, has been patched against a reflected cross-site scripting vulnerability.

In the ranking of plugins available for sale through the WooCommerce Extension Store, the plugin is the 45th most popular plugin.

What is important to note is that is the risk from a vulnerability has little to do with its popularity, but instead is largely based on the type of vulnerability. As we will get to in a little bit, this type of vulnerability is not one that is a major concern due to not being likely to be exploited.

The focus on usage wasn’t just something that author at the Threatpost was focused on, SiteLock tried to find it out for the “purposes of accurate impact disclosure”, despite that not being a major factor in the impact.

Next up in inaccurate information in the post is this:

“At the time of discovery it was a zero day on the current version,” said Logan Kipp, WordPress evangelist for security vendor SiteLock. “If this was discovered by someone else, it could have been a real problem.”

A zero-day vulnerability is one that is being exploited before the developer is aware of it; it isn’t just a vulnerability that has yet to be fixed. Real zero-day vulnerabilities are very serious issue since keeping your software up to date won’t protect you against them at first, which seems to have lead to many in the security industry to use the term incorrectly.

The next section makes the vulnerability sound really concerning:

“Theoretically, this is weaponizable by sending a crafted link to any party who has a set of logins on that website,” Kipp said. “And if they have an active session, you could hijack that session.”

An attacker could email that crafted link to an already established vendor on a site running WooCommerce. If the vendor is logged in and clicks on the link, an attacker could capture the session and run scripts on the vendor’s browser, taking control of any functionality they have, Kipp explained.

“The chances are very high that if they are the webmaster, they’re going to be logged in at the time of clicking the link and they’re going to have very high privileges,” Kipp said. Kipp characterizes XSS as a tool to gain higher privileges.

“It’s a means to go further, a foothold,” he said. “So while in itself it may not cause any direct damage to the website, we could potentially gain administrator privileges by hijacking sessions.”

The keyword there though is theoretical, because we just don’t see reflected cross-site scripting (XSS) vulnerabilities being exploited against the average website at this time. That could change at some point and it is possible that it could be used in a targeted attack.

What isn’t mentioned in any way in that article or SiteLock’s own article about this and is a possible partial explanation why you don’t seem much targeting of this type of vulnerability, all of the major webs browsers other than Firefox have protection against this type of vulnerability through XSS filtering. So to exploit them you would have to hope the exploitee was using Firefox or come up with a way around the protection provided by the web browser (or multiple ones to get around different protection in different web browsers).

If the SiteLock employee had left their comments with the above it would have been accurate, but they didn’t:

“A lot of times it’s overlooked because people don’t take it seriously. It’s a huge problem because folks don’t always grasp that maybe it can’t modify the website itself, but this is a perfectly weaponizable vector to target visitors,” he said.

This type of vulnerability isn’t a huge problem since it is unlikely to be exploited and isn’t a perfectly weaponizable vector.

Wordfence Jumps in

In what shouldn’t be surprising to anyone that is mildly familiar with the WordPress focused security company Wordfence, in their coverage of this vulnerability they passed along to their readers inaccurate information. Here is the first paragraph:

A reflected cross site scripting vulnerability has been reported in a premium WordPress plugin for WooCommerce known as the ‘Product Vendors‘ plugin. This plugin is used by 28% of all online WooCommerce stores.

As mentioned earlier the 28% really refers to claimed usage of WooCommerce, not usage of the plugin.

Further in to the post they make the claim that vulnerability “will be exploited”, despite the fact that there is very little likelihood of that:

If you are running an older version of the Product Vendors plugin, it is important that you upgrade immediately to avoid having your site exploited. This vulnerability is now public and will be exploited by attackers.

While they make a claim that their plugin will protect against this type of vulnerability (without providing any evidence), they make no mention that web browsers provide protection:

If you are using Wordfence it is unlikely that your site is exploitable because Wordfence includes advanced XSS protection for our free and paid customers.

Also worth noting is that they make no mention that SiteLock discovered the vulnerability, which seems to be in rather bad form.

Overall it looks like Wordfence saw this as a way to market their service and either they don’t have the capability to provide accurate information when it comes to security or they intentionally are misleading people. Based on everything we have seen from them, either seems possible, which doesn’t speak well to the state of WordPress security when you consider they are the company behind the most popular security plugin.

Why This is a Problem

When you strip out the false information included in the articles the problem with this type of coverage of vulnerabilities can be seen in another part of the Wordfence article:

Product Vendors version 2.0.35 is affected by the vulnerability. If you are using this plugin, you need to upgrade immediately to at least version 2.0.36, which includes the fix. The current version of Product Vendors is 2.0.40.

In the Product Vendors changelog, they do not mention that a vulnerability was fixed. The changelog entry for 2.0.36 simply says:

2017-07-28 – version 2.0.36
* Fix – Adjusts how we handle the vendor registration form validation.  

The takeaway from that should be that you should be keeping you plugins up to date at all times, since if this vulnerability was as serious as these security companies make it sound you would have left your website insecure for over a month if you relied on them telling you to update it instead of just updating it. Wordfence doesn’t seem to understand the importance of keeping plugins up to date seeing as they are not telling people they need to update to the latest version of the plugin despite knowing that they were unaware until a month after the fact that the version they are telling people to update to now, contained a security update.

The situation get worse when you consider that many more serious vulnerabilities don’t get covered. For example, we haven’t seen coverage of a real zero-day vulnerability in the plugin Asgaros Forum that was being exploited a couple of weeks ago. What also doesn’t get much coverage are vulnerabilities that haven’t been fixed, which are ones that could use news coverage because simply keeping your plugins update to date won’t protect you. As an example of that, on Tuesday we disclosed that a PHP object injection vulnerability, which is one that is much more likely to be exploited than a reflected XSS vulnerability, exists in the current version of a security plugin with 6,000+ active installs.