17 May

Wordfence Spreads False Report of Vulnerability in WordPress Plugin From WPScan Vulnerability Database

When it comes to improving the security of the WordPress ecosystem one of the big problems we see is that there is so much misinformation coming from the security industry itself. A prime offender is Wordfence, which despite having the most popular WordPress security plugin, is run by people that don’t seem to know almost anything about security and don’t seem to have any concern for accuracy in the claims they make (they also are fine leaving people relying on their plugin vulnerable to being hacked despite claiming that it will protect them).

Based on that we weren’t surprised that they would be spreading false information about a claimed vulnerability in a plugin based on data from the WPScan Vulnerability Database, which we have repeatedly warned has serious accuracy issues.

They also provided advice on evaluating plugins, which not surprisingly considering their lack of security knowledge, isn’t very useful for protecting against vulnerabilities that are a real threat. But there are things that you can that will actually help to protect you from those, as well get to.

A Lack of Due Diligence

In the post 22 Abandoned WordPress Plugins with Vulnerabilities they provide the list mentioned in the title using vulnerability listings from the WPScan Vulnerability Database. You don’t have to get past the first item list to find a problem, one that should have been fairly obvious. Here is the beginning of the list:

The first plugin WP PHP widget sticks out there as it 30 times more popular than the second most popular than the second most popular. While there are certainly issues with insecure plugins not being removed from the Plugin Directory (which is likely to get worse going forward as we will get to in an upcoming post), that seems like something that should been a red flag to Wordfence.

The asterisk next to it names indicates that the vulnerability being fixed:

We also found 4 plugins (marked with asterisks in the table below) that have fixed a vulnerability, but their fix was released in such a way that existing users are not updated to the newest fixed version. In each case, the author committed a fix to trunk but did not increment the version number and tag it properly in the plugin repository, so their users remain vulnerable.

Slightly down the post there is slightly different statement about the asterisk:

If the plugin is marked with an asterisk, you can disable and remove the plugin. Then reinstall it and you should have a newer version. We have not audited individual plugins for security so we can not verify whether a vulnerability has been comprehensively fixed.

We can’t understand why a security company would on the one hand say that vulnerabilities have been fixed, but that they didn’t actually check that they were fixed. That is irresponsible at best, incredibly negligent at worst. In the case of the claimed vulnerability in WP PHP widget they don’t appeared to have check things at all.

The first clue to that is the fact that the underlying report of the claimed full path disclosure vulnerability in the plugin was released on December 21, 2012, while the last update to the plugin was on November 10, 2010. That seems like a good indication that no change was made in regards to the report.

While there were changes made to the plugin after version 1.0.2, which is the most recent version and the one listed as being vulnerable, they don’t look like they could be related to claimed vulnerability.

Looking at that report it doesn’t come across as something that looks at all that legitimate as there is no code or explanation provided as to the issue. The only information given is that the vulnerability is supposed to be a full path disclosure vulnerability and that the vulnerability is “http://localhost/wp-content/plugins/wp-php-widget/wp-php-widget.php”.

If you were to install plugin on a production server requesting the URL /wp-content/plugins/wp-php-widget/wp-php-widget.php won’t normally cause a full path disclosure (will show what that is in a second), so that may have been the extent of what Wordfence did, if they did anything. The lack of full path disclosure would be equally true if you tried this with any version of the plugin.

Where you would get the full path disclosure if you had error reporting enabled in the server’s settings, in that case visiting the URL would get the following message:

Fatal error: Class ‘WP_Widget’ not found in [redacted]/public_html/pluginvulnerabilities.com/wp-content/plugins/wp-php-widget/wp-php-widget.php on line 29

In place the portion of that we redacted you would get the rest of the path to the file on the server, hence a full path disclosure. That alone isn’t going to allow you to hack a website, but it might aid in exploiting some other vulnerability.

So is that a vulnerability? We would say probably not if it doesn’t display when error reporting isn’t enabled (though the issue in this plugin could easily be fixed), but if it is, there is a much larger issue because the same thing will occur in the core WordPress software. For example, if you were to visit /wp-includes/wp-diff.php with error reporting enabled you would get this:

Warning: require(ABSPATHWPINC/Text/Diff.php): failed to open stream: No such file or directory in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

Fatal error: require(): Failed opening required ‘ABSPATHWPINC/Text/Diff.php’ (include_path=’.:/usr/local/lib/php’) in [redacted]/public_html/pluginvulnerabilities.com/wp-includes/wp-diff.php on line 13

So Wordfence’s claim that that the vulnerability had existed, but had been fixed is simply false. Either there never was vulnerability or there is a vulnerability that was never even attempted to be fixed. If it is the latter, then based on Wordfence’s recommendation you should be removing WordPress as well.

Evaluating the Security of Plugins

At the end of the post they state:

Plugins can make adding functionality to your website incredibly easy and are a big part of why WordPress is such a popular platform. The plugin repository on WordPress.org is an incredible resource, but as we have shown above it contains both abandoned plugins and ones with known vulnerabilities. Every plugin you add to your site increases your security risk, and you should evaluate each one to make sure it is being properly maintained.

Prior to that they give evaluation criteria:

A large number of plugin updates are submitted to the WordPress repository every day. For this reason it is important that you gain at least a basic understanding of who is behind a particular plugin before you install it. Here are a few steps you can take to evaluate whether you should use a plugin:

  • Check the average plugin rating.
  • Check when it was last updated.
  • Check that it is compatible with the current version of WordPress.
  • Check the number of active installs the plugin has. Some reliable and useful plugins have low install numbers but you should examine a plugin carefully if it has a low install base (below 1,000 active installs). It may not be maintained.

While we certainly suggest choosing a plugin that is being supported enough to list it as being compatible with the latest version of WordPress, it is important to understand that those criteria really are not a good way of avoiding an insecure plugin. To highlight that, look at results of looking at the information for the plugin Delete All Comments as of November 15 of last year (WordPress 4.6 was the then current of WordPress):

That all seems to meet their criteria, but five days later the security company NinTechNet would discover there was vulnerability in that was already being exploited. Even though the plugin has been recently updated before that, the vulnerability has never been fixed, so a plugin being maintained up the point you install it doesn’t necessarily even insure that an exploitable vulnerability will be fixed.

Realistically there isn’t much the average WordPress webmaster can do to evaluate the security of plugins. Instead your best bet is to make sure you are keeping your plugins up to date at all times and then look at options to provide you extra protection against vulnerabilities in them.

Our testing has shown that other security plugins don’t provide much protection against vulnerabilities in other plugins. For example, the vulnerability in Delete All Comments was not stopped by any of the 16 plugins we tested.

We offer several options that can provide extra protection. First the companion plugin for our service warns you when you are using plugins with vulnerabilities we see hackers targeting. To get more complete vulnerability data you can sign up for our service. Through our service we also work with developers to get vulnerabilities fixed and if you are using a plugin that hasn’t been fixed we are always available to consult with you on how best to deal with that (including providing you with a temporary fix so you can continue to use the plugin in the short term). When you use our service you also get suggest/vote for plugins to have a security review from us, which would catch many common security vulnerabilities in the review plugins (you can see the results of those review so far here).

17 May

Did Checkmarx Make Up Claimed High-Risk Vulnerabilities in Top WordPress e-Commerce Plugins?

Security journalism has been in rather bad shape for years, but at times it manages to be worse than others.

When it comes to coverage of WordPress what was a fairly popular line of stories years ago was to repeat claims by security companies that they had found a bunch of websites that had the same hack that were all running a certain outdated version of WordPress, with the implication of this that the hack was related to the WordPress version. When we would look into this we find problems from that websites were not all running the claimed version of WordPress or even running WordPress all, to vulnerabilities being cited as being in a certain version of WordPress actually being claimed vulnerabilities in plugins, to the blog of the security company where the claims were made running an even more out of date version of WordPress.

In recent years coverage has focused on vulnerabilities in WordPress plugins, which have actually existed, but in most cases are nowhere near as severe as the coverage would lead to believe (vulnerabilities in plugins that actually were severe often don’t get covered). It doesn’t appear that this change was due to security journalist requiring more proof before covering claims, instead it just seems to be have been happenstance as something that occurred late last year shows.

Back in late November the security company Checkmarx put out a report that they had found “high-risk vulnerabilities” in four WordPress plugins for eCommerce that could lead to “users of over 135,000 websites could find their personal data threatened by malicious parties or cyber criminals”. That lead to stories at Threatpost, SC Magazine, Computerworld, and Network World. At the time we noted that there wasn’t any actual evidence present to back up the claim and that it seemed entirely possible that vulnerabilities were not really severe. As SC Magazine wrote, the details, like what the name of the plugins was, would be released later:

Additional details on the vulnerabilities will be revealed only after the affected plug-in distributors have had an opportunity to respond to the disclosure, the company noted.

Recently we came across something else related to Checkmarx and that made us recall this. At that point we went looking to see if they had released any details of the vulnerabilities, we couldn’t find anything.

Several weeks ago we contacted the company to inquire where we could find the details of those vulnerabilities, we haven’t heard back.

Considering that it has been five months since they made the claims, there has been more than enough time for responsible disclosure, so we have to wonder if the vulnerabilities ever existed.

05 May

Be Aware That the Claimed Impact of Vulnerabilities is Not Always Accurate in Vulnerability Reports

When it comes to the many problems with the security industry, one of them that we see very often due to our work for this service is overstating the impact of vulnerabilities and claiming that issues that are probably not vulnerabilities are in fact ones.

The latest example of this we have come across is from DefenseCode, a company whose advisories we warned to be wary of last week. Earlier this week they put out a report (PDF) of claimed SQL injection vulnerability in the plugin Photo Gallery. The problems with it is that they are claiming an issue that we wouldn’t consider to be a vulnerability as being one, along with it looking like they overstated the potential impact, if it truly was one.

What makes us consider this to not be a vulnerability is the fact that is only accessible by Administrators, something they acknowledge in a way that seems misleading:

During the security analysis, ThunderScan discovered SQL injection vulnerability in WebDorado Gallery WordPress plugin. The easiest way to reproduce the vulnerability is to visit the provided URL while being logged in as administrator or another user that is authorized to access the plugin settings page. Any user with such privileges can obtain the valid bwg_nonce value by previously visiting the settings page.

What seems like it should be fairly obvious is that Administrators being able to do something isn’t usually a vulnerability. Normally Administrators would have the ability edit existing plugins and remove security checks or add new plugins that accomplish the same thing as the vulnerability.

So what other users would be “authorized to access the plugin settings page”? Normally none as the setting’s page and the AJAX function that are utilized to exploit this are only accessible to users with the ability to “manage_options“, which is only given to Administrators by default.

If you give a lower level user the “manage_options” capability two of the things they can do is to change whether user registration is enabled and what role that new users would have, so they would have the ability to create new Administrator users at that point and therefore you are effectively making them Administrators by giving them that capability.

That makes the next part of the claim somewhat moot as all the users who have access would effectively have full administrative privileges:

Users that to do not have full administrative privileges could abuse the database access the vulnerability provides to either escalate their privileges or obtain and modify database contents they were not supposed to be able to.

There is actually another problem with that beyond that user already being privileged because as far as we can tell the SQL injection vulnerability in this case couldn’t be used by the user to “escalate their privileges” or “modify database contents”. Looking at the relevant SQL query it looks to us that it could only be used to read data out of the database (the value $album_id is what is specified by the user):

$query = "SELECT id FROM " . $wpdb->prefix . "bwg_album WHERE published=1 AND id<>" . $album_id . " " . $where . " UNION ALL SELECT id FROM " . $wpdb->prefix . "bwg_gallery WHERE published=1 " . $where;

Maybe we are missing something here, but it seems that security companies often don’t understand that not all SQL injections have the same impact, so they repeat claims of what one could do without understanding if the one they found could do also be used to do that.

02 May

WP Site Guardian Uses WPScan Vulnerability Database Data, Which Can Be Accessed For Free

You can get vulnerability data on WordPress plugins from a lot of different sources, but in most cases the underlying data source is the same, the WPScan Vulnerability Database. While we think that is a good data source for a lot of people since you can get access for free, as the old saying goes you get what you pay for. For one thing they don’t actual test out claimed vulnerabilities, so they end up with fake vulnerabilities listed (included ones marked as having been fixed), real vulnerabilities that are not listed being fixed despite that being the case, and the most concerning unfixed vulnerabilities listed as being fixed.

For those looking for that type of protection against plugin vulnerabilities and that can afford our service it will provide you with what we consider to be much better data. For others, they will want to make sure to install our service’s companion plugin, as WPScan’s data is missing many of the vulnerabilities being targeted by hackers that are included in the free data that comes with that (their lack of that data is yet another issue with it).

What we find troubling is that there are products and services that use WPScan’s data without disclosing it is the source or providing any disclaimer as to the reliability of the data. Without those the person relying on the data doesn’t have the chance of understanding that . It also had leads to situations where it appears that multiple companies have found that a plugin contains a vulnerability, when in fact none of them have any idea of that, they simple are passing along WPScan’s data, which wasn’t accurate in those instances.

That brings us to a post on WordPress Support Forum that we ran across recently in our monitoring of that as part of keeping track of what new plugin vulnerabilities are being disclosed. It starts:

I recently bought the PRO version of the popular WP Site Guardian Plugin.
In their plugin Vulnerability section, it detected a problem with the Google XML Sitemaps Plugin.

We hadn’t heard of that plugin and the reference to it being popular seemed a bit odd.

Next they mentioned the details provided about the claimed vulnerability:

It is throwing this error:
Google XML Sitemaps – Authenticated Reflected XSS (via HOST header)

Which redirects to the bottom of this page:
https://plugins.trac.wordpress.org/browser/google-sitemap-generator/trunk/sitemap-ui.php#L1310

It seems quite likely the true source of that that is WPScan’s data as the title matches exactly to what it is in their data “Google XML Sitemaps – Authenticated Reflected XSS (via HOST header)“. The chances that someone else would have come up with that exact title independently are very small. The link in both is the same as well.

It doesn’t look like WP Site Guardian is disclosing their data source and in this case it would be relevant since this doesn’t appear to be a vulnerability. At best the issue looks to be a potential vulnerability. (The person that submitted it WPScan Vulnerability Database contacted us about at the same time they had submitted it to them and we never got a reply as to our question as to whether they had found a way to exploit it (and therefore it was vulnerability).)

In looking into what WP Site Guardian is, things don’t look at exactly on the level.

The website for it lacks any details, just bold claims like this:

WP Site Guardian – Proactive vulnerability Defence for WordPress

Protect against current and previously unknown plugin and theme vulnerabilities with the latest in anti-vulnerability technology.

That sounds impressive, but based on our knowledge of plugin vulnerabilities and our testing of other security plugins that would be difficult to pull off and there is nothing shown to indicate whoever is behind it is actual is doing that. It’s also worth noting that it isn’t clear what a previously unknown vulnerability would refer to, unless it is intentionally malicious code, vulnerabilities would have always been previously unknown otherwise they wouldn’t have existed in the first place.

The rest of the text doesn’t provide any more detail as to what is going on:

WP Site Guardian safe guards your sites by detecting and blocking plugin and theme threats.  Sloppy code on poorly written plugins and themes can leave your site open to threats for hackers looking for any opportunity for entry.

Anyone can make and sell a WordPress plugin, but few people have the skills to code plugins properly and safely.  This means that there are lots of popular products for free or on the market  that on installation will expose your site to hackers.

Even completely new WordPress users know that their security set up should be blocking those gaping holes left behind from coding mistakes or poor practice.  But few users set up the right defenses until it’s too late.

WP Site Guardian is the only WordPress security software that allows you to set it and forget it. WP Site Guardian does daily updates on the safeguards it employs – so your site is always protected with the latest best measures.

You can even be updated on all the threats being blocked or remain blissfully unaware.

Join over 2,000 happy customers and get started with WP Site Guardian today.

The ad that showed up in Google’s search results doesn’t make things look legitimate either:

[Wp Site Guardian 2017 Review - Save 99% Off & Exclusive Bonus‎ Adwww.marketingrack.com.au/WpSite_Guardian‎ [New] In-depth Wp Site Guardian 2017 Review. Save 99% Off & Free Bonus $12,000!]

Visiting the page in that ad we found that it isn’t actually a review and written as if by the developer of the plugin. Strangely that provides a lot more detail than the actual website of the plugin.

While it provides details it doesn’t give us confidence in the product if it was truly from the developer. Take this section:

WordPress itself openly broadcasts every piece of information a hacker needs to hack you, including your WordPress version, your theme & plugin names + versions & with that kind of information it doesn’t matter what security you are running – you are toast even to a script kiddie (baby hacker)

Shields up was developed to make your sites run in “stealth mode” – clearing all the critical information that WP broadcasts by doing so it reduces the risk of hack attacks by up to 95% – hackers simply get bored & move on to an easier target….another amazing pro-active defence tool in our toolbox…

Either this person who wrote this doesn’t know what they are talking about or they are lying to the readers. Hiding that information will have next to no impact. Many hack attempts are totally blind, that is a hacker will try to exploit a WordPress plugin vulnerability without even checking if the website is running WordPress, much less the plugin. In other cases hackers will request plugin file’s that we doubt that a plugin would try to hide, CSS and JavaScript files, since they may need to be accessible in the normal course of using the plugin.

As for the price, remember the ad stated it was 99 off, isn’t listed on the website or through the Buy Now button on the ad’s page, which seems odd as well.

Looking at the rest of the search results we didn’t see anything else that made this seem more legitimate.

02 May

Even Popular WordPress Plugins Not Getting Much Needed Cursory Security Checks

One of the ways we are very different from the other sources of vulnerability data on WordPress plugins that we are aware of, is that we actually review each reported vulnerability when preparing to add it to our data. That means that we can provide higher quality data than other sources, so you don’t get told among other things that an unfixed vulnerability has been fixed and don’t get warned about vulnerabilities that don’t exist as you do with other sources. That also means we have looked at numerous reports and we have seen the good and the bad of handling of security in WordPress plugins. Something we ran across recently managed to surprise us and is a good reminder that even popular plugins can have glaring security failures that are left in place for years.

The plugin Form Maker (also referred to as Form Maker by WD) as you might guess from the name handles forms on website and is fairly popular, with 90,000+ active installs according to wordpress.org. Last Wednesday a new version, 1.11.2 was released, which had as one of its changelog entries “Fixed: Security issue”. After noticing that the new version was indicated to have a security fix we looked around to see if there had been a report released on the issue, when we didn’t find any we started to take a look at the changes made in that version to see if the fixed security issue was a vulnerability that we should be adding to our data set.

What looked to be the relevant change was running a variable through the escaping function esc_html() in the file /admin/views/FMViewSubmissions_fm.php:

627
$temp[$g]->element_value = esc_html($temp[$g]->element_value);

Based on the name of file it seemed possible that this was related the page that would show the contents of submitted forms. It seems hard to believe that the plugin wouldn’t be properly handling the security of user input coming through forms submissions. Not only is that very basic when it comes to security, but if the developer had missed doing that you would think that for plugin used on some many websites someone else would have checked on that.

We then tried to see if there was previously a persistent cross-site scripting (XSS) vulnerability that change indicates that there might have been. We were immediately able to cause a persistent XSS to occur, though with further checking we found that we had gotten a bit lucky.

What we found is that if you changed the value of a selected radio button in a form to JavaScript code that code be saved unchanged in the database as part of the form submitting and the JavaScript would be output and run on the Submissions page in the WordPress admin area. The escaping added in version 1.11.2 prevents the JavaScript code from running.

When we went to do further testing we found that when we tried to submit JavaScript code in text input in a form that it was being saved to the database in escaped form and was still escaped when out Submissions page in the WordPress admin area. Clearly there was something different happening in the plugin’s processing of those two types of inputs.

In what might explain why the vulnerability had been in the plugin and had been there for a long time we had a bit of trouble figuring out where the code for saving form submissions that was involved here was located (it was located in the function save_db() in the file /frontend/models/FMModelForm_maker.php ). Once we found that the reason for this discrepancy between the handling of those inputs was obvious.

Here is the line for saving a radio input:

$value = isset($_POST['wdform_'.$i."_element".$id]) ? $_POST['wdform_'.$i."_element".$id] : "";

By comparison here is the text input’s line:

$value = isset($_POST['wdform_'.$i."_element".$id]) ? esc_html($_POST['wdform_'.$i."_element".$id]) : "";

In that the value is passed esc_html(), unlike the radio input.

Going back through older versions we found that the escaping that occurs for some inputs was not there when the code was originally added, instead in occurred in June of 2014, so before that the other inputs were also available to use for persistent XSS. For the version that changed occurred in, 1.7.10,  the changelog entry is “security issue fixed”. Its odd that the others were not changed in the same way at the time and that the more recent fix did not involve doing that as they are still stored in the database in potentially unsafe way (if say, another plugin were to display their data without doing their own escaping). We have just sent a message to the developer suggesting they do that.

That previous incomplete fix seems like another indication that having more eyes review security changes could leave to further improvements. We do plenty of that type work now, but it could be made easier for us and others to do that. It would be particularly helpful if developers provided more information on security fixes, so that others could easily review them. Instead of something like this where we had to dig through the changes made in a new version to try to figure out what is going on. While it is way down the list of things WordPress could do to improve security, them putting in place a formal process where developers could submit information on security fixes and it could be reviewed by others looks like it could lead to better security.

28 Apr

Don’t Assume That All Security Companies Are Not Actually Addressing Real Security Problems Related to WordPress

We have done a number of tests of WordPress security plugins to see if they protect against exploitation of real vulnerabilities in other plugins (and really should do some more). That the results of that testing showed that those plugins provided little to no protection against exploitation of the vulnerabilities wasn’t all that surprising to us, for a number of reason, including that we are often brought in to clean up hacked website that had multiple security plugins installed at the time the website was hacked. Something that really surprised us was the response from the developer of one of the plugins that provided no protection, BulletProof Security. They stated that “it is outside of the scope or intended purpose for any security plugins” to protect against vulnerabilities that exist in other plugins.

Based on their explanation of why that was, it would seem that would apply to other vulnerabilities as well, since they don’t believe any security plugin should interfere in the “normal functionality in any other plugins” and many, maybe most vulnerabilities, involve misuse of normal functionality. That misuse could be due to either someone who is not intended to have access to the functionality, accessing it, or the functionality being used in a way it isn’t intended to be. Considering that protecting against vulnerabilities in other software on the website being exploited is one of the few things that security plugins could actually do to protect a website from real threats, we wonder what it is the plugin is even supposed to being doing to earn the name BulletProof Security.

The problem with this sort of thing is that you have lot of people, the plugin has 100,000+ active installs according to wordpress.org, using a plugin promoted as providing bulletproof security when the developer isn’t even attempting to provide that. That sort of thing makes it harder for people to find that there are solutions that address real issues. As an example take a look at a recent comment on our post about the developer of that plugin believing it is outside of scope to protect against plugins vulnerabilities. To a large degree that commenter is basically describing what our service does, but as if it something that isn’t being done and would be difficult to do.

Here is what the commenter said that they believe we are expecting security plugins to do:

a) monitor the security flaws of *other* plugins (given there are probably hundreds and hundreds of them with major bugs),
b) and then create exceptions for these issues, and
c) then have to provide support to their customer base for those issues as well.

We do both “a” and “c” as part of our service. For “b” we instead try to work with developers of the plugins to get the vulnerabilities fixed, which when that happens helps even those not using the service. When vulnerabilities are not fixed then “c” comes in to play as we are available to work with customers to decide what is the best action to take in their situation. It might be that they can safely ignore a minor vulnerability (not all vulnerability impact everybody’s use case), we might be able to provide a workaround, or it might be that the plugin is so insecure that the best course of action is to remove it. We also provide data on the vulnerabilities in plugins that we see are being exploited in the free data that comes with our service’s companion plugin, so those not yet using our service can be warned when those type of vulnerabilities have not been fixed as well.

The commentator then claims the following problems with doing what they say we are suggesting:

1. Security plugins which are based on identifying illegal behaviours cannot be expected to be blocking what is essentially *normal & legal* functionality which is now insecure due to the poor coding of a 3rd party plugin. This would mean that they are essentially writing one-off specific case code for individual plugins and having to maintain that in their plugins. What a nightmare that would be for them.
2. They would need a team of people just to identify and test for 3rd party plugin code bugs and security issues. Purely from a business perspective, I cannot see how it would be viable to provide this based upon the costs of maintaining a security plugin in the rapidly changing WordPress ecosystem, notwithstanding that there are probably thousands of free plugins that are horribly written.

We avoid problem one by working with developers to vulnerabilities fixed, it should be noted that other companies promote services that with claim they do what is described there, but from what we have seen they don’t it very well.

For problem two, we actual already do this.

If there were less products and services out there promoting themselves in ways that are wildly inaccurate (the Wordfence Security plugin is promoted in part as “Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.”, despite that it couldn’t possible stop a lot of hacks) it would probably be easier for us to get more customers, which could allow us to expand what we are doing to address the security issues with plugins (for example, expanding the frequency of security reviews of plugins that we do).

27 Apr

You Still Won’t Always Know That a New Version of a WordPress Plugin Includes a Security Fix

When it comes to improving security, one of the problems we see is that it is possible to do things that are probably not productive, but look that way. One thing that we often think is not helpful are security companies and news organizations telling you need to update some WordPress plugin due to a security fix in the new version. That sounds like a good thing, as unless there is a bug in the new version doing that shouldn’t have a direct negative impact, but there are a couple of problems we see that come with that.

First, often times the threat posed by the vulnerability is vastly overstated, so you have some vulnerability would likely never be exploited on the average website treated as being critical. That is often done by talking up the worst case scenario and failing to mention important limitations on its exploitation. Some of this may be due to the fact that many security companies don’t actually have a good understand of what threat the vulnerabilities pose, as we often see that companies that clean up hacked websites are not determining how they got hacked (if you see someone claiming that websites are being hacked due to outdated software without pointing to a specific vulnerabilities there is a good chance they don’t know how they were hacked), so they wouldn’t have a good understanding of which ones are really a threat and which ones are not a big deal. (With our service we provide you our estimate of the likelihood of exploitation of vulnerabilities, so you have a better idea of how much of threat there is.) This also often leads to a lot comments that WordPress is insecure, despite a minor plugin vulnerability not being an indication of that.

Secondly, and we think much more importantly, is that this kind of thing gets people to lose focus from what they really should be doing, which is keeping their installed plugins up to date all of the time (if you are doing that, then there wouldn’t be a need to be told to update a specific one). The reason that is so important is that not only do a lot of the vulnerabilities that really pose a threat not get coverage, but plenty of vulnerability fixes don’t even get mentioned in the plugin’s changelog. When it comes to a lack of coverage, take for example the arbitrary file upload vulnerability we disclosed in a plugin last week, that is a type of vulnerability that is likely to be exploited, but so far we can find almost no one else covering it (we only found one personal blog with a mention of it). The same vulnerability also can be used an example of the lack of changelog mention, as these are the only entries in the version it was fixed:

  • Woocommerce 3.0.4 compatibility added
  • Fix – Fixed PopUp issue

Neither of those seem to relate to the vulnerability. That isn’t the only example we have run across in the last week either, take a SQL injection vulnerability in another plugin, which is much less likely to be exploited, that was disclosed on the WordPress Support Forum nearly two months ago and was fixed this week. Below are the changelog entries for the versions of the plugin released this week, can you guess which one is reference to a security fix?

1.2.2

  • Update: Use regex pattern matching to ensure session IDs are identical going in/out of the DB to account for encoding differences

1.2.1

  • Update: Additional filters for the setcookie parameters
  • Update: Expose the Session ID publicly
  • Fix: Better handling for malformed or broken session names

1.2.0

  • Update: Enhanced plugin organization
  • Update: Added WP_CLI support for session management
  • Update: Add Composer definitions
  • Fix: Break up the deletion of old sessions so queries don’t time out under load

As best we can tell it might be referred to with this one, “Fix: Better handling for malformed or broken session names”, but even we are not sure (from the testing we did we confirm that it was fixed in that version 1.2.1 though).

For a lot of people their best option to keep their plugins is up to date is to allow WordPress to automatically update them. That capability has been built-in to WordPress since version 3.7, but it isn’t enabled by default, like it is for minor WordPress updates. There a number options available to enable it, including our Automatic Plugin Updates plugin, which also allows you to exclude certain plugins from automatic updates and get sent an email when an update happens.

25 Apr

Be Wary of DefenseCode’s Advisories

In contacting developers about vulnerabilities in their WordPress plugins, whether they are ones we discovered or ones discovered by others where the discoverer didn’t contact the developer, we have fairly regularly had responses that we must be wrong about there being a vulnerability in the plugin. We have found that a bit odd, why would someone take the time to notify someone of a vulnerability that doesn’t exist? But as we have had more interactions with companies and individuals putting out reports of vulnerabilities that we have identified problems with, it has become clear that others are not always as careful as we are (we have also found that they are just as assured that issues we raise about their reports must be wrong, so both sides have something in common at least).

The latest example involves a company named DefenseCode, which we previously mentioned as we had both independently discovered a number of vulnerabilities in plugins by BestWebSoft. They also put out a report of a vulnerability in Magento recently that received a fair amount of coverage, despite the fact that the report could charitably be described as misleading (as part of the claimed issue didn’t exist unless you intentionally disabled Magento’s protection against it).

Last week they released a report of a vulnerability (PDF) in the plugin Ultimate Form Builder Lite. From the report it wasn’t clear if the vulnerability had been fixed. For example, the Solutions section reads as follows:

Vendor did not respond to our repeated attempts to send this advisory. All users are strongly advised to update WordPress AccessPress Social Icons plugin to the latest available version.

Beyond the wrong plugin listed there, it suggests updating the plugin, which wouldn’t do anything if the vulnerability hadn’t been fixed, but nowhere in the report is stated that is fixed.

The version impacted is just listed as “Various” and the timeline provided makes no mention of the vulnerability being fixed:

03/24/2017 Vendor contacted
04/12/2017 Vendor contacted
04/13/2017 Vendor contacted
04/19/2017 Still no response. Advisory released to the public

When we went to test out the vulnerability we found that the proof of concept did not work with the current version of the plugin. Looking over things we found that the vulnerability had been fixed in version 1.3.3, which was released on March 13, and the developer credited 0xSec Team for reporting it:

  • Fixed XSS issues on preview page and backend form settings page
  • Special Thanks to 0xSec Team for reporting the security bugs

That made DefenseCode’s claims to have contacted the developer for the first time on March 24 seem rather odd, as that was 11 days after the vulnerability was fixed. What we thought might explain is that the dates matches the ones in their report of a claimed vulnerability (PDF) in AccessPress Social Icons, which is the plugin mentioned in the Solution section, so maybe they had just included the wrong dates in the advisory and they had notified the developer after the 0xSec Team did, but before it was fixed.

When we contacted DefenseCode to let them know that something wasn’t right, as they claimed to have contacted a developer about a vulnerability well after it was fixed, they responded by providing a list of dates they contacted the developer, which were the same as the advisory, and a copy of the email they sent. That obviously didn’t address the issue at hand or even seem to be an attempt to do that.

In several more emails back and forth we never got clear answer to what was going on here, reading between the lines it seems to be possible that they discovered the vulnerabilities some time before they contacted the developer and didn’t bother to make sure that it still existed when they contacted them or before they released the advisory. That really shouldn’t be happening and it is likely to make it harder to get developers to respond promptly to report of vulnerabilities that actually exist in the current version of their plugins.

They seemed to be surprised that the developer didn’t respond to them, despite the fact that it is fairly common for developers not respond, and seemed to placing the blame for the situation on the developer not responding. They also seemed to not even grasp our point that it wouldn’t be all that surprising that the developer didn’t respond to someone claiming that a vulnerability existed in their plugin that had been fixed a week and half before.

Since the company at best is lax in their handling of claimed vulnerabilities, it would be wise to be wary of information included in their advisories and make sure you double check it before rely on it or repeating their claims (considering that security journalists don’t seem to care about the accuracy of what is in their articles they are unlikely to head this).

14 Apr

Plugin Using WPScan Vulnerability Database Data Doesn’t Warn When Using Unfixed Vulnerable Plugins

While we think that our service provides the best data on vulnerabilities in WordPress plugins, for many websites paying for a service to warn about the use of vulnerable plugins is probably not in the cards. You can always use the companion plugin for our service, which includes data on vulnerabilities in plugins that are being targeted by hackers. But what if you are looking for more broad based vulnerability data? That is where data from the WPScan Vulnerability Database can be good alternative, since there is no cost for access to their data (though some services actually charge for accessing that data). It is important to note that their data has some serious quality issues, including it not warning about vulnerabilities that are included our plugin’s data despite that being for vulnerabilities that are being exploited and the data being freely accessible (if you use a plugin or service that uses their data you will want to combine it with our plugin to protect you from this situation).

There are a number of plugins that provide access to that data, but as we found yesterday while preparing a post about another problem with WPScan’s data, not all of those plugins are equal and in the case of one them it is not providing important warnings.

While looking to show an example of one of them incorrectly warning about a vulnerability due to WPScan’s data indicating that a plugin was vulnerable when it wasn’t, we found that one of them, Vulnerable Plugin Checker, wasn’t providing a warning. We then tried to figure out what was going on and found the plugin will not provide any warning that a plugin is vulnerable if the vulnerability hasn’t been fixed. That is pretty serious issue since the most important use of this type of data is to warn when a vulnerability hasn’t been fixed, since if it has been fixed, simply keeping your plugins up to date will protect you even if you are not aware of the vulnerability.

To show what the cause is, let’s take a look at part of the code that adds a warning to a plugins listing on the Installed Plugins page, which is handled in part by the function admin_head(). The code checks to see if the plugin is known to be vulnerable with this line:

350
if ( isset( $plugin['is_known_vulnerable'] ) &&  'true' == $plugin['is_known_vulnerable'] ) {

The determination if it is vulnerable is handled with the following check in the function get_cached_plugin_vulnerabilities() (a substantially similar one is in the function get_fresh_plugin_vulnerabilities()):

151
152
153
154
155
// if plugin fix is greater than current version, assume it could be vulnerable
$plugin['is_known_vulnerable'] = 'false';
if ( version_compare( $vulnerability['fixed_in'], $plugin['Version'] ) > 0 ) {			
	$plugin['is_known_vulnerable'] = 'true';
}

For a plugin that hasn’t been fixed the value of $vulnerability[‘fixed_in’] in that will be null, so the plugin is considered to not be known to be vulnerable. Because the plugin is not considered to be vulnerable, no warning will be provided.

The end result of that if someone is relying on this plugin they would not be warned if, for example, they were using the latest version of Delete All Comments, despite a serious vulnerability in that, which was discovered by a security company after it was used to exploit a website:

We have notified the developer of the plugin through the WordPress Support Forum of the issue, so hopefully for those relying on the plugin it will get fixed quickly. If you are using another plugin or service that relies on WPScan’s data it would be a good idea to check if they are properly handling this type of situation and otherwise properly handling the use of WPScan’s data (in one other case we found a security company was misusing their data on vulnerabilities in WordPress and making false claims about WordPress websites being insecure).

Non-Independent Reviews

For a plugin that seems to have such a fundamental problem, taking a quick glance at its page on the Plugin Directory it might be surprising to see that it has received only five stars reviews:

While it is possible that independent reviewers might not have noticed this issue, in this case it looks like most of the reviews come from problematic sources. One comes from the developer of the plugin, another one comes from what looks to be their brother, and another one comes from account that looks like it was created just to post the review, which often is an indication that it isn’t an independent review. This seems like a good reason for those connected with a plugin to not be reviewing their own plugins, as it provides a skewed view of the plugin (would they ever give the plugin a poor review?).

13 Apr

WPScan Vulnerability Database Incorrectly Identifying Some BestWebSoft Plugins as Being Vulnerable

Earlier today we disclosed a reflected cross-site scripting (XSS) vulnerability we had found in numerous plugins by BestWebSoft after another security company that had independently found the same vulnerability disclosed it (the developer of the plugins was aware of it before either of us, but hadn’t fixed it in most of their plugins).

If we hadn’t already known about the vulnerability and prepared the data on the vulnerable plugins we would have had a lot of work to do today as the vulnerability impacts 53 plugins. The most time consuming part of preparing that data is determining what versions are vulnerable, but doing that insures that our customers are only notified if they are using a vulnerable version. While this vulnerability is unlikely to be exploited, for vulnerabilities that are likely to exploited determining the vulnerable versions is also important for those using the data while cleaning up a hacked website as it is possible that a website might be using a version that is older than the version identified as being vulnerable but is not vulnerable due to vulnerabilities not always existing in all older version (in a couple of cases last year vulnerabilities being exploited on a wide scale only existed in a single version of the plugins).

For those relying on another service or plugin to warn them of vulnerabilities in WordPress plugins they use, the underlying source of the data is likely from the WPScan Vulnerability Database and for those people they are likely to fair number of them being warned that they are using a vulnerable version of one of BestWebSoft’s plugins when they are not. The cause of that is that according to WPScan’s data none of the plugins have been fixed despite the fact that 13 of them have been fixed and were fixed before the disclosure. Take for instance the most popular fixed plugin, Google Sitemap by BestWebSoft, which has 90,000+ active installs according to wordpress.org. The vulnerability was fixed in that plugin two weeks ago.

Here is how it would look if WPScan’s data indicates a vulnerability was fixed:

And here is how their listing for this vulnerability currently looks:

Here is how it looks for an end user using one of the plugin’s that uses their data if they have the current version of Google Sitemap by BestWebSoft installed, despite it not being vulnerable:

The Downsides of Using WPScan’s Data

While we think that WPScan’s data is a good option for a lot of people because it is available for free, it does come with significant downsides that anyone using should know about. This also includes odd omissions of vulnerabilitieslisting false vulnerabilities in their data and listing vulnerabilities that haven’t been fixed as being fixed. Not only are we not aware of anyone using their data including notice of those issues, but some plugins and services that use the data don’t disclose is as the source of their data so even if someone was aware of the issues with their data, they wouldn’t know it impacts them. Also problematic are services that actually charge for access to the data, because if you are paying for WordPress plugin vulnerability data then you should be getting better quality data than this.