Using Insecure WordPress Plugins?Does your WordPress blog contain known insecure plugins? Check Now
Search This Blog
Web Software Updates
WordPress VersionWe are running WordPress 3.7.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: Website Security
When it comes to keeping your website secure your web host should be the least of your worries. These are technology companies, sometimes rather large, whose focus is on websites. You would think that they would be better at handling website security than anyone other security professionals. Unfortunately we often find that they are not. As just one example, last year we discussed the fact that Media Temple was incorrectly blaming a hack of websites hosted by them on their customers running outdated software on their websites, while they themselves were running outdated software on their website. Over a year later they are still are not bothering to take the basic step of keeping software running on their website up to date:
Trying to access the security of web hosts is difficult because much of the information needed to do that assessment is only available to them. There are some things that you can check on and one of those is whether they are keeping the version of PHP on the server hosting your website up to date. If you are using WordPress, Joomla, Drupal, or a lot of other web software then you are using PHP and it is important to keep that up to date, as a hacked website we cleaned up this week shows.
One of the basic steps of cleaning up a hacked website is determining how it was hacked and then fixing the vulnerability so that the website doesn’t get hacked again (unfortunately, many companies that clean up hacked websites cut corners and don’t do this). In reviewing the log files for the website in question we traced the original exploitation to this line in the website’s access log:
188.8.131.52 – - [16/Apr/2013:19:18:32 -0400] “POST /?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1″ 200 68
What that shows is that a vulnerability in PHP versions prior to 5.3.13 and 5.4.3 was attempting to be exploited. Unfortunately the website in question was running an older vulnerable version of PHP and was configured in a way that made it susceptible to the vulnerability. If PHP had been kept up to date the website would not have been hacked.
The PHP developers fairly regularly release new versions that fix security vulnerabilities in the software. The most recent releases with security fixes were versions 5.3.23 and 5.4.13, released in March. Unfortunately, we often find that our client’s web hosts are not keeping PHP up to date. If your web host isn’t keeping PHP updated you probably should move to a web host that takes such basic security seriously.
If you are wondering what version of PHP your web host is using for your website there are a number of ways to find that out. The least technical way to do that is to contact their customer support and ask them what version of PHP in use. It would also be good to ask them what their upgrade policy is for PHP and other software powering the web server, to make sure that they properly handling that. You can sometimes find the PHP version in use in the control panel for your website or the administrative area of the website. You can also use a tool we have created that allows you to check the version of various software running the server your website is on.
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.
Two weeks ago we posted about FatCow was running an over six years out of date version of phpMyAdmin on their servers. In the post we mentioned that was the most out of date software we had seen in a long time, but that dubious distinction has now been taken by 1&1 and the nearly sevens years out of date version of phpMyAdmin they use. They are running phpMyAdmin 2.6.4-pl3, which was released on October 22, 2005. The subsequent version, a security update, was released on November 15, 2005.
1&1 tells their customers it is important to keep software up to date to avoid being hacked:
One way to avoid attacks, is to make sure to keep your programs
and scripts up-to-date. Check regularly for security warnings and
make sure to install security patches as they become available.
They obviously don’t listen to their own advice, but they do claim that they do:
1&1 system administrators work hard to make sure that our 1&1 servers are protected from known vulnerabilities by keeping all programs and services up-to-date with.
phpMyAdmin provides a page that provides a listing of all security announcements for the software (something that other software developers should also be providing). In 2005, there were three serious security vulnerabilities found that probably impact the version of phpMyAdmin 1&1 is running. The version probably contains most, if not all, of the 16 serious severity security issues and 1 considered “quite dangerous” fixed in 2006 and 2007, that we counted that impact in the version used FatCow. And the version probably contains more vulnerabilities that were fixed in later years.
One of the most basic measures for keeping websites secure is to keep software running the website up to date, this is something that web hosts know and tell their customers. Unfortunately, many web host don’t seem to feel that they need to heed their own advice and run out of date software on their servers. This put their clients at risk of being hacked though exploitation of a known vulnerability in that software. Their use of outdated software also a warning sign that they may not be handling the rest of the security properly as well.
When we do work on a client’s website we do a check of what version of some common software (PHP, MySQL, phpMyAdmin, etc.) is running of the server. This is partly so that we can see how well web hosts are doing at keeping that software up date and also so that we can alert the clients when severely out of date software is in use. We continue to see that in many cases web hosts’ servers are running out of date versions of that common software, with known security vulnerabilities. The good news is that for most part we are seeing that the software is less out of date then it has been in the past. That made something we saw while checking a FatCow server in the past few days stick out. The server was using phpMyAdmin 184.108.40.206. That version was released on March 8 of 2006 and the next version, 220.127.116.11, was released eight days later. If over six years out of date hasn’t been the most out of date we have ever come across, it at least the most out of date we have seen in a long time.
phpMyAdmin provides a page that provides a listing of all security announcements for the software (something that other software developers should also be providing). Based on just the announcements for 2006 and 2007, the version of phpMyAdmin FatCow is using probably contains 16 serious severity security issues and 1 considered “quite dangerous”.
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.
Yesterday, Magento released an announcement on a serious security vulnerability in previous versions of Magento that “potentially allows an attacker to read any file on the web server” that “might include password files, configuration files, and possibly even databases if they are stored on the same machine as the Magento web server”. The vulnerability is due to a vulnerability in the XmlRpc component of the Zend Framework, which was announced last week. The details of the vulnerability can be found in the advisory by SEC Consult.
Magento has provided several solutions for protecting against this vulnerability. There is a workaround, patch files for older version of Magento, and a new release, 18.104.22.168, which is secured against the vulnerability. The workaround and patch files will resolve this issue for Magneto installations still running on outdated versions, but we would recommend, as always, that you upgrade to the latest version of software you run (the previous release, 22.214.171.124, fixed “some potential security vulnerabilities” according to Magento).
If you use any software that has the Zend Framework you should check to for an update or announcement from the developers on the status of the vulnerability in the software. Piwik announced last week that the current version of Piwik is not vulnerable as “Piwik neither uses nor includes the XmlRpc component from Zend Framework”. OpenX does contain the XmlRpc component and uses it, we didn’t check if their use is vulnerable but we did inform them of the vulnerability (we would strongly recommend strongly recommend against using anything from OpenX as they continue to have an atrocious security record). There are several WordPress plugins which contain the vulnerable component and we have informed the WordPress.org Plugin Directory maintainers of the vulnerability so they can take appropriate action.
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.
Over the past few weeks numerous serious security vulnerabilities have been found in WordPress plugins. Many of the vulnerabilities allow arbitrary file uploads, which can be used to add a backdoor script website to a website and allow an attacker remote access to the website. When websites are hacked using an exploit of software running on the website this is often the type of vulnerability that is utilized. Other vulnerabilities that have been recently discovered include file upload vulnerabilities limited to certain file extensions, remote file disclosure (so the contents of the wp-config.php or other sensitive file could be displayed), an SQL injection, and cross-site scripting (XSS) vulnerabilities. The details of many of the vulnerabilities can be found in Secunia’s advisories for them.
So far we have had several attempts on our website to exploit some of these plugins that had vulnerabilities related to Uploadify, which appears to have been first publicly disclosed on April 5. We have yet to see exploit attempts for any of the other plugins.
After spotting the attempts related to Uploadify, we started looking to the vulnerability and if the plugins had been fixed yet. During that process we noticed that some of those plugins were among a large number of plugins with unresolved vulnerabilities listed in recent Secunia Advisories. We then informed WordPress.org Plugin Directory maintainers of the plugins with those unresolved security vulnerabilities. We also informed them, as we have in the past, that they can that they can monitor Secunia Advisories for WordPress plugins, so that they are not reliant on issue being reported to them so that they can quickly respond.
The good news to report is that many of the plugins have been quickly updated to fix the vulnerabilities and the people in running the WordPress.org Plugin Directory have been fairly proactively in removing plugins from the directory until they have been fixed (though there are still some of the plugins we have notified them that still remain in the directory despite their vulnerabilities). The bad news is that some of the plugins are unlikely to be fixed and no warning is displayed in WordPress when these vulnerable plugins are installed. Until the time that WordPress handles that properly, which we have previously discussed the need to do, our No Longer in Directory plugin provides an interim solution. On the plugin’s page in WordPress it will identify any installed plugins that have been removed from the Plugin Directory and provides links to Secunia Advisories when available. We have just put out an update with a refreshed list of plugins removed from the WordPress.org Plugin Directory and added links to Secunia Advisories for 19 of the recent vulnerabilities. The Secunia Advisories include workarounds for the vulnerabilities, so that people running those plugins will be aware of a possible temporary fix for the vulnerability until it is hopefully properly fixed.
Last week we mentioned that we had found that a WordPress plugin that had a security vulnerability in its current version, that had recently been attempted to be exploited, had remained in the WordPress.org Plugin Directory for six months after it was publicly disclosed. That plugin had received an advisory from Secunia and we have reviewed the rest of Secunia’s WordPress advisories to check for any other plugins in the directory that also had unresolved security vulnerabilities. We identified 24 more plugins that have vulnerabilities in their current versions and had remained in the Plugin Directory since the advisory was released. We have reported those plugins to WordPress and they have been removed from the Plugin Directory. If and when the vulnerabilities are fixed they should return to the directory.
You can check if your WordPress installation is running any plugins that have been removed from the Plugin Directory, whether for security issues or other issues, with our plugin No Longer in Directory. We have just updated it with the plugins that we reported to WordPress and have added links to Secunia Advisories for any of the plugins that have received them.
The oldest Secunia advisory for a plugin with an unresolved issue that had remained in the Plugin Directory was from January of 2008 and the most recent was from February of this year. The types of vulnerabilities in these plugins included cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injections, and file inclusion. These plugins had over 560,000 combined downloads. The number of downloads that individual plugins had ranged from 300 to 93,000. Four of the plugins had over 50,000 downloads, which should be a reminder that just because a plugin is popular it doesn’t mean that it is more secure than less popular plugins.
We also found a situation where a plugin had been removed from the directory but a fork of the plugin has remained in the Plugin Directory despite also containing the vulnerability and two plugins that had their vulnerabilities fixed but the version number was not changed so that people that already had the plugin installed will remain vulnerable to being exploited. Resolution on those plugins’ issues from WordPress is still pending.
We plan to review other sources of claimed vulnerabilities to see if there are more plugins with publicly known vulnerabilities in their current versions that have remained in the Plugin Directory.
While reviewing recent logs for attempts to exploit WordPress plugins, for another post on this blog, we spotted one plugin that seemed out of place. While nearly all of the exploit attempts involved plugins that were no longer in the WordPress.org Plugin Directory or had recently been updated with security fixes, the WP CSS plugin was in the directory but hadn’t been updated since 2009. We then got a copy of the plugin to see if the vulnerability that was being attempted to be exploited worked in the current version. A quick check showed that the exploit worked. According to Plugin Directory statistics as of Friday the plugin had been downloaded 17,803 times. That a plugin was available in the Plugin Directory that has vulnerability that is actively being exploited was troubling, but what we found next was more troubling.
Before contacting the developer of the plugin and WordPress, we decided to take a look if there was more information about the vulnerability available. We first found a post from someone who had also had recent attempts to exploit the vulnerability on their website. We then found a Secunia advisory for the vulnerability that was release on August 26, 2011. We also found that a company named SecPod had created a OpenVAS plugin for the vulnerability. It is also likely that exploit attempts were caught in various honey pots.
With the vulnerability being publicly known for at least six months and recent attempts to exploit it, the question that needs to be asked is how the vulnerable plugin continued to be available in the WordPress.org Plugin Directory all of that time. Did no one ever contacted WordPress about the vulnerability or were they contacted about it and decided not to remove the plugin, pending a fix? It seems highly unlikely that WordPress was contacted and left the plugin in the directory as they responded to our message, and removed the plugin, within in two hours of us contacting them. It is possible that some of the people who had spotted the vulnerability contacted the developer of plugin and had not contacted WordPress despite the plugin being hosted in the Plugin Directory and it being recommend that they be contacted about WordPress plugin security issues.
While it appears no one contacted WordPress, they still should have been monitoring for plugins included in the Plugin Directory that have a publicly released vulnerabilities. For Secunia, all WordPress related vulnerabilities can be found here.
For anyone running the WP CSS plugin they should remove the plugin or remove the w-css-compress.php file until it is fixed, unless they are comfortable making a modification to the file to prevent exploitation. Deactivating the plugin will not prevent the plugin from being exploited.
The other issue that this situation raises is the lack of information provided to those running plugins that have been removed from Plugin Directory for security issues, we have addressed that in another post on this blog and plugin that provides an interim solution for the problem.