Trends in WordPress plugin security
Most of my time recently has involved working with WordPress plugin security. In a previous post I talked about some of the vulnerabilities which the dxw Security team have discovered and recently published.
One of my other responsibilities is monitoring lots of feeds for plugin security vulnerabilities reported by other people and adding them to our database. I’d like to talk about some themes we’re seeing there:
Vulnerabilities with no fix
Essential advice for staying secure is to keep all plugins updated to the latest versions. This is to ensure that have the latest security patches. But what if there is no security patch?
We frequently see vulnerabilities which are published with no fixed version available, or which have been removed from the plugin directory by the WordPress team.
This might have happened for several reasons:
- The plugin is old and has no active maintainer
- The maintainer couldn’t be contacted or stopped responding
- The maintainer didn’t take the vulnerability seriously and decided not to fix it (this does happen!)
- The researcher who discovered the vulnerability follows the ‘Full Disclosure’ process rather than responsible disclosure
Examples
No fix was available for the following vulnerabilities at the time of publishing:
The following plugins have been removed from the plugin directory because they were found to be vulnerable:
Lots of CSRF/XSS vulnerabilities
A Cross-Site Scripting vulnerability (XSS) is a weakness which allows an attacker to add HTML markup into a page or run JavaScript on it.
A cross-site request forgery vulnerability (CSRF) can be exploited by an attacker to, for example, trick a logged-in user into submitting a form on an admin screen, with data of the attacker’s choosing.
There are many different flavours of XSS, but in the worst case an attacker can automate most of the actions which an admin can do – including creating and deleting users!
This vulnerability is so common because many plugins involve a combination of a configuration form on the admin screen, with that data being displayed – either back into the form, or on the front-end.
Examples:
Lots of arbitrary file download vulnerabilities
An arbitrary file download vulnerability (a.k.a relative path traversal) is a security weakness which allows an attacker to download files which they should not normally be able to access.
The impact of this depends on how securely the server has been configured. In the very worst case, the attacker can get hold of the passwords for your server, and in the best case they can at least read the wp-config.php file, which contains login details for your WordPress database.
This sort of vulnerability is generally seen in plugins which allow files to be uploaded, or which create files which can later be downloaded.
Examples:
Proactive searching
Part of the reason that we’re seeing lots of similar vulnerabilities is that certain security researchers (Notably Nitin Venkatesh and ‘Larry W Cashdollar’) seem to be ‘mining’ for issues:
Often security vulnerabilities will be identified as a result of a penetration test or when software is which people would like to use is reviewed first. However certain classes of vulnerability have easily identifiable signatures, so it’s possible to run checks over the entire plugin directory looking for potential issues – ‘mining’. No doubt some hackers are doing the same.
MongooseWP: Plugin security alerts
MongooseWP is an email subscription service to alert website developers to security vulnerabilities in WordPress plugins. It’s powered by our vulnerability database which I’m maintaining, and describes the issues in terms that you can understand.
Making sure that you can find out if you have plugins with vulnerabilities with no fix is very important to help you stay secure, but historically this has been quite difficult. MongooseWP makes it easy.
You can sign up at www.mongoosewp.com and follow us on twitter: @mongoosewp.