27 Jun

Pagely Downplays Serious Problems With The Handling of Security Vulnerabilities in WordPress Plugins

Security isn’t in great shape these days and that certainly applies to WordPress plugins as some recent issues we have run across have reminded us. As we see it, one of the causes of this is that real problems with security rarely get discussed. There are probably many factors at play to cause that, but one that we see is that people will criticize you if you say anything they interpret to be negative when it comes to security (the irony of that seems lost on them). That seems to lead to a lack of honesty about what is going on and instead a focus on happy talk that doesn’t resolve the problems, even though many could be fixed without much effort if there was an interest in doing that.

An example of not discussing the real problems comes up with a post we ran across from the blog of WordPress web hosting company Pagely. The post discusses the increasing issue with PHP object injection vulnerabilities in plugins, but hidden below the surface of the post is a couple of problems that writer clearly is aware of, but doesn’t disclose. The relevant section of the post is the following:

Full disclosure: I am the reporting party for some of the above vulnerabilities. One in 2016, and so far in 2017, seven. I took a weekend to see how many insecure usages of unserialize() I could find in the plugin code base and within hours had handfuls of working vulnerabilities; I stopped only so I could start triaging and notifying plugin authors regarding how to enact fixes. Many of which were appreciative for the help.

That all sounds nice, it just isn’t true in one important way and that gets to a couple of major problems with the security of WordPress plugin that people on the WordPress side of things don’t seem to be interested in dealing with.

If you look up the vulnerabilities the author is referring to you will find that only 2 of the 8 have been fixed. For the unfixed plugins it seems unlikely they are going to be fixed considering that the plugins last updates were years ago:

The position of the people running the Plugin Directory is that people shouldn’t be warned about unfixed vulnerabilities, but as these plugins show many vulnerabilities have little chance of ever being fixed. Their continued refusal to warn people of those or to update the plugins themselves, which they have the ability to do and we would be happy to help them with, means that websites are being hacked when the hack could have been prevented.

It is unclear why Pagely’s post doesn’t mention any of this, instead only saying of their interaction with developers of the plugins, “Many of which were appreciative for the help”.

The other piece to this that isn’t mentioned is that all of those unfixed plugins still remain in the Plugin Directory. According to the listings for those vulnerabilities that isn’t due to the Plugin Directory not knowing about them, “The original researcher notified WordPress Plugins team.”. There are numerous problems with how the team behind the Plugin Directory handles security issues, but we haven’t seen any interest from them to improve what they are doing. Again, that would be something we would be happy to help them with.

It would be great if going forward Pagely would be willing to be honest about was is going on and maybe help to push WordPress to start finally warning about plugins with known vulnerabilities (something we have trying to get them to for over five years).

Vulnerabilities Left Undiscovered

Something else worth highlighting from that post is this:

There are a lot of plugins out there, and a lot of vulnerabilities – I had to cut my research short just due to time constraints. If you’re a researcher interested in picking up or helping out with this issue (hunting vulns, writing PoCs and recommending patches), get in touch.

Doing that type of work takes a lot of time, unfortunately it is something that most WordPress based security companies don’t do much, if any, of. Instead far too often they seem to be focused on making up threats and then claiming they will protect against them, then doing anything toward dealing with real threats. We do a lot to find and fix vulnerabilities in plugins, we have disclosed 18 vulnerabilities this month, and we have recently started trying to be more proactive in catching vulnerabilities as they are being introduced in plugins. If we had more customers we could do more, whereas those other companies would probably spend additional money to do things that are not all that helpful to improving the security surrounding WordPress.

27 Jun

The Problem With WordPress Forum Moderators Handing Out Inaccurate Security Information

One of the ways we keep track of security vulnerabilities in WordPress plugins is by monitoring the WordPress Support Forum for new posts related to that. In doing that we come across a lot of inaccurate information coming from the moderators of the forum. You won’t find much information from those that are knowledgeable about security there, because if our experience is any indication, they get run off by the moderators. That is one of the reasons that we said that a plan for overhauling the moderation of the forum needs to be put forward before we will start notifying the Plugin Directory of publicly disclosed unfixed vulnerabilities that exist in plugins in it again (the lack of us doing that means that there are currently plugins with publicly disclosed known vulnerabilities that have 323,400+ active install that are still in the Plugin Directory).

Through that monitoring we came across an example of the really troubling claims made by the forum moderators. In response to someone that had found malicious files on their website the moderator began by writing:

Are you asking for support? WordPress is secure and a lot of responsibility is on WordPress’ side, but it is also on the side of the webmaster. The webmaster needs to ensure all dependencies and core is kept up to date, and that secure passwords are used. That will be enough to prevent a hack, however there are ways to improve security as well: https://codex.wordpress.org/Hardening_WordPress

Considering that, for example, the last widely exploited plugin vulnerability was never fixed, just keeping plugins up to date will not at this time will not prevent hacks if you are using a vulnerable plugin. Or to look at a more recent example, a vulnerability was fixed in a plugin and then plugin returned to the Plugin Directory without the version number being bumped, so anyone already using the latest version is still wide open to being hacked even after we notified the developer of that. (If you used our service you would have already been notified if you were impacted. If you use another provider of vulnerability data you would not know about it because only we do the extensive monitoring and testing that is catching that sort of thing.)

Telling people that WordPress is secure in a way it isn’t puts them at risk, but it also helps the issue to fester, when, as we have been pushing for over five years, there is a solution.

Pointing people that Codex page isn’t much better, since it has been extensively edited by a few security companies and seems to be largely focused on pushing their products and services.

For example those security companies often are pushing the false claim that brute force attacks against admin passwords are happening, despite that not being the case. You would think otherwise if believed that page:

Website Firewalls allow you to proactively mitigate external attacks like exploitation attempts that try to abuse software vulnerabilities, brute force attacks that try to break into your admin panel, or denial of service attacks that try to kill the availability of your website. All real security threats.

Their are ability to prevent the exploitation of software vulnerabilities is limited at best, based on our testing and their makers lack of awareness of vulnerabilities being exploited.

The section on plugins makes no mention at all about unfixed vulnerabilities either:

Themes / Plugins

The vulnerability most affecting WordPress website owners stem from the platforms extensible parts, specifically plugins and themes. These are the #1 attack vector being exploited by cyber criminals to hack and otherwise misuse WordPress sites.

These vulnerabilities are not introduced intentionally, they are a normal part of software development. Developers address this by releasing updates. It’s important you take an inventory of all the plugins the website uses and subscribe to the developers mailing list to ensure you stay current with the latest updates.

It also really important to mention that while vulnerabilities can accidentally happen, the idea that they are a normal part of the development process is deeply troubling.

19 Jun

Making Changes to Fix Claimed Vulnerabilities in WordPress Plugins Can Have a Negative Impact

Fairly regularly we have found that reports of vulnerabilities in WordPress plugins turn out to be false. That doesn’t always stop developers from making change to fix them as if they really existed (at the same time developers often don’t fix real vulnerabilities). In many cases the change improves the plugin as the change doesn’t fix a vulnerability, but what was allowed to occur before could be consider a bug. In other cases the change duplicates something already occurring in the plugin or WordPress, which increases resource usage slightly, but doesn’t really make a major change. But as what happened recently with WP Job Manager shows it is possible that it could have a negative impact.

As we discussed last week, in the most recent release of the plugin a change was made so that files could no longer be uploaded through the plugin’s AJAX functionality by those not logged in to WordPress. We don’t really understand what the security relevancy of that was supposed to be as those not logged in would normally still be able to upload files through the plugin and according to a report labeling it as a vulnerability, their ability to upload images was supposed to be issue. The report even stated that there were website defacements due to this, which we haven’t been able to come up with an explanation as to how that could be possible since the types of are restricted so you can’t upload directly malicious files.

As thread on the support forum for the plugin shows websites using the plugin were using that removed functionality and that its removal has impacted them doing business:

Since recent running updates for WordPress and plugins. Users are no longer able to upload images via front end form when purchasing listing package.

 

We’ve also ran into this issue. In fact, it cost us a sale already 🙁

This is a good reminder that reporters of vulnerabilities should be careful and make sure they are in fact reporting something that is a vulnerability (and listen when someone else lets them know that something isn’t a vulnerability).  Developers should also be aware that reports of vulnerabilities are not always correct, at the same time they shouldn’t just ignore them as seems too often be the case.

This also seems like a good time remind people that we are also happy to provide free help to any developer of a WordPress plugin that is dealing with a security issue.

16 Jun

How Does Uploading an Image Through WP Job Manager Lead to Website Defacement?

Earlier today we looked at how the report of a vulnerability that was supposed to have been fixed in version 1.26.2 of the plugin WP Job Manager involved something that was not actually a vulnerability. There was a change made related to what was describe in the report, but it just added additional protection over what was already in place.

The other change listed in the changelog of that version seems also to not involve something that would normally be classified as a vulnerability:

Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in. Themes should check with job_manager_user_can_upload_file_via_ajax() if using endpoint in templates. (https://github.com/Automattic/WP-Job-Manager/pull/1020)

Even with that change those that don’t already have an account would by default be able to upload images because of how the plugin works (the types of files that can be uploaded were already restricted as detailed in post we wrote about a previous false report of a vulnerability in the plugin). In one of the comments on the pull to make the change, one of the developers says as much. In relation to question about those not logged in uploading images they responded:

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.

That then brings us to a vulnerability report from the JPCERT/CC and IPA that relates to this. In that they state that prior to 1.26.2 the plugin failed “to restrict access permissions” and that “A remote unauthenticated attacker may upload an image file to the server.”. Considering as we already stated that even with the change those that didn’t already have an account can upload images by default, it’s not clear how if a vulnerability previously existed that it is now resolved.

What seems more problematic is what they list in the addendum section:

As of June 15th 2017, JPCERT/CC has received several incident reports of website defacements exploiting this issue.

We don’t understand how being able to upload an image by itself would lead to a website being defaced. The closest we could think of, without say using it with a local file inclusion (LFI) vulnerability, is that they are considering just being able to upload an arbitrary image and then link to it as a website defacement. But as we mentioned twice before, the change made doesn’t really fix that, so if that issue actually existed then it should still exist.

If this didn’t actually lead to website defacements than passing along an unfounded claim would fairly irresponsible of them.

In you have another thought that might explain the website defacement claim, please leave a comment.

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.

09 Jun

WordPress Plugin Directory’s Security Review Leads to Putting Public At More Risk

Yesterday we announced we have temporarily ended our notifications to the WordPress Plugin Directory when there are plugins with disclosed vulnerabilities in the current version of the plugin that is in the directory, until they put forward concrete plans to resolve two issues. One of those is finally warning people when they are using plugins that have been removed from the Plugin Directory for security issues. While years ago they claimed they were working on doing this, more recently they have claimed that doing so would put people at more risk. It is truly bizarre position to take just considering that many of these vulnerabilities have been publicly disclosed, so hackers would already have easy access to as much or more information than anyone has proposed including when warning webmasters of the issue. Then you have the fact that plenty of these vulnerabilities are not only known to hackers, but being actively exploited before the plugins were removed from the Plugin Directory (we know this because we have reported many of those to the Plugin Directory).

While that is really a black and white issue, when it comes to security many things are not like that. And in many cases actions do have serious unintended consequences that are not obvious. For example, we wouldn’t have though that the Plugin Directory doing a security review of a plugin after it has been removed for a security vulnerability could lead to putting the public at more risk, but that turned out to be the case as we recently found.

When it comes to suggesting how to improving the handling of security issues with WordPress plugins one of the problems we have found is that things on the WordPress side of things are very opaque. For example, we know they have the ability to release new versions of plugins with a fix when the developer doesn’t do it, but we have found no explanation of what the criteria for doing that are. It looks like the main criteria may be a vulnerability getting press coverage, as that seems to be main difference between the one vulnerability we have seen do that with since the beginning of last year and several other nearly identical vulnerabilities that were all being exploited widely. If we knew what the criteria were we could suggest a change to make sure those plugins actually get fixed. About the only thing they do provide clear information on is what is required to have an update forced out.

Another issue we can’t find any information on is the security review that is done before a plugin removed from the Plugin Directory due to a security issue is returned to it (if you are aware of where that information can be found please let us know). We know these reviews are done from looking at changes made to plugins and some things we have heard from developers, but beyond that it is a mystery.

What we do know though is that they have or cause a number of problems. Far too often we have found that plugins have returned to the Plugin Directory without the vulnerability that caused them to be removed being fixed. In some cases other security changes have been made in response to a request from the Plugin Directory, so there clearly was a review, but one that didn’t accomplish what seems like its most important goal.

The review also slows down a fixed version being released, which seems like it might be a reasonable trade-off if the reviews insured the vulnerability was fixed, but it doesn’t. In some cases where the vulnerability has actually been fixed, but the review brought up other issues that were required to be resolved before the plugin returns. In some cases though the additional issues are not significant, so people remain at risk of the most serious issue for an extended period of time.

Another issue that we see happening, though we don’t have a good idea of how often it is occurring, is that developers decide to abandon the plugin due to this review process. On the one hand if the developer isn’t willing to properly handle security of their plugin, this might not be the worst thing, though with WordPress not warning people about vulnerable plugins it does leave a less than desirable situation. But what if that actually caused public to be at more risk? Well that actually has happened.

Back in January a persistent cross-site scripting (XSS) vulnerability was disclosed in the plugin Contact Form DB, which according to wordpress.org had 500,000+ active installs at the time. That plugin saves contact form submissions submitted through various contact form plugins, including Contact Form 7. After the developers interaction with the Plugin Directory team over improving the security of the plugin they decided to no longer list it in the Plugin Directory. As we noted at the time, the developer wasn’t entirely accurate in describing the situation, as their original attempt to fix the vulnerability had not actually resolved it as the claimed (we had contacted them privately to information of that, but never heard back), so it isn’t clear how much the plugin not returning to the Plugin Directory was on the WordPress side.

Whatever the case there, one of the end results is that many people using the plugin are still using an insecure version of the plugin. As far as we can tell other providers of vulnerability data for WordPress plugins still don’t list this vulnerability in their data (which speaks to the higher quality of our data), so even if someone is taking the extra step of using some product or services, other than ours, that warns of vulnerabilities in plugins they are unlikely to know about this.

Another end result is that other plugins started to gain popularity and new plugins were introduced.

Looking the chart of downloads of the plugin Save Contact Form 7 you can see the impact of the other plugin’s removal (please note the chart counts updating existing installations as downloads as well as new installs):

There is an immediate spike after Contact Form DB was removed. There is then a big spike in late February after an update was released. A lot of those downloads are people that stuck with the plugin, as it went from having 1,000+ active install in December to 4,000+ in February to the current 10,000+.

Going back to the chart you can see that the downloads drop to 0 at the beginning of March, which we would guess was caused by the plugin being removed for a security issue. After version 2.0 was released, which was listed in the changelog as a “Security update.” we tried to figure out if there was a vulnerability fixed and spotted a fix for SQL injection vulnerability in that version.

Also worth mentioning here, according to the stats on wordpress.org even a month after 2.0 was released less than half the installs are using that version:

Version 2.0: 39.5%

When we were looking over that SQL injection vulnerability we found a much more serious issue in the relevant code, it turns out that all the contact form submissions saved by the plugin are publicly accessible. More than a month after we contact the developer about the issue we have not heard back from them and the vulnerability remains.

With the ease of exploitation that is something that we believe is more of an issue that the vulnerability that lead to Contact Form DB being removed from the Plugin Directory or what sounds like the issues that were causing the Plugin Directory team to not return it to the directory. Based on the downloads chart it is pretty clear then that the security review has led to a lot more websites using this plugin and putting many more contact form submissions at risk of disclosure.

After discovering that vulnerability we looked over similar plugins and found that another had more limited version of this. The plugin Contact Form 7 Database allows anyone logged in to WordPress to view any contact form submissions saved by that plugin. On a lot of website that isn’t much of an issue, but if account creation is widely available on website, say if it, like our website, use WooCommerce, it could be more serious. When we contacted company behind the plugin more than a month ago about the issue they responded “Our developers working to fix it”, but so far it hasn’t been fixed.

That plugin was only introduced to the Plugin Directory in the middle of March, but it already has 3,000+ active installs.

Like Save Contact Form 7, that isn’t the only vulnerability has recently been discovered in the plugin. After running across a report of a persistent cross-site scripting (XSS) vulnerability (that report used to exist here, but has been removed), we found a reflected cross-site scripting (XSS) vulnerability and cross-site request forgery (CSRF)/form submission deletion vulnerability in the plugin. Those were eventually fixed.

06 Jun

Not Every Security Update of a WordPress Plugin is Actually a Security Update

One thing that we emphasis when it comes to protecting websites against vulnerabilities in WordPress plugins is to keep them up to date at all times. Trying to guess which versions are security updates by following some security company’s blog or monitoring the change logs and the updating only those plugins simply won’t work. For example, when we looked at the relevant changelog entries for vulnerabilities we had in our data set two and half years ago we found that 20 percent of the time there was no indication that a security vulnerability had been fixed.

But as something we just ran across reminded us, it turns out that you can also have a plugin’s changelog indicate that a new version has a security fix that it doesn’t. Sometimes that is due to a plugin’s developer believing a false claim that a plugin had a vulnerability (not surprisingly considering their track record, the person behind that false claim became an employee of Wordfence shortly after that). In that situation at least there is some change being made that is intended to be a security fix. That hasn’t the case with the plugin oAuth twitter sidebar widget.

One of the ways we keep track of vulnerabilities that have been in WordPress plugins is to monitor for indications that a security update has been released and determine if there has been a vulnerability fixed. Through that we came across the changelog entry for version 1.6 of the plugin oAuth twitter sidebar widget, which is “Security updates for latest WordPress version.” Looking at the changes made in that version we didn’t see any security updates, the only change made was to change the description of the plugin. Our first thought was that maybe the developer had forgotten to include the security fix and we should let them know about the oversight, but then looking over previous changes we found that this wasn’t the first time this had happened. With version 1.4, the changelog entry was “Security updates.”, but the only change made was to remove a “?” from a commented line of code, which would not have any security impact.

01 Jun

Vigil@nce (vigilance.fr) Engaged in What Appears to Be Large-Scale Copyright Infringement

When it comes to the WordPress plugin vulnerabilities included in our data set, many of those being added come from information we have collected on our own. That includes many vulnerabilities that we have discovered as we all an increasing number where it has been noted that a security related issue has been fixed plugin, but no report detailing the vulnerability hasn’t been released. For vulnerabilities that are discovered and disclosed by others we don’t just copy their data, we spend a fair amount of time checking over the vulnerability to make sure we are properly labeling the vulnerability, correctly identifying the vulnerable versions (or if the vulnerability even exists), and determining the likelihood that it would be exploited. We also often take additional action, including working with the developer of the plugin to get the vulnerability fixed.

There are plenty of other data providers that simply collect others people data and sell access to it, without providing anything back. Not too long ago we found one those providers, Vigil@nce (vigilance.fr), was taking it even further by wholesale copying at least some of our reports on to their website. That seems to be a pretty clear case of copyright infringement and looks to probably be of a much larger scale than just our reports.

After becoming aware of that, we sent them the following message about this:

We have been made aware that you have copied our copyrighted content on to your website, for example the contents of our post at https://www.pluginvulnerabilities.com/2017/03/03/vulnerability-details-remote-code-execution-vulnerability-in-opti-seo/ is located on your website at https://vigilance.fr/vulne/vul/02/2/0/2/2/vulnerability-details-remote-code-execution-vulner.html.

As this is not legal it must be my mistake; so how did this happen, when will you be removing any of our copyrighted content from your website, and how you will you insure it doesn’t happen again?

The response wasn’t what we were expecting:

Thank you for this report.

I’ll look at this matter tomorrow.

I’ll add a filter to ensure that your website cannot have a local
copy anymore.

It should be clean in 24 hours.

This seems to indicate that this wasn’t happening by accident and it sounds like it is standard practice.

It would be one thing if they stored a copy of content privately in case a website later went down, but that isn’t the case here.

Amazingly they make the following claim on the Legal Notice page of their website:

Documents presented on this site are the property of Vigil@nce.

In the public portion of their entries they don’t provide any credit to the discoverer or link to the original source, instead linking into their own website (here is a recent addition where you can see that). By comparison we link to the original disclosure in our data and credit them in our post detail what vulnerabilities we have recently adding to our data.

What we find even more striking about this, is that at least they identify themselves as being part of the Business Services division of Orange, which is company that does billions of dollars of business:

We wonder if Orange would mind if someone started copying their content.

On their website they don’t provide any information on how much they are charging for access their data, so we can’t compare how we do on pricing, but if you are trying to keep of vulnerabilities you will get more complete data from us, as well as helping to improve the security of WordPress plugins.

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 “4.6.4.2 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.4.2, 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 4.6.4.2 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.