28 Apr

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

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

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

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

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

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

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

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

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

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

For problem two, we actual already do this.

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

27 Apr

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

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

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

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

  • Woocommerce 3.0.4 compatibility added
  • Fix – Fixed PopUp issue

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


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


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


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

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

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

25 Apr

Be Wary of DefenseCode’s Advisories

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14 Apr

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

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

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

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

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

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.

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.