13 Oct

Not Really a WordPress Plugin Vulnerability – Week of October 13, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WP Smush

There recently was a report of a directory traversal vulnerability in WP Smush. If you believed the developers (who are also the developer of a security plugin) this is a vulnerability, the changelog for version 2.7.6 is:

  • Security: Fixed path traversal vulnerability. Thanks Ricardo Sánchez(@neorichi) for responsible disclosure.

The report provides a link that is supposed to confirm that it is a vulnerability, that link is to this comment in a thread on the WordPress Support Forum:

@neorichi, Just to update you, we’ve a new security release to fix the bug.

Appreciate your efforts to report this responsibly.

Cheers, Umesh

Looking at the proof of concept it seemed like something might be off about this, as it seemed that you might need a nonce to exploit the issue, but the report doesn’t explain whether a valid nonce is needed or not and if so, where it could be found:


That URL indicates that an AJAX accessible function is being accessed. Looking at version 2.7.5 that function is only accessible to those logged in, which is not noted in the report (that would make this an authenticated vulnerability at least):

add_action( 'wp_ajax_smush_get_directory_list', array( $this, 'directory_list' ) );

Looking the function being accessed, directory_list(), which is located in the file /lib/class-wp-smush-dir.php, you can see that before it checks for a valid nonce it checks to make sure the user making the request has the “manage_options” capability:

function directory_list() {
	//Check For Permission
	if ( ! current_user_can( 'manage_options' ) || ! is_user_logged_in() ) {
		wp_send_json_error( "Unauthorized" );
	//Verify nonce
	check_ajax_referer( 'smush_get_dir_list', 'list_nonce' );

Users with the “manage_options” capability would normally only be Administrators (and if others are given the capability they would normally be able to create Administrators accounts), which would normally have the ability to view the directory structure with their capabilities, so this isn’t really a vulnerability.

If you are going to claim this is a vulnerability (as the folks at ThreatPress,  WPCampus, and the WPScan Vulnerability Database have) we don’t see how it could be claimed that it is fixed as the change just restricts you to accessing directories within in the WordPress directory:

//Get the Root path for a main site or subsite
$root = realpath( $this->get_root_path() );
$dir     = isset( $_GET['dir'] ) ? ltrim( $_GET['dir'], '/' ) : null;
$postDir = strlen( $dir ) > 1 ? path_join( $root, $dir ) : $root . $dir;
$postDir = realpath( rawurldecode( $postDir ) );
//If the final path doesn't contains the root path, bail out.
if ( !$root || $postDir === false || strpos( $postDir, $root ) !== 0 ) {
	wp_send_json_error( "Unauthorized" );

Persistent Cross-Site Scripting (XSS) Vulnerability in Contact Widgets

A frequent source of false claims of vulnerabilities in WordPress plugins is a lack of understanding of the WordPress security model. WordPress has a capability “unfiltered_html” that allows users to do the equivalent of cross-site scripting (XSS), which in simply terms is just the ability to use JavaScript code. A claim of a persistent cross-site scripting (XSS) vulnerability in the plugin Contact Widgets  involved adding JavaScript code to a widget that is part of the plugin. Normally only Administrators are allowed to edit widgets, so the testing likely was done with a user who has the ability to do the equivalent of the vulnerability.

In one of the responses to the claim, one of the developers responded:

Then this is not a bug. We explicitly allow Administrators to do whatever they want in the widget via that unfiltered_html permission, just as core does with the Text widget.

Looking at the code here is what he is talking about (in the file /includes/class-contact.php):

'sanitizer'     => function( $value ) { return current_user_can( 'unfiltered_html' ) ? $value : wp_kses_post( stripslashes( $value ) ); },

Just to further confirm things were working correctly, we gave an Author level user, who doesn’t have the “unfiltered_html” capability, the ability to edit widgets by giving them the “edit_theme_options” and then tried the proof of concept. As expected the malicious input was sanitized and there was not exploitation, so there isn’t a vulnerability here at all.

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:

Status New

It has unpatched security issues and may have compatibility problems with the current version of WordPress. Get more information.

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.

18 Sep

Neither ThreatPress’ Database Nor Any Other Contains All Known WordPress Plugin Vulnerabilities

When it comes to getting data on vulnerabilities that have been in WordPress plugins that are being used on a website you have two main options. You can pay for our service and gain access to the data that comes with that or there several free sources of vulnerabilities available that can be accessed through plugins (there are others selling access to that free data and other sources that provide limited data on plugin WordPress plugin vulnerabilities as part of more general vulnerability data).

The free data is good option for a lot of people because it is free, but as the old saying goes you get what you pay for. The quality and quantity of data is lacking in comparison to what we provide, so we wouldn’t recommend them for websites that have security needs that would warrant being able to spend money on security.

A problem that we have found is that there are people unintentionally or intentionally making claims that those free sources are in fact much better than they are. That obviously is problematic for us, since people might believe that they are not getting more when paying for access to data, but it also leaves people that use those sources believing that they are being provided better data than they really are.

In May we touched on a claim that the WPScan Vulnerability Database has the “the most complete list of vulnerabilities” in WordPress plugins and in July we further confirmed that to not be accurate as we found that we had added 3 times as many vulnerabilities as that source in the month of June.

Recently we ran across someone that was has repeatedly promoted another source of data, ThreatPress. One claim being made about that source stood out:

It includes all known vulnerabilities

Based on knowing what we do and checking on how others are doing (because we want to make sure we are providing the best data possible), we can say with complete certainty that no data source contains all known vulnerabilities in WordPress plugins.

One way quick way to measure the completeness of data is to look at how many newly disclosed vulnerabilities have been added to sources recently. To do that we took a look at how many vulnerabilities disclosed so far this month have been added to the data sets of ThreatPress, WPScan Vulnerability Database, and for us. Here are the results:

  • ThreatPress: 2
  • WPScan Vulnerability Database: 3
  • Plugin Vulnerabilities: 14

You can see there is a clear difference between what you are getting with a free source versus paying for access to our data. Even the 14 vulnerabilities we have in our data isn’t all of them this month, as there are several vulnerabilities that we are still in the process of reviewing before adding to our data set.

Looking at the vulnerabilities the other two sources are missing, a couple of things stood out.

One of them is that neither of the free sources have any of the 3 vulnerabilities we have added to our data set that have not been fixed, which seem like they would be important to include.

The other is that the majority of new vulnerabilities added in our data set so far this month are also vulnerabilities that we discovered, all of which are missing from those free sources, despite them being publicly disclosed at the same time we added them to our data set.

That second issue also gets to an important point about our service; our service isn’t just about collecting data on vulnerabilities disclosed by others as those other data sources incompletely do. Among other things, we are discovering vulnerabilities and helping to get vulnerabilities we and others have discovered fixed. Recently most of the vulnerabilities we have discovered have come from our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. Other sources are the security reviews we do of plugins selected by our customers and additional vulnerabilities we identify while reviewing reports of vulnerabilities that have been discovered by others.

28 Jul

We Actually Help to Get Vulnerabilities in WordPress Plugins Fixed

When it comes to the security industry surrounding WordPress one of the disheartening things we see is when companies that are doing harmful things, like making claims that WordPress is insecure in ways it isn’t, to sell their products and services are somehow praised for being focused on the community. When that happens companies are less likely to do things that would actually help everybody and instead focus on things that actual make the security situation worse. At this point it wouldn’t take much to help out improve the security of hundreds of thousands of websites.

We do rather extensive monitoring of reports of vulnerabilities in WordPress plugins to make sure we are providing the best data on WordPress plugins. One of the places we monitor is the WPScan Vulnerability Database because occasionally people will submit reports of vulnerabilities directly to them. Through that monitoring last week came across a report from another website of a reflected cross-site scripting vulnerability in the plugin WP Statistics. That is a type of vulnerability that is highly unlikely to be attempted to be exploited on the average website, but with 400,000 active installs according to wordpress.org, there is a decent chance that it might be installed on some website that would be targeted by hackers and there could be exploit attempts against those websites (the average website doesn’t face targeted attacks).

The report on the vulnerability didn’t make any mention of any attempt to contact the developer of the plugin and based on the quick response and resolution we saw when we reported a similar vulnerability we found to the developer several months ago, it seemed likely that hadn’t happened. When we contacted the developer this time we also got a quick response and several days later the vulnerability was resolved. The developer made it sound like no one else had notified them before us, despite the vulnerability already being included the WPScan’s data, which is used by numerous WordPress security products and services.

It would seem that the people behind the WPScan Vulnerability Database didn’t do notify the developer either as we received several follow up emails from the developer letting us know that the new version had been submitted to GitHub and the released on the Plugin Directory. So if the WPScan people had also notified the developer they would have known that this has been fixed. But as of now it is not listed as being fixed in their data, despite the fix being released four days ago (if it was, there would be a mention of that in the Affects section):

This isn’t a one off situation, as we have regularly found that developers have not been notified of publicly disclosed vulnerabilities in their plugins.

11 Jul

We Added Three Times As Many Previously Unknown Vulnerabilities as the WPScan Vulnerability Database Did Last Month

If you are getting vulnerability data on WordPress plugins from someone other than us it is likely coming from the WPScan Vulnerability Database. That this is the data source being used often isn’t disclosed and we have yet to see anyone put any proper disclaimer as to the quality of the data or that they are simply passing along unverified claims.

If you go back through previous posts we have tagged related to that data source you can see more about the issues that come with their data, but we thought another way of looking how we provide superior data (which is just one of the features of our service) and why anyone paying a security service shouldn’t be provided their data was to look at how we compared to them in adding previously unknown vulnerabilities to our data set last month. In doing that we spotted an improvement to our process to provide even better data (we have a post coming out soon about another recent improvement) and a reminder that others involved in disclosing vulnerabilities can do a better job.

The top line, which people would probably be most interested in, is that we added 43 previously unknown vulnerabilities to our data last month and WPScan Vulnerability Database only added 14. That works out to them having only added a third as many, 33%, vulnerabilities last month.

WPScan Missed the Most Serious Vulnerabilities

Quantity isn’t everything though. While much of the security industry seems to be all too willing to make minor vulnerabilities sound like big threats, the reality is that most vulnerabilities are of little threat to the average website. They would be of more concern for the small sliver of websites that are likely to be targeted by hackers, which is the kind of websites we see more as being ones that it makes sense to use our service.

In looking at the vulnerabilities added to both sources last month, two vulnerabilities, an arbitrary file upload and arbitrary file viewing vulnerability, in one plugin stand out. Both of these are ones that are likely to be targeted by hackers if they were aware of them. The vulnerabilities were fixed, but the developer didn’t change the version number when they made that change. That means that those that already updated to the latest version remain vulnerable (as well as anyone still running an older version). We notified the developer after spotting that problem, but nearly a month later the version number still hasn’t been changed. For those using our service, they were notified long ago and provided instruction to resolve this problem by uninstalling and then reinstalling the plugin. For those relying on the WPScan Vulnerability Database’s data, they are completely unaware of these vulnerabilities.

There really isn’t a good reason for WPScan Vulnerability Database to missing those vulnerabilities. While we found that the vulnerabilities had been discovered and fixed through our extensive monitoring, which we have seen no evidence that anyone else even comes close to doing, the people behind that data source (or anyone else since they accept public submissions) could have simply followed our blog and become aware of these vulnerabilities, but apparently doing that is too difficult.

Room for Improvement on Our End

Since we have pointed several major problems with WPScan’s data additions, it would be unfair not to point out where we were less than perfect. To do that let’s take a look at the vulnerabilities added to WPScan’s data last month and whether we included them.

Also Included

10 of the 14 vulnerabilities they added were also added to our data during the month:

The last vulnerability listed there though is a good reminder of one of the quality issues with WPScan’s data. While their data lists the vulnerability as having been “fixed in version 4.6.5”, in truth it wasn’t fixed in that version or even fixed at the time they listed it as having been fixed. As we noted at the time, we notified the developer of the disclosure of the unfixed vulnerability and it was fixed shortly after that. If not for us the vulnerability likely would still be in the plugin.

Not Really a Vulnerability

Two of the reported vulnerabilities they included are ones that we were aware of but did not included in our data since they really are not vulnerabilities:

For Photo Gallery by WD, we already discussed the reason for the lack of inclusion.

For WP Jobs, access to the relevant page is restricted to those with the edit_themes capability, which would normally be Administrators, so this really wouldn’t be a vulnerability since Administrators normally already have the ability to do the equivalent of this. There is the possibility of related type of vulnerability that we have started to add to our data for which that plugin should be listed, which we will be discussing in an upcoming post.

Missed Vulnerabilities

Finally two vulnerabilities that actually existed that we were aware of but had not included in our data as of last month (they are now included):

For WP-Testimonials, the vulnerability was listed by the discoverer as being exploitable by an “authenticated user”, that is, someone logged in to WordPress. What was missing and often is missing from reports is what level of access a user has to have to exploit the vulnerability. That obviously makes a big difference, since most potential vulnerabilities are really not vulnerabilities if only accessibly by Administrators since among other things, they normally can edit plugins and remove any security protection.

In the case of this vulnerability it was normally only accessible by Administrators, but what we originally missed is that the plugin allows changing what users had access to the relevant page, so we should have listed it. We normally do check for that, but in preparing this post we realized a better way to do that. Instead of trying to look through a plugin’s settings, the better way to check for that is to look at the underlying code. In this instance when we went to write up this post we noticed the relevant code registering the vulnerable page listed the variable “$sfs_admng” as the capability need to access it:

add_menu_page('Testimonials', 'Testimonials', $sfs_admng, 'sfstst_manage', 'sfstst_adminpage', plugins_url('/wp-testimonials/sfstst_icon.png'));

When we went to look at what was used to specify that value we could see that it could be set from an option (setting):

if (get_option('sfs_admng') == '') { $sfs_admng = 'update_plugins'; } else {$sfs_admng = get_option('sfs_admng'); }

For WP Live Chat Support, the reason for our lack of earlier inclusion is the discloser had not provided enough information in their report to verify the vulnerability without us doing additional work. Doing that for this particular vulnerability got overtaken by other items that we needed to deal with. In this case though WPScan’s inclusion didn’t really provide their user with a better situation since when we got a chance to look into the details of the vulnerability we found that it had only been fixed in one of two locations it occurred. After we spotted that we notified the developer and it has now been resolved, so those relying on WPScan’s data and keeping their plugins up to date are protected despite not being told of what versions were really impacted.

13 Jun

Automattic Seems More Committed to Marketing Their Jetpack Service Than to a Safer WordPress Experience

For years WordPress has been knowingly leaving websites at risk of being hacked due to a refusal to warn when plugins are in use that known to be vulnerable and have been removed from the Plugin Directory due to that fact. Considering the damage that is caused by this and there not being any reasonable argument for not warning people, at times when removed plugins have been widely exploited we have started to wonder if this might not be due to gross negligence, but if there might be a more nefarious explanation.

The company closely associated with WordPress, Automattic, does have a several products marketed as security products, Jetpack and VaultPress, so allowing websites to be hacked to help those services could be an explanation, though we highly doubt it. That being said Automattic doesn’t seem to have the best interest of the public when it comes to security. For example, they have helped other security companies in pushing the false notion that there are many brute force attacks against WordPress admin logins, which takes the focus away from real security threats like unfixed vulnerable plugins.

While looking for something for another post we ran across something that relates to the issue of those removed plugins. On the Jetpack website they have a set of pages on the security of WordPress plugins named the WordPress Security Library. There they give the public information that WordPress has been refusing to. For example, they warn that plugin Form Lightbox is unsafe:



That refers to an option update vulnerability that exists in that plugin.

In explaining these pages in another in this section of the page, there is the following text:

About this information

This WordPress security information is part of our security library and is brought to you by Jetpack as part of our committment to a safer WordPress experience.

If you have any questions, please do not hesitate to contact us.

What isn’t mentioned there (as is so often is the case) is the source of that data, which is pretty clearly the WPScan Vulnerability Database. If you follow our blog, you would already be aware of the serious issues that come with the use of that source. As example of that, the plugin Downloads Manager is listed as being “Good” and the “current version safe”:

There is an indication there that it might not be, as they are not showing the name of the plugin instead its slug, “downloads-manager”, which seems to be because the plugin has been removed from the Plugin Directory. The reason for that is that the most recent version of the plugin has an arbitrary file upload vulnerability, which we discovered after we saw hackers targeting the plugin. That vulnerability isn’t in WPScan Vulnerability Database, as is the case with many very exploitable vulnerabilities we have discovered and publicly disclosed.

Even when WPScan has data on a vulnerability the Jetpack website isn’t always accurately presenting it (this seems to be a frequent issue with services and products reusing their data). For the plugin Delete All Comments they also list it as being “Good” and the “current version safe” despite the fact that they list a vulnerability being in up to version 2.0, which is the most recent version:


So Automattic is presenting bad information to those looking at this section of the website, but what makes this all the more troubling is that right below the “Safety Recommendations” section of these pages is two sections advertising their service:

So their commitment seems less to the safety of WordPress, seeing as they haven’t joined us in trying to finally get WordPress to warn about removed vulnerable plugins, and more to promoting their service using someone else’s data without disclosing that.

It is also worth noting that if their “Regular, automated scans of your site for malware, threats, and hacks.” are also using the WPScan Vulnerability Database’s data then you their customers are going to be unaware of many vulnerabilities, like the one in Downloads Manager, so if you are actually interested in protecting against vulnerable plugins then you should at least install the companion plugin for our service, since we list in the free data that comes with that, vulnerabilities like the one in Downloads Manager. For more complete data, as well the ability to vote/suggest plugins to receive a security review from us and helping us to further improve the security of WordPress plugins, sign up for our service.

01 Jun

DefenseCode and WPScan Vulnerability Database Falsely Label Unfixed Vulnerability as Being Fixed

A little over a month ago we put out a warning to be wary advisories from the company DefenseCode after our interaction with them regarding an issue with one of their advisories. In that instance their report claimed that they had contacted the developer of a plugin about a vulnerability that had been fixed in the plugin before they claim to have even first contacted the developer about it, which was odd. There was also this odd line:

Vendor did not respond to our repeated attempts to send this advisory. All users are strongly advised to update WordPress AccessPress Social Icons plugin to the latest available version.

What would have been the purpose of updating the plugin if the vulnerability hadn’t been fixed?

Yesterday they released a report of vulnerabilities in the plugin Newsletters. Once again when we went to review this before adding it to our data things didn’t add up.

The solution section reads as follows:

Vendor resolved the security issues after we reported the vulnerabilities. All users are strongly advised to update WordPress Tribulant Newsletters plugin to the latest available version.

So the vulnerability was supposed to be fixed, but in what version? It wasn’t directly stated anywhere, but at the beginning of the advisory it listed “Versions” as “ and below”.

The timeline provided didn’t match that though. Here is the timeline provide:

2017/04/04 Vendor contacted
2017/04/06 Vendor responded, update released
2017/05/29 Advisory released to the public

Looking at the development log for the plugin you can see that the next version after, 4.6.5, was released on January 26, 2017. Which is well before they claim to have contacted the developer. So maybe it was fixed in a later version? The problem with that being true would be that the most recent change made was on March 29, which is before they claim to have contacted the developer.

Looking at the changelog for version 4.6.5 we found two entries that might be related to one of the claimed issues, a “file disclosure” vulnerability:

  • IMPROVE: Sorry, this file type is not permitted for security reasons
  • IMPROVE: More secure permissions on export files

In testing the first few examples listed in the advisory in version we found them exploitable and then we found them still exploitable in 4.6.5. In fact we found that in the current version they still are exploitable. After discovering that we promptly notified the developer and we received this response early today:

We are currently checking and will confirm whether or not it has been resolved.
If not, we will release an update later today still with escaped data.

From that it isn’t clear if the developer had intended to fix it before and didn’t (there doesn’t appear to be any change related to the issues in version 4.6.5 or a later version) or if there had never been an attempt. If DefenseCode had actually contacted the developer and was told it was fixed they should have checked to make sure the vulnerability was in fact fixed, because we often find that developers mistakenly think they have fixed vulnerabilities when they haven’t.

It also worth noting here that the “file disclosure” vulnerability listed in the advisory doesn’t appear to be a vulnerability as it would only be exploitable by Administrator-level users that would normally be able to accomplish what that does with their permitted capabilities, by say installing a plugin that allows browsing files.

For those using our service they have already been notified by now if they are vulnerable and given instructions on how to get in touch with us if they wanted help with dealing the situation, where they are using a plugin that has a vulnerability in the latest version of it.

For those instead relying on a service or a plugin that uses data from the WPScan Vulnerability Database, as often is the case they would be getting lower quality information as they have added the vulnerability today, but are claiming that it was fixed back in version 4.6.5:

This is yet another reminder of the importance to double check that any vulnerabilities that the WPScan Vulnerability Database’s data is claiming have been in your plugins and have been fixed have in fact been fixed. Or just use a service that does that in the first place. Making things more problematic, providers using their data often don’t disclose it is the true source of their data and or provide a disclaimer as to the quality issues that come with their data.

25 May

The WPScan Vulnerability Database Doesn’t Contain the Most Complete List of WordPress Plugin Vulnerabilities

When it comes to the problem with security one of the issues that underlies a lot of it is lack of evidence based claims, whether the claims come from the security industry or the public. When coming from the security industry it looks like a lot of that is knowingly false, for example claiming that a service would protect websites from being hacked while the services actual function is to try to detect that the website has been hacked after it has been hacked.

A recent example of a claim from the public that isn’t backed by evidence involves an odd situation mentioned in the post on our recent security review of a plugin where the plugin, which is for protecting against spam, is checking if the installed version of WordPress has security vulnerabilities. We don’t understand why that functionality is in the plugin, but in doing that the plugin sends information that sometimes wouldn’t be publicly known to the website wpvulndb.com. In trying to explaining why it is checking for vulnerabilities in the installed version of WordPress the developer of the plugin made this claim:

The WPScan Vulnerability Database (wpvulndb.com) is legit, and is one of the best resources out there for WordPress security as it contains the most complete list of vulnerabilities for WordPress, Themes and Plugins.

No evidence is cited for that claim and from our own experience when it comes to plugins that isn’t back up by what we have seen. We know this not only because we on occasion check competing data sources to make sure we provide the best data on vulnerabilities in plugins to our customers, but also because we monitor this data source as part of our extensive monitoring for information on plugin vulnerabilities, as on occasion vulnerabilities are submitted directly there (most of their data comes from third-parties).

From doing that we know that many vulnerabilities that we have discovered, including many that hackers either were already or very likely to exploit in the future are not included. Considering that we discover quite a few of the vulnerabilities that on its own would be a problem with being the most complete list, but in occasions when they have added vulnerabilities we have discovered, there have been indications that they have spotty inclusions of vulnerabilities they are even aware of, as in two instances we looked into where we had disclosed multiple connected vulnerabilities at once (four in one instance and five in the other) they only included one of the vulnerabilities in each instance. We looked into those situations because we were trying to understand what led them to include those ones and not the others, but we couldn’t fix an explanation, so it looks like they just are not very thorough.

Simply having more vulnerabilities in your data set though isn’t necessarily better though, as the quality of your data also matters. That is where WPScan Vulnerability Database has serious issue because they usually don’t verify the vulnerabilities as we always do. That leads a number of problems, including them listing false reports of vulnerabilities in their data and claiming unfixed vulnerabilities are fixed. That latter issue seems rather important since knowing if you are using a vulnerable seems to be the most important use for this type of data, it also means you would need to double check any vulnerabilities they claimed are fixed (or you could use a service that actually does that for you).

There are two takeaways from that. First, when you see claims made about security you should look if there is evidence that supports the claims presented. If you don’t, the claim should probably be assumed to not be known be true. When evidence is present, if possible, you would want to check over the evidence presented, because we have found that in some of the few instances where it is provided, it has been manipulated. Second, if you are going to recommend relying on data from the WPScan Vulnerability Database it is important to note its limitations. We actually think it is a good source for a lot of people because its data can be accessed for free, but you get what you pay for and those relying on it should really be aware of its limitations.

17 May

Wordfence Spreads False Report of Vulnerability in WordPress Plugin From WPScan Vulnerability Database

When it comes to improving the security of the WordPress ecosystem one of the big problems we see is that there is so much misinformation coming from the security industry itself. A prime offender is Wordfence, which despite having the most popular WordPress security plugin, is run by people that don’t seem to know almost anything about security and don’t seem to have any concern for accuracy in the claims they make (they also are fine leaving people relying on their plugin vulnerable to being hacked despite claiming that it will protect them).

Based on that we weren’t surprised that they would be spreading false information about a claimed vulnerability in a plugin based on data from the WPScan Vulnerability Database, which we have repeatedly warned has serious accuracy issues.

They also provided advice on evaluating plugins, which not surprisingly considering their lack of security knowledge, isn’t very useful for protecting against vulnerabilities that are a real threat. But there are things that you can that will actually help to protect you from those, as well get to.

A Lack of Due Diligence

In the post 22 Abandoned WordPress Plugins with Vulnerabilities they provide the list mentioned in the title using vulnerability listings from the WPScan Vulnerability Database. You don’t have to get past the first item list to find a problem, one that should have been fairly obvious. Here is the beginning of the list:

The first plugin WP PHP widget sticks out there as it 30 times more popular than the second most popular than the second most popular. While there are certainly issues with insecure plugins not being removed from the Plugin Directory (which is likely to get worse going forward as we will get to in an upcoming post), that seems like something that should been a red flag to Wordfence.

The asterisk next to it names indicates that the vulnerability being fixed:

We also found 4 plugins (marked with asterisks in the table below) that have fixed a vulnerability, but their fix was released in such a way that existing users are not updated to the newest fixed version. In each case, the author committed a fix to trunk but did not increment the version number and tag it properly in the plugin repository, so their users remain vulnerable.

Slightly down the post there is slightly different statement about the asterisk:

If the plugin is marked with an asterisk, you can disable and remove the plugin. Then reinstall it and you should have a newer version. We have not audited individual plugins for security so we can not verify whether a vulnerability has been comprehensively fixed.

We can’t understand why a security company would on the one hand say that vulnerabilities have been fixed, but that they didn’t actually check that they were fixed. That is irresponsible at best, incredibly negligent at worst. In the case of the claimed vulnerability in WP PHP widget they don’t appeared to have check things at all.

The first clue to that is the fact that the underlying report of the claimed full path disclosure vulnerability in the plugin was released on December 21, 2012, while the last update to the plugin was on November 10, 2010. That seems like a good indication that no change was made in regards to the report.

While there were changes made to the plugin after version 1.0.2, which is the most recent version and the one listed as being vulnerable, they don’t look like they could be related to claimed vulnerability.

Looking at that report it doesn’t come across as something that looks at all that legitimate as there is no code or explanation provided as to the issue. The only information given is that the vulnerability is supposed to be a full path disclosure vulnerability and that the vulnerability is “http://localhost/wp-content/plugins/wp-php-widget/wp-php-widget.php”.

If you were to install plugin on a production server requesting the URL /wp-content/plugins/wp-php-widget/wp-php-widget.php won’t normally cause a full path disclosure (will show what that is in a second), so that may have been the extent of what Wordfence did, if they did anything. The lack of full path disclosure would be equally true if you tried this with any version of the plugin.

Where you would get the full path disclosure if you had error reporting enabled in the server’s settings, in that case visiting the URL would get the following message:

Fatal error: Class ‘WP_Widget’ not found in [redacted]/public_html/pluginvulnerabilities.com/wp-content/plugins/wp-php-widget/wp-php-widget.php on line 29

In place the portion of that we redacted you would get the rest of the path to the file on the server, hence a full path disclosure. That alone isn’t going to allow you to hack a website, but it might aid in exploiting some other vulnerability.

So is that a vulnerability? We would say probably not if it doesn’t display when error reporting isn’t enabled (though the issue in this plugin could easily be fixed), but if it is, there is a much larger issue because the same thing will occur in the core WordPress software. For example, if you were to visit /wp-includes/wp-diff.php with error reporting enabled you would get this:

Warning: require(ABSPATHWPINC/Text/Diff.php): failed to open stream: No such file or directory in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

Fatal error: require(): Failed opening required ‘ABSPATHWPINC/Text/Diff.php’ (include_path=’.:/usr/local/lib/php’) in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

So Wordfence’s claim that that the vulnerability had existed, but had been fixed is simply false. Either there never was vulnerability or there is a vulnerability that was never even attempted to be fixed. If it is the latter, then based on Wordfence’s recommendation you should be removing WordPress as well.

Evaluating the Security of Plugins

At the end of the post they state:

Plugins can make adding functionality to your website incredibly easy and are a big part of why WordPress is such a popular platform. The plugin repository on WordPress.org is an incredible resource, but as we have shown above it contains both abandoned plugins and ones with known vulnerabilities. Every plugin you add to your site increases your security risk, and you should evaluate each one to make sure it is being properly maintained.

Prior to that they give evaluation criteria:

A large number of plugin updates are submitted to the WordPress repository every day. For this reason it is important that you gain at least a basic understanding of who is behind a particular plugin before you install it. Here are a few steps you can take to evaluate whether you should use a plugin:

  • Check the average plugin rating.
  • Check when it was last updated.
  • Check that it is compatible with the current version of WordPress.
  • Check the number of active installs the plugin has. Some reliable and useful plugins have low install numbers but you should examine a plugin carefully if it has a low install base (below 1,000 active installs). It may not be maintained.

While we certainly suggest choosing a plugin that is being supported enough to list it as being compatible with the latest version of WordPress, it is important to understand that those criteria really are not a good way of avoiding an insecure plugin. To highlight that, look at results of looking at the information for the plugin Delete All Comments as of November 15 of last year (WordPress 4.6 was the then current of WordPress):

That all seems to meet their criteria, but five days later the security company NinTechNet would discover there was vulnerability in that was already being exploited. Even though the plugin has been recently updated before that, the vulnerability has never been fixed, so a plugin being maintained up the point you install it doesn’t necessarily even insure that an exploitable vulnerability will be fixed.

Realistically there isn’t much the average WordPress webmaster can do to evaluate the security of plugins. Instead your best bet is to make sure you are keeping your plugins up to date at all times and then look at options to provide you extra protection against vulnerabilities in them.

Our testing has shown that other security plugins don’t provide much protection against vulnerabilities in other plugins. For example, the vulnerability in Delete All Comments was not stopped by any of the 16 plugins we tested.

We offer several options that can provide extra protection. First the companion plugin for our service warns you when you are using plugins with vulnerabilities we see hackers targeting. To get more complete vulnerability data you can sign up for our service. Through our service we also work with developers to get vulnerabilities fixed and if you are using a plugin that hasn’t been fixed we are always available to consult with you on how best to deal with that (including providing you with a temporary fix so you can continue to use the plugin in the short term). When you use our service you also get suggest/vote for plugins to have a security review from us, which would catch many common security vulnerabilities in the review plugins (you can see the results of those review so far here).

02 May

WP Site Guardian Uses WPScan Vulnerability Database Data, Which Can Be Accessed For Free

You can get vulnerability data on WordPress plugins from a lot of different sources, but in most cases the underlying data source is the same, the WPScan Vulnerability Database. While we think that is a good data source for a lot of people since you can get access for free, as the old saying goes you get what you pay for. For one thing they don’t actual test out claimed vulnerabilities, so they end up with fake vulnerabilities listed (included ones marked as having been fixed), real vulnerabilities that are not listed being fixed despite that being the case, and the most concerning unfixed vulnerabilities listed as being fixed.

For those looking for that type of protection against plugin vulnerabilities and that can afford our service it will provide you with what we consider to be much better data. For others, they will want to make sure to install our service’s companion plugin, as WPScan’s data is missing many of the vulnerabilities being targeted by hackers that are included in the free data that comes with that (their lack of that data is yet another issue with it).

What we find troubling is that there are products and services that use WPScan’s data without disclosing it is the source or providing any disclaimer as to the reliability of the data. Without those the person relying on the data doesn’t have the chance of understanding that . It also had leads to situations where it appears that multiple companies have found that a plugin contains a vulnerability, when in fact none of them have any idea of that, they simple are passing along WPScan’s data, which wasn’t accurate in those instances.

That brings us to a post on WordPress Support Forum that we ran across recently in our monitoring of that as part of keeping track of what new plugin vulnerabilities are being disclosed. It starts:

I recently bought the PRO version of the popular WP Site Guardian Plugin.
In their plugin Vulnerability section, it detected a problem with the Google XML Sitemaps Plugin.

We hadn’t heard of that plugin and the reference to it being popular seemed a bit odd.

Next they mentioned the details provided about the claimed vulnerability:

It is throwing this error:
Google XML Sitemaps – Authenticated Reflected XSS (via HOST header)

Which redirects to the bottom of this page:

It seems quite likely the true source of that that is WPScan’s data as the title matches exactly to what it is in their data “Google XML Sitemaps – Authenticated Reflected XSS (via HOST header)“. The chances that someone else would have come up with that exact title independently are very small. The link in both is the same as well.

It doesn’t look like WP Site Guardian is disclosing their data source and in this case it would be relevant since this doesn’t appear to be a vulnerability. At best the issue looks to be a potential vulnerability. (The person that submitted it WPScan Vulnerability Database contacted us about at the same time they had submitted it to them and we never got a reply as to our question as to whether they had found a way to exploit it (and therefore it was vulnerability).)

In looking into what WP Site Guardian is, things don’t look at exactly on the level.

The website for it lacks any details, just bold claims like this:

WP Site Guardian – Proactive vulnerability Defence for WordPress

Protect against current and previously unknown plugin and theme vulnerabilities with the latest in anti-vulnerability technology.

That sounds impressive, but based on our knowledge of plugin vulnerabilities and our testing of other security plugins that would be difficult to pull off and there is nothing shown to indicate whoever is behind it is actual is doing that. It’s also worth noting that it isn’t clear what a previously unknown vulnerability would refer to, unless it is intentionally malicious code, vulnerabilities would have always been previously unknown otherwise they wouldn’t have existed in the first place.

The rest of the text doesn’t provide any more detail as to what is going on:

WP Site Guardian safe guards your sites by detecting and blocking plugin and theme threats.  Sloppy code on poorly written plugins and themes can leave your site open to threats for hackers looking for any opportunity for entry.

Anyone can make and sell a WordPress plugin, but few people have the skills to code plugins properly and safely.  This means that there are lots of popular products for free or on the market  that on installation will expose your site to hackers.

Even completely new WordPress users know that their security set up should be blocking those gaping holes left behind from coding mistakes or poor practice.  But few users set up the right defenses until it’s too late.

WP Site Guardian is the only WordPress security software that allows you to set it and forget it. WP Site Guardian does daily updates on the safeguards it employs – so your site is always protected with the latest best measures.

You can even be updated on all the threats being blocked or remain blissfully unaware.

Join over 2,000 happy customers and get started with WP Site Guardian today.

The ad that showed up in Google’s search results doesn’t make things look legitimate either:

[Wp Site Guardian 2017 Review - Save 99% Off & Exclusive Bonus‎ Adwww.marketingrack.com.au/WpSite_Guardian‎ [New] In-depth Wp Site Guardian 2017 Review. Save 99% Off & Free Bonus $12,000!]

Visiting the page in that ad we found that it isn’t actually a review and written as if by the developer of the plugin. Strangely that provides a lot more detail than the actual website of the plugin.

While it provides details it doesn’t give us confidence in the product if it was truly from the developer. Take this section:

WordPress itself openly broadcasts every piece of information a hacker needs to hack you, including your WordPress version, your theme & plugin names + versions & with that kind of information it doesn’t matter what security you are running – you are toast even to a script kiddie (baby hacker)

Shields up was developed to make your sites run in “stealth mode” – clearing all the critical information that WP broadcasts by doing so it reduces the risk of hack attacks by up to 95% – hackers simply get bored & move on to an easier target….another amazing pro-active defence tool in our toolbox…

Either this person who wrote this doesn’t know what they are talking about or they are lying to the readers. Hiding that information will have next to no impact. Many hack attempts are totally blind, that is a hacker will try to exploit a WordPress plugin vulnerability without even checking if the website is running WordPress, much less the plugin. In other cases hackers will request plugin file’s that we doubt that a plugin would try to hide, CSS and JavaScript files, since they may need to be accessible in the normal course of using the plugin.

As for the price, remember the ad stated it was 99 off, isn’t listed on the website or through the Buy Now button on the ad’s page, which seems odd as well.

Looking at the rest of the search results we didn’t see anything else that made this seem more legitimate.