White Fir Design Blog

When it comes to the security of WordPress, despite lots of misinformation and outright fear mongering, the security is quite good. The developers of WordPress have been quite good at handling security, and when a security issue is found they promptly respond to the issue and the fully automatic update mechanism for security updates included since WordPress 3.7 means that those security updates are promptly applied for most websites. Unfortunately the handling of security of plugins isn’t as good. While most of the vulnerabilities found in plugins are unlikely to lead to your website being hacked, there are some that are easily exploitable. In most cases simply updating your plugins when WordPress notifies you of a new version will protect you (or setting them to automatically update with our Automatic Updates Plugin or another similar tool), but there are a couple of situations where that isn’t true.

The first situation is where a plugin that is in the wordpress.org Plugin Directory has a vulnerability that isn’t’ fixed. Once the people running Plugin Directory are informed of the issue they will pull the plugin. That will prevent anyone more from installing the plugin but leaves everyone already running the plugin vulnerable as they are not provided any warning. We have been pushing for that to be changed for several years, but that still hasn’t happened. If you would like to see that change then please vote for that to happen.

The second situation is where a vulnerability exists in a plugin that isn’t in the wordpress.org Plugin Directory. While it is possible for these plugins to be hooked into WordPress’s normal update mechanism that isn’t always done, leaving the admin of the website to be unaware of a new version with a security fix being available.

For the first situation, we have for some time provided a plugin that lists installed plugins that have been removed from the directory and in some cases also includes a security advisory. For the second situation, we have new plugin that can help with that by warning if versions of plugins with known vulnerabilities are installed in WordPress.

Let’s take a look at how that works. Recently the Revolution Slider and Showbiz Pro plugins have been getting a lot of attention for a couple of security issues that existed in older versions. The first vulnerability allowed the viewing of arbitrary files (that could be exploited to view the database credentials stored in the wp-config.php file), that impacts Revolution Slider versions 4.1.4 & below and Showbiz Pro versions 1.5.2 & below. The second and much more serious vulnerability allows malicious files to be uploaded on to the website, that impact Revolution Slider versions 3.0.95 & below and Showbiz Pro versions 1.7.1 & below. If you have our Plugin Vulnerabilities plugin installed and you have one of those versions of Revolution Slider or Showbiz Pro installed you will see an alert message on the Installed Plugins page like this:

In addition to the vulnerabilities in Revolution Slider and Showbiz Pro our plugin currently has data on 116 vulnerabilities. That is still a small portion of all the plugin vulnerabilities out there, but we are continuing to add additional vulnerabilities. This week we added 30 vulnerabilities to the plugin. Going back to the first situation where plugin have been removed from the wordpress.org Plugin Directory the plugin also helps with that as we have data on security vulneabilities in the most recent versions of 24 plugins, which have been removed from the Plugin Directory.

With the plugin you can also see vulnerabilities that have existed in other versions of plugins you have installed from the Plugin Vulnerabilities page in the Plugin menu.

When it comes to security companies, we often see that they seem less interested in actually improving security than getting themselves attention. In some cases the harmful effects of this are quite obvious, like when a security companies falsely implicates a piece of software as being a common connection between a group of hacked websites leading people to believe that software is insecure when it isn’t. A less obvious situation where this attention seeking comes in to play is when a security company warns that you need to update a WordPress plugin since it has a security vulnerability. What could be the problem with that you are probably thinking? The answer is that you need to update all of your plugins in a timely manner, and not try to keep track of what ones might have a security vulnerability and therefore need to be updated immediately. The reason for this is that there is a good chance that you won’t be able to tell if an update fixes security vulnerability, even if you review the changelog for plugin (which in turn is more likely to warn you about security issue than following any security company).

Recently we started working on a new plugin, Plugin Vulnerabilities, that provides information on vulnerabilities that exist and previously existed in the plugins you have installed in WordPress. One of the places we look at when determining what versions of a plugin are susceptible to a vulnerability is the plugin’s changelog. In doing that we have found that the amount of details provided in the changelog when a security issue is fixed varies widely. In many cases the fact that a vulnerability has been fixed is disclosed (sometimes with basic details of the vulnerability include as well), but in plenty of cases there is no mention at all that a security vulnerability has been fixed.

To get a better idea how frequently security vulnerability fixes are left out of the changelog, we went through the vulnerabilities currently listed in our Plugin Vulnerabilities plugin for which the relevant plugin is currently in the wordpress.org Plugin Directory and tallied up whether the vulnerability being fixed was mentioned in the changelog or not. In our sample of 66 plugin updates, we found that in 19.7 percent of them the changelog made no mention of a vulnerability being fixed. The breakdown of the changelog mentions are as follows:

• 43 updates listed that a vulnerability fix was included
• 10 updates mentioned that a fix for a potential or possible vulnerability was included (in all cases the vulnerability was in fact exploitable)
• 13 updates made no mention of a vulnerability being fixed

Jut based on the fact that you have about a 1/5 chance that a security fix isn’t mentioned in changelog, not updating plugins all the time seems like a bad idea, but what is more important is how severe the vulnerabilities fixed that are not mentioned can be. Take for instance version 5.2.91 of Special Text Boxes plugin, which had the following listed as the change made in the release:

The possibility of manipulating custom themes has been removed by request of administration of wordpress.org plugins repository.

Would you have guessed that referred to fixing an arbitrary file upload vulnerability that was being actively exploited before 5.2.91 was released? Probably not.

One of the things that we have noticed in looking at security vulnerabilities in WordPress plugins over the years is that backup plugins are often found to have vulnerabilities. While working on our new plugin that lets you know what vulnerabilities are or have in the past existed in the WordPress plugins you use we have seen that the poor security of backup plugins is continuing. Two examples highlight the problems with security of not just backup plugins, but all plugins.

DB Backup Plugin

Because backup plugins create files containing sensitive data, backup plugins need to prevent unauthorized users from downloading those files. One way to do that is block direct access to the files and then permit users to download them through the plugin. Unfortunately that can introduce a new security risk since if the download mechanism is not secured it can be abused to download files that someone shouldn’t have access to. That is the case with the plugin DB Backup, which was found to allow anyone to download arbitrary files from the website. That could for example be used to download the wp-config.php and therefore provide the login credentials for the website’s database.

The bigger problem that this highlights is what happens when a security vulnerability doesn’t get fixed, as is the case with this plugin. Right now if you go to the page for this plugin https://wordpress.org/plugins/db-backup/ you get served a search page:

This is due to the plugin being pulled from the Plugin Directory, probably due to someone notifying WordPress of the issue. This prevents anyone from downloading the plugin, but what about people that already have it installed? Unfortunately they are not given any notice that they are using a plugin with a security vulnerability. That obviously shouldn’t be the case, but despite our pushing for that to change for years WordPress still has corrected this issue. If you would like to see that change then please vote for that to happen.

XCloner – Backup and Restore

Another general problem with plugins is that the developers don’t always have much concern for security. The developer of the XCloner – Backup and Restore plugin falls in to that category, which has put the users of the plugin at risk in multiple ways.

The most recent vulnerability discovered in the plugin allowed any one who could log in to WordPress to download any backup files created by XCloner. What is of more concern is the developer’s response. The person who discovered vulnerability states that they notified the developer on November 7 and 13, the vulnerability wasn’t fixed after either of those. It also wasn’t fixed after the vulnerability was publicly disclosed on November 19. It finally got fixed within a day of us reporting the vulnerability to WordPress and the plugin being pulled pending a fix. You can see they only had to make minor changes to fix the issue, so this could have easily been fixed before if they had been interested. If we hadn’t reported the vulnerability it is quite possible the vulnerability still wouldn’t have been fixed.

This isn’t an isolated incident. Below is the list of the unsuccessful attempts a security company made to notify of them of vulnerabilities in a standalone version of XCloner:

– 6 notifications by email
– 4 notifications via contact form
– 1 notification via twitter.

The latest vulnerability is one of five that have been discovered in the plugin. The others are:

• Backup download vulnerability in versions 2.1-2.2.1
• Local file inclusion (LFI) vulnerability in versions 2.1-3.0
• Reflected cross-site scripting (XSS) vulnerability in versions 2.1-2.2.1
• Cross-site request forgery (CSRF) vulnerability in versions in 2.1-3.1.0

The developer’s lack of concern for security isn’t just for their software, seeing as their website is currently running a nearly four year old version of WordPress: