28 Jun

Other Data Sources on WordPress Plugin Vulnerabilities Belatedly Add Vulnerability While Falsely Claiming It Has Been Fixed

When it comes to the problems with the security industry one of the fundamental issues is the abundance of false and misleading claims about the capabilities of products and services. The breadth of that is on display in how often that occurs with our little piece of the industry, data on vulnerabilities in WordPress plugins, where among other issues you have a company falsely claiming their data set contains all known vulnerabilities despite actually not even adding the most vulnerabilities and Wordfence claiming the data they use only contains  “Confirmed/Validated” vulnerabilities. On that latter front we recently came across another example of other data sources falsely claiming that a vulnerability had been fixed, when it hadn’t. Getting that right seems like a critical element in providing this type of data, since correctly informing about unfixed vulnerabilities seems like it would the most important element. This time it involves a vulnerability that we were warning our customers for a month before the other data sources even added to their data set.

One of the things we do to make sure we provide the most complete data on vulnerabilities in WordPress plugins is to monitor for indications that a new version of a plugin includes a fix for such a vulnerability. With version 2.0.5 of the plugin WordPress Comments Import & Export, which was released on May 7, originally one of the changelog entries was “Fix the vulnerable to Remote Command Execution.”. Minutes later it was changed to “Bug fix, comment data filtered.” We looked into that and found that there was a CSV injection vulnerability that was attempted to be fixed in that version, but the fix was incomplete. We then put out a post with the details of the vulnerability on May 17. We notified the developer of the plugin that the vulnerability had not been fixed then as well. On June 6 the changelog was modified again to add “CSV Injection was fixed – reported by one of our user (Bhushan B. Patil) CVE-2018-11526”.

While the details of our post on the vulnerability are only available to our customers, other data providers could have known a fair amount about the vulnerability with just the title of our post. The final version of the changelog would have also given them a lot to go on and yet they didn’t add the vulnerability until it was disclosed by the discoverer.

When the discoverer, Bhushan B. Patil, disclosed it, they incorrectly stated it had been fixed. That isn’t an uncommon situation. Despite that, other data sources just blindly repeated that it was fixed without checking things over.

Here is ThreatPress’ entry:

The most widely used data source, the WPScan Vulnerability Database, got things even more wrong since they claim it was fixed in version 2.0.4:

Proper Warning Missing

One key difference with those data sources and ours is that they are accessible for free, so there is a tradeoff to be made when using a free data source. If the lack of checking if vulnerabilities were fixed was the only limitation with those data sources, you could mitigate that by testing out if vulnerabilities in plugins you use have actually been fixed, but that isn’t only one of the issues with them. Another is that they are missing plenty of more important vulnerabilities than the one in WordPress Comments Import & Export from their data sets. Take for example an unfixed vulnerability in the plugin KingComposer that we discovered and had disclosed on May 16. That is a vulnerability that we have seen evidence that hackers are already trying to exploit, so it would be something that you would want to be warned about, but those data sources still don’t contain that vulnerability. Since we don’t want people to be left in the dark in that type of situation we includes the details of vulnerabilities that look like they are being exploited in the free data that comes with the companion plugin for our service, so even those not using our service can be warned.

Any providers using data sources like those should be providing proper warning about the quality issues that are inherent in the data they are using. Unfortunately that isn’t the case. Some even take it further. Earlier we mentioned how Wordfence claims that the data they use on plugin vulnerabilities is “confirmed/validated”, but there data is none other than the WPScan Vulnerability Database, which as this situation shows, doesn’t do that. Lying in that way seems like it should be a serious issue, but considering that Wordfence has a long history of serious lies like that, which haven’t impacted them so far, we unfortunately don’t think it will cause them any damage.

10 May

How Free Data Sources for WordPress Plugin Vulnerabilities Compare To Us with Possibly Targeted Vulnerable Plugin

One of the reasons why security is in such bad shape despite the enormous amount of money spent on it is that there is a failed market when it comes to security products and services. In simple terms it isn’t currently possible for consumers to make well informed decisions between different products and services due to rampant falsehoods and outright lies about them as well as a lack of watchdogs to limit those or independent entities that provides accurate information needed to be able to make informed decisions. What sticks out to us is how widespread these falsehoods and outright lies are. We often see them in just the somewhat obscure area we deal in, data on vulnerabilities in WordPress plugins.

Just last week we discussed how the makers of the very popular WordPress security plugin, Wordfence Security, were lying by claiming that the data source they use is “official” and only contains “confirmed/validated” vulnerabilities. In reality neither of those claims is true, there is no official source of WordPress plugin vulnerability data and their data source doesn’t actually confirm or validate vulnerabilities before including them. What they didn’t mention nor are we aware of them disclosing elsewhere is what the data source used is, which is the WPScan Vulnerability Database. They are hardly alone in using that source and they are certainly not alone in not being upfront about using that data source, which is its own problem because we have seen people believe that multiple organizations were confirming a vulnerability when all of them were simply repeating an unconfirmed claim from that data source.

Even in an instance where a service was being upfront about using their data, they were falsely claiming that it providing better quality data than it truly does. Three months ago we discussed MainWP promoting their usage of WPScan’s data with the claim that:

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

The reality here is that something updating in real-time does not say anything about the completeness of its data, just how much time it takes for new data to propagate and WPScan’s data is far from the most complete.

The WPScan Vulnerability Database is Not Listing any Vulnerabilities in This Plugin

As we mentioned earlier today, yesterday we had a request probably from a hacker on this website for a file from the plugin Google Drive for WordPress (wp-google-drive), which contains a vulnerability that was disclosed a month ago. As we discussed at the time of disclosure, the vulnerability was incorrectly labeled as being a remote code execution (RCE) vulnerability when disclosed. The actual type of vulnerability, arbitrary file deletion vulnerability, is a type that based on past experience is not something that hackers have been very interested in, so the interest from a hacker may be due to them believing the plugin actually contains a RCE vulnerability, since those are much more likely to be exploited, at least based on past experience.

Whether something in the plugin is actually going to be exploited or not, it would seem that letting people know that this plugin has publicly disclosed unfixed vulnerability would be even more important considering there is what looks to be targeting of the plugin. If you are relying on WPScan’s data though you wouldn’t know about it. If they had any vulnerability for the plugin in their data set it should be listed between the following two plugins, but nothing is listed:

By comparison we have listed the vulnerability in our data set since April 13. Considering that the vulnerability is unfixed and was listed on a prominent general data source since shortly before that, there isn’t a good reason for WPScan’s data to not contain it. At the same time WPScan’s data is available for free for non-commercial software, so the quality may be in line with what should be expected in that instance. The problem though is that often times it is promoted like MainWP promotes it, leading people to believe they are getting access to data at the same quality level as ours, without the cost of ours.

Other Free Sources Do Better, But Still Get It Wrong

WPScan isn’t the only free accessible source of vulnerability data and others do better when it comes to this plugin.

With the companion plugin for this service we include free data on vulnerabilities that look to be being exploited. Due to noticing the request for this plugin we added the previously disclosed vulnerability to it today, along with another vulnerability we found while looking over things.

In looking at other free data sources we found they included the vulnerability, though inaccurately labeled.

The plugin WebDefender, which contains its own vulnerability data, added the vulnerability on April 16, but labeled it as “Remote CE”, which seems to indicate they didn’t actually check over the report before adding it. Two days later the data source ThreatPress added the vulnerability and also incorrectly labeled it as a “Remote Code Execution (RCE) vulnerability”. When vulnerabilities are not checked over this can lead to a number other issues, including incorrectly stating that a vulnerability has been fixed when it hasn’t, which is rather common occurrence.

The closest we found to an accurate labeling was in spreadsheet linked to from an April 16 blog post on WPCampus that labeled it as “Authenticated Arbitrary File deletion” vulnerability. We are not sure where the idea that it required being logged in to exploit it, but at least the general type is correct.

03 May

We Wouldn’t Call WP Engine A Good Web Host for Providing Inaccurate Data on WordPress Plugin Vulnerabilities to Their Customers

When it comes to getting information on the security issues in WordPress plugins, developers of plugins are not always the best source. That is the case with a persistent cross-site scripting (XSS) vulnerability discovered by Federico Scalco that was in the plugin Caldera Forms. While that was claimed by the discoverer of the vulnerability, the developer of the plugin, and all of the other data sources of vulnerabilities in WordPress plugins we are aware of, to have been fixed in version 1.6.0 of the plugin, it actually wasn’t, as testing out the claimed vulnerability would have show any of them (the ease of testing that would will be something we will go into in another post). If you were using our service you would have been correctly notified that it hadn’t been fixed.

That has now been fixed in version 1.6.1.1. Here what the developer wrote about that:

This release is an additional fix for CVE-2018-7747 . I was alerted earlier today that there was one remaining problem that did not get fixed. The security issue that we disclosed two weeks ago is called a stored XSS vulnerability. In simpler terms that means that there was a way to use Caldera Forms to store some JavaScript that could be triggered to run later.

In Caldera Forms 1.6.0 I used a function that removes all JavaScript on the output that was previously exploitable. That prevented the stored JavaScript from running. Since exploiting a stored XSS vulnerabilities is a two step processes — store and then retrieve later — this update prevents the issue from being exploited in the future.

Caldera Forms 1.6.1.1 adds the same protection in one more location and prevents the behaviour that was shown to me today.

While we are not mentioned there for some reason, we were the ones that notified the developer of it not being fixed. The reality of the situation is that 1.6.0 had not removed “all JavaScript on the output that was previously exploitable” and the location which was claimed to be shown to them was part of the original advisory on the issue.

While we are not mentioned in that, they did link to one of the data sources, the WPScan Vulnerability Database, that falsely claimed that the vulnerability had been fixed before. That isn’t the only time that the developer of that plugin has recently promoted that data source, despite the developer now knowing that they provide inaccurate data.

The other example we ran across popped up in our monitoring of the wordpress.org Support Forum to keep track of vulnerabilities in WordPress plugins. In response to someone asking about a message from the WPScan Vulnerability Database about the vulnerability the developer wrote this:

Yes, there are security fixes in 1.6.0. I worked with the developer who found and responsibilities disclosed the issues. A part of that process is registering it with the database. That documents the issue.

More importantly, it triggers alerts that plugins need to be updated on good hosts. I got a notice from WPEngine about my own site. That’s the best system available to us for getting the word out about vuldrabilites that are not severe.

We don’t think a good web host would be spreading WPScan’s inaccurate data without at least having a disclaimer that the data has serious quality issues, which might have been a reminder to the developer that they shouldn’t be promoting it. By promoting data sources that are not responsible with their data, developers are actually hurting users of their plugins, since if we didn’t exist then the vulnerability likely would have remained in the plugin for the foreseeable future. If more people knew the truth about what different data sources provided it would likely mean more customers for our service, which would mean we could be doing even more to improve the security of WordPress plugins (and therefore WordPress in general), which is already probably more than every other security company out there.

Something else we noticed that seems worth noting it terms of improving the security of plugins was something mentioned in the post announcing the release of version 1.6.0 of the plugin:

In order to ensure that this fix does prevent these potential XSS vulnerabilities, and also that we do not re-introduce the vulnerability, we have created new automated tests. These tests, which are in a private git repository, will be run on future releases and we will add additional security checks in the future.

Clearly those automated tests didn’t actually accomplish that. Just in general, our experience is that automated testing is useful as additional tool for knowledgeable professionals when checking over the security of a WordPress plugin or other software, but they have some serious limitations and their abilities are often overstated.

02 May

Wordfence Falsely Claims Their Data Source on WordPress Plugin Vulnerabilities is “Official” and “Confirmed/Validated”

When it comes to getting data on vulnerabilities in WordPress plugins there appear to be a lot of sources, but in reality most of the time it is really comes from the WPScan Vulnerability Database. While we think that that data source is a good option for a lot of people since it is available for free, you do get what you pay for. And anyone reusing that data should be upfront about the real source of the data and alert people to the serious quality control issues that come along with it.

Considering that people behind the Wordfence Security plugin don’t seem to have any qualms about lying no matter how blatant the lies, it wasn’t surprising to see they have gone beyond not providing the proper disclosure of their use of WPScan’s data to making false claims that make it sound like it much better than it really is. We just ran across them giving their usage an imprimatur as being from an “official” source and falsely claiming that the data is “confirmed/validated” when neither of those things are true about the WPScan’s data.

In a recent thread on the wordpress.org Support Forum, which we ran across in our monitoring to keep track of vulnerabilities in plugins for our service, someone wrote:

Hello,

We’re noticing an increase in the amount of plugin updates that are not being marked as “Security Fix” in our wordfence emails (“Problems found on http://www.example.co.uk“).

The most recent occurrence of this was the uk-cookie-consent plugin.
This updated from 2.3.9 to 2.3.10 after a security vulnerability was patched.

Changelog:
2.3.10
Fixed: fixed security vulnerability identified by James Boughey

We maintain a large client base and rely on these emails to quickly determine if the update needs to be applied immediately (Security related) or if it can be put on hold temporarily (Feature update).

Kind regards

First, we should note that trying to decide whether to update a plugin based on data about what plugin vulnerabilities is a very bad idea, since even if you are using a better data source that the WPScan Vulnerability Database it isn’t going to provide the level of coverage of vulnerabilities needed to try to pick and choose what plugins to update. That is why in addition to providing a service with better data, we also have a plugin that will turn on WordPress built-in ability for plugins to automatically update.

Update 5/4: We should also note that one reason why someone might think that trying to choose when to update plugins based on claims that they have a security issue is something that is not a bad idea is Wordfence’s postings about vulnerabilities in plugins.

In this case it actually would have been correct for Wordfence to not mark this as a “Security Fix” since, as we discussed last week, the claimed vulnerability that was supposed to be fixed in that version didn’t actually exist.

The response from a Wordfence employee was this:

We do mark plugins as being vulnerable when we know for certain they are.

Unfortunately we can’t rely on authors’ changelogs for detecting vulnerabilities, because there are too many inconsistencies (for example, they might mention “security hardening”, which isn’t necessarily a vulnerability fix) and some authors maintain changelogs outside of wordpress.org or commit changelogs in a non-standard way.

Once a vulnerability is officially confirmed we update our servers’ list of known vulnerabilities which then allows scans to accurately report the issue.

I confirmed the “UK Cookie Consent” plugin now shows a critical scan result with a link about the security fixes for version 2.3.9 -> 2.3.10.

Contrary what is written there, Wordfence doesn’t actually have any idea if a vulnerability actually exists when they mark them as such. By “officially confirmed” they are actually referring to a vulnerability being listed in WPScan’s data, which isn’t official in any way, nor is there any official confirmation out there. (We confirmed that is their source by comparing WPScan’s data to what Wordfence is marking as including security fixes and we have also previously seen more obvious usage of WPScan’s faulty data by Wordfence.)

The ease that Wordfence lies about things continues to be stunning to us. That they not only get away with it, but that public comes up with excuses for them doing that, is a good example of why security is in such bad shape.

What makes this worse is that if you actually look at WPScan’s data for that claimed vulnerability they specifically note that it isn’t verified:

So the vulnerability isn’t actually confirmed even unofficially.

In a follow up reply the Wordfence employee had made further claims:

It’s not that we perform specific checks on our side, rather we update our list of known vulnerabilities by pulling information from an official source; our servers are updated at least once a day.

Sometimes a plugin author fixes a vulnerability that hasn’t been reported yet and in such case official sources for vulnerabilities do not report the issue.
Regarding the time frame; again it all depends on when the security issue gets confirmed/validated. We have no control over that.

Again, there is no official source. It obviously sounds impressive though, which seems to be the point, and they rightly assume that most people wouldn’t bother to question something like that.

Also, contrary what is claimed there, there is no reason that Wordfence couldn’t have control over confirming/validating vulnerabilities in WordPress plugins, but that would require doing some actual work. And why would they when they can get away with claiming to provide the “best security available” for WordPress websites while failing to even do the things actually claim to do.

That WPScan’s data include vulnerabilities that don’t exist is much less of issue than other problems including incorrectly claiming that vulnerabilities have been fixed when they haven’t (which we will be discussing a couple of examples of in an upcoming post), but also that they are missing a lot of vulnerabilities that are being exploited (including ones where there isn’t a fix), which you would be warned about by us even if you don’t use our service (through use of the service’s companion plugin).

If you are actually interested in getting the most complete data on vulnerabilities in WordPress plugins, with all of the vulnerabilities actually confirmed/validated, that is exactly what our service provides. We have been told that Wordfence doesn’t admit to people that our service or any like it exists if they contact them looking fro that, despite them admitting they were aware of us after someone called them out on the claim that no service like ours exists.

27 Apr

Not Really a WordPress Plugin Vulnerability – Week of April 27, 2018

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 release 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. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Persistent Cross-Site Scripting (XSS) Vulnerability in Cookie Consent

With a claimed persistent cross-site scripting (XSS) vulnerability in the plugin Cookie Consent the proof of concept didn’t make a lot of sense to us:

1) Access WordPress control panel.
2) Navigate to the ‘Pages’.
3) Add a new page and insert the script you wish to inject into the page title.
4) Now navigate to ‘Settings’ and select ‘Cookie Consent’.
5) Now click on the ‘Content’ tab.
6) Your injected script will now be executed.

It wasn’t at all clear what was supposed to be the connection between the actions in steps 1-3 and the plugin. It turns out there really isn’t any.

What seems to have happened here is that the person behind this doesn’t understand that Administrator level-users (as well as the only other users, Editors, that can create pages by default) normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting (XSS). In this situation if at step four you had instead visited the page created in steps 1-3 the script would also run, so other than this occurring on an admin page the same result would occur without the plugin.

If a user could create new pages and didn’t have the unfiltered_html capability they wouldn’t be able save a script to a page’s title in the first place, so there wouldn’t be an issue when the plugin’s page is accessed.

Persistent Cross-Site Scripting (XSS) Vulnerability in Responsive Cookie Consent

The person behind that claim made also made a claim of the same type of vulnerability in the plugin Responsive Cookie Consent, which we found on another data source of plugin vulnerabilities, the WPScan Vulnerability Database, which doesn’t do the same type of checking we do before adding claimed vulnerabilities.

In this case the claimed vulnerability at least was connected directly with the plugin:

1) Access WordPress control panel.
2) Navigate to the Responsive Cookie Consent plugin page.
3) Select one of the input fields. For example, “Cookie Bar Border Bottom Size”.
4) Insert the script you wish to inject.
5) Save the plugin settings.
6) Injected script will run in the victim user’s browser. Depending on which input field you inserted the script, the script may also run everytime you load the Responsive Cookie Consent plugin page.

As we explained with the previous claimed vulnerability, Administrator level-users are normally have the unfiltered_html capability, which allows them to do the equivalent of cross-site scripting (XSS), so if only they have access to it, it wouldn’t really be a vulnerability. Looking at the code that sets up the admin page for the plugin, we could see that it is limited to those with the “manage_options” capability:

4
add_submenu_page('options-general.php', __('RCC Settings', 'responsive-cookie-consent'), 'RCC', 'manage_options', 'rcc-settings', 'rcc_options_page');

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).

There still was the possibility have been an issue if there was a lack of protection against cross-site request forgery (CSRF), but we found that is properly protected against.

13 Feb

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19 Dec

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

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

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

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

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

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

18 Dec

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

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

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

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

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

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

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

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

Claims of Fixed Vulnerabilities in RegistrationMagic

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

Those claims were then repeated on the WPScan Vulnerability Database:

And also by WPCampus:

 

Only Accessible by Administrators

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

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

Sorry, you are not allowed to access this page.

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

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

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

This Vulnerability Hadn’t Been Fixed

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

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

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

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

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

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

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

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

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

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

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

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

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

Not Really a WordPress Plugin Vulnerability – Week of November 3, 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.

Full Path Disclosure in Inline Image Upload for BBPress

At the end of September we mentioned that the website WPCampus wasn’t properly crediting us when discussing things we had written, but it isn’t just us that is true with us. Last week in their post on plugin vulnerabilities they credited Wordfence for discovering a vulnerability, but for the other claimed issue they discussed they left out any mention of the discoverer:

For this week’s unfixed vulnerabilities, the Full Path Disclosure issue with the Inline Image Upload for BBPress (and it’s Pro version) isn’t a vulnerability by itself, but can be used in combination with other attacks that require knowing the server path. Hopefully the vendor will release a fix soon, but if not, you can mitigate this issue by ensuring display_errors is disabled for php for your site.  The specifics of how you disable it will depend on your hosting set up.  If you’re not sure, contact your hosting provider or system administrator.

In looking at the linked spreadsheet with the details, we immediately noticed it looked like this wasn’t really a vulnerability as it said in the note for it, “Ensure error_reporting/display_errors is turned off/disabled”. As we noted back in May with a claim made by Wordfence if you consider this a vulnerability then WordPress is also vulnerable:

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

WPCampus isn’t the only source of WordPress plugin vulnerabilities passing along inaccurate information on vulnerabilities that we ran across this week. During our monitoring of the WordPress Support Forum we looked at thread bringing up a claimed vulnerability in the plugin Comment Attachment. The message from the plugin Vulnerable Plugin Checker that uses data from the WPScan Vulnerability Database shown in the thread stated:

Comment Attachment has a known vulnerability that may be affecting this version. Please update this plugin.

Comment Attachment 1.0 – XSS

That isn’t all that helpful to someone trying to figure out what is going on. Looking at the relevant entry in WPScan’s data pointed to the source of the claim. The instructions for exploiting the claimed issue are as follows:

1) Download “Comment Attachment” And Install
2) Go To Sitting Comment Attachment :
Settings > Discussion > Comment Attachment
3) Insert In “Attachment field title” This Code And Save :
“><script>alert(/Arsan/)</script>
4) And Try To See Your Post And Comment; Follow Link :
http://localhost/wp/?p=1

To access that page you have to have the “manage_options” capability. 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 “unfiltered_html” capability and therefore could do the equivalent of this.

20 Oct

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

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

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

Severity: Critical

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

Status New

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

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

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

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

Here is the entry as it is currently:

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

The third reference cited by WPScan states that:

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

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

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

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

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

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

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

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