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.

14 Apr

Plugin Using WPScan Vulnerability Database Data Doesn’t Warn When Using Unfixed Vulnerable Plugins

While we think that our service provides the best data on vulnerabilities in WordPress plugins, for many websites paying for a service to warn about the use of vulnerable plugins is probably not in the cards. You can always use the companion plugin for our service, which includes data on vulnerabilities in plugins that are being targeted by hackers. But what if you are looking for more broad based vulnerability data? That is where data from the WPScan Vulnerability Database can be good alternative, since there is no cost for access to their data (though some services actually charge for accessing that data). It is important to note that their data has some serious quality issues, including it not warning about vulnerabilities that are included our plugin’s data despite that being for vulnerabilities that are being exploited and the data being freely accessible (if you use a plugin or service that uses their data you will want to combine it with our plugin to protect you from this situation).

There are a number of plugins that provide access to that data, but as we found yesterday while preparing a post about another problem with WPScan’s data, not all of those plugins are equal and in the case of one them it is not providing important warnings.

While looking to show an example of one of them incorrectly warning about a vulnerability due to WPScan’s data indicating that a plugin was vulnerable when it wasn’t, we found that one of them, Vulnerable Plugin Checker, wasn’t providing a warning. We then tried to figure out what was going on and found the plugin will not provide any warning that a plugin is vulnerable if the vulnerability hasn’t been fixed. That is pretty serious issue since the most important use of this type of data is to warn when a vulnerability hasn’t been fixed, since if it has been fixed, simply keeping your plugins up to date will protect you even if you are not aware of the vulnerability.

To show what the cause is, let’s take a look at part of the code that adds a warning to a plugins listing on the Installed Plugins page, which is handled in part by the function admin_head(). The code checks to see if the plugin is known to be vulnerable with this line:

if ( isset( $plugin['is_known_vulnerable'] ) &&  'true' == $plugin['is_known_vulnerable'] ) {

The determination if it is vulnerable is handled with the following check in the function get_cached_plugin_vulnerabilities() (a substantially similar one is in the function get_fresh_plugin_vulnerabilities()):

// if plugin fix is greater than current version, assume it could be vulnerable
$plugin['is_known_vulnerable'] = 'false';
if ( version_compare( $vulnerability['fixed_in'], $plugin['Version'] ) > 0 ) {			
	$plugin['is_known_vulnerable'] = 'true';

For a plugin that hasn’t been fixed the value of $vulnerability[‘fixed_in’] in that will be null, so the plugin is considered to not be known to be vulnerable. Because the plugin is not considered to be vulnerable, no warning will be provided.

The end result of that if someone is relying on this plugin they would not be warned if, for example, they were using the latest version of Delete All Comments, despite a serious vulnerability in that, which was discovered by a security company after it was used to exploit a website:

We have notified the developer of the plugin through the WordPress Support Forum of the issue, so hopefully for those relying on the plugin it will get fixed quickly. If you are using another plugin or service that relies on WPScan’s data it would be a good idea to check if they are properly handling this type of situation and otherwise properly handling the use of WPScan’s data (in one other case we found a security company was misusing their data on vulnerabilities in WordPress and making false claims about WordPress websites being insecure).

Non-Independent Reviews

For a plugin that seems to have such a fundamental problem, taking a quick glance at its page on the Plugin Directory it might be surprising to see that it has received only five stars reviews:

While it is possible that independent reviewers might not have noticed this issue, in this case it looks like most of the reviews come from problematic sources. One comes from the developer of the plugin, another one comes from what looks to be their brother, and another one comes from account that looks like it was created just to post the review, which often is an indication that it isn’t an independent review. This seems like a good reason for those connected with a plugin to not be reviewing their own plugins, as it provides a skewed view of the plugin (would they ever give the plugin a poor review?).

13 Apr

WPScan Vulnerability Database Incorrectly Identifying Some BestWebSoft Plugins as Being Vulnerable

Earlier today we disclosed a reflected cross-site scripting (XSS) vulnerability we had found in numerous plugins by BestWebSoft after another security company that had independently found the same vulnerability disclosed it (the developer of the plugins was aware of it before either of us, but hadn’t fixed it in most of their plugins).

If we hadn’t already known about the vulnerability and prepared the data on the vulnerable plugins we would have had a lot of work to do today as the vulnerability impacts 53 plugins. The most time consuming part of preparing that data is determining what versions are vulnerable, but doing that insures that our customers are only notified if they are using a vulnerable version. While this vulnerability is unlikely to be exploited, for vulnerabilities that are likely to exploited determining the vulnerable versions is also important for those using the data while cleaning up a hacked website as it is possible that a website might be using a version that is older than the version identified as being vulnerable but is not vulnerable due to vulnerabilities not always existing in all older version (in a couple of cases last year vulnerabilities being exploited on a wide scale only existed in a single version of the plugins).

For those relying on another service or plugin to warn them of vulnerabilities in WordPress plugins they use, the underlying source of the data is likely from the WPScan Vulnerability Database and for those people they are likely to fair number of them being warned that they are using a vulnerable version of one of BestWebSoft’s plugins when they are not. The cause of that is that according to WPScan’s data none of the plugins have been fixed despite the fact that 13 of them have been fixed and were fixed before the disclosure. Take for instance the most popular fixed plugin, Google Sitemap by BestWebSoft, which has 90,000+ active installs according to wordpress.org. The vulnerability was fixed in that plugin two weeks ago.

Here is how it would look if WPScan’s data indicates a vulnerability was fixed:

And here is how their listing for this vulnerability currently looks:

Here is how it looks for an end user using one of the plugin’s that uses their data if they have the current version of Google Sitemap by BestWebSoft installed, despite it not being vulnerable:

The Downsides of Using WPScan’s Data

While we think that WPScan’s data is a good option for a lot of people because it is available for free, it does come with significant downsides that anyone using should know about. This also includes odd omissions of vulnerabilitieslisting false vulnerabilities in their data and listing vulnerabilities that haven’t been fixed as being fixed. Not only are we not aware of anyone using their data including notice of those issues, but some plugins and services that use the data don’t disclose is as the source of their data so even if someone was aware of the issues with their data, they wouldn’t know it impacts them. Also problematic are services that actually charge for access to the data, because if you are paying for WordPress plugin vulnerability data then you should be getting better quality data than this.

20 Mar

False Vulnerability Report: Store XSS Vulnerability in WP Markdown Editor

As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them. The data on these false reports is also included in our service’s data.

When it comes to false reports of vulnerabilities in WordPress plugins some of them don’t set off any red-flags until you start to look closely at them. Others, like a recent report claiming there was persistent cross-site scripting (XSS) in the plugin WP Markdown Editor set off multiple red-flags with the just a quick glance, though they still require being fully checked as some reports of actual vulnerabilities end up being quite of poor quality.

The first red-flag in the report was that there was no code or other detailed information provided; instead the report consisted entirely of a small amount of text and three screenshots. If the person behind the report hadn’t looked at the underlying code, they could have missed important information that would have let them understand if a vulnerability actually existed or not.

That issue is particularly acute in this case because the screenshots showed saving JavaScript code on the page for adding a new post to WordPress and being saved. Normally both Editor and Administrator-level users are allowed to do just that due to having the unfiltered_html capability, so the action being taken is also a red-flag that this might be false.

To test out the vulnerability we first tried taking the actions show in the report logged in as an Author-level user. We entered the code on a new post as suggested in the report and clicked the “Toggle Preview” button and the JavaScript ran, which really isn’t a vulnerability (as we will come back to in a bit). Since this is supposed to be a persistent XSS vulnerability this JavaScript code needs to persist when saving the post, but it didn’t. It didn’t even get displayed when previewing the post normally.

We then tried everything again but with an Administrator-level user. Unlike the previous instance the JavaScript remained when saving the post. That would indicate that the plugin was not actually permitting persistent XSS, as Administrator-level users, unlike Author-level users, should be able to do that and the reporter likely did their testing using a user with the unfiltered_html capability.

As confirmation of that we tried things again with an Editor-level user that had the unfiltered_html capability removed and the JavaScript was not saved.

So there isn’t a persistent XSS vulnerability, but what about the JavaScript code running for the Author-level user when clicking the “Toggle Preview” button. Seeing as the user would be taking the actions to cause that it would probably be classified as self XSS, which isn’t a vulnerability, but a social engineering attack because you would need to trick someone into doing that. Is that a concern? Not really, since the same exact thing could be done by getting them to enter JavaScript code into their web browser’s console.

WPScan Spreads a False Report

While we actually test out vulnerabilities before adding them to our data, so we avoid including false reports like this, other data sources clearly do not. Take the WPScan Vulnerability Database, which is the true source of WordPress plugin vulnerability data for almost any service or plugin other than ours that provides that type of data,  it has this false vulnerability in their data set:

That is despite those major red flags that the vulnerability likely didn’t exist.

Why Was The Plugin Removed From the Plugin Directory?

If you visiting the page for the plugin in the Plugin Directory now you will get this as the plugin has been removed:

As of a couple of weeks ago it was there. Was it removed due to the Plugin Directory incorrectly believing there was vulnerability in it? Maybe, but it could also be something else. Unfortunately the people behind the Plugin Directory continue to keep people in the dark about removed plugins.