13 Jul

ThreatPress’ Strange Claim That Plugins Are the Most Common Cause of WordPress Website Hacking

When it comes to improving web security, one of the big problems we see is that there is so much inaccurate and outright false information put out by the security industry. That among other things, leads to people spending a lot of time and money trying to protect against threats that don’t really exist. Even when real threats get mentioned we often find that claims are being made that are not supported by the cited source of the claim (assuming there even is one). That is often the case when it comes to security surrounding WordPress, including our specific focus, WordPress plugins. As a quick example that we ran across not too long ago, a WordPress focused security company named ThreatPress claimed in a post that:

Plugins are the most common cause of WordPress website hacking.

Following that link gets you to a page that makes no mention whatsoever as to the cause of WordPress websites being hacked. What makes that so strange is that what is linked to is another post on ThreatPress’ own website, which is about how many plugin and theme vulnerabilities they added to a data set they collect last year. Considering the services that company provides they should be well aware that number of vulnerabilities found in WordPress plugins wouldn’t in any way tell you how often they are the cause of WordPress website being hacked.

It is also worth noting that their data set is missing a very significant number of vulnerabilities considering they claim to have only added 200 new plugin vulnerabilities last year, while we had added over 500. That doesn’t match up with one of their employees claim that their data set “includes all known vulnerabilities”.

28 Jun

CVE Doesn’t Provide Great Information on WordPress Related Vulnerabilities

The last few days we have had a bit of traffic to our website from a page on the website of the Common Vulnerabilities and Exposures (CVE), which aims to be “a list of common identifiers for publicly known cybersecurity vulnerabilities” and is “is sponsored by US-CERT in the office of Cybersecurity and Communications at the U.S. Department of Homeland Security“. The page that traffic is coming from is for a claimed vulnerability in WordPress, described as follows:

WordPress version 4.8 + contains a Cross Site Scripting (XSS) vulnerability in plugins.php or core wordpress on delete function that can result in An attacker can perform client side attacks which could be from stealing a cookie to code injection. This attack appear to be exploitable via an attacker must craft an URL with payload and send to the user. Victim need to open the link to be affected by reflected XSS. .

There are not any more details to indicate if this refers to something that has been fixed or even enough to confirm if it truly has existed. Strangely a post on a reflected cross-site scripting (XSS) vulnerability in the plugin WP Statistics that we released in April of last year is the only reference:

What connection that post has with that claimed vulnerability is a mystery to us. One possibility is that someone just listed it since it also is a vulnerability of the same type and related to WordPress.

That isn’t the only problematic recent entry.

Earlier today we discussed how other data sources on vulnerabilities in WordPress plugins have incorrectly labeled that a vulnerability in the plugin WordPress Comments Import & Export has been fixed despite it still existing in the current version. While the CVE entry for that vulnerability doesn’t specifically say it has been fixed it states “The plugin “WordPress Comments Import & Export” for WordPress (v2.0.4 and before) is vulnerable to CSV Injection.”

The references listed for that seem problematic in a couple of ways:

First they provide a link to the changelog of the plugin as confirmation. Based on the description of what confirmation means it appears that is only intended to confirm that vulnerability existed, not that it has been fixed. The problem with that, which should be apparent to anyone that deals with claimed vulnerabilities, is that developers do not always have a good understanding of security and we have seen plenty of situations where a developer repeated a claim that a vulnerability had existed in their plugin that hadn’t existed (at the same time developer often don’t acknowledge that there had been vulnerabilities that had existed). In this case while the vulnerability still exists the changelog for version 2.0.5 reads “CSV Injection was fixed – reported by one of our user (Bhushan B. Patil) CVE-2018-11526”. That changelog entry was added after we had notified them that the vulnerability had not in fact been fixed in that version.

The other is unexplained link to the WPScan Vulnerability Database entry for this vulnerability, which doesn’t offer any unique information and actually falsely claims that the vulnerability was fixed in an earlier version than anyone else is claiming:

Considering that database has a commercial service it seems inappropriate that a government sponsored entity is being used to provide it free advertising like that.

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.

04 Jun

Trying To Determine If WordPress Plugins Are Being Exploited Is Harder When Hackers Do Odd Things

One of the things that we do to make sure our customer are getting the best protection against vulnerabilities in WordPress plugins is to do monitoring to try to spot when hackers are looking to exploit vulnerabilities in those plugins. In doing that we have found that other security companies that make extraordinary claims about protection they provide don’t do that, even one that claims to have “unmatched access to information about how hackers compromise sites”, despite their ability to provide protection being limited without knowing about vulnerabilities that are being exploited. Something else we have found is that hackers do some odd things, including trying on a large scale to exploit vulnerabilities that have never existed. When security companies are not putting in the work that particular situation can lead to situation like when Wordfence was leading people to believe that a popular plugin had a vulnerability it had never had.

One of the areas of odd activity we have been seeing a fair amount of recently has been what looks to be hackers trying to access malicious files that others hackers may have placed in modified copies of legitimate plugins. This doesn’t make a whole lot of sense since the success rate of those types of attack would be incredibly small. Looking into one recent example of that lead to us finding what looks to be attempts to exploit an unfixed vulnerability that we recently disclosed.

Last week we had a request on this website for a file that would be at /wp-content/plugins/background-image-cropper/image/ico/search.php. That would appear at first glance to be a file for the plugin Background Image Cropper, which currently has 500+ active installs. But in looking at the plugin we found that not only has there not been that file in any version of the plugin, but the plugin doesn’t contain a directory /image/ico/ or /image/ (or any directories for that matter). In looking at the small amount of code in the plugin there was nothing that could have been exploited that could have lead to another file being added to the plugin’s directory.

What looks to have happened is that for whatever reason a hacker had decided to use that particular plugin as part of getting malicious code on to websites by installing a modifed version of the plugin after they have gained access to the admin area of WordPress as Administrator level user. That possibility would match with what is mentioned in a review of the plugin. Then some other hacker was trying to in turn exploit a file added to the plugin by the first hacker. Considering that including legitimate installs the plugin has less than 600 active installs, the success rate for that type of attack is going to be incredibly small.

While reviewing logs files on a hacked WordPress website we were cleaning up over at our main business several days after that, we ran across another attempt to access a file that would ostentatiously be in that plugin, /wp-content/plugins/background-image-cropper/wp-post.php, but again it isn’t in the plugin. In looking at all the requests sent from the same IP address we could see that two other files were attempting to be accessed:

178.170.82.27 - - [23/May/2018:04:04:07 -0600] "POST /wp-uti.php HTTP/1.1" 500 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:06 -0600] "POST /wp-uti.php HTTP/1.1" 500 303 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:12 -0600] "POST /wp-content/uploads/kc_extensions/background-image-cropper/wp-post.php HTTP/1.1" 500 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:11 -0600] "POST /wp-content/uploads/kc_extensions/background-image-cropper/wp-post.php HTTP/1.1" 500 303 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:58 -0600] "POST /wp-content/plugins/background-image-cropper/wp-post.php HTTP/1.1" 500 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:53 -0600] "POST /wp-content/plugins/background-image-cropper/wp-post.php HTTP/1.1" 500 303 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"

One of those interesting, /wp-content/uploads/kc_extensions/background-image-cropper/wp-post.php, because part of the path/file name structure was the same as the previously mentioned request. The rest of path, /wp-content/uploads/kc_extensions/, looked like it could be related to exploitation of a vulnerability in KingComposer we recently disclosed after spotting it due to proactive monitoring to catch vulnerabilities before they can be exploited, as exploitation would lead to files being placed in that location. That vulnerability has yet to be fixed by the developer despite us notifying them of it back on April 16.

Nowhere in that set of requests or the others in the logging was there an attempt to exploit the vulnerability in KingComposer, so we couldn’t be sure what was going on there.

In doing some other looking into that, we found what looks like pretty conclusive evidence that there are attempts now to exploit that vulnerability. There are various reports of abusive activity for an IP address that include trying to access a file in the directory that files would go if it was exploited, /wp-content/uploads/kc_extensions/reup/upload.php, and to access the address needed to exploit the vulnerability,
POST //wpadmin/adminpost.phpactionupload. What is also notable there is that the hacker has some understanding of things beyond just looking at our report because in our explanation we showed sending the input “action” as a POST input, but their requests do it as a GET. It is even possible that the hacking is unrelated to our disclosure, as it isn’t unreasonable to believe that hackers could be do the exact same type of monitoring that we do catch that type of thing.

If you were using our service and KingComposer you would have already been warned about the unfixed issue weeks ago and we would have been available to determine how best to handle the situation. Since we have now seen evidence it is being exploited we had the vulnerability to the free data that comes with the companion plugin for our service, so even those not using our service can be warned about. If you are relying on another data source for info WordPress plugin vulnerabilities there is a good chance you still are not being warned since most of those still have not added the vulnerability despite our public disclosure of it over two weeks ago.

If you want to get ahead of vulnerabilities like this, the same check that lead to us identifying the possibility of that vulnerability in KingComposer is included in our Plugin Security Checker tool (which is accessible through a WordPress plugin of its own), so you can identify if a plugin might have the same type of issue and is in need of further checking by using that too.

16 May

dxw Overstating Risk of Vulnerabilities in WordPress Plugins

When it comes to improving the security of websites among the many problems is that the public doesn’t have a good understanding of how much risk various security issues pose. That leads to among other things, people believing that websites must have been hacked due to software on a website that contained a known vulnerability despite no evidence to support that and it being very unlikely that the vulnerability would be exploited, much less that it could have lead to the website being hacked. Unfortunately we often find those involved in security are the ones overstating the risk posed by vulnerabilities.

On Monday we detailed a vulnerability that had been fixed in the plugin Metronet Tag Manager, where the changelog entry for the version it was fixed in was “Fixed serious security issue. Please Update.” A possible explanation why it was labeled as such despite not being anywhere near a “serious” issue came yesterday, as on Tuesday the finder of the vulnerability, dxw, released a report on the vulnerability with the title “CSRF in Metronet Tag Manager allows anybody to do almost anything an admin can”. The third sentence of the description seems to explain that claim:

As this vulnerability allows adding arbitrary JavaScript, the attacker can use it to control an admin user’s browser to do almost anything an admin user can do.

That all makes it sounds like it would be likely to be used to hack websites, but in reality there is about zero chance that the vulnerability would be exploited average website at this time. The chances of exploitation of that type of vulnerability could change at some point and it could be of more interest in a targeted attack, but it isn’t something of major concern for the average website at this time. The reason for that isn’t all that complicated and it also explains why that title is so misleading.

With a cross-site request forgery (CSRF) vulnerability an attacker could cause someone else to take an action they didn’t intend to take. In this case, for the vulnerability to be exploited, an attacker would need to get someone logged in as Administrator user on a WordPress installation to access a page the attacker controls. That is something that we don’t see hackers trying to do against the average website whether with this type of vulnerability or others that rely on that same type of action. Nowhere in their report did dxw mention the need to be logged in at all to exploit this, much less as an Administrator to have been able to exploit this, despite that clearly being a requirement.

What makes dxw claim more problematic to us is that to us saying anybody can do something would imply that anyone could take the action, whereas you would need to get one of a limited amount of people to take an action. This isn’t one time claim, for example with another recent CSRF vulnerability they titled their report “CSRF in WP User Groups allows anybody to modify user groups and types”.

Details Matter

In looking at another of their recent discovered vulnerabilities to add it to our data set we found another overstated claim. The title for a report on that vulnerability is “WP ULike allows anybody to delete any row in any WordPress table”. One of the claims made in it is:

The plugin contains a wp_ajax action which allows any authenticated user (it doesn’t check permissions) to delete any row of almost any table in the database (the table must begin with $wpdb->prefix).

Another is this (emphasis ours):

In a real attack, the form could be made to auto-submit on page load, and submit the form multiple times with different table and id values meaning that a single user falling for a phish could wipe the whole database.

The line of code that handles the deletion referred to in those statements is this:

$wpdb->delete( $wpdb->prefix.$table ,array( 'id' => $id ));

The critical part of that is “array( ‘id’ => $id )” as that defines what gets deleted from the table. That will delete a row from table where the “id” columns value is the value specified by $id, which comes from user input. If a table doesn’t contain an “id” column then nothing can be deleted. While two important WordPress tables, posts and users, have an “ID” column, which unless case sensitivity is in place their entries can be deleted, the others do not, so this could not be used to “wipe the whole database”.

dxw is at least aware of the column limitation as the last steps of their proof of concept states:

The value of id or table can be changed allowing deleting any row in any table with the WordPress prefix at the start of its name, and having an id column

So either they didn’t fully checks things over before making a sensational claim or they knew better and included that claim anyway.

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

Wordfence Security Didn’t Actually Stop Exploitation of Vulnerability That Isn’t Really a Vulnerability

When it comes to security products and services one of the many problems is that the public often is making claims about them that are not true. Oftentimes people will claim that a product or service has successfully protected a website when they don’t know that is true. Instead they are assuming that is true because the website was not hacked while using it (that they know of), but considering that most websites don’t get hacked, that correlation does not indicate causation. We have also often seen people repeating claims that products can provide some particular type of protection which seem to be based entirely on an unsupported claim made by the makers of the product or service. Considering the many times we have seen security companies lying (in addition to many falsehoods that we can’t say whether they know what they are saying is true or not) those claims being repeated are often not true.

While looking into a report of a claimed vulnerability in a WordPress plugin the other day we ran into another example of that sort of thing. Someone going by the handle B0UG had claimed that the plugin UK Cookie Consent had contained a persistent cross-site scripting (XSS) vulnerability. A new version of the plugin was released, which indicated that this had been a vulnerability:

  • Fixed: fixed security vulnerability identified by James Boughey

As we discussed in more detail in our weekly post on claims of vulnerabilities in WordPress plugins that are not really vulnerabilities, there really wasn’t a vulnerability here since the supposed vulnerability involved a situation where WordPress users are specifically permitted to use the equivalent of XSS.

In the remediation of section of the report there is the following information:

Update to the latest version available. Implement a web application such as Wordfence.

Considering that this wasn’t really a vulnerability we wondering if the plugin Wordfence Security would truly stop this as claimed. It seemed unlikely, since, as we just mentioned the supposed vulnerability involved action that is actually permitted to be happening.

To test things out, we created a fresh install of WordPress 4.9.5, and then installed version 2.3.9 of Cookie Consent, and version 7.1.3 of Wordfence Security. We then did the first three steps of the proof of concept for the supposed vulnerability using an Editor-level user (since that would be the lowest level user that would normally have the ability to take those steps):

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.

Wordfence didn’t stop doing any of those steps. We set the script in step 3 to show an alert box that reads “Wordfence Security was supposed to stop this.”

Then logged in as Administrator-level user we completed the steps that could only be taken by them:

4) Now navigate to ‘Settings’ and select ‘Cookie Consent’.
5) Now click on the ‘Content’ tab.
6) Your injected script will now be executed.

If Wordfence Security didn’t prevent this from happening the message “Wordfence Security was supposed to stop this.” would be shown at step 5 and that is exactly what happened:

That is actually the correct result, but it wasn’t what someone that thinks they have some security knowledge believed and was telling others, which is a good reminder of the poor state of security recommendations out there. What makes it more striking is that it would have been easy to test this out, unlike so many other inaccurate claims that are made. If a claim is being made regarding security products and services without supporting evidence (which is true about almost all of them) it would probably be best to assume that it is false based on everything we have seen.

02 Mar

This Isn’t Great Information on What Are Supposed to be the Most Attacked WordPress Plugins

When it comes to better understanding security surrounding WordPress there is dearth of useful data. For example, despite millions of websites using various security plugins and numerous claims of the effectiveness of them, the few test we have done of them to see if they could protect against the exploitation of real vulnerabilities in other plugins are almost the only testing that has every been done. Considering that that the results showed that they provide almost no protection, it isn’t like a lack of testing is due to a lack of need for that information. Most of the data that you might run across is of little value and often is distorted even further when repeated by others.

Recently while we were looking for information on something else we ran across a recent post on the website, jeffbullas.com, titled “The Top 50 Most Attacked WordPress Plugins Making Your Site Vulnerable to Hackers” (http://www.jeffbullas.com/attacked-wordpress-plugins/). A few paragraphs in, things already looked really bad, as there is this claim:

One study revealed that almost 98% of WordPress blogs were easily exploited because they were running outdated versions of the software, or outdated plugins.

There is no link to this supposed original study or any other information in the post about it (despite plenty of other links in it), so who knows if it really exists. But it if did, it must have come from someone that has no idea what they are talking about, since the number is absurd.

Moving on, here is the explanation of the information provided:

This post will highlight the 50 most attacked WordPress Plugins in 2017. The report will showcase:

  • The number of total attacks. This will determine the total number of attacks that were reported by the particular plugin.
  • The type of the attack. This will reflect the “Location File Inclusion” (LFI) attack that allows exploiters to download any file they want, or the “Unrestricted File Upload” that allows exploiters to upload a “shell” that gives them full remote access to target the site.
  • The exploit database link. This will determine the language used by the penetration testers and vulnerability researchers.
  • The WordPress plugin website.This will provide you details and information about the plugin and a link to download.

There is no explanation as to where the total number of attacks is supposed to have come from, which seems like it would be rather important to note. It looks like for portions of the list the plugins are ranked by the number of attacks, but occasionally the number of attacks changes dramatically from one plugin to the next, which makes us more suspicious as to whether the numbers are even real.

In an indication of the lack of understanding of the topic by the author, they confuse a local file inclusion (LFI) vulnerability with an arbitrary file viewing (or arbitrary file download) vulnerability despite linking to a page that accurately describes what a LFI vulnerability is.

We can’t even decipher what “This will determine the language used by the penetration testers and vulnerability researchers.” is supposed to mean (we also haven’t seen evidence that penetration tester discover a measurable amount of vulnerabilities in WordPress plugins).

Right after that is this statement:

If you use any of these attacked WordPress plugins on your website, you may want to look into ways to improve your security.

That’s not all that helpful.

At the bottom of the post they give better advice, though the post doesn’t indicate if the vulnerabilities have been fixed and therefore is upgrading will do any good:

If you use any of the above plugins, ensure you upgrade to the latest version, and adopt Wordfence with Firewall enabled to protect your WordPress sites from unexpected brute force attacks in the future.

Also notable here, is that brute force attacks are hot happening, so installing a plugin to protect against them would not be good advice since it would also add additional security risk (that isn’t a hypothetical risk).

To see the questionable value of this type data (if it was even accurate) just look at the first entry:

#1. Recent Backups (Backup for your website)

Total attacks: 2,159,725

Type: LFI

Exploit database:https://www.exploit-db.com/exploits/37752/

Website link: https://wordpress.org/plugins/recent-backups/

First this vulnerability was disclosed on August 10, 2015, so there is a good chance that if it would have lead to a website being hacked it likely would have occurred before 2017. What is important to note is that the type of vulnerability, arbitrary file viewing, is one of the most targeted types of vulnerabilities, but it doesn’t appear to usually lead to websites being hacked. What the vulnerability is normally exploited to do on a WordPress website is to view the contents of the WordPress configuration file, wp-config.php. The main piece of information that can be gathered from doing that are the database credentials for the website. As best we can tell hackers don’t try much to utilize that, the only time we can recall that leading a lot of WordPress websites being exploited due to that type of vulnerability was when GoDaddy had screwed up and starting making databases remotely accessible that were configured to not allow that.

The other thing that seems rather important about this, is that plugin is only used on 100+ websites according to wordpress.org, so the impact its exploitation could theoretically have is rather limited.

If the attack number is accurate, the main take away here is that hackers will try to exploit vulnerabilities that are used on very few websites and where the chance of successfully exploiting them is limited. That doesn’t require a list of 50 plugins and the post doesn’t provide any insight like that or useful information like if the vulnerabilities were fixed.

A far simpler way to check if you are using versions of plugins that hackers appear to exploiting would be to install the companion plugin to our service, as that will automatically check all the plugins installed against the free data on just that type of vulnerability that comes with that plugin.