Applying the Lessons of Recent WordPress Defacements to the Handling of Plugins on Your Website
Recently quite a few WordPress websites (though not as many as the inflated claims by Wordfence and other security companies would have you believe) have been defaced due in large part to improper handling of security by the webmasters of those websites. While an exploitable vulnerability existed in 4.7.0 and 4.7.1, most websites running WordPress 4.7 at the time were protected well before exploitation began due to the fact that the websites were promptly updated to 4.7.2 through WordPress’ automatic background updates, which have been in WordPress since version 3.7. The websites defaced were either ones were those automatic updates don’t work (which from our experience isn’t often) or where people had intentionally disabled them and then failed to promptly manually update.
The lessons from that when it comes to WordPress itself is that you should make sure the automatic background updates are working, not disable them, and that minor updates are the ones that should be applied promptly. Considering that when it comes to a WordPress website being hacked, this is the first time in years that there has been a vulnerability in WordPress has been the source of many hacked websites and plugins on the other hand are a source in a fairly continually basis, how can what happened here be used to take better care when it comes to plugins.
Keeping Plugins Up to Date
The first lesson is keeping your software up to date is critical to keeping the website secure, as vulnerabilities will exists in software for the foreseeable future and new versions will need to be released when they are found. Unless you are going to constantly monitor your website, your best option for keeping plugins up to date is to have the updates applied automatically, like the update to WordPress 4.7.2 would normally have happened. WordPress actually has the ability to do that already, as the automatic background updates functionality has the ability to do all updates automatically, including major WordPress, plugin, theme, translation updates. By default those are all disabled, leaving only minor WordPress updates to happen automatically. One option for turning them on is to use our Automatic Plugin Updates plugin, which enables the functionality for plugins updates, along with the ability to exclude certain plugins from automatically happening and control whether an email is sent out when the automatic update occurs.
You Won’t Always Know About Security Updates
One of the complaints we have seen with the handling the vulnerability WordPress is not enough notice was given. That doesn’t really square with what happened. While this particular vulnerability was not disclosed at the time the new version was released to limit the damage that could be done, it was quite clear that 4.7.2 was security update. The announcement post was titled “WordPress 4.7.2 Security Release” and the post starts out:
WordPress 4.7.2 is now available. This is a security release for all previous versions and we strongly encourage you to update your sites immediately.
The announcement originally went on to describe the three other vulnerabilities that were fixed in the version (no non-security fixes were included).
When it comes to plugin updates that fix security vulnerabilities there is good chance that you won’t know that is the updates includes a security fix. Back in December 2014 we looked at the publicly disclosed vulnerabilities that we had in our data set of vulnerabilities at the time and we found that in nearly 20 percent of the time there was no mention made that a security fix was included in the changelog entries for the version that fixed the vulnerability. The severity of vulnerabilities varies widely so the percentage of fixes that go unmentioned alone doesn’t tell the whole story. Take one of the security updates, it involved a vulnerability that was already being exploited prior to a version being released to fix it. The changelog for the version that fixed it read:
The possibility of manipulating custom themes has been removed by request of administration of wordpress.org plugins repository.
Would anyone guess that referred to such a serious vulnerability?
Get Warned About Known Vulnerable Plugins
In the case of the WordPress vulnerability it was quickly fixed after being reported, but our experience of collecting data on numerous plugin vulnerabilities and discovering many of them (including many that are already being exploited), is that many of them are not promptly fixed or ever fixed. As long as WordPress refuses to alert people when they are using plugins they know to be vulnerable, that creates an obvious risk even if you keep your plugins update.
We provide two options to help protect you against such a situation. First is the companion plugin for our service includes in data on vulnerabilities in plugins that we see hackers targeting. Second, by using our service you get access to more complete data, as well support on how best to deal with such a situation. Maybe you can safely ignore a minor vulnerability, maybe we can provide you with a temporary fix until the plugin is properly fixed, or maybe the plugin is completely insecure and shouldn’t be used. Whatever is the case, we will work with you to make the decision for your website. The service also allows you to participate in deciding what plugins will get security reviews done by us, so that you can have better assurance that the plugin you use are properly secured.
For those where our service isn’t in your budget you can get expanded data beyond what is available for free with our plugin by pairing that with a plugin that uses data from the WPScan Vulnerability Database (do a search on the Plugin Directory for “wpscan” to find those). We strongly recommend against relying on their data along since they are missing many vulnerabilities included in our plugin’s data. Not surprisingly considering that they fail to include data that they could easily copy from our plugin, there are several major issues with WPScan data, which makes it a bad option if you can afford our service.
Remove Unused Plugins
Some vulnerabilities are exploitable even if the plugin is deactivated, so if you are no longer using a plugin the best thing you can do is to remove it, as you remove any risk that it introduces.
Security Plugins Won’t Do Much to Protect You
While security plugins makes all sorts of promises about the ability to protect your website, the reality from our testing them against real vulnerabilities in plugins is that they provide little to no protection against vulnerabilities in other plugins. Take a vulnerability disclosed back in December in the plugin Delete All Comments, which had 30,000+ active installs at the time, that was discovered when it was exploited on a website and still hasn’t been fixed. We found that none of the 15 plugins, including all of the most popular ones, protected against exploitation in our test.
The developer of one of the most popular security plugins, BulletProof Security, recently told us that “it is outside of the scope or intended purpose for any security plugins” to protect against vulnerabilities in other plugins.
I read that the automatic-update function of WordPress doesn’t use certificates and even not evaluates the the origin of the source.
Also read this: https://www.wordfence.com/blog/2016/11/hacking-27-web-via-wordpress-auto-update/
I do not feel comfortable with this autoupdate-function.
All updates are done over HTTPS, which means there is a certificate and evaluation of the origin of the source done. In any case, how do you think that doing those updates manually would be more secure since doing it that way would use the same infrastructure as automatic updates?