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
- Magento Adds PHP 5.5 Support with Magento 18.104.22.168
- GoDaddy Distributing Software With Known Security Vulnerabilities
- GoDaddy’s Bad Response to the Drupal 7 Vulnerability
- Drupal 7.32 Usage Reached 24 Percent in Second Week
- Exploit Attempts of Drupal 7 Vulnerability Are Reminder That Hiding Software Versions in Use Isn’t a Security Measure
Web Software Updates
WordPress VersionWe are running WordPress 4.0.1 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
From dealing with lots of hacked websites one of things that we know is that detecting malicious code through automated processes isn’t very effective. The variety of code makes it difficult, but what makes it much more difficult is that often the code appears to be designed to be able to avoid detection from these automated processes (which in turn usually makes it easy for a human to spot). Unfortunately other companies dealing hacked website haven’t figured this out or are not interested in making sure the websites they deal with get fully cleaned and secured, leading to many instances where we are hired to re-clean up hacked websites after they have failed to get the job done. One of the latest examples we saw was of a web host using 6Scan on a hacked website. 6Scan describes their services as “Powerful Automated Website Protection” and they describe their ability find malicious code with the following, “You might not be aware if your site has already been compromised, but our scanner will recognize the traces hackers leave behind. You’ll see immediate results—as comprehensive as they are easy to understand—displayed on our dashboard.”. Though, from what we saw it is at least a rather poor malicious code scanning tool.
At the point we were brought what had happened is that the web host for the website would detect the website was sending spam emails, suspend it, run 6Scan on it and remove the files they detected as malicious, and then after some amount of time spam email would get sent out again and the process would start over. What a quick check of the website’s files showed was that 6Scan was not detecting much of the malicious code and that meant the hacker still had access after the code they were detecting was removed. Considering that the web host in question is touted on 6Scan’s homepage as one of their “Trusted Partners” we don’t think that they were doing something wrong in use of the tool that lead to the poor detection.
The 6Scan scan that was run right before we did our clean up detected 54 files with malicious code and missed the malicious code in 40 other files, so their detection rate was not very good at only 57 percent. What was more surprising is how easy to spot most of the files they missed were. Many of the files were stored in the wp-admin and wp-includes directories of a WordPress website. Since those two directories generally should only contain files that come with WordPress any additional files would be a red flag. In other cases malicious code was added to core WordPress files that shouldn’t be modified, which also would be a red flag. In both cases someone reviewing the results of a file comparison with a clean install of WordPress would have easily noticed the malicious code, while 6Scan’s automated processes did not.
There are a few of important takeaways from this. First, if someone says they are going to clean up a hacked website with automated tools, you are going to want to find someone else to do it. You might get lucky with a hack that is rather simple and the malicious code gets fully detected, but if you don’t then it is going to mean multiple cleanups and in some cases more problems. It also important to hire someone that will determine how the website was hacked in the first place, as doing that and fixing the vulnerability is the way to protect against the hack happening again (that was certainly important for us to fully clean up the website in this instance). The final one is that you should avoid 6Scan as they either don’t understand that the service they provide can’t do what they claim or they know that it can’t don’t care. Instead you should spend your time and money on making sure you do things that will actually protect your website from being hacked in the first place, so someone like us doesn’t have to clean up after it gets hacked.
Right now the jQuery website has a pretty obvious security problem. They are running an outdated version of WordPress:
The next version of WordPress, 3.9.2, which was released on August 6, included a number of security fixes and users were “strongly encourage you to update your sites immediately”. We are not aware of a mass exploitation of those vulnerabilities (or any others in older versions of WordPress in years), but some of the vulnerabilities fixed might be exploitable in a targeted attack. Back in WordPress 3.7, a new feature was introduced that automatically applies maintenance and security updates, like WordPress 3.9.2, so most websites that had been running WordPress 3.9.1 would have been upgraded within a day of the release of 3.9.2. That means that either the jQuery web developers disabled that feature or their server has some issues preventing the automatic updates from occurring. (Those automatic updates can be extended to plugins with our Automatic Plugin Updates plugin.)
Unfortunately the use of outdated software on the jQuery website isn’t an uncommon occurrence, when we looked at data from one of our tools earlier this year we found that 60 percent of WordPress were running a version below the then current version (we also found widespread use of outdated version of Drupal and Joomla.). A good way to keep track of the update status of websites you manage is with our Up to Date? Chrome app.
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.