WordPress Plugins

A Good Example of What is Wrong With The Management of the WordPress.org Plugin Directory

Through the work we do for our Plugin Vulnerabilities service we spend a lot of time on the Plugin Directory, dealing with issues in plugins on it (mostly security issues), and interacting with the people running it. Our experience is that things are not really handled well by the people running it. Something we ran across today seems like a good example of the poor state of the people managing it, which we thought would be good to share to help expose the bad state of things.

Since we have several plugins in the Plugin Directory, prior to the release of a new version of WordPress we get an email asking us to test our plugins with compatibility with the new version of WordPress and then update them to indicate they are compatible with the new version. Here is the email we got prior to 4.5 (the plugin listed as only being tested up to 3.6 is due to the fact that the plugin’s functionality was integrated into the next version of WordPress):

Hello, WhiteFirDesign!

WordPress 4.5 is scheduled to be released on April 12. Are your plugins ready?

After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.5. This information provides peace of mind to users and helps encourage them to update to the latest version.

Here are the current “tested” values for each of your plugins:

* https://wordpress.org/plugins/automatic-plugin-updates/ (tested up to 4.5)
* https://wordpress.org/plugins/https-updates/ (tested up to 3.6)
* https://wordpress.org/plugins/no-longer-in-directory/ (tested up to 4.4)
* https://wordpress.org/plugins/plugin-vulnerabilities/ (tested up to 4.5)

For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.

Looking to get more familiar with 4.5? Check out this roundup post on the core development blog: https://make.wordpress.org/core/2016/03/30/wordpress-4-5-field-guide/

Thank you for all you do for the WordPress community, and we hope you will enjoy 4.5 as much as we do.
WordPress core contributors

So clearly the Plugin Directory wants people to be testing their plugins for compatibility and then updating the compatibility information.

Based on that you would think that the person described as the “WordPress.org Tech Dude”, who is involved in managing the Plugin Directory, would be setting an example by making sure to do that, but as we noticed today that isn’t the case. For one of their plugins PHP Code Widget, which has 100,000+ active installs, it is still only listed as being compatible up to WordPress 4.4. WordPress 4.5 was released in April and WordPress 4.6 getting closer to release, with the third beta released a week ago.

It isn’t a situation where the plugin is no longer supported, hasn’t been tested, or the developer just forgot to update the compatibility. As a couple of forum threads show, the developer is instead just refusing to update the compatibility listing. If that sounds strange to you, you are no alone, but that is inline with the type of attitude we have seen when dealing with those people.

SiteGuarding.com’s WordPress Security Plugin Touts Its Use For Those That Pirate Software, While Charging For Its Services

When it comes to security plugins for WordPress, we don’t think to highly of most of them. But we have continued to be surprised how low things can go with them. Take for example the WP Antivirus Site Protection (by SiteGuarding.com) plugin, which on it’s description page on the Plugin Directory it states near the top:

This plugin will be especially useful for everybody who downloads WP themes and plugins from torrents and websites with free stuff instead of purchase the original copies from the developers. You will be shocked, how many free gifts they have inside 🙂

Their touting its use for those that pirate WordPress themes and plugins is kind of incredible on its own (note the lack of past tense in terms of downloading that software or lack of suggestion not to do that). But more incredible is the fact that at the same time the plugin is really just a connection for a mostly paid service, so they think you should pay them, but are okay with people not paying the developers of software.

What makes that dichotomy more striking is the comments from the developer on some of the negative reviews of the plugins.

One review reads:

If your website contains a file larger than 25MB, the plugin will abort and ask you to upgrade rather than just skipping it and warning you. The plugin is just a leadgen ploy. Uninstalled. Further more, of all the wordpress hacks I’ve ever seen, files affected are NEVER large or over a few kb.

That seems like reasonable complaint, which gets this response from the developer:

free version has limits. if you are not ready to pay for the security enjoy and live with the viruses.

As part of their response to another review the developer wrote in part:

If you installed it again. It means plugin is good, you just dont want to pay for good plugins and services and want everything for free.

It is also worth noting that there are a lot of rather fake looking reviews for the plugin.

The Fact That Wordfence Couldn’t Clean Up a Hacked Website Doesn’t Stop People From Suggesting That It Will Clean It

When it comes to improving the security of websites one of the biggest problems we see if the shear amount of bad information, including lots of bad advice, that is being put out there. We frequently see people suggesting using the Wordfence plugin for WordPress, which we have hard time believing somebody who is knowledgable about security would recommend due to a number of issues. Those issues include the fact that broad based security plugins like that are not all that useful against real threats, that more than a few security vulnerabilities have been found in the Wordfence plugin itself, that the developers don’t seem to have a good grasp of security, and that the plugin produces some really bad false positives. Usually you have no way of knowing if somebody giving out that advice has a different opinion in regards to those types of things or they are giving advice without really being informed about the situation. In some cases you can see that advice is being handed out uniformed, though.

As part of keeping track of security issues in WordPress plugins for our Plugin Vulnerabilities service, we monitor the wordpress.org forum for threads related to plugin vulnerabilities. In addition to helping to find some more vulnerabilities to include in our data, we run across threads about other security issues related to WordPress and WordPress plugins. In one of those we saw when the use of Wordfence being suggested as a solution, when that clearly wasn’t helpful advice.

The original poster in the thread described the problem they were having cleaning up a hacked website. After trying numerous things, including reverting to a backup copy, malicious files were continuing to be added to the website. At the end of the post they mentioned that they have three WordPress security plugins installed, but that they hadn’t been any help:

Protections plugins I’m currently using (and which can’t find anything wrong with the website)

https://wordpress.org/plugins/antivirus/

https://wordpress.org/plugins/better-wp-security/

https://wordpress.org/plugins/wordfence/

Despite that one those plugins was Wordfence, the second and third responses suggested that Wordfence could deal with the issue:

Yes, those are not default files. WordFence is the best for scanning once you are already infected.

and

I had the same issue, so far WordFence has done a great job. Two days and no wp-checking.php has showed up. Yet!

In this type of situation what we would recommend, and did later in the thread, is to see if you can determine if the hacker still has some sort of access to the website, which is allowing them to continue to modify the website, and if that is the case, close off that access.

Incidentally, one of the other plugins they were using, AntiVirus, was one that we found was flagging a fresh install of WordPress as having virus back in 2012.

iThemes Security Plugin Has “One-Click Secure” Button That Does Nothing Except Claim The Website Has Been “Secured”

We are frequently asked what about various broad based WordPress security plugins and which ones should be used. Our answer to the second part of that is none of them. These plugins generally provide little protection against actual threats and have been found to have security vulnerabilities themselves fairly often. That second part might sound odd, you would think that someone developing a security related plugin would be very careful about the security of their plugin, but people that actually know about security would be unlikely to be involved in developing one of these due to the first part of that, that they don’t provide much protection against actual threats.

So what you are left with is products generally developed by people that don’t have much concern for real security and in a lot of cases seem to be mainly interested in making money by taking advantage of the public that understandably lacks strong security knowledge. That results in lots of plugins and related services that end up scaring people based on bad or false information and that collect information from users under false pretense.

If you are looking for some particular security feature you would be better off finding a plugin that doesn’t also include a kitchen sink of other features with it, since that reduces amount of code that could be harboring security vulnerabilities. The important things you need to do to keep your website secure are listed here.

The iThemes Security Plugin And Trust

That all brings us to something we just ran across with one of those plugins, iThemes Security (formerly Better WP Security), which is listed as having 700,000+ active installs.

One important element of any security product is trust, since the average user can’t verify that a product does what it says, they are trusting the developers in a major way. Any abuse of that trust should be a major red flag. That trust is something the developers of the iThemes Security plugin don’t seem to care about.

When you install and activate the iThemes Security plugin a notice is displayed at the top of the page with a button to “Secure Your Site Now”:

ithemes-security-1

Clicking on that brings up this page:

ithemes-security-2

The most important part of that would seem to be the section Titled “Secure Your Site”:

Use the button below to enable default settings. This feature will enable all settings that cannot conflict with other plugins or themes.

When you click on the One-Click Secure button, you get a message that it is “Working…” for a moment:

ithemes-security-4

Then it will tell you that “Site Secured. Check the dashboard for further suggestions on securing your site.”:

ithemes-security-5

Based on that you would think that the website has been secured in some way after doing that. It turns out that nothing actually has happened, something we found about when ran across a post on a thread on the WordPress.org support forum for the plugin that stated

Please note that since the 5.2.0 release (5.2.1 included) clicking on the One-Click Secure button in the First Important Steps modal window will not do anything despite the fact that it still reports:

Site Secured. Check the dashboard for further suggestions on securing your site.

which is also kind of lame as there is no longer a Security Status section on the Dashboard page …

Note this is not a bug, since iThemes knowingly removed the code that was normally executed behind this button …

If you want to see that for yourself you can see the changes made in version 5.2.o here (doing a search on the page for “Register one-click settings” will take you to parts of the page where that is shown). What makes this even more incredible is how long ago this happened, version 5.2.0 was release on January 18 and the post pointing that out is now two months old, and yet it is still that way now.

When they don’t care about misleading people with something that visible, then you have to wonder what else they might be misleading people about. We already spotted one other thing, but you will have to wait for a future post to hear about that.

Why Does The WordPress Plugin Directory Have Rules If They Don’t Bother To Enforce Them?

When it comes to distribution platforms for software one of the frequent complaints of developers is uneven enforcement of rules and regulations, which makes it hard to know what is and isn’t acceptable. Recently we came across an example of this with Plugin Directory for WordPress:

While dealing with one of the vulnerabilities we recently discovered through our Plugin Vulnerabilities service, we were have a bit of issue discussing communicating about the issue since it turned out the plugin had two names.

On the Installed Plugins pages in WordPress it is referred to as Spider Event Calendar:

On the Plugin Directory its name is WordPress Event Calendar:

Okay, actually while the main name is WordPress Event Calendar, you can see that it is referred to by both names in different places:

It is confusing to say the least and it seems like restricting a plugin to one name would be reasonable thing to do, but what seem to be the bigger issue here was with the fact that using the word WordPress in a plugin’s name is supposed to be against the rules of the Plugin Directory.

On the Detailed Plugin Guidelines page it says:

Don’t violate our trademarks. Don’t use “wordpress” in your domain name. Use “wp” instead, or better yet, come up with your own original branding! People remember names.

On the Developer FAQ page it is put a lot more clearly:

Are there names you don’t permit?

We don’t allow ‘WordPress’ in plugin names as it’s redundant and somewhat obvious that you’re a WordPress plugin.

A little more looking showed that the same developer had six plugins with WordPress in the name:

webdorado-wordpress-plugins

All six of those plugins have associated paid plugins.

A search of the Plugin Directory shows that these are far from the only ones using WordPress in the name of plugins:

It certainly seems like the Plugin Directory is allowing the word WordPress to be used since it is in such wide use and it would be easy to detect its usage in the name of the plugins when getting the name of the plugins from their files to show it in the Plugin Directory. If this is the case then the documentation should be updated, otherwise we have just provided the people running the Plugin Directory with an easy way to find a lot plugins that they need to do something about.

Security Company with WordPress Security Plugin Doesn’t Keep Their Own WordPress Installation Up to Date

When it comes to trying to improve the security of websites, one of the problems that we see is that while many people are still not taking basic security measures with their websites there are plenty of companies pushing additional security products and services. In some cases we have seen that the inflated claims of some of those products and services lead people to not take basic measures, since those products and services claim that they will prevent them from being hacked, and because they haven’t taken the basics security measures they end up getting hacked. While we do don’t have much evidence, we are concerned that other people don’t take basic security steps since keeping seems so daunting when they are told they need to being using all of these different products and services to keep their website secure.

A question that underlies this is if these companies actually are all that concerned about security or if they just trying to make a quick buck peddling products and services whose security implications they have little understanding. One way quick check to get an idea of their concern for security is to see if they are keeping the software running their own websites up to date. The results we have seen in the past haven’t been good, like the time we found that all of the companies we looked that were advertising to clean up hacked Joomla websites were all running outdated software (mostly Joomla). This time around we happen to run across the website of a company name Centrora Security, you can see from the results of a Chrome extension we make that they are not keeping the WordPress installation running their website up to date:

Not only have they not updated it for ever over a year and not updated it for the two most recent major versions, 4.1 and 4.2, but they have missed three security updates for 4.0.x series: 4.0.2, 4.0.4, and 4.0.5. Since WordPress 3.7, minor version updates like those security updates would normally be applied automatically, so either Centrora Security unwisely disabled that feature or some bug is stopping that from happening in their case. If it is the later then Centrora Security could actually help to improve the security of WordPress websites by working the WordPress developers to resolve that, so that others impacted by the issue could also start getting updates.

While they don’t take the basic step of keeping WordPress up to date, they produce a WordPress security plugin that they claim is the “MOST POWERFUL WORDPRESS SECURITY PLUGIN”. Probably not all that surprisingly they are not running the latest version of their own plugin on the website (the readme.txt for the plugin on the websites is from version 4.8.4), even though keeping WordPress plugin update to date is also an important security measures.

The Slow Pace of WordPress Plugin Vulnerabilities Getting Fixed

Since we have been reviewing publicly disclosed security vulnerabilities in WordPress plugins to add them to our Plugin Vulnerabilities plugin, one of the things that has stood out to us is how long it can take for vulnerabilities to get fixed. Part of what makes this stand out is that in many of the cases fixing the vulnerability is quite easy, so it seems that many developers are just not too concerned about keeping their plugins are secure.

Let’s take a look at recent example of this. Back in March g0blin Research discovered an authenticated persistent cross-site scripting (XSS) vulnerability in the plugin AddThis Sharing Buttons (formerly Smart Website Tools by AddThis). This plugin currently has over 200,000 active installs according to WordPress.org, has 12 listed authors, and is developed a private corporation of the same name. The vulnerability was caused by an Ajax function that should only be accessible to Administrator level users being accessible to any registered user. That severely limits the potential danger of the vulnerability since most WordPress based websites do not allow the public to create accounts, so someone relatively trusted with malicious intent would be required for the vulnerability to be exploited. It also should make it quite easy to fix, but as the timeline included with advisory (show below) shows it took the developers over two months to fix the issue:

2015-03-19: Discovered
2015-03-19: Vendor notified
2015-03-19: Vendor responded – link to report provided
2015-03-20: Version 4.0.7 released – issue still present
2015-03-26: Vendor responded with intent to fix
2015-03-31: Update requested from Vendor
2015-04-07: Vendor responded stating that a fix is in progress
2015-04-13: Update requested from Vendor
2015-04-16: Vendor states that fix is undergoing QA
2015-05-04: Update requested from Vendor
2015-05-11: Update requested from Vendor
2015-05-12: Vendor states that fix was rejected by QA, has been redeveloped and has been passed back to QA for re testing.
2015-06-01: Notified vendor of intention to contact WordPress Plugins team
2015-06-03: Version 5.0.4 released – issue resolved
2015-06-10: Advisory released

So what does it take to get this type of issue fixed?

There are two functions that are often used to check if someone is Administrator level user. The more widely used is to check if the user has the capability to manage_options:

current_user_can( ‘manage_options’ )

That capability is normally only provided to Administrator level and above users, and allows access to WordPress settings pages. That would be particular relevant for fixing this vulnerability as the vulnerable Ajax function is something that would have normally be accessed from a settings page.

The second function checks if a user is a Super Admin or Administrator:

is_super_admin()

With that function if network mode is enabled (WordPress MutliSite) it will return true if the user is a Super Admin and when network is not enabled it will return true if the user is an Administrator. Beyond the implications that this has with MultiSite websites, there is a potential that someone will accidentally use is_admin when they meant to user is_super_admin. That would be a security problem of its own, as is_admin only checks if an administrative page is being requested and “does not check if the user is logged in, nor if the user even has access to the page being requested”.

So what did the AddThis Developers come up after months and having a fix rejected by quality assurance?

First up is the relevant function before being fixed:

public function addthisAsyncLoading()
{
if ($this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
}
die; //exit from the ajax request
}

Here is the fixed version (fix bolded):

public function addthisAsyncLoading()
{
if (current_user_can( ‘manage_options’ ) && $this->_checkAsyncLoading()) {
$updateResult = $this->updateSettings($this->_postVariables);
}
die; //exit from the ajax request
}

Why it two months to add less than a line of code is something we don’t understand. It could have been worse, in another case with the same failure to check on a user level, it to the plugin being pulled the plugin from the Plugin Directory for the vulnerability to be fixed (following us reporting it to Plugin Directory).

44.7 Percent of Plugins in the WordPress.org Plugin Directory Haven’t Been Updated in Over Two Years

Plugins play an important part in the success of WordPress, but they also introduce their own issues. Security issues obviously get a lot of attention, but there are other issues like the fact that not all plugins continue to be supported long term. One measure of how many plugins continue to be supported is to look at when plugins were last updated, as even plugins that have not needed any changes should have been updated periodically to indicate that they are compatible with new versions of WordPress. On the WordPress.org Plugin Directory, plugins that have not been updated in over two years have a banner at the top of the page that states “This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”:

Last year, following a suggestion for our No Longer in Directory plugin, we added the functionality to list installed plugins that had not been updated in over two years in addition to its listing of plugins that have been removed from the Plugin Directory. We also put up a post looking at how many plugins that met that criteria at the time. Now, a little over year later we thought it would be a good time see again how many plugins haven’t been updated in over two years.

As of earlier today a total of 16,935 listed plugins had not been updated in over two years. That is 44.7 percent of all 37,905 of listed plugins. (Last year’s percentage isn’t equivalent since we included all plugins that entries in the Subversion Repository for the Plugin Directory, even if the plugin wasn’t currently or possibly ever in the Plugin Directory.)

Below we have charted what year these plugins were last updated. The number for 2013 is lower as plugins last updated after May 18 of 2013 would still be under two years out of date.

Warnings Missing in WordPress

While the WordPress.org Plugin Directory website displays a warning banner at the top of a plugin’s pages, inside WordPress a similar warning is not provided. Here is what is shown on the Add Plugins page in WordPress for the same plugin shown in the screenshot above:

Here is what you see if click the More Details link on that page:

Also if you have one of these plugins installed you don’t get shown any notice on the Installed Plugins page:

WPScan Incorrectly Identifies Plugin Vulnerabilities as Being Fixed

The WPScan tool is “black box WordPress Security Scanner written in Ruby which attempts to find known security weaknesses within WordPress installations”, which is described as being intended “for security professionals or WordPress administrators to asses the security posture of their WordPress installations.” We find that claim somewhat odd since it scans a WordPress website from the outside of the website, which not only isn’t necessary if you have admin access to the website (which anyone involved with the security of website should have), but is also an inefficient way of doing a security scan when you have that access. While doing some research for another post we identified another problem that makes the tool bad for use by a security professional: their data indicates that plugin vulnerabilities have been fixed as of versions of the plugin that still in fact contain the vulnerabilities. Since this gets to a larger problem we have been seeing, we though it would make sense to take a look at this.

In WPScan’s vulnerability data for a a vulnerability in a plugin named Ajax Search Lite it says that the vulnerability impacted versions at or below 3.1 and that the vulnerability was “fixed in version 3.11”. The first claim is wrong and the second claim was wrong as of the date their data was last updated, March 21. We know this because we help to get the plugin fixed after that.

As part of the process of adding WordPress plugin vulnerabilities to our Plugin Vulnerabilities plugin, we check to make sure the claimed vulnerabilities actually exist (which they sometimes don’t) and we try to determine all of the version that are vulnerable. Knowing what versions are vulnerable is important when trying to determine how a WordPress website was hacked (as we do when cleaning up Hacked WordPress websites), as you can rule out a plugin’s vulnerability if the installed versions is not vulnerable. In adding data for over 225 vulnerabilities to our plugin so far, we have found that while some vulnerabilities have existed in every version of a plugin, many impact less versions, in some cases only one version has been impacted. What has been more surprising in working on the plugin is how often we find that even though a vulnerability has been listed as fixed, it hasn’t been. That was the case with Ajax Search Lite.

When we starting looking into the security advisory for Ajax Search Lite we figured that the vulnerability had probably been fixed in version 3.11 of the plugin based on the changelog entry for that version, “A possible security issue fix”, and the release date. After confirming that vulnerability existed in the prior version, 3.1, we checked to make sure it was fixed in 3.11, but it wasn’t. Looking at the changes between 3.1 and 3.11 we didn’t see anything that looked like the security fix. We then took a look at another plugin from the same developer Related Posts Lite that was reported to have the same issue. In that case the vulnerability had been fixed, so it looked to as if the developer simply forgot to include the fix in Ajax Search Lite. We notified the developer on March 26 of the issue; they then promptly responded and fixed the vulnerability. They still haven’t increased the version number so that anyone who got version 3.11 before that happened is still vulnerable. Because WPScan doesn’t do what we do, with their tool you wouldn’t know that you could still be running an insecure version.

What has made the issue of unfixed vulnerabilities even more surprising to us is that organizations that would think would be careful about this sort of thing, haven’t been. Take for instance another vulnerability we looked at recently. High-Tech Bridge, a security services provider, put out a security advisory for a vulnerability in the Easing Slider plugin. In it they stated that the vulnerability was “Fixed by Vendor” and indicated that the fix occurred in version 2.2.0.7. When we went to check on the vulnerability we found that it still existed in that version. In the changelog for that version it was listed that “Fixed some $_GET input validation security issues.”, which would appear to relate to the security issue identified, but they had not in fact done that to inputs that were the root of this vulnerability. It appears that High Tech Bridge didn’t actually test out their sample exploit in the new version, since it was obvious that it wasn’t fixed if you did that. We alerted the developer to the issue and the locations of the vulnerable code, which lead to the vulnerability actually being fixed in version 2.2.1. Once again if you are relying on WPScan you would be in trouble since they indicate the vulnerability impacted versions at or below 2.2.0.6 and that the vulnerability was “fixed in version 2.2.0.7”.

While this highlights the problem of relying on WPScan for security purposes, it also points to any area where the security of WordPress plugin could be improved. If WordPress provided a process where a plugin is reviewed after a security vulnerability is supposed to have been fixed then these types of issues could be quickly caught and fixed. As to who would provide the funding for this, we already have a good idea.

WordPress Leaves Very Vulnerable Plugin In Plugin Directory

On March 8 an arbitrary file upload vulnerability, which would allow anyone to upload any kind of files to a website, was disclosed in the Reflex Gallery plugin. This type of vulnerability is probably the most serious vulnerability for a website since, unlike many types of vulnerabilities that rarely get exploited, it is question of when, not if, it will be exploited on websites. This is due to the fact that a hacker can use the vulnerability to upload a .php backdoor script, which will give them remote access to the website without having to interact with the software already running on the website. The only good news in this case it that the plugin is not very popular, the WordPress Plugin Directory lists as having 2,000+ active installs.

When we started to take a look at the vulnerability report to include it in our plugin that notifies of known security vulnerabilities in WordPress plugins we noticed that this plugin had previously had another arbitrary file upload vulnerability that existed in versions 1.0-3.0. The proof of concept for the previous vulnerability looked similar to the new one, both of them targeted the file /admin/scripts/FileUploader/php.php in the plugin. The main difference between them was that second included a couple of URLS parameters in the request, ?Year=2015&Month=03. Our first thought was that new vulnerability might somehow be related those URL parameters, though as we dug in we found what was really going on.

In version 3.0.1 the first vulnerability was fixed by changing the line

$allowedExtensions = array();

$allowedExtensions = array(“jpeg”, “gif”, “png”);

in the file /admin/scripts/FileUploader/php.php.

That restricted what file extensions could be uploaded, so that .php files could not be uploaded. While this provided basic protection, it was less than should have been done. Since the front-end of the plugin’s upload functionality is only accessible admin users the underlying upload function should have also been restricted to admin users. That way if there were some other vulnerability in it only admins would be able to exploit it, which really isn’t much of a problem. There are a couple of other potential issues that come from allowing anyone to upload files. First, you have the chance for denial of service (DOS) attack from someone filling up all of the websites disk space with uploaded files. Second, since only the file extension is limited, it is still possible to upload files with PHP code, which could be combined with a local file inclusion (LFI) vulnerability to exploit a website.

We then looked at what changes were made in the most recent version, 3.1.3, and that showed what happened with the second vulnerability. In the file /admin/scripts/FileUploader/php.php the line

$allowedExtensions = array(“jpeg”, “gif”, “png”);

was changed to

$allowedExtensions = array();

So for some reason the fix that was put in place before was removed, which re-opened the vulnerability. What makes this seems odder is that the changelog for 3.1.3 list only two changes made:

Fixed issue of gallery info not updating on Edit Gallery page
Additional security fixes

Last Monday, after looking into the vulnerability we attempted to notify the developer of the plugin about the disclosure of the vulnerability and the underlying cause. Were not sure if they got because when we submitted a message on their website’s contact form it didn’t provide any indication that message had been successfully sent. If we can’t reach a developer or they don’t respond our next step with a vulnerability that exist in a plugin that is available in the WordPress Plugin Directory is to report to the people running it. We originally planned to do that on Friday as that would have give the developer four days to deal with it first, but then on Thursday while reviewing our log files to see what WordPress plugin vulnerabilities there had been recent exploit attempts for we saw that there was attempt to exploit this vulnerability. It was done during a series of requests (shown below) that included trying to exploit some rather old vulnerabilities so it is likely that was not an attempt based on the recent disclosure, but the previous one.

79.143.187.194 – – [12/Mar/2015:02:07:37 -0400] “GET /blog/2010/11/19/oscommerce-2-3-includes-fixes-for-security-vulnerabilities-and-security-enhancements//xmlrpc.php HTTP/1.1” 301 567 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:07:38 -0400] “GET /blog/2010/11/19/oscommerce-2-3-includes-fixes-for-security-vulnerabilities-and-security-enhancements/xmlrpc.php HTTP/1.1” 404 6349 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:07:41 -0400] “GET //xmlrpc.php HTTP/1.1” 200 439 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:07:42 -0400] “GET / HTTP/1.1” 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:07:52 -0400] “GET //wp-content/themes/vip/includes/uploadify/upload_settings_image.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:07:58 -0400] “GET / HTTP/1.1” 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:07 -0400] “GET /wp-content/themes//timthumb.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:10 -0400] “GET / HTTP/1.1” 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:19 -0400] “GET /wp-content/themes//thumb.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:23 -0400] “GET /wp-content/plugins/woopra/inc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:25 -0400] “GET /wp-content/plugins/wp-seo-spy-google/ofc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:27 -0400] “GET /wp-content/plugins/invit0r/lib/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:29 -0400] “GET /wp-content/plugins/chart/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:31 -0400] “GET /wp-content/plugins/wp-slimstat-ex/lib/ofc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:33 -0400] “GET /wp-content/themes/cameleon/includes/fileuploader/upload_handler.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:36 -0400] “GET /wp-content/themes/switchblade/framework/_scripts/valums_uploader/php.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:41 -0400] “GET /wp-content/plugins/reflex-gallery/admin/scripts/FileUploader/php.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:45 -0400] “GET /wp-content/themes/elemin/themify/themify-ajax.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:49 -0400] “GET /wp-content/plugins/front-file-manager/upload.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:52 -0400] “GET /wp-content/plugins/complete-gallery-manager/frames/upload-images.php HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:08:56 -0400] “GET /wp-content/plugins/is-human/engine.php?action=log-reset&type=ih_options();eval(base64_decode(JHM9cGhwX3VuYW1lKCk7CmVjaG8gJzxicj4nLiRzOwoKZWNobyAnPGJyPic7CnBhc3N0aHJ1KGlkKTsK));error HTTP/1.1” 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6”
79.143.187.194 – – [12/Mar/2015:02:09:00 -0400] “POST /wp-content/plugins/radykal-fancy-gallery/admin/image-upload.php HTTP/1.1” 404 5864 “-” “libwww-perl/6.08”
79.143.187.194 – – [12/Mar/2015:02:09:02 -0400] “POST /wp-content/plugins/mm-forms-community/includes/doajaxfileupload.php HTTP/1.1” 404 5864 “-” “libwww-perl/6.08”
79.143.187.194 – – [12/Mar/2015:02:09:05 -0400] “POST /wp-content/plugins/html5avmanager/lib/uploadify/custom.php HTTP/1.1” 404 5864 “-” “libwww-perl/6.08”

At that point we immediately sent an email to the people running the Plugin Directory alerting to the vulnerability and the fact that it was currently being exploited (along with details on three other vulnerabilities). In most cases in the past when we having reported vulnerabilities to them in this way they have quickly responding by taken the plugin down until a fix was released, so that no additional websites would made vulnerable. Unfortunately, as of posting this on Monday morning the plugin has not been updated or pulled from the plugin directory.

Improving The Handling of Plugin Vulnerabilities

This situation highlights a couple of serious problem that come with the current handling vulnerabilities in WordPress plugins, but also points to where improvements can be made.

Making it Easier to Report Vulnerabilities

The current methods for reporting security vulnerabilities are lacking. You can try to contact the developer through their website, but isn’t also easy to find an email address or contact to do that. Some plugins have email addresses they specifically suggest you use to contact them about security issues, but they also can be hard to locate on their websites. You can try contacting the developer through the plugin’s support forum in the Plugin Directory, but not every developer monitors that closely and it is public so that can limit ability to safely disclose information. From what we have seen it appears that many people that are discovering vulnerabilities don’t know that the can also contact the Plugin Directory about the issue, which isn’t too surprising since it isn’t prominent displayed.

One possible solution for this would be to provide a mechanism on the plugin’s page on the Plugin Directory for security vulnerabilities to be reported, which would then send it along to the developer and the people running the Plugin Directory.

Checking on Fixes

What we see fairly often is that when developers attempt to fix publicly disclosed vulnerabilities they either only partially fix it or don’t fix it at all. In other cases the disclosed vulnerability is only part of a wider security issue. Putting a place a process where a review by someone with a better understanding of security is done after the developer thinks they have fixed the vulnerability could go a long way to improving the security of plugins. We already have a good idea of who could provide the financial supports this (in the meantime our checks during the process of adding the vulnerability to our Plugin Vulnerabilities plugin have lead to a number of these situation getting resolved).

In this case if the file uploading had been restricted to admins, then even with the undoing of the file extension restriction the security vulnerability would not have opened back up.