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.

21 Feb

When The Solution to a Vulnerability in a WordPress Plugin is to Have Updated It Years Ago

Earlier today we were discussing an example of the problem with WordPress plugins not being kept up to date. Recently we have also been looking in to another example of that, which also shows the type of work we do to make sure our clients have the best data on vulnerabilities in WordPress plugins and also some of what developers have to deal with when it comes to claims of them in their plugins.

One of things we do to keep track of vulnerabilities in WordPress plugins is to monitor the Support Forum on wordpress.org for topics related to those. Recently we came across a thread for the plugin Spider FAQ that indicated there might be a vulnerability in it:

Today OpenBugBounty wrote us a mail, that we have a css vulnerability problem with the searchfield from Spider-Faq.

One resolution is, to filter some Signs in the Searchfield. Can anyone tell me, where the Searchfield is located and where we should enter the Filter for the Symbols?

That sounded like it was describing a reflected cross-site scripting (XSS) vulnerability in the plugin’s search functionality on the frontend of the website. When we went to check on that though we found that things seemed relatively secure. What seemed to be the relevant code escapes what is submitted to be searched for (in the form of POST input search) to prevent XSS:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

It looks like it would be better to be using esc_attr() instead of esc_html(), but other than things seemed fine.

At that point we were not sure what was going on and we waited to see if any more information would be disclosed in the thread that might make things clearer (due to the terrible moderation of the Support Forum, we avoid participating in it at this time).

After a response from the developer, the original poster responded with additional information. What was helpful to us in that was that they listed the address where this was occurring. With that we tried to see what version of the plugin was being used on the website, since it could have been that a vulnerability had existed in older versions of the plugin.

We were quickly able to identify that the version of the plugin being used on the website was from the 1.0.x series. That series was indeed vulnerable to this issue, as there is no escaping when the search term is output:

<div align="right"><input type="text" class="search_keyword" id="<?php echo 'skey'.$faq->id ?>" name="search<?php echo $faq->id ?>" value="<?php if(isset($_POST['search'.$faq->id])) { echo $_POST['search'.$faq->id]; } ?>" />

Version 1.1, which fixed that, was released on November 19 of 2013. So the plugin hasn’t been updated in over four years on that website.

Proof of Concept

Submitting the following proof of concept as the search term on a frontend page for the plugin will cause an alert box with the number 1 to be shown. Major web browsers other than Firefox provide XSS filtering, so this proof of concept will not work in those web browsers.

“><script>alert(1);</script>

21 Feb

The Failure to Update Vulnerable Plugin is Reminder of Security Industry’s Apparent Lack of Interest in Making Sure Websites Are Secure

Something we have recently been thinking might be a helpful way to explain why security is in such bad shape despite the amount of money being spent on it, is to think of the security industry not as the “security industry” but as the “insecurity industry”. By that we mean that most of the security industry seems to not be focused not trying to make things secure, but on selling people on the idea that insecurity is very much the natural state of things, that you are under constant attack, and that while they can offer you the best security, you shouldn’t expect that the protection provide by that is actually all that effective.

As an example of that, take something from Wordfence recently, where they seem be describing a situation where some web hosts had failed at doing a basic of security for their service and allowed customers to access to other customers’ files. Not only is that a failure at a basic level for a web host, what they seem to be  describing is something that was huge issue with web hosts a number of years ago, so there would be even less excuse for that still happening in 2018. To Wordfence though the situation was very different:

It’s important to note that vulnerabilities are a fact of life in any service, system or software. Finding, confidentially disclosing and fixing vulnerabilities is how industry works with the information security community to improve the products and services we use and keep the public safe. The process that we use is well established and is widely used by organizations that include Google’s “Project Zero” and Cisco’s “Talos” security group.

When vulnerabilities are found and vendors are responsive, you benefit as a customer of those vendors and can know that your vendor reacts quickly to fix security problems and will likely do so long term, keeping you and your data safe.

A disclosure like this is not an opportunity for “vendor shaming” or a witch hunt. All developers who write enough code write vulnerabilities at some point in their career. It is in fact a moment to celebrate responsive vendors and a well handled incident that left customers and the online community safer.

At Wordfence, we are excited when a vendor works closely with us to fix a vulnerability and responsive vendors garner the greatest respect from our engineering team.

If you read over the whole post and the comments it seems pretty clear that Wordfence doesn’t even know what the underlying cause of the issue was, so the idea they worked closely with the web hosts to fix it seems to be something we see fairly common with them, a hyperbolic statement overstating what they are doing.

What makes this worse is that it is likely that Wordfence’s keeping quiet on this allowed the problem to fester when if it had publicly disclosed promptly there would have been more pressure on the web hosts to promptly fix this. By not doing that there was an upside for Wordfence though, as they could get more people to pay them to clean websites, when the web host really should have been handling cleaning them up since they caused the problem in the first place.  You also have to wonder about Wordfence not seeming to understand that disclosing something is being exploited already is not the same as discovering something that hackers don’t appear to know off yet, where a limited delay of disclosure can make a lot more sense.

Also notable, one of the comments doesn’t paint such a great picture of Wordfence’s handling of this:

My client got hacked several times on Hostway and neither Hostway or Wordfence’s cleaning team figured out this was the issue at the time. We changed hosting providers and have been safe ever since. I’m glad you found this both to validate my diagnosis that the weak link was Hostway and so that Hostway’s customers will now be safer.

60 Percent Insecure

If we are wrong about this and the most of the security industry is in fact concerned about security, they don’t seem to be acting in a way that matches that. To show how even the basics of security are still failing to happen, while security companies don’t seem to acting as if there is a crisis  and instead trying to sell people on more advanced solutions (for which there is little to no evidence are actually more effective or effective at all) takes something we just ran across.

Several days ago we had a request at one of our other websites for a file that would be located at /wp-content/plugins/smart-google-code-inserter/smartgooglecode.php, which is a file from the plugin Smart Google Code Inserter. That was likely a request probing for usage of that plugin before trying to exploit a vulnerability in it. After noticing that we went to try to figure out what a hacker might be interested in trying to exploit in the plugin.

In looking over the current version we didn’t see anything that looked like it might be targeted by a hacker.

On January 1 Benjamin Lim had disclosed a persistent cross-site scripting (XSS) and a SQL injection vulnerability had existed in earlier versions of the plugin. The persistent cross-site scripting XSS vulnerability seems like it could be something that a hacker might be interested in since that would allow a hacker to get malicious code to be served up on the frontend pages of vulnerable websites and just that type of issue has been something that has been exploited before.

Those vulnerabilities were fixed on November 29, so if people were doing the security basic step of keeping software up to date, attempts to exploit this shouldn’t be of much concern since it shouldn’t impact many of the 9,000+ active installations of the plugin (according to wordpress.org). Unfortunately, if the wordpress.org data is accurate, about 60 percent of the installs of this plugin are still not using the fixed version, 3.5:

The Wrong Focus

To bring this back around to Wordfence, also in November, we wrote about how their behavior relates to just this issue:

When it comes to improving the poor state of security, what can be seen over and over is that the focus needs to be on the basics. Take for instance the widely covered breach of Equifax, which was a situation where simply keeping their software up to date would have prevented the breach from happening. But the security industry isn’t focused on that and doesn’t seem to ever consider that what they are doing is far too often part of the problem, even when it impacts them.

That type of issue applies with WordPress plugins, where many hacks involve exploitation of vulnerabilities that have already been fixed. So what is probably going to provide you better protection then any security product or service would be to simply keep your plugins update at all times (many of the security plugins don’t seem to provide any protection against those vulnerabilities), which can be done with things like our Automatic Plugin Updates plugin. But telling you that doesn’t help the security industry to sell their products and services, so you don’t often here that from them.

As example let’s take a look at a post from yesterday from Wordfence about vulnerabilities in several plugins, which ends:

We encourage you to share these vulnerabilities with the larger WordPress community to help keep site owners safe from exploitation.

If you read through the rest of the post they don’t ever say that you should be keeping your plugins up to date at all times, which is actually the best advice when it comes to the vulnerabilities mentioned there. Instead they tell you the plugins they are mentioning now should be updated “immediately”, which for one of the plugins is well after a hacker had started trying to exploit one of the vulnerabilities that had been in it. The three plugins they mention are far from the only recent updated plugins that had updates that fixed security vulnerabilities, so only mentioning that people should update those isn’t all that helpful.

The rest of the post is like so much from Wordfence, mainly an ad for their services, which seems to be the real reason they want people to share it. As well get to in a moment one of the vulnerabilities in the plugins they mention is an example of the poor quality of what Wordfence paid service provides over doing the basics and the post shows again that Wordfence has very limited security knowledge, despite claims to the contrary.

A couple weeks later we wrote something along the same lines involving another well known name in WordPress security, Sucuri.

To see another indication of the lack of understanding of the important of keeping software up to date at all times from the security industry, checkout a comment from another posts of ours from someone that describes themselves as a “Web application security and accessibility evangelist.”

By comparison, well before we ever created this service, we had introduced the aforementioned Automatic Plugin Updates plugin, which turns on WordPress’ abiltiy to automatically update plugins.