Serious Security Vulnerabilities Recently Found in Numerous WordPress Plugins

Over the past few weeks numerous serious security vulnerabilities have been found in WordPress plugins. Many of the vulnerabilities allow arbitrary file uploads, which can be used to add a backdoor script website to a website and allow an attacker remote access to the website. When websites are hacked using an exploit of software running on the website this is often the type of vulnerability that is utilized. Other vulnerabilities that have been recently discovered include file upload vulnerabilities limited to certain file extensions, remote file disclosure (so the contents of the wp-config.php or other sensitive file could be displayed), an SQL injection, and cross-site scripting (XSS) vulnerabilities. The details of many of the vulnerabilities can be found in Secunia’s advisories for them.

So far we have had several attempts on our website to exploit some of these plugins that had vulnerabilities related to Uploadify, which appears to have been first publicly disclosed on April 5. We have yet to see exploit attempts for any of the other plugins.

After spotting the attempts related to Uploadify, we started looking to the vulnerability and if the plugins had been fixed yet. During that process we noticed that some of those plugins were among a large number of plugins with unresolved vulnerabilities listed in recent Secunia Advisories. We then informed WordPress.org Plugin Directory maintainers of the plugins with those unresolved security vulnerabilities. We also informed them, as we have in the past, that they can that they can monitor Secunia Advisories for WordPress plugins, so that they are not reliant on issue being reported to them so that they can quickly respond.

The good news to report is that many of the plugins have been quickly updated to fix the vulnerabilities and the people in running the WordPress.org Plugin Directory have been fairly proactively in removing plugins from the directory until they have been fixed (though there are still some of the plugins we have notified them that still remain in the directory despite their vulnerabilities). The bad news is that some of the plugins are unlikely to be fixed and no warning is displayed in WordPress when these vulnerable plugins are installed. Until the time that WordPress handles that properly, which we have previously discussed the need to do, our No Longer in Directory plugin provides an interim solution. On the plugin’s page in WordPress it will identify any installed plugins that have been removed from the Plugin Directory and provides links to Secunia Advisories when available. We have just put out an update with a refreshed list of plugins removed from the WordPress.org Plugin Directory and added links to Secunia Advisories for 19 of the recent vulnerabilities. The Secunia Advisories include workarounds for the vulnerabilities, so that people running those plugins will be aware of a possible temporary fix for the vulnerability until it is hopefully properly fixed.

24 More WordPress Plugins With Publicly Known Vulnerabilities Were in Plugin Directory

Last week we mentioned that we had found that a WordPress plugin that had a security vulnerability in its current version, that had recently been attempted to be exploited, had remained in the WordPress.org Plugin Directory for six months after it was publicly disclosed. That plugin had received an advisory from Secunia and we have reviewed the rest of Secunia’s WordPress advisories to check for any other plugins in the directory that also had unresolved security vulnerabilities. We identified 24 more plugins that have vulnerabilities in their current versions and had remained in the Plugin Directory since the advisory was released. We have reported those plugins to WordPress and they have been removed from the Plugin Directory. If and when the vulnerabilities are fixed they should return to the directory.

You can check if your WordPress installation is running any plugins that have been removed from the Plugin Directory, whether for security issues or other issues, with our plugin No Longer in Directory. We have just updated it with the plugins that we reported to WordPress and have added links to Secunia Advisories for any of the plugins that have received them.

The oldest Secunia advisory for a plugin with an unresolved issue that had remained in the Plugin Directory was from January of 2008 and the most recent was from February of this year. The types of vulnerabilities in these plugins included cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injections, and file inclusion. These plugins had over 560,000 combined downloads. The number of downloads that individual plugins had ranged from 300 to 93,000. Four of the plugins had over 50,000 downloads, which should be a reminder that just because a plugin is popular it doesn’t mean that it is more secure than less popular plugins.

We also found a situation where a plugin had been removed from the directory but a fork of the plugin has remained in the Plugin Directory despite also containing the vulnerability and two plugins that had their vulnerabilities fixed but the version number was not changed so that people that already had the plugin installed will remain vulnerable to being exploited. Resolution on those plugins’ issues from WordPress is still pending.

We plan to review other sources of claimed vulnerabilities to see if there are more plugins with publicly known vulnerabilities in their current versions that have remained in the Plugin Directory.

WordPress Plugin With Publicly Known Vulnerability Remained in Plugin Directory For Six Months

While reviewing recent logs for attempts to exploit WordPress plugins, for another post on this blog, we spotted one plugin that seemed out of place. While nearly all of the exploit attempts involved plugins that were no longer in the WordPress.org Plugin Directory or had recently been updated with security fixes, the WP CSS plugin was in the directory but hadn’t been updated since 2009. We then got a copy of the plugin to see if the vulnerability that was being attempted to be exploited worked in the current version. A quick check showed that the exploit worked. According to Plugin Directory statistics as of Friday the plugin had been downloaded 17,803 times. That a plugin was available in the Plugin Directory that has vulnerability that is actively being exploited was troubling, but what we found next was more troubling.

Before contacting the developer of the plugin and WordPress, we decided to take a look if there was more information about the vulnerability available. We first found a post from someone who had also had recent attempts to exploit the vulnerability on their website. We then found a Secunia advisory for the vulnerability that was release on August 26, 2011. We also found that a company named SecPod had created a OpenVAS plugin for the vulnerability. It is also likely that exploit attempts were caught in various honey pots.

With the vulnerability being publicly known for at least six months and recent attempts to exploit it, the question that needs to be asked is how the vulnerable plugin continued to be available in the WordPress.org Plugin Directory all of that time. Did no one ever contacted WordPress about the vulnerability or were they contacted about it and decided not to remove the plugin, pending a fix? It seems highly unlikely that WordPress was contacted and left the plugin in the directory as they responded to our message, and removed the plugin, within in two hours of us contacting them. It is possible that some of the people who had spotted the vulnerability contacted the developer of plugin and had not contacted WordPress despite the plugin being hosted in the Plugin Directory and it being recommend that they be contacted about WordPress plugin security issues.

While it appears no one contacted WordPress, they still should have been monitoring for plugins included in the Plugin Directory that have a publicly released vulnerabilities. For Secunia, all WordPress related vulnerabilities can be found here.

For anyone running the WP CSS plugin they should remove the plugin or remove the w-css-compress.php file until it is fixed, unless they are comfortable making a modification to the file to prevent exploitation. Deactivating the plugin will not prevent the plugin from being exploited.

The other issue that this situation raises is the lack of information provided to those running plugins that have been removed from Plugin Directory for security issues, we have addressed that in another post on this blog and plugin that provides an interim solution for the problem.

WordPress Leaves Admins Unaware of Insecure Plugins on Their Websites

These days when WordPress gets hacked it isn’t likely to be due to a vulnerability in WordPress, it’s much more likely to be due to a plugin. Unfortunately, there hasn’t been enough focus on the security issues related to plugins and working to fix those. A glaring example of this, that we found while preparing some information for this post, is that the WP CSS plugin contained a vulnerability that had been publicly known for six months, that the vulnerability had been recently attempted to be exploited, and yet it was still being distributed in the WordPress.org Plugin Directory until last Friday.

WP CSS also highlights another failing of the current plugin security handling. It’s something that we share some of the blame for because we should have realized the issue existed long ago and we are now trying to make an amends for that by taking on the issue. The following is the process that is supposed to take place after a security vulnerability in a plugin is reported to WordPress, as we had done with WP CSS.

  1. The plugin is de-listed from the repository, to prevent further downloads of an insecure plugin.
  2. If the exploit is accidental or not obviously malicious, the developer is notified via email. The email comes from a valid address (plugins at wporg) and can be replied to.
  3. The plugin developer presumably fixes the exploit or tells us that it is an invalid exploit, updates the plugin in SVN, and emails back saying so.
  4. We check it out, and either provide advice or re-enable the plugin.

For websites that haven’t had the plugin installed yet the process protects them from the vulnerability. But the same can’t be said for all the websites that already have the plugin installed. If the vulnerability is promptly fixed then the websites should be okay as long as the plugins on the website are kept up to date. The big problem comes when plugins are either not promptly fixed or never fixed at all. In those cases websites with the plugin installed admins receive no notification in WordPress that there is a security vulnerability in the plugin or even that it has been removed the Plugin Directory. There also isn’t any indication on the WordPress Plugin Directory that the plugin was removed, instead when you go to the page where the plugin used to exist you are just told “Whoops! We couldn’t find that plugin. Maybe you were looking for one of these? ” (you can currently see an example of this with the WP CSS page).

It’s not clear why no information is provided, it seems hard to believe the people who are handling plugin security issues at WordPress would not be concerned what happens to websites who already have the plugins installed. If the idea is that hiding the issue would provide the websites with the plugins installed some protection it doesn’t make much sense and isn’t working. In many cases the vulnerabilities have been publicly released, as is the case with WP CSS. For potential attackers it is easy to find the information, but people running WordPress websites are much less likely to be looking at those things. It’s then not surprising that we are seeing attempts to exploit removed plugins. In the month of February the following 14 removed plugins were attempted to be exploited on our website:

  • 1 Flash Gallery (1-flash-gallery)
  • Category List Portfolio Page (category-list-portfolio-page)
  • Disclosure Policy Plugin (disclosure-policy-plugin)
  • DP Thumbnail (dp-thumbnail)
  • IP Logger (ip-logger)
  • is_human() (is-human)
  • jQuery Slider for Featured Content (jquery-slider-for-featured-content)
  • Kish Guest Posting (kish-guest-posting)
  • LISL Last-Image Slider (lisl-last-image-slider)
  • Really Easy Slider (really-easy-slider)
  • Rent-A-Car-Plugin (rent-a-car)
  • VK Gallery (vk-gallery)
  • WordPress News Ticker (wordpress-news-ticker-plugin)
  • WP Marketplace (wp-marketplace)

You would only need to have one of those plugins installed to have your website successfully hacked. In all of those attempts, it looks like the attempts were part of a general attempt to exploit as many websites as possible. It appears that many removed plugins contain vulnerabilities that wouldn’t be useful for this type of mass attack, but would be useful for a targeted attack on a website so the issue plugins with known vulnerabilities should be a major concern for websites that are likely to targeted for attack.

An Interim Solution

Instead of just complaining about this we have come up with an interim solution for the issue by creating a plugin that reports any installed plugins that have been removed from the WordPress.org Plugin Directory. All you have to do is to install the plugin and go the plugin’s page to see if there are any installed plugins that have been removed from the directory.Screenshot of No Longer in Directory Plugin

One obvious and reasonable question is to ask is why our plugin warns about all removed plugins instead of just the ones with security vulnerabilities. The biggest reason for doing it this way is that because WordPress doesn’t release information on why plugins were removed we don’t which ones were removed security issues. We could just limit our warning to plugins that have publicly released vulnerabilities, but that leaves the possibilities that we miss some or many more plugins. The other issues is that plugins that have been removed for other reasons are unlikely to be fixed if a security vulnerability is found after it has been removed, for some plugins it appears that this has been the case.

A limitation of the plugin is that it will only warn about plugins that have been removed as of the last time we updated the plugin list in the plugin. Our current plan is to update the full list once a month.

We are looking at the possibility of integrating information on the security vulnerabilities in removed plugins into the plugin, so that admins can make more informed decision about what to do if there are removed plugins installed in their WordPress installation.

If WordPress does make changes to Installed Plugins page to warn of removed plugins, then it would also be good to also provide the option of showing the relevant changelog entries as well so that admin are aware of when security issues have been fixed in plugins. Some plugins already have similar functionality built into them. That functionality is also available with the Changelogger plugin.

If you are looking to increase the security of your WordPress installation and you perform software updates in WordPress you should take a look at out our plugin for performing update processes using HTTPS.