21 Mar

VulDB Includes False Report of Vulnerability in WordPress Plugin

One of the differences when you get data on vulnerabilities in WordPress plugins you use from us instead of other providers is that we actually make sure that claimed vulnerabilities exist. Being warned about a vulnerability that doesn’t exist obviously isn’t useful, especially if you are told that vulnerability is in the current version of the plugin, which is often the case.

Yesterday we looked an example of just such a situation with the plugin WP Markdown Editor. We mentioned how the WP Scan Vulnerability database, which is the true source of plugin vulnerability data for almost any service or plugin other than ours, includes this vulnerability in their data. They are not alone, as the website VulDB, vuldb.com, also includes it.

That website describes itself as follows:

VulDB is the number 1 vulnerability database documenting more than 96000 vulnerabilities since 1979. A team of experts is looking for newly disclosed vulnerabilities on a daily basis. After the analysis of the technical capabilities the issue is documented in the database. This kind makes it possible for administrators and security experts to deal with the fast moving vulnerability market.

Seeing as the vulnerability doesn’t exist, any analysis they did clearly wasn’t thorough, but their description make it sound like there wasn’t really any analysis done at all (emphasis ours):

A vulnerability was found in WP Markdown Editor Plugin 2.0.3 on WordPress and classified as problematic. This issue affects an unknown function of the component IMG Element Handler. The manipulation with an unknown input leads to a cross site scripting vulnerability (stored). Using CWE to declare the problem leads to CWE-79. Impacted is integrity. An attacker might be able to inject arbitrary html and script code into the web site. This would alter the appearance and would make it possible to initiate further attacks against site visitors.

The weakness was disclosed 03/10/2017. The identification of this vulnerability is CVE-2017-6804 since 03/10/2017. The attack may be initiated remotely. Neither technical details nor an exploit are publicly available. The price for an exploit might be around USD $5k-$25k at the moment (estimation calculated on 03/10/2017).

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

You don’t even need to take our word that the vulnerability doesn’t exist as what they cite as their source states that:

** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

17 Feb

WordPress Shutdowns Discussion of Their Refusal to Warn About Unfixed Vulnerable Plugins

Since 2012 we have been trying to get WordPress to start warning webmasters when their websites are using plugins that have been removed from the Plugin Directory due to security issues (and notify people in general that they are using plugins that have been removed from it). In the past WordPress’ position was that they were working on implementing this, but as of the last year the position has changed that they can’t do this because it would cause people to be “MORE at risk“. Not only does this not make sense, as we will come back to in a moment, but they don’t want to even honestly discuss the issue. For example, last July they even deleted a reply of ours on the Support forum pointing out that the handling of vulnerable plugins was not in as good shape as they were portraying it.

With that background it probably shouldn’t be surprising to see what happened to a recent thread on the wordpress.org Support Forum, which we previously mentioned, that was discussing the lack of notification when plugins are removed from the Plugin Directory. The head of the Plugin Directory decided to close that thread due to it being “non-productive”. It seemed plenty productive to us, as people were discussing better ways to handle things. The closing seems to us to be part of a continued lack of professionalism on part of people on the WordPress side, which really isn’t acceptable considering the widespread and high profile use of the software. Seeing as the person doing the closing is intimately involved in the issue being discussed, it doesn’t seem like they should be making the call to close the thread.

Before they closed it they got to have the last word, which makes the closing even more problematic. By closing the thread after that it doesn’t allow for others to try to help them understand that WordPress’ position on this is not only misguided, but is leading to websites being hacked that should not have been. Since we can’t reply in the now closed thread, we wanted to explain again why the position they are taking is so bad.

Here was there explanation on why they think it is a bad idea to warn people:

Since we remove plugins for many reasons, the minority of which being security related, we do not disclose the reason why any one particular plugin was removed. Our quite serious and valid concern is that if we were to disclose that a specific version was at risk without providing a fix, we would put people at a greater risk. In addition, by removing the plugin, we put pressure on the developers to address the situation promptly.

As we have discussed in more detail previously there a number of problems with that.

It starts with the fact that many vulnerabilities have already been disclosed publicly, so the bad guys are already aware of them. WordPress disclosing that the plugin is vulnerable provides less information than attackers would already have available to them. While that might cause more interest from attackers, it would also allows websites using the plugins to take action, say removing the plugin.

Then you have the fact that plenty of plugins are removed after a vulnerability is already being exploited (this something we know because we are frequently the ones that spot the exploitation and report the vulnerabilities to them). If WordPress were notifying people of the vulnerable plugin in this situation they could actually take action, while right now they are left open to being exploited. It is this fact that makes us wonder at times if there might not be a more nefarious reason for not warning people (the company closely associated with WordPress, Automattic, has a security service, VaultPress, for example).

Another problem with this idea is something the people running the Plugin Directory are aware of, which is that some vulnerable plugins are never fixed. One of the reasons we know they are aware of this is they are keeping track of how long a plugin is removed, as this part of their comment shows:

I promise you this: We ALWAYS contact the developers and do our best to make it clear what was required to have the plugin restored as quickly as possible. The average plugin is restored within a week.

Another reason we know that they know this is because it is clear that some vulnerable plugins are never going to be fixed. While most vulnerable plugins are vulnerable due to a coding mistake, there have been some plugins that are intentionally malicious. Take for instance a group of plugins we discussed back in October, where someone had copied existing plugins and submitted them to plugin directory with malicious code added to them. The developer would have no reason to release a new versions that removes the vulnerable code, as having that in the plugins was their only reason for creating them. Those plugins were also an example of another issue, even if vulnerabilities are never publicly disclosed, hackers can figure out that they existed and exploit them.

The threat that vulnerabilities pose varies widely, with many vulnerabilities having almost no chance of being exploited on the average website, so what matters the most in terms of unfixed vulnerabilities is if vulnerabilities that are being exploited or are likely to be exploited ever get fixed and how long it takes for that to happen. Two fairly recent examples show that relying on plugins being fixed by the developer is not taking care of those situations.

Take a vulnerability in the plugin Delete All Comments, which was discovered due to being the source of a hacked website. That plugin had 30,000+ active installs according to wordpress.org at the time it was removed in late November or early December, as of today it has not been fixed (it isn’t clear if the vulnerability was intentionally introduced or a coding mistake).

Back in July we spotted a vulnerability being exploited in the plugin Form Lightbox, which had 10,000+ active installs. We were not the only ones that had, as it was removed before we got around to notifying the Plugin Directory. That plugin had not been updated since 2013, so the chances of it being updated seemed low at the time, and in fact it still hasn’t been fixed.

WordPress does have another option available to them if they truly wanted to protect people, but don’t want to warn people about unfixed vulnerabilities. They can fix the plugins themselves, they even have the ability force websites to update to the new version. They have done that on very limited occasions. Like much of their handling of security, what the criteria for them doing that are not clear. That would also require more work than simply alerting people to vulnerable plugins, but since they don’t want to do that, it seems like what they should be doing if they truly were interested in keeping people safe. If they become interested in expanding when they do that, we would be happy to help.

Protecting Yourself in The Meantime

Seeing as we are often the ones that report to the Plugin Directory that a plugin has a vulnerability, whether something we discovered or something that was disclosed by someone else, but not reported to them, using our service will get you alerted to most of the vulnerabilities they are likely aware of. You also are provided with an estimate of how likely the vulnerability is to be exploited and we are available to help you make the best decision on what to do if the vulnerability in the plugin has yet to be fixed (maybe you can ignore the vulnerability or maybe we can provide you with a workaround until a proper fix is released by the developer).

Because we don’t want people to be hacked, in the companion plugin for our service we include data on vulnerabilities in plugins we see hackers targeting, so you would have been long ago warned if you were using any of the plugins with vulnerabilities we previously mentioned in this post.

With our service you also get suggest/vote for plugins to receive security reviews by us, so you have better assurance that plugins you use are properly secured.

13 Feb

Applying the Lessons of Recent WordPress Defacements to the Handling of Plugins on Your Website

Recently quite a few WordPress websites (though not as many as the inflated claims by Wordfence and other security companies would have you believe) have been defaced due in large part to improper handling of security by the webmasters of those websites. While an exploitable vulnerability existed in 4.7.0 and 4.7.1, most websites running WordPress 4.7 at the time were protected well before exploitation began due to the fact that the websites were promptly updated to 4.7.2 through WordPress’ automatic background updates, which have been in WordPress since version 3.7. The websites defaced were either ones were those automatic updates don’t work (which from our experience isn’t often) or where people had intentionally disabled them and then failed to promptly manually update.

The lessons from that when it comes to WordPress itself is that you should make sure the automatic background updates are working, not disable them, and that minor updates are the ones that should be applied promptly. Considering that when it comes to a WordPress website being hacked, this is the first time in years that there has been a vulnerability in WordPress has been the source of many hacked websites and plugins on the other hand are a source in a fairly continually basis, how can what happened here be used to take better care when it comes to plugins.

Keeping Plugins Up to Date

The first lesson is keeping your software up to date is critical to keeping the website secure, as vulnerabilities will exists in software for the foreseeable future and new versions will need to be released when they are found. Unless you are going to constantly monitor your website, your best option for keeping plugins up to date is to have the updates applied automatically, like the update to WordPress 4.7.2 would normally have happened. WordPress actually has the ability to do that already, as the automatic background updates functionality has the ability to do all updates automatically, including major WordPress, plugin, theme, translation updates. By default those are all disabled, leaving only minor WordPress updates to happen automatically. One option for turning them on is to use our Automatic Plugin Updates plugin, which enables the functionality for plugins updates, along with the ability to exclude certain plugins from automatically happening and control whether an email is sent out when the automatic update occurs.

You Won’t Always Know About Security Updates

One of the complaints we have seen with the handling the vulnerability WordPress is not enough notice was given. That doesn’t really square with what happened. While this particular vulnerability was not disclosed at the time the new version was released to limit the damage that could be done, it was quite clear that 4.7.2 was security update. The announcement post was titled “WordPress 4.7.2 Security Release” and the post starts out:

WordPress 4.7.2 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.

The announcement originally went on to describe the three other vulnerabilities that were fixed in the version (no non-security fixes were included).

When it comes to plugin updates that fix security vulnerabilities there is good chance that you won’t know that is the updates includes a security fix. Back in December 2014 we looked at the publicly disclosed vulnerabilities that we had in our data set of vulnerabilities at the time and we found that in nearly 20 percent of the time there was no mention made that a security fix was included in the changelog entries for the version that fixed the vulnerability. The severity of vulnerabilities varies widely so the percentage of fixes that go unmentioned alone doesn’t tell the whole story. Take one of the security updates, it involved a vulnerability that was already being exploited prior to a version being released to fix it. The changelog for the version that fixed it read:

The possibility of manipulating custom themes has been removed by request of administration of wordpress.org plugins repository.

Would anyone guess that referred to such a serious vulnerability?

Get Warned About Known Vulnerable Plugins

In the case of the WordPress vulnerability it was quickly fixed after being reported, but our experience of collecting data on numerous plugin vulnerabilities and discovering many of them (including many that are already being exploited), is that many of them are not promptly fixed or ever fixed. As long as WordPress refuses to alert people when they are using plugins they know to be vulnerable, that creates an obvious risk even if you keep your plugins update.

We provide two options to help protect you against such a situation. First is the companion plugin for our service includes in data on vulnerabilities in plugins that we see hackers targeting. Second, by using our service you get access to more complete data, as well support on how best to deal with such a situation. Maybe you can safely ignore a minor vulnerability, maybe we can provide you with a temporary fix until the plugin is properly fixed, or maybe the plugin is completely insecure and shouldn’t be used. Whatever is the case, we will work with you to make the decision for your website. The service also allows you to participate in deciding what plugins will get security reviews done by us, so that you can have better assurance that the plugin you use are properly secured.

For those where our service isn’t in your budget you can get expanded data beyond what is available for free with our plugin by pairing that with a plugin that uses data from the WPScan Vulnerability Database (do a search on the Plugin Directory for “wpscan” to find those). We strongly recommend against relying on their data along since they are missing many vulnerabilities included in our plugin’s data. Not surprisingly considering that they fail to include data that they could easily copy from our plugin, there are several major issues with WPScan data, which makes it a bad option if you can afford our service.

Remove Unused Plugins

Some vulnerabilities are exploitable even if the plugin is deactivated, so if you are no longer using a plugin the best thing you can do is to remove it, as you remove any risk that it introduces.

Security Plugins Won’t Do Much to Protect You

While security plugins makes all sorts of promises about the ability to protect your website, the reality from our testing them against real vulnerabilities in plugins is that they provide little to no protection against vulnerabilities in other plugins. Take a vulnerability disclosed back in December in the plugin Delete All Comments, which had 30,000+ active installs at the time, that was discovered when it was exploited on a website and still hasn’t been fixed. We found that none of the 15 plugins, including all of the most popular ones, protected against exploitation in our test.

The developer of one of the most popular security plugins, BulletProof Security, recently told us that “it is outside of the scope or intended purpose for any security plugins” to protect against vulnerabilities in other plugins.

08 Feb

A Simple Redirection Was Enough to End an Attempt to Exploit Vulnerable WordPress Plugins

We often see security companies try to make hackers sound very scary and sophisticated in what appears to be an attempt to make it more likely that people will purchase their products and services, but the reality is often quite different. While there do seem to be some sophisticated efforts to exploit vulnerabilities in WordPress plugins, including cases where hackers look to be the ones that have discovered vulnerabilities that exist in plugins (for which we are often the ones that then detect that), a lot of hacking attempts are decidedly not that.

In the past we talked about the correlation between what plugin vulnerabilities get exploited and what vulnerabilities there are YouTube videos on how to exploit, which doesn’t really sound like something you would expect from sophisticated actors. In another instances we spotted a hacker incorrectly trying to exploit a vulnerability in a plugin that only 60+ active installs. We recently came across another example of how poor some of the attempts are.

While reviewing the logs of this website to see how often and when there had been hacker activity related to one plugin with a vulnerability in it, we came across a series of requests probing for usage of quite a few WordPress plugins with known vulnerabilities. What is show below won’t necessarily mean much if you are unfamiliar what is shown in log files, but the important element here is that the number 301 included on each of those lines:

192.169.250.35 - - [17/Jan/2017:22:36:58 -0500] "GET /wp-content/plugins/weever-apps-20-mobile-web-apps/static/js/config/wx.tabtypes.js HTTP/1.0" 301 637 "-" "-"
192.169.250.35 - - [17/Jan/2017:22:36:58 -0500] "GET /wp-content/plugins/dop-slider/libraries/js/jquery.uploadify.min.js HTTP/1.0" 301 607 "-" "-"
192.169.250.35 - - [17/Jan/2017:22:36:59 -0500] "GET /wp-content/plugins/developer-tools/js/developer-tools.js HTTP/1.0" 301 587 "-" "-"
192.169.250.35 - - [17/Jan/2017:22:36:59 -0500] "GET /wp-content/plugins/social-networking-e-commerce-1/js/effects.js HTTP/1.0" 301 601 "-" "-"

The significance of that is that 301 in that location indicates that the requester was told that the requested URL has permanently moved to another location. In this case the cause of that is likely that the URLs were requested without the “www.” portion of our website’s address or they were requested using HTTP instead of HTTPS. What should happen next is that a request should be made to the new URL that was sent back with the previous request. That didn’t happen, so if we were using any of those plugins the hacker would not have found out that we were using it and then moved on to trying to exploit it. We don’t use any of the plugins they were probing for, but someone that did could have been saved from being hacked by this. Handling a 301 redirect is relatively basic task when making requests to web pages, so it shouldn’t be something that doesn’t get properly handled in this type of situation.

06 Feb

If You Used Our Service You Would Already Know About the Security Vulnerability That Has Been in Contact Form DB

Back in 2012, years before we started this service we noticed a couple of big problems with how security issues in WordPress plugins were being handled. The first one was that there were many vulnerabilities that existed in the current versions of plugins that had been publicly disclosed, but the plugin remained available in the Plugin Directory. The second was that when a vulnerability in a plugin was reported to the Plugin Directory the plugin was removed from it, protecting any websites not already using the plugin from the vulnerability, but websites already using it were not given any notice of the vulnerability, leaving them vulnerable.

In the present the first problem would likely still largely exist if wasn’t for us making sure that developers and the Plugin Directory are notified when unfixed vulnerabilities are disclosed. The second problem still exists despite it being indicated years ago that a solution would be forth coming, a more recent explanation of why that hasn’t happened doesn’t make sense.

The second problem has recently been a topic of discussion in relation to what has happened to the plugin Contact Form DB, which wordpress.org had recently reported as having 500,000+ active installs. Several weeks ago a persistent cross-site scripting (XSS) vulnerability that existed in the plugin was disclosed. Shortly after that the plugin was removed from the Plugin Directory. At this time the plugin remains out of it, due to the Plugin Directory insisting on further security improvements. While that is the case people have been wondering where it went and then discussing the fact that the current handling of this type of situation leaves people left with no information when something like this happens.

Considering that we suggested letting people have at least a general idea of what is going on years ago, we obviously think giving everyone information on what is going on is a good idea. In the meantime if you are using our service you would already know what is going on, something that would seem to be useful to someone like one of the commenters there, whose comment in part reads:

That would also enable existing users to know that there was a vulnerability and choose to disable or knowingly risk it. As it is now, my agency has hundreds of sites using this plugin and we had no idea there was an issue with it.

One of the ways we keep track of vulnerabilities in WordPress plugins is to monitor the WordPress Support Forums, something we started doing after belated becoming aware of a plugin with intentionally malicious code shortly after we started the service. Through that we became aware of the vulnerability on January 13 and added it to our data on the same day.

Another thing we do as part our service, which others providing vulnerability data on WordPress plugins don’t do, is that we test out each vulnerability, so when the developer released a new version, 2.10.29, that was supposed to fix this, we tested it out. We found that it didn’t fix it, we then updated our data so our customers would know that they were still vulnerable. We also notified the developer of the issue and where in the code the vulnerability still remained (as well as a suggestion for a better fix). A newer version has been submitted to the Plugin Directory that does resolve this, but it currently isn’t available through the normal update mechanism.

For vulnerabilities that haven’t been fixed we are always available to work with our customers to make a determination as to what to do in the meantime. Maybe it is something you can safely ignore, maybe it is something that disabling, but not removing won’t resolve, or maybe we can provide with a workaround (as we could have in this situation).

Other Providers Still Don’t List This Vulnerability

So what if you are relying on another provider of vulnerability data in plugins? You wouldn’t know about this vulnerability. If you get your vulnerability data from another plugin or service it likely uses data from the WPScan Vulnerability Database (the use of their data is not always disclosed) and the vulnerability still isn’t listed in that. That is also true for the plugin CWIS Antivirus Scanner, which uses its own data.

At this point the people behind those could have known about the vulnerability even without doing the extensive monitoring we do, to provide our customers with the best data, as we listed it in our latest monthly post on what was new with the service along with the rest of the vulnerabilities we added last month. That’s a reminder of the lower quality of the data you are going to get if you get your plugin vulnerability data from someone other than us.

31 Jan

Developer of Popular WordPress Security Plugin Thinks It Outside of Scope For Them To Protect Against Vulnerabilities

Back in November we discussed the belief of a developer of a WordPress security plugin with 500,000+ active installs, that it was normal for security plugins to themselves be insecure. While that was fairly incredible to hear, we have just across a belief from the developer of another security plugin, with 100,000+, which we think that tops that.

The developer of the plugin BulletProof Security stated that “it is outside of the scope or intended purpose for any security plugins” to protect against vulnerabilities that exist in other plugins (and based on their explanation of why, it would seem other similar vulnerabilities as well). When you consider that vulnerabilities in plugins are a leading source of WordPress websites being hacked (exploitation of vulnerabilities in WordPress itself being few and far between), that means that relying on this plugin to protect a website will leave it fairly vulnerable to a real threat. The description of the plugin doesn’t make any mention of this intended limitation, which seems like it should be something that is prominently warned about.

Let’s take a step back from that statement, because in how that came about, what is provided is a good example of poor state of the security information surrounding WordPress.

One of things we do to keep track of vulnerabilities in WordPress plugins is to monitor the wordpress.org Support Forum for threads related to those. In doing that we run into a lot of other security threads and occasional we will add our input.

In a thread from someone asking about the security of WordPress, someone suggested using a couple of security plugins:

The terms “secure” and “security” mean different things to different people, and the fact that WordPress is well-written in relation to “security” — no major flaws or vulnerabilities to be exploited — does not mean your self-hosted site is secured by WordPress. I use BulletProof Security to “harden WordPress” and much more…
https://codex.wordpress.org/Hardening_WordPress
https://wordpress.org/plugins/search.php?q=bulletproof
https://www.google.com/search?q=harden+wordpress
…and I also have the stand-alone version of NinjaFirewall out in front of everything at my hosting account:
https://wordpress.org/plugins/search.php?type=term&q=ninjafirewall

There are various other options, of course, but just do not let the idea that WordPress is “secure” lead you to believe WordPress covers your needs related to site security.

We responded explaining that through our testing of them, those two plugins and all the others tested have provided very little to no protection against the exploitation of vulnerabilities in other plugins:

It’s worth noting here that security plugins don’t necessarily provide much, if any, protection against vulnerabilities. We have done fourtestsofthem to see if they could protect against exploitation of real vulnerabilities that existed in other plugins. In only one instance did one, NinjaFirewall (WP Edition), provide protection that wasn’t easily bypassed and that came with the tradeoff that Editor-level and below users could not upload media through WordPress anymore. BulletProof Security provided no protection in any of the tests.

The developer of BulletProof Security responded, but apparently confused us with the developer of NinjaFirewall (WP Edition):

Uh well your opinion is biased. So you should state something to that effect. Also your tests do not include all/every possible BulletProof Security code that is available and the test parmeters seemed skewed in favor of your plugin. Nothing personal, I don’t blame you for using this tactic – just noting facts.

Before we figured that they were confusing us with another company, we were confused about the claims that our testing was skewed.

They then responded again:

Oops. I misread the article. This is not an obvious sales pitch article and link. I reread the article and it is completely unfounded and frankly ridiculous because the test parameters are not any sort of valid security test parameters. I could make up stuff too, but why bother. 😉

Obviously whoever posted that junk does not know anything about website security at all.

Again somehow the testing wasn’t valid (and we don’t know “anything about website security at all”).

Yet another response:

Normally I would just ignore ridiculous junk like this, but in reality this is a disservice to average folks. Why? Because that information is misleading either intentionally or unintentionally due to an unqualified person reporting some junk that just makes people worried about nothing.

This time they called the testing “ridiculous junk”, but still not citing anything that specifically that was wrong with it. The only person at this point that seemed to be misleading people was the developer of BulletProof Security, but the average person would have a hard to knowing that. That is ongoing problem with WordPress security information, as even many of the biggest names don’t understand the basics, but claim and feel otherwise, leading to false information to be spread widely.

After we posted a response they claimed that the testing was “not valid information”:

Oops again. Guess I should have checked WhoIs first. I see that this is your website. Sorry about negating your article, but unfortunately it is not valid information.

But again there wasn’t any specific issue they were pointing to and we were still not sure what they might be referring to.

When they final got to some detail on what was wrong with the testing, it didn’t make sense:

What I question is your test parameters themselves. They seem too general/broad and not realistic. Security plugins are not supposed to block anything that appears to be normal functionality in another WordPress plugin, otherwise security plugins would end up breaking most WordPress plugins normal functionality. So your test parameters need to factor in a realistic attack vector that excludes any normal functionality in any other plugins. There a lot of other things that you also have to factor into the test environment equation that I will not go into. In a nutshell, your test parameters and environment are simply not realistic.

As we responded, what they are really saying is that it is not realistic to test security plugins against real vulnerabilities (including one that looks to have been widely exploited at the time we did the testing):

You are proving our earlier point, as it is hard to distinguish between a request legitimately accessing functionality and exploitation of a vulnerability. Many, maybe most vulnerabilities, involve legitimate functionality being used by someone that shouldn’t have access to it or in a way that it wasn’t intended. The end results is that it would be very hard for security plugins to provide much, if any, protection against vulnerabilities.

Before we had left that response they had left another, which seems like an endorsement of our plugin/service since we actually warn about security vulnerabilities in plugins:

I’ll just use this one test example that you did:

For each of the tested plugin we set up a fresh install of WordPress 4.7, installed the version 2.0 of Delete All Comments, and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

The problem here is that the Delete All Comments plugin has a coding mistake/security vulnerability. Most if not all WP security plugins will not interfere with the normal functionality of another WP plugin for the reason I stated above. So basically the basis of this test is no good. What of course is the only solution is the Delete All Comments plugin would need to fix the bug.

If security plugins are not intended to protect against vulnerabilities, that means they are not doing much to protect you against real threats (security plugins can’t protect against lots of other things, since those involve an attacker having access at a lower level than the plugins run).

Humorously they then were offering to provide us further explanation of why security plugins shouldn’t protect against vulnerabilities:

Yep, I understand where you are coming from, but unfortunately it is outside of the scope or intended purpose for any security plugins. If you would like further explanation then you can contact us here: https://www.ait-pro.com/contact/

27 Jan

Inaccurate Data on What Versions of WordPress Plugins Are Impacted By Vulnerabilities is Now Being Spread

When it comes to improving web security, whether it relates to WordPress or not, a big impediment we see to that happening is that it is very easy for inaccurate information to be spread. Oftentimes it is done by security companies, that either don’t know what they are talking about or who find that inaccurate information is useful for marketing their products.

A recent example of this relates to something we discussed back in September. Back then we came across a page that had a list of vulnerable plugins and it was suggested that you check over the list to see if you were using any. What the list seemed to be more of at the time was an attempt by the company behind it to promote their security plugin, Security Ninja. We say that because at the time the list was almost, if no entirely, just the free vulnerability data we include with the companion plugin for our service, which it would be much easy for people check for by installing the plugin instead of reading through a list.

One of the things that made it rather obvious that our data was the source of the list was that for each vulnerability they listed the impacted versions of the plugin, which they referred to minimum and maximum affected versions. That data appears to be something that only we generate, so unless they were also doing that themselves, we must have been the source.

Knowing what versions are impacted can very helpful when dealing with a hacked website, as many vulnerabilities only impact a limited number of versions (in a couple cases last year vulnerabilities that were widely exploited only impacted a single version of the plugin). With other data sources they will usually say that a vulnerability impacts a certain version and all versions below that, which could lead someone cleaning up a hacked website with out of date plugins to think that there was a vulnerability that didn’t exist on the website and cause them to miss the actual source (possibly leading to the website getting hacked again).

We recently came across the page again and found that there had now been vulnerabilities added to the list that didn’t come from our data. For those we expected the minimum and maximum vulnerable versions would not be listed, since they wouldn’t be available for those. But to our surprise there were versions listed. The problem, they are the wrong versions.

Take for example a file deletion vulnerability we discovered in the plugin Post Grid, which impact versions 2.0.6 through 2.0.12 of the plugin. The vulnerability is listed on the page, but a little differently, it listed as being an unauthenticated arbitrary file deletion, which likely indicates their knowledge of it came from the WPScan Vulnerability Database as that is how the vulnerability is listed in their data. On the page the minimum version is listed as 2.0.12 and the maximum version is listed as 2.0.13. That clearly isn’t right and doesn’t match WPScan’s data either, since they list the vulnerability as impacting versions “<= 2.0.12” and being “fixed in version 2.0.13”.

So what is going on? The answer seems to be that either they don’t know what they are doing at all or they don’t care; they are listing as the minimum version the last version that was listed vulnerable and as the maximum version the version that was listed as being the one that included a fix for the vulnerability. As another example of this, take a look at the listing for a unauthenticated change passwords vulnerability Ultimate Member, which look to come from WPScan’s data. They list the minimum version as being 1.3.75 and the maximum version as being 1.3.76, whereas WPScan’s data lists it as impacting versions “<= 1.3.75” and being “fixed in version 1.3.76”.

So if you were using their data you would think that versions that are not impacted are and versions that are impacted are not, which is a bad thing.

Even if they were using the data on which versions were impacted from other sources correctly there is another problem, we often find that vulnerabilities have not actually been fixed despite the belief by the plugin’s developer and the discoverer of the vulnerability (and even in some cases, the Plugin Directory). Since we actual test each vulnerability out, we can provide accurate information on which versions are vulnerable and let you know if you are using a vulnerable version.

At beginning of this post we mentioned how easy it is for inaccurate information to spread, in this case the page allows you to tweet out the message “Check if you are risking your site by using hacked & dangerous #wordpress #plugins.”. If you do a search on Twitter for the beginning of that message you can see that has happened quite a few times.

24 Jan

Wordfence Security Still Doesn’t Protect Against Plugin Vulnerability More Than 30 Days After It’s Developer Became Aware of It

When it comes to the poor state of web security a lot of the blame for that can be placed on the security industry. The security industry is terrible in many ways, but one of the most troubling ones we have seen from being in it, is how often security companies are not telling the truth. Trust is an important part of security and the public is largely relying on the companies to be truthful about the protection they provide, since few in the public (and few at security companies) would have the ability to tell if the claims were truthful.

When it comes to WordPress security, one company that we have repeatedly seen saying things that are not true is Wordfence, the company behind the most popular security plugin Wordfence Security. One example of this we found was their claim that they provide “protection from the latest threats” through “unmatched access to information about how hackers compromise sites”. What we have repeatedly found is that they (and every other security company) are unaware of vulnerabilities that are in the current version of plugins and being exploited. We know this because we have found those vulnerabilities and taken action to protect the public against them. More striking is that we found many by just monitoring our few websites, where Wordfence’s claim is tied to being involved with over 1 million websites, so either they are not doing what they claim to be doing or they are completely incompetent, neither which should be true about a company behind such a popular product.

As we discussed a month ago, how Wordfence promotes their plugin is false even in relation with other claims they make.

On WordPress’s Plugin Directory page for the Wordfence Security plugin the description of it begins:

Secure your website with Wordfence. Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

And later states that:

Wordfence Security is 100% free and open source. We also offer a Premium API key that gives you Premium Support, Country Blocking, Scheduled Scans, Password Auditing and we even check if your website IP address is being used to Spamvertize.

But as we mentioned in that post:

Despite that, it turns out that unless you are not using Wordfence’s paid service you actually can easily get hacked (and even with that you are left vulnerable to their slow response to vulnerabilities). You don’t have to take our word on that, Wordfence admitted to that fact yesterday.

You see, when they add protection against a vulnerability they only provide protection for their paying customers at first and they claim that after 30 days they provide it to non paying users of the plugin. That would mean for the first 30 days if you are using their plugin and not their paid service you are not protected, which is in direct contradiction the claim that the plugin “stops you from getting hacked”. For the vulnerability in Delete All Comments that we were discussing then, it turns out that isn’t even true.

The protection for the vulnerability in Delete All Comments should have been provided to the public on January 15, as Wordfence belated started providing protection to their paying customer against the vulnerability December 16.

We were curious to see how robust their protection would be against the vulnerability, due to something we noticed when we tested 15 security plugins ability to protect against the vulnerability back in December and found that none of them protected against it. That was surprising for one of the plugins, since it was from the company that discovered the vulnerability while cleaning up a website that had been hacked due to it and they said that their plugin provided protection. When we went to see what was going on we found that it did protect against exploitation if you tried to exploit the vulnerability in a different way then we tried. So we were curious to see if Wordfence Security did a better job or not.

When we tried to do that today we found that Wordfence Security still doesn’t protect against the vulnerability, so either the Wordfence hasn’t provide firewall rule to free users of the plugin as they claimed they would by now (it looks like that is the case) or the rule doesn’t work. Considering that the vulnerability has still not been fixed and is being exploited pretty widely that obviously is a big issue and likely lead to websites getting hacked that wouldn’t if people used better solutions, like our plugin, which even if you are not using paid service, has been warning about the vulnerability since December 12 (it similarly warns for other vulnerabilities that we see being exploited).

11 Jan

A Case For WordPress Providing Details on Fixed Security Issues in Plugins

When it comes to providing information on security issues in web software the amount of information disclosed varies pretty widely. For WordPress security issues fixed in the core they are disclosed when the new version is released. For example, here is how they were mentioned in the most recent security release, 4.6.1:

WordPress versions 4.6 and earlier are affected by two security issues: a cross-site scripting vulnerability via image filename, reported by SumOfPwn researcher Cengiz Han Sahin; and a path traversal vulnerability in the upgrade package uploader, reported by Dominik Schilling from the WordPress security team.

For plugins, which are developed by third-parties, no information is released by WordPress. That isn’t the way that everyone handles the situation. TYPO3, for example, releases security bulletins, including for third party extensions.

In the past we have discussed the issue of WordPress keeping everyone in the dark about security issues in the current version of plugins that they are aware of. While they do remove those plugins from the Plugin Directory, that does nothing for those who are currently using them. Something we recently ran across seems to make the case that providing information on security issues that have been fixed could be useful as well.

It starts with a review from three weeks ago that we ran across recently, as part of our monitoring of the wordpress.org Support Forum for mentions of plugin vulnerabilities, for the plugin Menu Image that claimed that “Plugin applies malware/addware to your site.” The review stated that:

I just wanted to post a warning about this plugin. I have noticed various malicious scripts being added to one of my sites. After countless hours of tracking I found that Menu Image was the problem code. There seems to be an exploit or hole in your code.

We often run across reviews with claims that a plugin is the source of hacking where it is either unsupported by any evidence or where a quick check of the plugin shows that plugin could not have been the source of what happened to the website.

Others responded that they were having the same issue.

The developer responded in a way that wouldn’t seem to be appropriate even if the claim was totally false:

Please, disable the Menu-Image plugin and remove it from your wordpress site at all and never use it in future. I think this will not solve your problem. All plugin code you can check here: https://github.com/zviryatko/menu-image, compare it with that you have.

The reality is that the plugin was in fact the cause of this, something the developer was likely aware of (and certainly should have been), but also something the WordPress was in all likelihood also aware of.

If you read through all the responses on the review the cause of malicious JavaScript is a file notice.php that existed in some versions of the plugin.

What the legitimate purpose of that file was supposed be, if any, isn’t clear. The changelog entry for the version it was added in simply states “Add notification plugin.”

In a support forum thread five from months ago where someone asked why the noticed.php file was connecting to domain apistats.net the developer responded with this:

Yes, there is a strong reason for that, it’s help to make plugin work much better, also there’s no security issue, you can check the code by yourself. When you installed the plugin you saw the license agreement and you accepted it.

How it was supposed to make the plugin work much better isn’t explained.

Checking the code would just tell that it is making a request to that domain, it doesn’t explain why and wouldn’t show what would get served from that (according to one of the responses to the review malicious code was only served from that domain for part of the day).

The fact that there is a license agreement seems like a red flag, looking at what you actually get shown makes things seem even shadier, as you could easily think you are just agreeing the GPL:

The last response in that thread is from the developer, who indicates that the people on the WordPress side of things were aware of a security issue with the file:

Hello, I’ve removed all that code, when plugin will be approved by wp.org security team, it will be back again!

When the issue was resolved the changelog entry stated “Remove notification plugin. It was not a good idea btw.”, which wouldn’t give any one an indication what had really happened.

If WordPress had provided security bulletin on the issue after it was fixed it would have helped to clear up for people that dealt with this what was going on without them having to do a lot digging themselves. As this case shows relying on developer to provide that type of information isn’t always going to work out.

21 Dec

Wordfence Is Leaving Sites Relying on Their Plugin Vulnerable to Unfixed Vulnerability That They Know is Being Exploited

On WordPress’s Plugin Directory page for the Wordfence Security plugin the description of it begins:

Secure your website with Wordfence. Powered by the constantly updated Threat Defense Feed, our Web Application Firewall stops you from getting hacked.

And later states that:

Wordfence Security is 100% free and open source. We also offer a Premium API key that gives you Premium Support, Country Blocking, Scheduled Scans, Password Auditing and we even check if your website IP address is being used to Spamvertize.

Despite that, it turns out that unless you are not using Wordfence’s paid service you actually can easily get hacked (and even with that you are left vulnerable to their slow response to vulnerabilities). You don’t have to take our word on that, Wordfence admitted to that fact yesterday.

Before we get to that, let’s provide you with some important background information. On November 20 the security company NinTechNet discovered that the WordPress plugin Delete All Comments had an arbitrary file upload vulnerability, which allows a hacker to upload any file they want and through that they can do almost anything they want with a website. They discovered that while cleaning up a website that was hacked through that vulnerability (unlike so many security companies they actual did the important step of trying to determine how the website was hacked). They contacted the developer of the plugin and didn’t get a response. Subsequently they notified the Plugin Directory and the plugin was removed from that. The vulnerability has yet to be fixed, so anyone still using it is vulnerable to being exploited.

On December 10 NinTechNet publicly disclosed the vulnerability. We then added it to the data for our service. We put out a new version of our service’s companion plugin with the vulnerability added to the free data included in it on Monday, the 12th, so those not using our service yet started getting warned about the issue (WordPress really should be warning about this, but their position is that doing that would put people at more risk). On Monday we also started seeing what looked to be hackers probing for usage of the plugin, so it looks like more widespread exploitation of the vulnerability probably began then as well.

Then on Friday we did a test of 15 security plugins, including Wordfence Security, to see if they would prevent the vulnerability from being exploited. This would be a situation where a security plugin could provide some value, since even if you keep your plugins up to date, you would still be vulnerable since the plugins hasn’t been fixed. The result was that none of the plugins provided any protection.

That wasn’t the only instance where Wordfence security wouldn’t stop you from being a vulnerability from being exploited, in five previous test we have found that it provided no protection in three and the protection was easily bypassed in the other two (many of the other plugins we have test have provided no protection in any of test they were included in).

Against those results a recent posting on Reddit by them stood out, they wrote:

I’d say about 2 years ago I would not have been comfortable running WordPress even with Wordfence on a mission critical site where data theft is a disaster.

Today that has changed and there is one thing that changed it: Our firewall. Back when I wrote and launched the code for Wordfence myself (in 2011) we didn’t even have a firewall. We launched a full blown firewall some time ago and it’s now evolved to the point where I’m completely confident that if you install our firewall and are running WordPress, you are going to be much more secure than if you’re running an alternative product, even if that alternative CMS is behind a firewall.

and

So if you run our firewall I’m 100% confident you can run WordPress securely on a large mission critical production site. We’re doing it ourselves for wordfence.com along with several other major sites we run. All use our firewall.

We responded pointing to the results of our testing that showed the reality is their product doesn’t live up those claims.

Their response to that is rather troubling.

In regards to the vulnerability in Delete All Comments they only did anything about it on December 16:

We developed a firewall rule for that exploit and released it into production on December 16th, the moment we heard about it from our users. That’s a screenshot from our internal Slack. It’s a fun read – shows what a great place Wordfence is to work.

They also only became aware of because of their users, so they are not actively monitoring for information on vulnerabilities in plugins. We were not the only ones that noticed the disclosure before then, it was included in WPScan Vulnerability Database on December 11.

Later in the post they claim that:

As you can see, the team responds very quickly.

Which is the opposite of the truth.

But now people using their plugin are protected right? No:

The rule is now in production for Wordfence Premium. It will only be available in the free Threat Defense Feed 30 days after release, so around Jan 15th.

So they know that vulnerability is already being exploited, since that is how it was discovered, but they are leaving people that use their plugin, but not also their paid service, vulnerable for a month.

Update (1/24/2017): More than a week after the rule was supposed to be available to those using the plugin without their service, we found that the Wordfence Security plugin still doesn’t protect against the vulnerability, so the claim the rule would be available to those using just the plugin after 30 days turned out to be false (or less likely, the rule isn’t effective at all).

They then went on to try to downplay this by claiming the plugin was not very popular twice (emphasis ours):

FYI, that plugin was pulled from the repository and is no longer available. It wasn’t very popular when it was in the repo.

We deploy rules for vulnerabilities and their exploits the moment we hear about them or see them exploited in the wild. That just wasn’t a widely exploited vulnerability or a popular plugin. In the case of the vulnerability above, we heard about it because you were making some noise about it. Our users alerted us.

So what do they consider to be an unpopular plugin, one that as of a month ago had 30,000+ active installs.

We would consider that popular. So does WordPress, as the Popular section of the Plugin Directory currently includes plugins with a 10,000+ active installs.

It turns out that not that long ago so did Wordfence. In a post written in November of last year,  New Vulnerabilities in 6 Popular WordPress Plugins, one of the 6  popular plugins had 30,000+ active installs. It went even lower than that. One of the others had only 2,000+ active installs. Did they really radically change their view of what constitutes a popular plugin in 13 month or does their view change to fit the narrative they are going with?

Also worth noting in that is this portion “We deploy rules for vulnerabilities and their exploits the moment we hear about them or see them exploited in the wild”. So their protection relies on them being aware of vulnerabilities, which is fairly big problem since we have repeatedly found that Wordfence is unaware of vulnerabilities despite them promoting their Real-Time Threat Defense Feed as giving them “unmatched access to information about how hackers compromise sites”.

What You Should Do If Use Wordfence Security

The best case we see with Wordfence is that they don’t have a good understanding of security, which leads them to repeatedly make false claims. That probably isn’t a good base for creating a good security plugins, which makes the fact that it is the most popular WordPress security plugin with 1+ million active installs problematic (the plugin even has been found to have vulnerabilities of its own in a number of instances). It then wouldn’t be all that surprising that they would make claims about their plugin,like we mentioned earlier in the the post, that don’t match reality.

A worse case scenario is that they are intentionally misleading people to push their plugin and service. Take an example last week where they claimed that there was a recent increase in brute force attacks against WordPress admin password and of course the way to protection yourself against them is to use their plugin. The problem with that being that brute force attacks are not happening. What looks to be going on are dictionary attacks, which involved trying common passwords and can be protected against by simply by using a strong password, no security plugin needed.

Given that, avoiding their plugin could help to attract more people to plugins and companies that have a better handle on security, leading to improved WordPress security.

Beyond that, getting warned when you are using a plugin with a vulnerability that is being exploited would be a good idea. As we mentioned earlier the WPScan Vulnerability Database has included since before Wordfence even became aware of it, so using a plugin that uses their data would do the trick in this instance (if you do a search for “wpscan” on the Plugin Directory you will find a number of those plugins).

As we have discussed in the past though the WPScan Vulnerability Database doesn’t always do a good job of included vulnerabilities in their data (among other issues). That is where the companion plugin for our service can come in. Last week in addition to adding the vulnerability in Delete All Comments to the free data included with that, we added vulnerabilities that were likely being exploited in the current versions of a plugin with 20,000+ active installs and another with 40,000+ active installs (this one has now been fixed). Neither of those are currently included in WPScan’s data, despite us publicly disclosing them at the same time we added them to our data for the service and in the plugin.

If you want more comprehensive information on vulnerabilities in plugin you use can sign up for our service. With that you get information on not just vulnerabilities that are already being exploited, but all vulnerabilities being discovered whether by others or by us (as well as rating on the likelihood of the vulnerability being exploited).

You also get support, so if you run into a situation where you are using a plugin that has yet to be fixed we can help you to make the best decision on handling that. In some cases you can safely ignore the issue, in others we can provide you with a workaround, in others the best option might be to stop using the plugin.

To help keep it from getting to situation where vulnerabilities are first discovered when they are being exploited our paying customers get to suggest and vote for plugins to get a security review done by us.

Finally, by using our service you are helping to improve to the security of WordPress plugins for everyone, as the work we do for the service helps to get numerous vulnerabilities, including many that were already being exploited, fixed for everyone.

Currently you can try the service for free for a month.