Are Your Websites Up to Date?You can keep track of what versions of concrete5, Drupal, Joomla, Magento, MediaWiki, Moodle, PrestaShop, Revive Adserver, TYPO3, SPIP, WordPress, and Zen Cart are running on all of the websites you manage with our Up to Date? Chrome app.
Search This Blog
Web Software Updates
WordPress VersionWe are running WordPress 4.0 and despite what many supposed "security experts" claim letting you know what version we are running does not make us less secure.
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: WordPress
When it comes to the security of websites, what we see over and over is that the basics are not even being handled by people that shouldn’t have a problem doing it. If you are running a WordPress website then part of Security 101 is keeping WordPress up to date, as it prevents your website from being hacked due to a known vulnerability in an older version of WordPress. Unfortunately, that isn’t being done in many cases as can been seen in the fact that only 40 percent of WordPress websites were running the latest series of WordPress in the data set we looked at in March.
You would think that providing better management tools would help this situation, though the example of one of the providers of such a tool would say otherwise. ManageWP describes its services as providing you the ability to “Manage all your WordPress sites from one place – including updates, backups, security and more.” You would certainly expect they would be keeping the WordPress installation powering their website up to date, but they’re not:
ManageWP’s failure to take handle a basic security task is sharp contrast to their claims of security. For example, they claim
Securing ManageWP and the sites we interact with has always been our highest priority. We use state-of-the-art encryption and security standards that go above and beyond what WordPress, itself, offers, to ensure that your sites are protected.
On another page they make a series of claims about their security:
How ManageWP Is Secure
- We have a full-time security specialist
- We regularly perform penetration testing
- No credit card information stored
- No WordPress passwords stored
- OpenSSL encryption
- ManageWP is built on top of WordPress
- Account password encryption
- White hat reward program
If you are security specialist who fails to make sure such a basic security measure is taken then you probably should find another profession.
Two years ago we created a plugin that list any installed WordPress plugins that have been removed from the WordPress.org Plugin Directory. There are a number of reasons that plugins are removed, the most important being when it has a security vulnerability. For that reason WordPress should alert when a plugin has been removed, until that occurs our plugin can be used to check if any installed plugins have been removed.
Recently it was suggested that the plugin also list plugins that have not been updated by their developers for over two years as well. On the Plugin Directory website, plugins that have not been updated in over two years have a banner at the top of the page that states “This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”. Even plugins that have not needed any changes should have been updated periodically to indicate that they are compatible with new versions of WordPress. For the reasons listed in the banner it would be helpful to those already running the plugin to be aware the situation as well.
One of things we looked at before deciding to add a listing of plugins that had not been updated in over two years was how many plugins fall in to this category. We first checked a small sample and found that many of the plugins fell in this category. When we looked at all of the plugins we found that was still the case. As of yesterday a total of 12,703 plugins had not been updated in over two years. That is 30 percent of all the plugins that have entries in the Subversion Repository for the Plugin Directory. Not all plugin entries have actually been used, so the percentage of plugins that people could being using is probably higher.
Below we have charted what year these plugins were last updated. The number for 2012 is lower as plugins last updated after March 9 of 2012 would still under two years out of date.
Today we released a new version of the plugin that lists installed plugins that have not been updated in over two years. If you want to check if you are using any plugins that have not been updated in over two years install our No Longer in Directory plugin (available through the Add new page in the WordPress admin area) and then in the admin area go to the plugin’s page in the Plugins menu. The page will list any installed plugins that have been removed for the directory first and then any plugins that have not been updated in over two years.
In WordPress 3.7 a new feature was introduced that causes WordPress to automatically apply minor updates to WordPress (for example, going from 3.7 to 3.7.1). The underlying system that handles that also supports doing automatic updates for major updates, plugin updates, and theme updates as well. The reason for limiting it to minor updates by default makes a lot of sense, because there is a process in place for minor updates to make sure there is a little chance as possible for something going wrong. The lead developer of WordPress describes the process as:
Background updates are incredibly, incredibly safe. Sites already running WordPress 3.7 have attempted more than 110,000 updates without a single critical failure, thanks to a number of verification steps that have made updates that much more reliable. A background update for a minor or security release (which is all they are enabled for, by default) means downloading and copying over just a few files. We’ve gotten really good at that. We’ve also spent years honing our craft of shipping stable and targeted fixes in minor releases — we don’t indiscriminately backport bug fixes. They must be serious bugs, and fixes go through additional levels of review, including at least two lead developers. And, we have the ability to roll out an automatic update over a period of hours or days. For 3.7.1, we’ll likely see how a few hours of user-initiated updates go before telling about 1% of sites to update, then steadily increase that percentage.
Depending on the situation of an individual website enabling other updates to occur automatically as well makes sense. Keeping plugins up to date is an important as it prevents the website from being exploited due to a vulnerability in an outdated version of the plugin. At this point we haven’t seen a vulnerability in WordPress that is likely to lead to the average website being hacked in years, but with plugins that isn’t the case. So keeping plugins up to date is at least as important as keeping WordPress up to date. If you use plugins that have a good track record of not breaking after an update (we haven’t had any issues with the plugins we use on our blogs over many years) then it can make sense to turn on automatic updates for plugins.
Turning on automatic plugin updates can be accomplished by adding the following line to functions.php of your current theme:
add_filter( 'auto_update_plugin', '__return_true' );
If you prefer not to modify your theme you have another option with our new plugin, Automatic Plugin Updates, which enables automatic plugin updates along with providing a couple of additional features. The lesser additional feature is that it turns on email notifications for those automatic plugin updates (this can be disabled). The bigger feature is that it enables disabling automatic updates for selected plugins. This can be useful if you have modified plugins in use or if you have plugins that you are more concerned that an update could cause problems with the website. While you can roll your own code to do this as well, with our plugin you don’t have to worry about changes being made in the process of handling excluding plugin from automatic updates. As of the current beta of WordPress 3.9 the process has changed from previous versions, causing code written for the old versions to not stop the automatic update from happening, and our plugin is already ready to handle that if the change remains in the production release of 3.9. Both of the additional features can be accessed on the plugin’s setting page:
Last month we spotlighted at the fact that 31 percent of Joomla websites checked with our Joomla Version Check tool during January were still running Joomla 1.5, for which supported ended September 2012. This month we decided to take a look at if websites that were running a supported Joomla series, either 2.5.x or 3.x, were being kept up to date based on last month’s data from the tool. Unlike websites still running Joomla 1.5 that need a more complicated migration to be brought up to a supported version, the upgrade process for websites running 2.5.x or 3.x is relatively simple. Keeping software running on a website up to date is a basic security measure, so if websites are not being kept up to date when it is relatively easy it shows that website security is in bad shape.
Joomla 2.5.18 was released during the month so Joomla 2.5.x websites would have been up to date if they running 2.5.17 or 2.5.18. Unfortunately 58 percent of the Joomla 2.5 websites were detected as running older versions (for some installations the tool only could tell they were using Joomla 2.5 and those listed as 2.5.x in the chart).
54 percent of the Joomla 2.5 websites checked contain known security vulnerabilities, as they are running versions below 2.5.15, the most recent release with security fixes.
For Joomla 3.x the results are slightly better as only 48 percent were detected running versions prior 3.2.1 or 3.2.2 (3.2.2 was release during the month alongside 2.5.18).
41 percent of the Joomla 3.x websites checked contain known security vulnerabilities, as they are running versions below 3.1.6, the most recent release with security fixes.
Outdated WordPress and MediaWiki Versions Heavily Used Too
The results for the WordPress and MediaWiki websites checked during February using our tools for those pieces software were also not good.
For WordPress, 60 percent of the websites checked were running a version below the current series, 3.8.
For MediaWiki, 47 percent of the websites checked were running a series no longer supported. The currently supported versions are 1.19.x, 1.21.x, and 1.22.x.
When it comes the security of WordPress there are unfortunately a lot of people out there spreading bad information. We were on the receiving end of one of these in the past few days. We received an email from xpedientdigitalmedia.com trying to get us to promote an infographic on WordPress security from their website WPTemplate.com. You can tell how much they care about security when you see this:Keeping WordPress up to date is one the basic security measures that you need to doing to make sure your website is secure. If you are website about WordPress you have no excuse for not keeping it up to date, especially when the release notice for the new version, that was released last month, warns:
This is a security release for all previous versions and we strongly encourage you to update your sites immediately.
Amazingly their security advice includes making sure to keep WordPress up to date, but they don’t follow their own advice and you shouldn’t either.
It really isn’t worth going through all of the bad information they managed to pack in to their infographic, but here are a couple of really bad pieces of advice:
One of their security recommendations is “Do not install WordPress themes that are available for free.”. Something being free doesn’t make it insecure and something costing money doesn’t make it secure. WordPress is free, would that make it insecure? Do they think that the free themes on the WordPress website are insecure?
The second one is doozy. They claim that one of the “most common ways that result in the site being hacked” is “approving comments that are non relevant”. This isn’t even a way to be hacked, much less a common one. If adding a comment could lead to your website being hacked that would be a huge security vulnerability and the solution wouldn’t be to not approve irrelevant comments. What would stop someone from exploiting the vulnerability with a relevant comment instead?
Unfortunately their bad advice isn’t just on their website. A lot of websites have taken up their offer to spread the thing, including noupe, WP Daily Themes, and WP Daily. Incidentally, WP Daily titled their post on WordPress 3.5.2 UH OH. WP 3.5.2 SECURITY UPDATE. DO THIS NOW. and yet they didn’t:
A Step To Actually Improve WordPress Security
Currently if a plugin in the WordPress.org Plugin Directory is found to have a security vulnerability and it is not fixed the plugin is removed from the Plugin Directory. Unfortunately anyone who is already using the plugin is not provided any alert that the plugin is known to be insecure. We have been pushing for this situation to be handled properly for some time. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin.
In yet another sad sign of how bad internet security is these days, a security company named Checkmarx released findings on security vulnerabilities in WordPress plugins (PDF) while running their own website on an outdated an insecure version of WordPress:
In their report one of their recommendations is keeping plugins up to date:
3. Ensure all your plugins are up to date
Do not ignore all those notification emails of an upgraded plugin version. You can even use a
purposeful WordPress plugin that notifies admins on updates to other installed plugins.
There are also third party services which provide a plugin update notification and
How is it that security companies that seem to understand basic security practices fail to take them with their own websites?
Also, on Checkmarx’s website they tout they are a member of the Open Web Application Security Project (OWASP), which we recently noted also runs their website on outdated and insecure software.
Another Security Recommendation for WordPress Plugins
Checkmarx’s report is missing one important step that should be taken related to security of WordPress plugins. Currently if a plugin in the WordPress.org Plugin Directory is found to have a security vulnerability and it is not fixed the plugin is removed from the Plugin Directory. Unfortunately anyone who is already using the plugin is not provided any alert that the plugin is known to be insecure. We have been pushing for this situation to be handled properly for some time. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin.
We have had a number of people contact us about having issues gaining access to the login page in WordPress recently and we wanted to pass along information that affected websites should be getting told by their web hosts as well by now. There has recently massive attempt to brute force the login for WordPress based websites. Hostgator describes it as being a highly-distributed and global attack. While hackers have been attempting to gain access to website, whether using WordPress or a variety of other software, that use weak passwords for years, the big issue here is that the massive size of attempts is causing high load on servers and that has caused web hosts to block access to the WordPress login page while attempting to deal with this. If your website is hosted on a server shared with websites being targeted it can impact your websites even if you are not targeted.
Hostgator has reported seeing over “90,000 IP addresses involved in this attack”, which means that a web host cannot simple block a few IP address to stop the attempts. That also provides a reminder that limiting login attempts by blocking IP addresses after several failed attempts has a serious limitation as security feature when massive amount of IP address are available for an attack.
While security of the login process can be improved by restricting login access to certain IP addresses or using multi-factor authentication, websites can prevent an un-targeted login attack by making sure only strong passwords are used.
As part of our continued focus on the problems related to the security of WordPress plugins, last month we compiled some statistics on plugin vulnerabilities found during the second quarter of 2012. As they might be useful to others we wanted to share them.
We used Secunia’s advisories for our data set as their advisories include vulnerabilities discovered by the developers of the plugins and those discovered by others, which provides a good mix of data. Secunia reviews the reported vulnerabilities so their advisories do not include false reports of vulnerabilities that we find in other sources of vulnerability data.
It is important to keep in mind that the vulnerabilities found are not necessarily representative of what vulnerabilities remain in plugins. A lot of what determines what vulnerabilities are found is what kind people happened to look for or find.
A few more quick notes on the data: we have excluded a plugin that was not ever available in the WordPress.org plugin directory, the data was generated on July 16, and the numbers in the charts do not correlate with each other as some plugins had multiple vulnerabilities.
This chart shows the breakdown of the types of vulnerabilities found in the plugins:
The largest percentage were reflective cross-site scripting (XSS) vulnerabilities, which, while serious, are not a kind of that are likely to be used in an targeted hack of a website so they are not a major concern. The second largest group of vulnerabilities was unrestricted file upload vulnerabilities. This type of vulnerability can be easily exploited to place backdoor script on a website, which a hacker can then use to do pretty much anything on the website. Some may be familiar with the TimThumb vulnerability, which was this type of vulnerability. That so many unrestricted file upload vulnerabilities were found is a good reminder of need for plugins with file upload capabilities to be carefully scrutinized to insure that plugins with this type of vulnerability are not available in the plugin directory.
This chart shows the number of plugins with vulnerabilities that have been fixed and not fixed:
That over a quarter of the plugins have not fixed is troubling, but even worse is the types of vulnerabilities in those plugins:
A third of those vulnerabilities are unrestricted file uploads. Not surprisingly due to the ease of exploitation and power granted, we have been seeing attempts to exploit the plugins found to have those vulnerabilities.
There is good news, plugins with unresolved security vulnerabilities are getting removed from the WordPress.org plugin directory, which had not always happened in the past. That is partly due to our making sure that plugins with unresolved security vulnerabilities are reported to the people maintaining the plugin directory, so that they get properly handled. Removing the plugins does not help when the plugin is already installed and that is why WordPress needs to provide alerts for removed plugins with unresolved security vulnerabilities. In the mean time you can use our plugin No Longer in Directory to check if you are using plugins that have been removed. If a removed plugin has a Secunia advisory that will be linked to in the plugin’s report.
SC Magazine Australia’s recent article “50,000 sites compromised in sustained attack” incorrectly claims that WordPress was associated with a past malware campaign and tries to link general security issues to WordPress. As we continue to see the harmful impact of the bad security information, particularly when it involves WordPress, we want to clear up some of the claims in the article and fill in the critical missing information on actually protecting against security vulnerabilities in WordPress plugins.
The most blatant error in the article comes near the end of the article where it is stated that “Vulnerabilities in WordPress plugins have been long understood. Last year, large malware campaigns including the LizaMoon attacks exploited those holes” The LizaMoon attack was part of a frequently hyped multiyear campaign that targets ASP and ColdFusion based websites that have fairly basic SQL injection vulnerabilities. It had nothing to do with WordPress or any WordPress plugins. The link they provide about the LizaMoon attack makes no mention of WordPress and we are not aware of any source that ever claimed that it had a connection with WordPress. The rest of the article isn’t much better. Earlier it says:
Attackers targeted holes in a string of plug-ins for blogging software — such as WordPress— including timthumb, uploadify and phpmyadmin.
None of those things are themselves plugins for WordPress or other blogging software, nor is blogging software the only thing targeted by hackers. We probably deal with as many websites that are hacked due to outdated Joomla extensions as WordPress plugins, so there doesn’t appear to be a good reason to spotlight WordPress for special attention as the article did.
phpMyAdmin is web based administration tool for MySQL database. Several years ago there was WordPress plugin that added phpMyAdmin to WordPress which contained an exploitable vulnerability, but at this point it isn’t a major target of hackers as the plugin was removed back then. phpMyAdmin itself is frequently probed for on our website, so that is likely why phpMyAdmin would be listed as being targeted. That doesn’t explain why it be listed as a being a plugin for WordPress or other blogging software, though.
The TimThumb and Uploadify libraries are included in some WordPress plugins and those have been targeted (though since we last discussed recent serious security vulnerabilities in WordPress plugins we have seen attackers expand from targeting just the recent Uploadify based vulnerabilities to the other upload vulnerabilities recently identified).
Later in the article it claims then claims that Plesk is being targeted (web hosts are not always good about keeping that up to date), so it appears somebody involved in the article just threw together an incomplete list of software that gets targeted without any specific relation to the malware mentioned, while singling out WordPress.
Another worrisome aspect of the article is that it cites a “malware researcher” from Sucuri, the company that has a malware scanner that doesn’t actually bother to scan a website for malware before falsely flagging it.
Protecting Against WordPress Plugin Vulnerabilities
What the article lacks, as stories about hacks often do, is any information on protecting websites from the vulnerabilities they are warning about. For WordPress plugin vulnerabilities, you would hope the answer is to update your plugins, as by the time a vulnerability is being exploited it should have already been patched. Unfortunately, in an analysis of WordPress plugin vulnerabilities in the second quarter of 2012, that we just did, we found that a fourth of the plugins had not been fixed (we will have a post with the full details of the analysis in the next few days). What makes this even worse is that most of the vulnerabilities in those plugins were serious vulnerabilities that are the most likely to lead to website being hacked. So what happens when plugins are not fixed?
When the maintainers of the WordPress.org Plugin Directory are made of aware of a security vulnerability in a plugin they will remove the plugin from the directory until it is fixed. Unfortunately, when we started looking into this earlier this year we found that many plugins had never been reported and had remained in the directory including one in which hackers were attempting to exploit at the time. Since then we have been making sure that any plugins with reports of unresolved security vulnerabilities are reported and appropriate action is taken (we have also been warning them about security issues that impact plugins, including notifying them about the recent Zend Framework vulnerability that impacted several plugins). While removing the plugins until they are fixed prevents any additional websites from being exposed to the vulnerabilities, websites already using the plugins don’t receive any warning and remain vulnerable as we have discussed before. The process of adding alert in WordPress when plugins that have been removed from the Plugin Directory are installed has begun and you can help to make sure it is given a high priority by voting for implementing that change. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we released update for the plugin, with new vulnerabilities, at the beginning of the week).
Currently when a WordPress plugin is reported to have a security vulnerability it is removed from the WordPress.org Plugin Directory until the vulnerability has been resolved, but no warning is provided to anyone who already installed it. While many plugins are promptly fixed, there are quite a few that remain vulnerable for a long time or are never fixed. We think that WordPress should alert on the Installed Plugins page in WordPress if an installed plugin has been removed from the directory and provide at least a general reason it has been removed, as many are removed for reasons other than security vulnerabilities, so that appropriate action can be taken by admins. If you would also like to see that happen you can help by voting for our idea on the Ideas section of WordPress.org. To vote you will first need to create a WordPress.org Forum account (or log in if you already have account) and then you can rate the idea by clicking on one of the stars under the heading Rate This (click the right most star for the highest rating for the idea). You can also add your own comments on how the issue should be handled.
Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we just released our beginning of the month update for the plugin).
While we are discussing the issue of plugin vulnerabilities, we should say that since our last post about this we have been seeing that plugins with Secunia advisories for outstanding issues are being promptly removed from the Plugin Directory until those are resolved. This is great improvement from earlier this year when we found that vulnerable plugins had remained in the directory for years. With that happening we are now looking to make sure that they maintainers of the Plugin Directory are aware of any vulnerabilities which haven’t received Secunia advisories. We just reported a plugin that was found to have a fairly serious information disclosure vulnerability to them and they promptly took action (we alerted the developer of the plugin a week ago and had not received any response). For anyone that finds a vulnerability in a plugin available in the Plugin Directory and is unable to get a response from the developer, you can find directions for contacting the Plugin Directory here.