When it comes to open source software one of the ideas is that by having the source code available then the software is more secure since you are not relying on only the developer of the software to have reviewed the code. So how does that match up with the security of WordPress plugins? A recent security situation we ran into with the plugin WP Editor seems to indicate that it isn’t working that way.

If people were regularly looking over the security of WordPress plugins, WP Editor would seem to be something that would have been looked at by now. It has 100,000+ active installs according to wordpress.org, which puts in the top 200 plugins (out of over 44,000 plugin currently in the Plugin Directory). The plugin replaces WordPress regular editor for plugins and theme files in the admin area, which should flag it as something that should be reviewed since a security issue with its the ability to modify PHP files could lead to website being hacked. Its functionality also seems to be something that would be used by more advanced users, which you would think would increase the chances it would be reviewed for security issues.

The description of the plugin mentions it use of AJAX, “Using Asynchronous Javascript and XML (AJAX) to retrieve files and folders, WP Editor sets a new standard for speed and reliability in a web-based editing atmosphere.”, which as we will get to in a moment, is something that increases chances of a security issue and would seem to be something that should have also flagged this plugin as needing a good review.

Two more items that would heighten our concern about a plugin’s potential for security risk is that it contains its ability to view the contents of files and upload them. We frequently see attempts to exploit vulnerabilities that allow the viewing of files, using them to try see the contents of the wp-confg.php files, which contains the database credentials for the website. Vulnerabilities in file upload capabilities are probably the most exploited type of vulnerability and when they are unrestricted the question isn’t a question of whether a disclosed vulnerability will be exploited, but when.

In the case of this plugin, it looks like the only person that bothered to take a look at it before us was someone interested in exploiting vulnerabilities.

Easy To Find Vulnerabilities

A couple of weeks ago we started getting requests on one our websites for a file in the WP Editor plugin, /wp-content/plugins/wp-editor/js/wpeditor.js. Seeing as we didn’t have the plugin installed, there wouldn’t normally be any requests for that file. The requests therefore would be from someone looking to see if the plugin was installed. It is possible that could be due to someone doing a survey of usage of the plugin, but it would usually due to someone looking for usage of a plugin to try to exploit a vulnerability in the plugin. In this case the first request came along side of a request for a file for another plugin that had a recently disclosed vulnerability, so that seemed to be pretty good indication someone was looking to exploit a vulnerability in WP Editor.

Since we didn’t have the plugin installed we couldn’t see what the hacker would try to exploit in the plugin if the JavaScript file had existed. We then checked our data set for any vulnerabilities we were already aware had existed in the plugin and found none.  Next we looked for any public reports of vulnerabilities in the plugin and found none. Finally we checked if there was any indication that the plugin had any recent security fixes, which a hacker could have reverse engineered to exploit, and found that the plugin hadn’t been updated in 8 months.

After that we started looking over the plugin to see if we could find any security issues that might interest a hacker. In a matter of minutes we had found some serious issues that could be something a hacker would be interested in exploiting. We certainly don’t have some special expertise, so if we could find them someone else with a little security expertise could have found them if they had ever looked at the plugin.

The issues involved a common problem we see with WordPress plugins, plugin developers use AJAX functions without properly restricting them. By default AJAX functions are available to all logged in users, so in the case of this plugin, functions that were only intended to be sued by Administrator level users were accessible to Subscriber level users and above. Those functions included modifying existing files, uploading new files, and viewing the existing contents of files. All of these are things that hackers are known to exploit. Since most WordPress websites are accessible by one user account or trusted user that obviously limits the threat of this, but with 100,000+ active installs there are bound to be some that allow open user registration would have be at high risk of being exploited.

We later were able to track what looks to be the source of the exploit attempts and the vulnerabilities we noticed were those that there would have been exploit attempts.

Protecting Yourself Against Plugin Vulnerabilities

That doesn’t paint the best picture of the security of WordPress plugins. So what can you do about it?

You could hire someone to do a security review of all of the plugins you use. That would give you the best assurance of the security of your plugins, but it isn’t necessarily going to be cheap (since plugins keep changing, you would need to keep having that done to be best protected).

Another option is to use our service, as we will make sure that you are quickly notified if any vulnerabilities in plugins you use become public. For vulnerabilities like this where it wasn’t fixed at the point we became aware of it, we could have helped to deal with the risk until a fix was released (which in this case only occurred because we notified the appropriate parties).