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.

15 Dec

When a Security Company Does the Right Thing and The WordPress Plugin Directory Drops the Ball

Due to how bad the security industry is we rarely have the ability to point to a situation where the a security company has done the right thing, but today we have one to discuss.

Yesterday, we discussed how security companies rarely do one of the three basic components of a proper hack cleanup, which is to try to determine how the website was hacked. As we mentioned in that post, in instances where that isn’t done we are frequently brought in to re-clean the websites after they get hacked again. The problem of not determining how the websites are hacked doesn’t always just impact that website, if the vulnerability exploited exists in the current version of software on the website then spotting an early exploitation has the possibility of limiting the amount of additional websites that get hacked due to it. That possibility occurred with an arbitrary file upload vulnerability that exists in the WordPress plugin Delete All Comments. On November 20 the security company NinTechNet was looking into a hacked website and found the website was hacked due to that vulnerability. It wasn’t all that hard to spot with the combination of the logging and the code in the plugin, but since so many security companies don’t even try to determine how the websites they are cleaning up have  been hacked, something like that can easily get missed.

The vulnerable code was introduced in version 2.0, which was the first release put out by a new committer and that lead someone that mentioned the vulnerability to us, to believe this might have been intentional. To us it also looks like something that could have happened when someone writes code without having a good grasp of the security implications of what they wrote.

After NinTechNet spotted this they did the following:

The author was informed on November 20th but did not respond. We contacted the WordPress plugin department and the plugin was removed from the repository the same day.

On Saturday they publicly disclosed the vulnerability. Subsequent to that we added it to the service’s data and added it to the free data that comes with the service’s companion plugin on Monday, so even those not using the service yet could have gotten notified of the issue (if you haven’t installed the plugin, now would be a good time to do that).

Looking at the logging from our websites and the third-party data we monitor we don’t see any evidence of wide scale attempt to exploit this until Monday. So between when NinTechNet came across this and that there was a chance for the WordPress Plugin Directory to mitigate the threat from this when the developer didn’t.

The easier thing they could do is to start warning people when they are using vulnerable plugins that have been removed from the Plugin Directory, but they are refusing to do that on the basis that it puts people at more risk. As we discussed before that doesn’t make much sense as hackers can still figure out that the vulnerabilities exist even if they keep quiet about it.

The other option would be for them to put out a new secured version of the plugin, which they have the ability to do. They even have the ability to have the update to that version of the plugin happen automatically, in the same way that minor WordPress updates now occur automatically (and in the same way all plugin updates can happen with our Automatic Plugin Updates plugin). Like a lot of security related items involving the Plugin Directory, the process for deciding to release a secured version is rather opaque. In one instance when we tried to raise the issue over the lack of this happening on the wordpress.org Support Forum our post was deleted without explanation and the plugin being discussed was never fixed. If they decide to improve the situation we would love to help with it.

Instead they did neither, leaving everyone using the plugin vulnerable.

Until WordPress gets better about this you can help protect your website for free by installing the service’s companion plugin and installing one of our other plugins that lists plugin you are using plugins that have been removed from the Plugin Directory. For those with the budget you can sign up for our service, where you get data on all plugin vulnerabilities, not just ones that are already being exploited, and you also have the ability to suggest and vote for plugins to have a security review done by us, which could help catch more security vulnerabilities in plugins before they have a chance to be exploited by hackers.

06 Sep

Yet Another Very Vulnerable Plugin Returned to The WordPress Plugin Directory Without Actually Being Fixed

When it comes making sure that vulnerabilities in WordPress plugins get fixed we play important role in making that happen, but we are having to play an outsized role because others are not doing their part, which has once again lead to websites remaining vulnerable to being hacked for much longer than they should have been.

One of things that we do to provide the best data on vulnerabilities in WordPress plugins to our customers is that we monitor our websites and some outside data sources for evidence that hackers are targeting plugins. In many case the evidence doesn’t itself give any indication of what the vulnerability the hacker is targeting, just that the hacker is looking for usage of the plugin by requesting a .css or .js files in the plugin’s directory. From there we try to determine if the hackers is targeting a previously known vulnerability or there is a vulnerability that exists in the current version that hacker could be targeting. Through that work we have found numerous vulnerabilities included many that it looks like hackers have known and been exploiting for months and sometimes longer. What we found fairly troubling about this is that we look to be the only security company doing, even though at least one other would certainly like you to think they are.

That brings us to our recent discovery of a persistent cross-site scripting (XSS) vulnerability in the WP-Piwik plugin. While combing through data from one of the outside data sources we monitor, we came across the possibility that a hacker had been targeting the plugin back in January. In looking over the plugin for the kind of vulnerability that hackers might exploit (many types of vulnerabilities are unlikely to be targeted by them), we noticed that anyone could change the plugin’s settings. The potential damage that could be done using that depends on what impact the plugin’s settings can have on the website. In this case, the settings could be changed to load JavaScript on the website’s page and that in turn could be used to serve malware on them. This isn’t a hypothetical issue as in February of last year, this type of vulnerability was exploited on a large scale to serve malware on websites using the Fancybox for WordPress plugin.

Once we had found the vulnerability we quickly notified the developer of the details of the issue, suggested they may want to request to have the plugin automatically updated after being fixed, and let them know that if needed any help in dealing with it, to get back to us. Two weeks went by without any response or the vulnerability being fixed. At that point we disclosed the vulnerability, added it to the data that comes with our service’s companion plugin (so that even those that don’t use the service would get alerted), and notified the Plugin Directory of the issue.

A short time later the plugin was removed from the Plugin Directory, which protected those not already using the plugin from being exposed to the issue. Those already using the plugin were left in the dark since WordPress continues to refuse to alert them in such a situation.

Two days later the plugin returned the Plugin Directory with a new version, 1.0.10, that was supposed to fixed the vulnerability, but didn’t. As those that follow our blog would already know, the WordPress’ failure to properly check over plugin’s before returning them to the directory has been an ongoing issue. In some cases you could excuse it to some extent because it would easy enough to think the vulnerability was fixed, like one situation where the code to fix the vulnerability had been added, but was one line below where it needed to be to function properly. In this case the new code was not what you would have expected to fix this, so thorough checking should have been done, but it doesn’t look like it was.

The attempted fix involved adding an additional check before saving the settings. In the function that checks if a settings change is include in the request before those changes can be applied, isConfigSubmitted(), an additional check is done by calling a new function isOptionsPage(). The function isConfigSubmitted() in 1.0.9:

617
618
619
private function isConfigSubmitted() { 
    return isset ( $_POST ) && isset ( $_POST ['wp-piwik'] ); 
}

The function isConfigSubmitted() in 1.0.10:

617
618
619
private function isConfigSubmitted() { 
    return self::isOptionsPage() && isset ( $_POST ) && isset ( $_POST ['wp-piwik'] ); 
}

The isOptionsPage() function is intended to check “if current page is WP-Piwik’s option page” by comparing two values:

1243
1244
1245
1246
1247
public static function isOptionsPage() { 
    require_once(ABSPATH . 'wp-admin/includes/screen.php'); 
    $screen = get_current_screen(); 
    return $screen == self::$optionsPageId; 
}

When we tried our proof of concept (included in our post about the vulnerability) we found that this check didn’t stop the exploitation of the vulnerability. The reason for that is that two values being compared are empty and therefore the same.

We notified the developer of the issue along with a suggestion on how to properly fix the issue, they responded shortly afterward and two days later version 1.0.11 was released, which fixed the issue.

The fixed involved using another new check in the isConfigSubmitted() function by calling the isValidOptionsPost() function:

617
618
619
public static function isConfigSubmitted() { 
    return isset ( $_POST ) && isset ( $_POST ['wp-piwik'] ) && self::isValidOptionsPost(); 
}

The function isValidOptionsPost() checks to make sure that request is coming from someone who should be able to make changes to the settings, by checking current_user_can( ‘manage_options’ ), and that they intended to make the changes, by checking check_admin_referer( ‘wp-piwik_settings’ ), to prevent against cross-site request forgery (CSRF):

1243
1244
1245
public static function isValidOptionsPost() { 
    return is_admin() && check_admin_referer( 'wp-piwik_settings' ) && current_user_can( 'manage_options' ) ; 
}

WordPress Needs to Improve

The developer could have improved the situation by responding quicker and getting back to us the first time we contacted them so we could have worked together to come up with a proper fix instead of requiring two releases to make that happen. But since developers are not likely to running into situation like this very often, trying to improve things by focusing on them seems to be difficult. Instead the people behind WordPress who deal with this type of issue on an ongoing basis seem to be the better are to focus to improving the situation. What exactly needs to be done isn’t clear because their handling of vulnerable plugins is rather opaque (making it less opaque could be starting point for fixing not only this, but other issues with the process). Maybe there needs to additional checking done before returning a plugin or maybe there needs to be a better understanding of how to checks thing over by the people already doing that. Whatever the case, we would be happy to help them, since getting these vulnerabilities fixed as quickly as possible is our goal.

17 Aug

WordPress Doesn’t Fix Severe Vulnerability in Plugin And Doesn’t Want To Have An Honest Discussion About the Issue

Recently we have been having an issue where someone (or someones) that has the ability to edit and delete post on WordPress’ support forum had been doing those things to some of our posts on their support forum. Last week discussed on such instance where that look liked an attempt to cover up the fact that WordPress has an ongoing problem where plugins they know contain a vulnerability that have been removed from the Plugin Directory due to that, then return to it without the vulnerability being fixed. Over at our main blog we discussed that it appears that whomever is doing it doesn’t want the public to know what is going, as in another instance they also deleted a reply to a post of ours that just thankedus for the information we provided, which if it remained, would have made it obvious that a post from us had existed and had been deleted. While preparing to write this post about the issue of WordPress’ handling a vulnerability in a plugin that appears to have been abandoned, we noticed that another such instance of a deletion that looks like an attempt to cover up yet another piece of WordPress’ current poor handling of vulnerabilities in plugins.

On July 17 we saw requests for a .css file from the plugin Form Lightbox across our websites. That is usually an indication that a hacker is probing for usage of the plugin before trying to exploit a vulnerability in it. Seeing as the requests hit all of our websites, that pointed to there probably being a large campaign to exploit something in the plugin. After noticing the request we started trying to figure out if there was a vulnerability so that we could add it to our data and see what we could do about getting it fixed. We quickly found an option update vulnerability in the plugin, which would allow anyone to change WordPress’ options (settings). One possible way that could be exploited is to turn on user registration and set it so that new users had the Administrator role, giving the attacker the ability to do almost anything on the website. Later in the day the plugin was removed from the Plugin Directory, so at least one other person had noticed the issue and notified the Plugin Directory before we had done so.

On July 20 a post was started on the support forum for WordPress, Plugin disappears from repo as vulnerability is revealed?. The original post was later edited, but from a cached copy here is how it read (the bolded portions were later removed by someone else with the ability to do that):

Hi,
Is there any rules about triaging security vulnerabilities in plugins?

I was a fan of Form Lightbox {DEAD LINK}, a simple plugin that let you embed a form in a lightbox.

According to Google’s cache, it was still available on 16/7, 2 days before this was published:

https:// www.pluginvulnerabilities.com/2016/07/18/option-update-vulnerability-in-form-lightbox/

There’s a giant security hole in the plugin. I’ve had 4 sites exploited using it. A simple google search reveals a number of others that have been bitten.

If WordPress.org pull the plugin (in line with the disclosure practices of pluginvulnerabilities.com) , and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

Otherwise, those affected are left high and dry (until they find out how their sites are being pwned, by other means).

The “WordPress.org Tech Dude” responded:

If WordPress.org pull the plugin, and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

If we pull the plugin for security reasons, then the author usually patches it. If it’s severe enough, we may patch it ourselves after an author does not respond. This is handled on a case by case basis.

After noticing the thread through our monitoring of the support forum for vulnerability related issues, we saw that there were a number of problems with that reply, which we address in a reply that was deleted some time later:

Seeing as we are the people that are reporting many of the vulnerabilities to the Plugin Directory that cause plugins to be pulled, we can say that the reality is that plenty of those plugins never get fixed. In other cases they are not fixed in a timely manner. Also, in some cases you guys put the plugin back in the Plugin Directory even though the vulnerabilities have not actually been fixed, including a recent case where it looks like a hacker had been exploiting a plugin prior to it being removed from the Plugin Directory.

In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this. Not only does the plugin have an easily exploitable vulnerability, but it appears that a hacker is already exploiting it. That is how we became aware of the issue in the first place.

As mentioned in the post cited above, the plugin was removed before our post was released, so the post’s release had nothing to do with the plugin being removed.

If you used our Plugin Vulnerabilities plugin you would have been warned about this vulnerability a couple of days ago, since we include data on vulnerabilities in plugins that have hacking attempts against them in the free data included with that plugin.

There was never any reply to our reply, so it seems that no one from the WordPress side wanted to dispute anything we had said in it. They then could have taken it as wake up call that things need to be improved (something we would happy to help them with). Instead at some point later our post was completed deleted without any notification to us that it in some way violated any policy on the forum. What has happened with the plugin since then, shows that, not surprisingly, trying to cover up things in this way doesn’t actually deal with the issue.

If you go to the plugin’s page on the Plugin Directory now you will see that it is still removed (the message mentioning that it has been removed in the screenshot was added to the page by the Plugin Vulnerabilities Chrome extension):

form-lighbox-plugin-directory-page

That doesn’t always mean that nothing has been done, as from what we have seen from checking on what is happening with other plugins with vulnerabilities is that there can sometimes be a significant delay between the developer submitting a new version to the underlying the Subversion repository and the plugin returning to the Plugin Directory (probably due to some review of the fix needing to occur first). In this case though, the most recent change to the plugin remains one from three years ago:

form-lightbox-development-log

As we mentioned in our reply in that post, “In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this.”, so if WordPress is going to patch severe vulnerabilities when the plugin’s author this seem to be one where that should have happened. That means that for the 10,000+ websites using the plugin (according to wordpress.org, as of the time the vulnerability started being exploited) are left without a secured version to update to. We don’t think that WordPress necessarily should be expected to fix any vulnerabilities in plugins, but what they should at least do is notify those using plugins that they are vulnerable. That is something that they could have done long ago, but they continue to refuse to do it on the basis that it would put websites at risk, which doesn’t make much sense in case like this, where a hacker is already exploiting the vulnerability on a large scale and others are able to easily identify an exploitable vulnerability in the plugin.

16 Aug

WordPress Keeping The Public In The Dark About Plugins They Know Are Vulnerable

One of the key pieces of advice for keeping your WordPress website secure is to keep your plugins up to date, since that prevents the possibility of the website from being exploited through a security vulnerability that has been fixed in a newer version of the plugin. There is a limitation to that though, that it only protects you from vulnerabilities that the developer has fixed. So what happens if a vulnerability is discovered in a plugin available in the Plugin Directory and it doesn’t get fixed by the developer? Once the Plugin Directory is notified of the vulnerability the plugin is removed pending a fix, unless the vulnerability is really minor. That protects anyone who is not yet using the plugin, since they won’t be able to install it through normal means, but what about those who already have it installed? For them nothing happens. That is something that has concerned us for years.

As part of our effort to improve the situation, four years ago we put a suggestion up on the Ideas section of the wordpress.org website suggesting that webmasters should be alerted when they are using a plugin that has been removed from the Plugin Directory. Not to long after that idea was marked as “Good idea! We’re working on it”.

Around the same the “Lead Plugin Wrangler” at WordPress explained that a solution was being worked on:

FWIW, we’re working on a solution. Part of the problem is we’ll close a plugin for many reasons:

* Guideline violations
* By request
* Security
* Licensing

And then of course there are subsets to these, like would you care about an alert if I told you a plugin was closed because it has affiliate links on the repository page? It doesn’t impact the user as much as all that. So we have to sort out how best to alert the right times, and then we have to figure out the best way to alert without spreading FUD.

We’ve actually started a step one on the backend, to allow the admins who moderate a better way of seeing what’s closed and what isn’t. Next up, a way for us to tag WHY a plugin was closed. It’s being worked on though 🙂

Four years later that still hasn’t happened. Two months ago the same person explained why it hasn’t happened:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

If an exploit exists, hackers will be targeting the vulnerability en-mass.

That’s exactly the issue. If we make it known there is an exploit, the hackers attack everyone :/

If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.

We will get in to why this is position is misguided at best in a second, but first it is worth mentioning that this isn’t a new stance. Back in February of 2012, our plugin No Longer in Directory, which lists installed plugins that have been removed from the Plugin Directory, was first rejected for inclusion in the Plugin Directory due to plugin’s description emphasizing that plugins can be removed the Plugin Directory due to security issues (which they felt was “alarmist and counter-productive”). Their message read in part:

We do not release details where possible of security issues before a fix is available. Given what you do I am sure you know this is the correct behaviour.

At the time we were flabbergasted by that, not only because they wrong, but they thought that it was obviously the right position.

Here are some of the reasons that this position is so misguided:

The Details Are Often Are Already Public

What makes hiding the fact that a plugin has a vulnerability seems so obviously misguided is that in many instances (maybe most of them) the details of the vulnerability have already been publicly disclosed. The people running the Plugin Directory are well aware of that fact just based on how often we notify them of public disclosures of vulnerabilities that are in the current version of plugins in the Plugin Directory. Hackers are already likely to know about those public disclosures, so letting people with the plugin installed know of them as well shouldn’t do much to increase the hacker’s knowledge. By comparison the average webmaster of a website using them is unlikely to know about those disclosures, so you are greatly increasing the chances that they can do something about it by notifying them, while not increasing the chances of exploitation by hacker by very much.

It Can Be Incredibly Easy To Figure Out Where a Vulnerability Exists

But what about a situation where the vulnerability hasn’t been publicly disclosed? The claim by WordPress is that “If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.” It doesn’t seem to be a good idea to us to keep quiet about vulnerabilities so that only some hackers can exploit your website, instead of making you aware of the issue so that you could remove the plugin and prevent anyone from hacking it.

What make this more problematic is that from recent experience we have found that it can be very easy to find an exploitable vulnerability by just knowing that other people are trying to exploit a plugin. Starting in early May we started getting requests on our website that seemed to be people looking for usage of plugins for which there were not known to have vulnerabilities. In all but two instance so far we were able to quickly find security vulnerabilities that are the kind that hacker would try to exploit. In one of the instances where we didn’t find a vulnerability that a hacker was would try to exploit looks like the hackers might have been trying to target a vulnerability that wouldn’t normally be exploitable and in the other the code was so insecure that we couldn’t narrow down where to look (but we did find two vulnerabilities that were less likely to be exploited).

In many of the cases we able to find these vulnerabilities in a matter of minutes. If we can do that you can be sure that people that are actually trying to hack website could do that as well.

Vulnerabilities Are Not Always Fixed in A Timely Manner, If At All

It would be one thing if WordPress withheld their knowledge of vulnerabilities for several days while a fix for the vulnerability was being put together. But as they are well aware it can be months before a developer gets around to fixing a vulnerability. For example, the plugin SEO Redirection, which has 60,000+ active installs according to wordpress.org received a fix for a vulnerability that was disclosed at the end of March in the middle of June (that plugin was then removed from the Plugin Directory again, but then returned without it being fixed). The developer didn’t even have to come up with fix since the disclosure include a proposed fix, which they used. In another case we looked at last year it took two months for a vulnerability in a plugin with 200,000+ active installs to be fixed despite requiring less than a line of code to fix.

In other cases vulnerabilities that hackers are known to be exploiting are never fixed, for example the plugin Plugin: Newsletter has an arbitrary file viewing vulnerability that was disclosed in May of 2012 that was never fixed and we continue to see attempts to exploit it. So when the WordPress folks say they won’t release details of vulnerabilities until they are fixed they are in fact saying is that they are fine with the possibility of keeping the public in the dark forever about the vulnerability.

12 Aug

WordPress Tries to Sweep Plugin Security Issue Under the Rug Instead of Fixing It

Recently we have been finding that someone on the WordPress team has been deleting and editing some of our post on their support forum and because they don’t want others to know that, in one instance they even deleted someone else’s post that simply thanked us for one of our posts. While it has been rather troubling in general, one other instance that stuck out to us in the most recent purge, was a case where they removed a single sentence from a post, that sentence was “(including when the people running the Plugin Directory have failed to notice that)”, which was in reference to the fact that we often find that vulnerabilities that are claimed to have been fixed have not actually been fixed. The linked post, from the end of March, discussed the fact that plugins that had been removed from the Plugin Directory due to security issues were returning without the vulnerabilities actually being fixed.

While it would be close to impossible to insure that all of the plugins in the Plugin Directory are free of vulnerabilities, making sure that  plugins that you are aware have had a vulnerability are not restored before they are actually fixed shouldn’t be, since it could be prevented by simply testing out to make sure the vulnerability has been fixed before restoring the plugin.

Unfortunately since March the issue has continued to happen. At the end of June we discussed another example involving a situation where we spotted what looked to be a hacker probing for the usage of the BePro Listings plugin (likely due to them being aware of a vulnerability in the plugin and looking for websites to exploit it on) and we then identified a vulnerability that hackers were likely to exploit in the plugin (as well as another fairly serious vulnerability). After contacting the developer and getting no response we notified the Plugin Directory and the plugin was removed. The plugin subsequently returned to the Plugin Directory without actually being fixed. It was only after we got in touch with the developer again that we were able, after several back and forths, to get them to finally fix it.

Just this week we spotted another instance of this happening, which also highlights the difficulty that there can sometimes be in getting developers to fix vulnerabilities in their plugins. This time it involves a persistent cross-site scripting (XSS) vulnerability that was publicly disclosed back in December of 2014 in the plugin SEO Redirection, a plugin with 60,000+ active install installs according to wordpress.org. The advisory seems to indicate that the discoverer had notified the developer at the time. A support forum post from over a year ago also notified the developer, but at the time the developer claimed the vulnerability didn’t exist:

I tested the plugin and displayed to me the same message, but there is no XSS in the plugin, ignore this message, I will try to change the parameters name or the tag name to stop this message from being appeared.

We then ran across the advisory earlier this year and added the vulnerability to our data set. At the time the plugin was removed from the Plugin Directory, due to a  SQL injection vulnerability that was in the plugin at the time. After the plugin came back in to the directory without the persistent XSS vulnerability fixed we notified the Plugin Directory of its existence and the plugin was removed a week later at the end of June. Earlier this week the plugin returned to the Plugin Directory, at that point tested it out again to make sure the vulnerability was gone and found that it wasn’t. There was a security related change in version 3.7, but it does not look like it was attempt to fix this and we can’t even tell if the change was related to a vulnerability.

It seems to us it would be a better use of the WordPress’ team members time to make sure that vulnerabilities in plugins are being fixed before restoring them to the Plugin Directory instead of trying to cover up the fact that they are not doing this. Until they get more serious about security you can protect yourself by using our service, so that you get alerted if a vulnerability is in the plugins you use, even in cases where the WordPress team misses them still existing.

01 Aug

Yet More WordPress Plugins With Apparent Zero-Day Vulnerabilities Go Unnoticed By Security Companies

One of the things we do to provide our customers with the best data possible on vulnerabilities that impact the WordPress plugins they use, is monitoring our websites for hacking attempts. For the first few months of the service we were seeing attempts to hack vulnerabilities already included in our data and very old vulnerabilities that we didn’t yet have in our data. Starting at the beginning of May we started seeing what looks to be requests from hackers probing for usage of plugins that we could not find any public disclosure of a vulnerability or any indication in the changelog that a vulnerability that hackers might be interested had existed and the been fixed in the plugin. When that occurs we quickly try to find if there is vulnerability that exists in the current version of the plugin that hackers would be interested in. In most cases we are able to find something that if hackers are not already exploiting, then they would exploit if they were to become aware of it (by comparison many vulnerabilities discovered in plugins are ones that are very unlikely to be exploited on the average website).

Seeing as we often find those vulnerabilities in a matter of minutes, those vulnerabilities are a good reminder that the security of WordPress plugins is not in great shape at this point. While some developers are quick to respond with a new version of the plugin that fixes the vulnerability, all to often fixes take weeks and in many cases the plugins have yet to be fixed. All of that is contrary what you might hear from people closely connected to WordPress.

The other thing that we have found troubling about this is that in most case we appear to be the only ones spotting the interest of hackers in these plugins and the vulnerabilities they contain. When this started happening in May, we expected the opposite, that we would be only one of many spotting these and we were interested in seeing how our response time would compare. You would certainly expect that to be the case based on how certain companies promote their services, Wordfence being one example we discussed previously.

By the middle of June as we kept spotting more vulnerabilities this way we got interested in seeing if we could gather more data than we could from just get from our websites, to see if we could catch more of these vulnerabilities and improve the speed at which we catch them. We found several websites with just such data and we quickly found more vulnerabilities. It also lead us to be more concerned about the state of WordPress plugin security, seeing as unlike the previous vulnerabilities where the explanation of why we were spotting these vulnerabilities and others were not, could have just been of our quick response to them. With many of the vulnerabilities we have found through this third-party data, that couldn’t be the explanation, since hackers seem to have starting to exploit them long ago. The first vulnerability we discovered this way involved a request from more than a year before.

As we continue to review more of that data we continue to find more such cases, last week that lead us to finding arbitrary file upload vulnerabilities (the most likely to be exploited common type of vulnerability) in three plugins, where hackers made request for the plugins in June of last year, July of last year, and February respectively. While we hope that we have made big dent in finding such vulnerabilities, we really have no way of knowing how many more may be out there.

01 Aug

Misleading Information on The Security of WordPress Plugins Coming From The WordPress Side Too

When it comes to improving the security of WordPress plugins one big problem we see is that it is hard for the community at large to have a good understanding of what the real issues are and therefore push for the needed changes, because security companies put out so much misleading information. We often see security companies discussing vulnerabilities that is of a type that is very unlikely to be exploited, and instead of mentioning the limited threat, they instead only mention the worst case scenario. That isn’t helpful and it does have a negative impact, as we see people thinking that they have been exploited by these types of vulnerabilities when they clearly were not. Another issue we sometimes see is that security companies will exclude important information on the limitations of vulnerabilities, for example we repeatedly spotted Wordfence excluding any mention that vulnerabilities they were discovering were only exploitable when logged in to WordPress, which limits the chance of exploitation by a large degree and is important to mention since it allows many webmasters to immediately know that the vulnerability could not have impacted their websites before it was fixed.

Because press coverage of security is often little more than repeating claims of security companies, who are in turn putting out misleading information, you end with sensationalistic coverage that provides little value.

What we have been seeing more of lately, maybe because of our monitoring of the WordPress support forum to help keep track of what plugin vulnerabilities are out there, is misleading information coming from people on the WordPress side of things as well. One recent example came from someone labeled in the support forum as “Support Representative”, who is also any employee of Automattic, the company closely associated with WordPress. In regards to a question about the security of plugins they responded:

All plugins at https://wordpress.org/plugins/ go through very intense security screening by real human volunteers, so you generally have nothing to worry about.

With that said, no one is psychic. Some enterprising hacker may find a new never-before-seen exploit that one of these plugins is vulnerable to. That’s true for every web software, even WordPress itself. When that happens, the developers are notified, and they generally react quickly to release an update with a fix.

Some more reading for peace of mind:

https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

https://wordpress.org/about/security/

We were absolutely puzzled by that, as it is so far from the reality of the situation, starting with the fact that plugins do not got through an intense security screening. There is a manual review done before a plugin is allowed into the Plugin Directory, but we can’t find any claim that it includes an intense security screening. One of the documents they linked to in that response specially states that “Inclusion of plugins and themes in the repository is not a guarantee that they are free from security vulnerabilities.”. If this review is intended to be an intensive security screening it is failing at that, as we recently found two plugins that had serious and fairly obvious vulnerability that had existed in them since they were added to the directory five months ago.

When an update of a plugin is submitted it is made available immediately without any sort of review or screening, and seeing as vulnerabilities can be introduced in an update, even if plugins were fully secure when first introduced, they could start getting insecure with the first update.

From the work we do for this service, not only are there vulnerabilities that exist in plugins in the Plugin Directory, but we recently have been finding vulnerabilities that hackers look to have been exploiting for months (or in some case over a year) and the plugins have not been fixed and they have remained in the Plugin Directory (if not for our work, who knows how much longer the plugins might have stayed in that state).

Another glaring problem with what was said is that very few vulnerabilities being discovered are “never-before-seen exploit[s]”. From what see from reviewing publicly disclosed vulnerabilities before adding them to our data set and discovering plenty of vulnerabilities ourselves, is that the vulnerabilities often involve well known issues, that is even the case with the vulnerabilities that are being exploited.

The last problem, which is something that is important to note because it points to an important improvement that could be made, is the claim that developers “generally react quickly to release an update with a fix”. From what we have seen dealing with lots of vulnerabilities, the reality is that while some developers will respond very quickly, others are not responding in what we consider a reasonable time frame. That includes vulnerabilities that are being exploited already, which we have seen take weeks for developers to respond with a fix and in other cases where the developer isn’t around any more, the vulnerabilities never get fixed. The Plugin Directory has the ability to step in to issue a fix for a vulnerability and does sometimes do that, but what the criteria is for that is opaque and it doesn’t happen nearly enough (if they need help in improving the handling of that we would be happy to help).

26 Jul

WordPress Plugin Directory’s Failure to Enforce Developer Guidelines Puts Websites At Risk

One of the issues we sometimes spot when reviewing reports of vulnerabilities in WordPress plugins is that the vulnerability has been fixed but the version number of the plugin has not been increased. That means that people downloading the plugin at that point will be secured against the vulnerability, but anyone who already had the plugin installed will still be vulnerable since there is no new version for them to be prompted to up date to. While it easy thing to resolve we have found that sometimes even after contacting the developers they won’t bump the version number. Why that is, is a mystery to us.

Not only is this a security issue, it also violates the Developer Guidelines of the Plugin Directory, specifically guideline 15:

All code changes to a plugin that has a Stable Tag of “trunk” must result in the version number being upgraded. For the trunk and tags method, trunk can be continually updated without version number changes, while tags should generally not be updated ever past the initial tagging unless the readme is being updated with regards to supporting the newest version of WordPress.

While they are referred to as guidelines, as you can see the language reads more like a rule.

A couple months ago we were reviewing a report of a vulnerability in the plugin wordpress responsive thumbnail slider. The report turned out to be false, but while reviewing that the version number of the plugin was at 1.0, despite numerous changes having been made to it over several years. It could have been that they started at a version number below 1.0 and then eventually got to that version, so we went and checked the first release and found that the version number was already 1.0 in that release. We then looked at some of the other plugins from the same developer and found that many of them were not having their version number increased with new releases. We also noticed they had actually lowered the version number of one of the plugins recently, so it wasn’t an issue that they didn’t know how to change the version number.

It would be one thing if the changes made without changing the version number were cosmetic, but in a quick check we found that at least three of the plugins with thousands of users each, have security related items listed in a log message and are still at version 1.0:

After noticing that we created a support thread on one of the plugins letting them know that they needed to increase the version number, in case they were not aware of that. After a month the version numbers had not been changed and having received no response in that thread, we contacted the Plugin Directory to let them know about this. Part of their response was that “They don’t HAVE to, but they’re stupid not to…”, which doesn’t match with the Developer Guidelines. We replied noting that the guidelines said that they do have to, but we didn’t get a response back. Now a month on from that, the plugins have still not had their version numbers increased, so probably thousands of website are still using versions of those plugins prior to the security releases and remain vulnerable.

The vulnerabilities that we could tell were fixed in the aforementioned plugins, don’t look like ones likely to be exploited, so this isn’t likely to lead to websites being hacked, but this still isn’t an acceptable situation.

29 Jun

Very Vulnerable WordPress Plugin Returns to Plugin Directory Without Being Fixed

When we discover a vulnerability in a plugin we can help protect the customers of our service by alerting them to the issue and they can then take the action they feel appropriate (we can also assist them in determining what is the appropriate action to take). For plugins that we seeing exploitation attempts against them, we also include the data on the vulnerabilities in the companion Plugin Vulnerabilities plugin, so even those who haven’t signed up the service get notified. But the best thing that can happens is that  the developer of the plugin fixes the vulnerability to insure that everyone can get protected without having to do anything more than update the plugin.

After discovering a vulnerability we notify the developer of the plugin about the vulnerability and offer to help them fix it, but often we don’t even hear anything back from them and the vulnerability isn’t fixed. When that happens the last thing we can do is notify the Plugin Directory about the issue. For most vulnerabilities they will then pull the plugin from the Plugin Directory pending it being fixed.

Far too often having a plugin removed from the Plugin Directory will be the only thing that will get a developer to fix a vulnerability. In one recent case of this, the developer was posting comments on our post about a vulnerability in their plugin, claiming that there wasn’t actually a vulnerability, as they were fixing the vulnerability.

Unfortunately as we have found again the Plugin Directory doesn’t always make sure the at vulnerabilities have actually been fixed before returning to the Plugin Directory. This time it involves two vulnerabilities we discovered in the plugin BePro Listings at the beginning of the month. After seeing what look to be someone probing for usage of the plugin on one of our websites (we were not alone in seeing requests for this plugin), probably looking to exploit something in the plugin, we found that plugin had an arbitrary file upload vulnerability and a post deletion vulnerability. The post deletion vulnerability would allow anyone to delete any post or page on the website, without it being sent to the trash, so it could do a lot of damage, but it isn’t the type of vulnerability we see much in the way of exploit attempts. The arbitrary file upload vulnerability, which could allow a hacker to almost anything with the website, is the kind of vulnerability that hackers are often trying to exploit.

We contacted the developer of the plugin about the issue, but still have never heard back from them. Due to serious nature of the vulnerabilities and the fact that someone was likely looking to exploit them or something else in the plugin, we quickly notified the Plugin Directory and the plugin was removed. The plugin has returned after changes were made, but ones that did not fix the issues.

To see what went wrong let’s take a look at what was done.

For the arbitrary file upload vulnerability from doing a diff from the development log you can see a change made to restrict what file extensions can be uploaded, which in a quick glance would look like it could fix the issue.

bepro-listings-arbitrary-file-upload--vulnerability-change

 

But by testing out the vulnerability with our proof of concept you would see that the file is still successfully uploaded. That is due to the fact that the code that restricts the file extension runs after the code that saves the uploaded file to the file system:

$check_move = @move_uploaded_file($_FILES["bepro_form_image_".$counter]["tmp_name"], $full_filename);

For the post deletion vulnerability we are not sure how the change done was meant to fix the vulnerability. That vulnerability was due in large part due to the misuse of the function is_admin() and not limiting who could access the function that does the deleting. Nothing was done to fix either of those issue, instead a nonce check was added. Since that nonce is accessible on any listing created by the plugin, it has little impact on someone being able to exploit it.

bepro-listings-post-deletion-vulnerability-change

Now we need to restart the process and notify the developer that issues still exist, hopefully the will get back to us this time so we can help them resolve this.