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 “ and below”.

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

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

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

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

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

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

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

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

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

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

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

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

25 May

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

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

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

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

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

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

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

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

25 May

Plugin Problems (pluginproblems.info) by WPX hosting Spreads False Information About WordPress Plugin Vulnerabilities

When it comes to security surrounding WordPress unfortunately there are lots of irresponsible parties that, either because they don’t understand security or because they don’t care, are spreading false information. That makes it harder to deal with the real problems that exist and are not getting the attention they need. Take for instance Wordfence the maker of the most popular WordPress security plugin, that among other things makes up threats and spread false information about claimed vulnerabilities in WordPress plugins, while the public continues to be left in the dark when they are using plugins that have been removed from the wordpress.org Plugin Directory due to security issues (including ones that are being exploited on a wide scale).

Another example we just ran across is the website Plugin Problems, pluginproblems.info, which appears to mainly exist to advertise the web hosting company WPX Hosting. We ran across them as they signed up for our service in what looks to an attempt lift information we provide to our clients, for their own website. Beyond any impact on our business doing that would cause, that is problematic as they have already shown they will spread widely false information, which we don’t want to have any part in enabling, so we have canceled their free trial for our service. The spreading of widely false information we spotted involves their first post titled “LayerSlider: XSS & SQL Injection Vulnerability“.

In what seems like rather bad form they don’t even mention who disclosed the claimed vulnerability they are writing about or link to the discloser’s post on it, which can be found here.

The post on Plugin Problems doesn’t get past the first sentence without a couple of major falsehoods:

It has just come to light that the popular plugin, LayerSlider Responsive WordPress Slider Plugin, by kreatura, currently has a massive vulnerability.

Near the end of the post you would find that the claim the plugin currently has the claimed vulnerability isn’t true, as it states:

To patch up the security gap on your website, you must update your Layer Slider plugin to the latest version or at least to version 6.2.1.

So as long as you are keeping it up to date, then you would be protected if the vulnerability had existed. That mistake is minor in comparison to the claim that the plugin has a “massive vulnerability”, as in reality what is claimed to be the vulnerability by the original discloser is a type of vulnerability that at this time has almost no chance of being exploited on the average website.

A couple of paragraph’s down we think that anyone that deals much in the security of WordPress plugins would see something that indicates the person writing the post doesn’t understand the basics, which would be a good reason for the company behind this website not creating the website or writing that post:

In the Slider Settings screen, there’s an option to save any changes. When saving those changes however, the plugin does not validate the request with a nonce (a string generated by WordPress which acts as a token for each request and is used to identify the WP user which is making that request).

A nonce is used to make sure that a user intended to take an action; it isn’t used to identify what user is making a request. The use of a nonce prevents cross-site request forgery (CSRF). Nowhere in the post is CSRF mentioned, but in the original it takes center stage as the post is titled “Layer Slider 6.2.0 CSRF to XSS to SQLi with POC”.

Seeing as we don’t see any evidence of attempts to exploit CSRF vulnerabilities on the average website at this time this would make the vulnerability rather minor, something that even the original discloser doesn’t seems to be aware of as they claim the impact is:

8/10 . It is CSRF to stored XSS bug, but LayerSlider has more than 55.000 sales and God knows in how many WordPress themes it is bundled in. This puts it as a high impact vulnerability.

If this type of issue was really as concerning as they both claim that would be a very big problem as cross-site request forgery (CSRF)/cross-site scripting (XSS) vulnerabilities are rather common and based on some recent interaction with developers to try get them fix, something that plugin developers often don’t have a even a basic understanding of.

One of the things we uniquely provide when it comes to data on vulnerabilities in WordPress plugin is an estimation of the likelihood of exploitation, so if you use our service you can avoid being misled by the frequent overstated claims of the severity of vulnerabilities.

The next part of Plugin Problem post diverges from the original discloser as they state:

Therefore, when the request is not validated, the user does not have to be an administrator to save those settings.

Once again something that is bolder is not true, as if you look at the discloser’s proof of concept it states to test it you need to:

log in to a website with Admin privileges

If you were to read the rest of their details, it would sound like this is a “massive” vulnerability but based on the reality of rest of it there is little risk here:

With a simple POST request to ‘admin-ajax.php’, any SQL injection can be performed through Layer Slider’s vulnerability.

This weakness can allow hackers to see the current users on a website, or even create an administrator user for themselves and explore the site freely.

It Wasn’t One Time Thing

Plugin Problems post taking from one of our posts for our customers is equally bad. As with the previous example, the bolding in their post refers to something that isn’t’ true:

This vulnerability is particularly for version 6.18 of the plugin.

The vulnerability is not particular to one version, but impacted numerous versions. That is something that a customers of ours that was using plugin would know because one of the things we do that you won’t find elsewhere is an accurate listing of impacted versions of a plugin.

The rest of their post is full of things large and small that are either not true or don’t even make sense. On the low end, it claims the latest version of the plugin is 6.19, despite that not being true. When it comes to not making sense there is this:

In part of the plugin’s code, where the pages and their actions are defined, the classes are not sanitized.
Sanitisation of fields and classes in PHP means to validate and make sure that the code/input is properly formatted.

Someone that writes PHP code would probably be rather confused by a reference sanitizing PHP classes since those are a structural element of code and not something that sanitization would be relevant to. What looks to have happened is the writer is in some way referring to the fact that reflected cross-site scripting (XSS) vulnerability in the plugin involves something output in class attribute of an HTML element and mix that in to something that doesn’t make sense. The need for sanitization would be the same if was occurring anywhere else, so being output in a class attribute wouldn’t be a significant thing.

More False Information from WPX Hosting

A quick check of the website of the web hosting behind the Plugin Problems website showed that their spreading of bad information on WordPress security isn’t limited to that website.

For example, on the page What Security Plugins does WPX Hosting Recommend? they write:

WordPress is the world’s most popular blogging platform; due to this popularity, hackers have taken an interest in taking advantage of poorly secured WordPress websites.

Using a security plugin on your website is highly recommended, as they will keep your website secure from known vulnerabilities.

There are many security plugins out there, however not all of them do a good job. We have tested out many of the released security plugins and have found the following most useful in securing websites:

In reality we have done testing of security plugins and found that they provide little to no protection against known vulnerabilities in other plugins. In the most recent test of a vulnerability that looks to have been being exploited on a wide scale, none of the plugins provided protection in the test. For two of three plugins they recommend, iThemes Security and Sucuri Security, they have provided no protection in our testing and neither of them even look as if they are designed to provide protection, so the claim by WPX Hosting there is very wrong.

If you are looking for actual protection installing the companion plugin for our service will alert you to vulnerabilities in plugins once we start to see them being targeted by hackers. Signing up for our service will get you access to expanded vulnerability data, support if you are dealing with a vulnerable plugin that hasn’t been fixed, and the ability to participate in deciding what plugins will receive security reviews from us.

23 May

How Our Data on Vulnerabilities in WordPress Plugins Compares to ThreatPress

One of things we focus on with our service is making sure we our providing the best data on WordPress plugin vulnerabilities to our customers. As there a number options out there, we look to see how they compare to make sure we are surpassing that. What we have found so far is that the other options out there really are not in the same league as what we provide (and they don’t provide the other important features that we do). The latest source we ran across seems to be a good example of that.

One of the thing we do be able to provide data on the most vulnerabilities is that we monitor for changes made to plugins that are related to security, which in addition to vulnerabilities and other security fixes can bring up changes made to security plugins. Through that we ran across a new plugin named ThreatPress and its data set of plugin vulnerabilities. A quick check showed several issues, the first being enough to disqualify this source as serious alternative to us at this time.

That issue is that the data set has very few recent vulnerabilities:

While the heading for the data listed is Disclosure Date, the dates for the first couple of entries don’t match the disclosure dates in their references, so either the dates refer to something else (maybe when they added them to their data set) or they are didn’t reference their real source for those for those listings (which seems possible as well for those two entries).

Since their dates are not clear, for comparison purposes we will assume the disclosure dates listed is the same as the month they added them. So far in May we have added 22 vulnerabilities and they added 0. Last month we added 84 (most of them being from a set of plugins we were one of three discoverers of) and they added 2. In March we added 41 and they added 4.

Quantity isn’t everything, but looking at the results most of the vulnerabilities they added are not likely to be exploited and they hadn’t added what is probably the most serious recent vulnerability. That vulnerability also hasn’t been added to other available data sources either, showing that they don’t even take the simply step of monitoring vulnerabilities that we publicly disclose. With them failing to include those, not surprisingly they are also missing the harder to find ones that we are able to spot through our fairly expansive monitoring.

There were a couple of other issues we noticed in a quick check over their data:

Inaccurate Impacted Versions

Like other data source we have seen, they don’t actually determine what the earliest version that is vulnerable while labeling as if they had. For example, for the most recent vulnerability, a reflected cross-site scripting (XSS) vulnerability in Ultimate Form Builder Lite, the listing under the Versions heading is:

Affected In <= 1.3.2
Fixed In <= 1.3.3

As with many vulnerabilities, not all versions below 1.3.3 are actually impacted. In our testing we found it only impacted versions starting with 1.2.0.

Where that type of detail is particularly important is if you are using the data as part of a hack cleanup, as from our experience they often involve websites that haven’t been updated for some time. When relying on other data source you can end up being told that there are vulnerabilities on the website that don’t actually exist in the version being used, which could mislead as to the source of the hack. We also provide an estimate of the likelihood of exploitation, which helps to focus on vulnerabilities that are likely to be the source of the hack (as many vulnerabilities have almost no chance of being exploited on the average website).

More Bug than Vulnerability

The second most recent vulnerability listed is Multiple SQL injection in AccessPress Social Icons, which we wouldn’t consider a vulnerability. If you just looked at their changes made in the version that fixes it there does appear to be a SQL injection vulnerability fixed. But if you actually look into the details, as we did at the time it was disclose you would see that the page where this occurs on is only accessible to those logged in to WordPress with the manage_options capability, which would normally only be Administrators:

add_submenu_page('aps-social', __('Social Icons','accesspress-social-icons'), __('Social Icons','accesspress-social-icons'), 'manage_options', 'aps-social', array($this, 'main_page'));

Administrators would normally be able to almost anything they want, so a SQL injection vulnerability wouldn’t provide them with any access they wouldn’t have. They also would normally be able to edit installed plugins, so they could undo any protection against this type vulnerability as well.

If you were to give a lower level user the manage_options capability they would normally be able to create a new Administrator level user with what they have access to with that capability.

If this was considered a vulnerability it should have been labeled as an authenticated SQL injection vulnerability.

With this issue there also isn’t even a possibility of cross-site request forgery (CSRF) coming in to play, as the plugin checks for a valid nonce before the potentially vulnerable code ran:

if (isset($_GET['action'], $_GET['_wpnonce'], $_GET['si_id']) &amp;&amp; wp_verify_nonce($_GET['_wpnonce'], 'aps-edit-nonce')) {
} else {