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:

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()):

// 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.

11 Apr

Not Every Report of a WordPress Plugin Vulnerability Involves a Real Vulnerability

In our dealing with hacked websites we have recently been working with quite a few people that have come to us after trying to do some work to figure out the source of the hack themselves. They will bring up that they have found reporting that software on the website has had vulnerabilities and those might have been the cause. In reality most of those vulnerabilities have very little chance of being the cause of a website being hacked in general and in some cases they have no chance since the vulnerability didn’t actual exist.

Narrowing down what vulnerabilities could be a possible cause of a website being hacked is good use of our service (and then going forward, getting ahead of vulnerabilities in your website’s plugins by having them reviewed for security issues by us and getting notified of if vulnerabilities are discovered in the version of them you are using).

One of the pieces of data that is uniquely included in our data is an estimation of how likely a vulnerability is to be exploited, which is largely based on our years of experience dealing with hacked websites.

Another couple of important aspect of what we uniquely do when it comes to WordPress plugin vulnerability data is weeding out false reports of vulnerabilities, so you only have to look through real vulnerabilities, and letting you know which versions are impacted (as vulnerabilities can impact as little as one version of a plugin, so outdated version in use on a website might not be vulnerable).

We just ran across a good example of false report of a vulnerability, which involves the plugin Spider Event Calendar (Calendar by WD). A report was released claiming that plugin contained a blind SQL injection vulnerability that could cause:

Public defacement, confidential data leakage, and database server
compromise can result from these attacks. Client systems can also be
targeted, and complete compromise of these client systems is also possible.

While that sounds scary and likely to lead to a website being hacked, the reality is that this type of vulnerability would usually only allow slowly reading out the data from a website’s database and we don’t see that being used by hackers on a wide scale at this time. It could be used in a targeted attack and would be of great concern if sensitive data was stored in the database in that situation.

What makes this false has to do with how the issue could be accessed. The report states that:

To exploit the vulnerability only is needed use the version 1.0 of the HTTP
protocol to interact with the application.

In reality the page where the report states the request would be sent to is only accessible to those who are logged in as Administrators (technically those with the manage_options capability, but usually only Administrators have that capability). Administrators normally have the ability to edit plugins, so they could remove any protection against this issue, and the ability to add plugins, so they could add a plugin that allows them to more easily access the data in the database than this issue would permit. While it would be accurate to call this issue a bug, calling it a vulnerability doesn’t seem accurate. If someone has access to an Administrator account then the website likely has much bigger issues than this as well.

It doesn’t look like the omission that accessing this issue requires being an Administrator was unintentional, as we previously interacted with person behind this report to point out that another claimed vulnerability not only required being an Administrator, but involved taking an action they would normally be specifically permitted to do. They stated they were aware that it was only accessible to Administrators, but apparently didn’t feel the need to note that. When they later released a report on the claimed vulnerability they left out any mention that it required being logged in as an Administrator as well.

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: - - [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 "-" "-" - - [17/Jan/2017:22:36:58 -0500] "GET /wp-content/plugins/dop-slider/libraries/js/jquery.uploadify.min.js HTTP/1.0" 301 607 "-" "-" - - [17/Jan/2017:22:36:59 -0500] "GET /wp-content/plugins/developer-tools/js/developer-tools.js HTTP/1.0" 301 587 "-" "-" - - [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…
…and I also have the stand-alone version of NinjaFirewall out in front of everything at my hosting account:

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.