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.
Three years ago we posted about the fact that trust marks shown on websites that claim to certify that the websites are secure cannot be trusted to identify if a website is actually secure for a number of reasons, including that in many cases they scan the websites from the outside so there are many things that they would never detect. What we recently noticed is that the Norton Secure Seal service fails to do a really basic security check that can be done from the outside. When it comes to the security of websites one of the basic security measures is to keep the software running the website up to date. This prevents the website from being hacked to the exploitation of a known vulnerability in the software that has been fixed in a subsequent release. As we have found the Norton Secure Seal service doesn’t check to make sure the software running the website they are claiming is secure is up to date.
As an example of this we will take a look at the website of an IT security company that carries the Norton Secure Seal as you can see here:
Using our Joomla Version Check web browser extension you can see that the website is running an outdated version of Joomla:
That version of Joomla, 3.1.1, is seven months out of date and more importantly subsequent versions have fixed four security vulnerabilities, including a vulnerability rated as having critical severity and a vulnerability rated as having high severity. A website with that level of security issue should not be labeled as being secure.
The technology our web browser extension uses to detect that Joomla is powering a web page and what version is in use is rather simple and there is no excuse for a major company such as Symantec, the maker of the Norton Secured Seal service, not being able to do the same. Providing more awareness that an outdated version of Joomla is in use is definitely needed as outdated versions of Joomla are widely used, including among companies that provide security services for Joomla websites, and some older versions contain a vulnerability that is being exploited by hackers.
It isn’t just Joomla that Norton Secured Seal service doesn’t check to make sure is up to date; the same website has a blog running an outdated and insecure version of WordPress as well:
We are frequently hired to clean up websites that another company was previously hired to clean up but then has been hacked again (or wasn’t actually cleaned up in the first place). In some cases we wouldn’t lay the blame on the company, sometimes hacks are well hidden and getting them cleaned up can take more than one cleanup (which you shouldn’t be charge extra for) and in other cases there are security issues that the company doing the cleanup can’t handle. For example, if your web host has a security issues then they are going to only ones who can fix that. What we find in most instances though is that company doing the hack cleanup has not done the basic elements of the hack cleanup.
When someone contact us about cleaning up a website that was previously cleaned the first question we asked is if the first company determined how the website was hacked. Determining how the website was hacked is important part of the cleanup as if you don’t know how it was hacked you won’t know if the security issue that allowed the website has been fixed. Considering that the websites have been hacked again it isn’t surprising that the answer we hear over and over is that they didn’t. But isn’t just that they didn’t determine how the website got hacked, the companies didn’t even try to determine how the website was hacked. Either these companies are knowingly cutting corners or they don’t care enough about the service they providing to know what work they should be doing. In either case what they are doing is highly unethical.
We don’t ask our clients who they previously hired, but they do bring it up from time to time. During recent cleanup of a Joomla website the previous company was mentioned and when we went to their website we noticed that they were running an outdated version of Joomla. Keeping the software running on a website is a basic security measure, so any company that doesn’t bother to do that really shouldn’t have anything to do with the security of other people’s website. We took a look around at companies advertising to clean up Joomla websites and we found that all of the companies were running out of date software. As warning to the public and as a reminder of how bad the current state of companies providing security services is we have highlighted them below:
Dean Marshall Consultancy (http://www.deanmarshall.co.uk/)
Support for Joomla 1.5 ended in September 2012, so a websites shouldn’t be running it anymore (though many, including joomla.org, are still using it as we mentioned yesterday). As part of cleaning up a hacked website still running Joomla 1.5 you will eventually want to migrate it to a newer version, which doesn’t seem like a task for a company that still hasn’t done it for their own website.
Joomla Help Live (http://joomla.cmshelplive.com/)
Joomla 1.7 is over two years out of date and more importantly it has a serious security vulnerability that we have seen being exploited.
Joomla 3.0.3 is ten months out of date and there have been four subsequent versions with security updates.
US Joomla Force (http://www.usjoomlaforce.com/)
Joomla 2.5.11 is seven months out of date and there have been two subsequent versions with security updates.
WordPress 2.8.5 is over four years out of date and there have been 17 subsequent versions with security updates.
When it comes to making sure websites are secure one of the basic things that needs to be done is to keep the software up to date. For Joomla that means that currently means running either the latest version of Joomla 2.5 or 3.2. We continue to clean up many hacked websites that are still running Joomla 1.5, for which support ended in September of 2012. While most of the hackings are due to security issues unrelated to the outdated version of Joomla, it is concern that so many are still running Joomla 1.5. To get a better understanding how wide spread use of Joomla 1.5 is we have compiled the data on what versions were found on the website checked with the online version of our Joomla Version Check tool (which is also available as web browser extension for Firefox and Chrome) during January.
As can be seen in the pie chart below 31 percent of the websites checked during the month were running Joomla 1.5 and 2 percent were still running Joomla 1.0, for which support ended in July of 2009.
Some, if not most of the blame for this, should go to Joomla developers that didn’t provide an easy path to move to a newer version. Instead of being able to upgrade to a newer version of Joomla a more complicated migration needs to be done and curiously the developers did not provide a tool to do that, relying on third party tools to handle it. We have found that some of those tools provide rather poor results. The difficulty in moving to a newer version is probably best highlighted by the fact that portions of the Joomla website are still running Joomla 1.5, including the Extensions Directory:
The other very concerning stat that shows up in the data is that 6 percent of the websites were running a Joomla version between 1.6 and 2.5.2. Last month we discussed that a serious vulnerability in those versions of Joomla is being exploited and people still running those versions need to upgrade as soon as possible. Unlike migrating from Joomla 1.5, upgrading those installations to the latest version of Joomla 2.5 is fairly easy and it shows that the handling of security of Joomla websites is in need of improvement.
For those looking for someone to handle keeping Joomla up to date we provide Joomla upgrade services on a one-time and yearly subscription basis.
One of the biggest obstacles we see to improving website security is that many of the organizations that should be leading on security are not even taking basic website security measures themselves. One type of organization we see that with is news organizations that cover web security. Previously we discussed several that were running very out of date and insecure versions of Drupal. This time we will use InfoRiskToday, which describes itself as providing “credible, timely information that security leaders can put to use as they craft comprehensive information security strategies”, to highlight a security risk and several tools that we provide that can make detecting it relatively easy.
Plesk is control panel software that runs under a website and permits management of the software on the server and configuring the server. It also has had serious security vulnerabilities that have lead to many websites being hacked (one example being a major hack at Media Temple). The way to remain relatively secure against that sort of thing is to keep Plesk up to date, as should be done with all software. Unfortunately what we have seen is that there are still servers using Plesk 9, for which extended support ended back in June of last year. Since it isn’t supported anymore, if a new security vulnerability was found it wouldn’t be fixed, so Plesk should be updated to a supported version as soon possible to keep it secure.
We have created a pair of web browser extensions available for Chrome that can make checking for such an outdated Plesk installation relatively easy. The first one, Control Panel Login, looks for HTTP headers that indicate that Plesk is in use and when found displays the Plesk logo in the URL bar. Here is how looks when you visit InfoRiskToday’s website:
Clicking on the icon takes you to the standard URL for logging on to Plesk from the website. Our second extension then comes in to play. Control Panel Version Check will display an icon in the URL bar if it detects that a page with Plesk version information is being visited. Clicking on the icon will then display the version information and indicate if it is outdated. In InfoRiskToday’s case you can see that they are still using Plesk 9:
When it comes to the security of your website, your web host plays an important part but too often they are failing do what they need to do to keep your website secure. One of things they should be doing is keeping software on the server up to date as that prevents your website from being exploited due to a known vulnerability in the software.
To make it easier to spot when web hosts are using outdated control panel software we released the Control Panel Version Check extension, available for Firefox and Chrome, back in December. Using it you can see that HostGator is using an outdated version of cPanel:
The version of cPanel they are running, 11.36, has only been unsupported for a week now so the situation isn’t nearly as bad as many of the hosts we highlight for running years out of date software. But what makes it worth highlighting is that on HostGator’s website they say that they provide the “Latest cPanel Control Panel”:
The latest version at this point is 11.42, which was released a couple of weeks ago. If you are going to tout that you are using the latest version of cPanel then it is really unacceptable to not even be using a supported version.
In addition to the outdated cPanel, HostGator is using a year out of date version of phpMyAdmin:
There have been a number of serious security vulnerabilities fixed in subsequent versions of phpMyAdmin.
When it comes to bad security advice, one of the most prominent items is that hiding what version of software you are running will provide you with protection. The reality is that in most cases hackers won’t even bother checking if you are running the software before attempting to exploit a hack. Will show you an example of that in a second, but the important take away is that if you are running software with known vulnerabilities the solution is to to update the software instead of trying to hide what version you are running because if you are running a vulnerable version you are going to get hacked no matter how hard you try to hide the version.
When people promote hiding the version in use they are actually making website less secure because it makes it harder for people to see that someone is running an outdated version that needs to updated and warn them. Google’s Webmaster Tools provides alerts when outdated software is in use, but that only works when the version information is available. We have created a web browser extension that warns when various outdated software is in use according to the meta generator on the page, but that only works if that version information hasn’t been removed from the page.
BOT for JCE
Outdated versions of the Joomla extension JCE contain a very serious security vulnerability that allows a hacker to upload files to a website. Exploitation of this vulnerability has been a common cause of the hackings among the hacked Joomla websites we have cleaned up. This would seem to due in part due to ease that someone can exploit it due to the fact that the disclosure included PHP code that handles exploiting the vulnerability. It easy to spot if that code has been used as the user agent left in the log files is “BOT/0.1 (BOT for JCE)”. Our website doesn’t even run on Joomla, but we have had numerous attempts to exploit outdated versions of the JCE extensions anyway. Some of the attempts just appear to completely untargeted (probably someone trying the exploit on every website), while a lot of others appear to be based simply on the word joomla being in a URL on the website. Our recent logs show a significant spikes in attempts after we had a post on a security vulnerability in Joomla. The log entries for one of those attempts is shown below and the important element to note is that the hacker starts out by trying to exploit the vulnerability. They make no attempt to check if a vulnerable version of JCE is in use, that JCE is in use, or that Joomla is even in use first. Any attempt to hide what version of JCE or Joomla would have no impact of the vulnerability being exploited.
220.127.116.11 – - [03/Feb/2014:01:01:08 -0500] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1″ 500 885 “-” “BOT/0.1 (BOT for JCE)”
18.104.22.168 – - [03/Feb/2014:01:01:08 -0500] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.1″ 404 5923 “-” “BOT/0.1 (BOT for JCE)”
22.214.171.124 – - [03/Feb/2014:01:01:08 -0500] “POST /blog/2014/01/14/vulnerability-in-joomla-1-6-1-7-and-2-5-0-2-5-2-being-exploited-now/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1″ 500 885 “-” “BOT/0.1 (BOT for JCE)”
126.96.36.199 – - [03/Feb/2014:01:01:08 -0500] “POST /blog/2014/01/14/vulnerability-in-joomla-1-6-1-7-and-2-5-0-2-5-2-being-exploited-now/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.1″ 404 6290 “-” “BOT/0.1 (BOT for JCE)”
188.8.131.52 – - [03/Feb/2014:01:01:10 -0500] “POST /blog/2014/01/14/vulnerability-in-joomla-1-6-1-7-and-2-5-0-2-5-2-being-exploited-now/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1″ 500 885 “-” “BOT/0.1 (BOT for JCE)”
184.108.40.206 – - [03/Feb/2014:01:01:10 -0500] “POST /blog/2014/01/14/vulnerability-in-joomla-1-6-1-7-and-2-5-0-2-5-2-being-exploited-now/index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.1″ 404 6290 “-” “BOT/0.1 (BOT for JCE)”
220.127.116.11 – - [03/Feb/2014:01:01:11 -0500] “GET /blog/2014/01/14/vulnerability-in-joomla-1-6-1-7-and-2-5-0-2-5-2-being-exploited-now/images/stories/food.php?rf HTTP/1.1″ 404 6237 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
18.104.22.168 – - [03/Feb/2014:01:01:09 -0500] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1″ 500 885 “-” “BOT/0.1 (BOT for JCE)”
22.214.171.124 – - [03/Feb/2014:01:01:19 -0500] “POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&version=1576&cid=20 HTTP/1.1″ 404 5923 “-” “BOT/0.1 (BOT for JCE)”
126.96.36.199 – - [03/Feb/2014:01:01:20 -0500] “GET /images/stories/food.php?rf HTTP/1.1″ 404 5921 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
We have recently gotten a number of questions about how much disruption upgrading from OpenX to the new Revive Adserver causes and as other undoubtedly have the same questions we wanted to address those for a wider audience. The good news is that the upgrade should be seamless in most instances. While the software has new name – due to ownership of the software being transferred – and a jump in version number from 2.8 to 3.0, the changes so far have been under the hood. This means that you won’t have to make changes to zones, campaigns, banners, ad positions, etc.
Two of the releases of Revive Adserver (3.0.0 and 3.0.2) have fixed security vulnerabilities that could lead to the ad server being hacked, so if you haven’t upgrading yet you should do that as soon as possible. There have also been bug fixes and modernization, including support for PHP 5.4 and 5.5, included in the new versions so far.
If you have previously done an upgrade between versions of OpenX 2.8 then you should find the process to be the same when upgrading to Revive Adserver.
So far the only issue we have run in to with the upgrade is that in one instance the upgrade failed to remove the OpenX Market plugin, which had been deprecated. The failure to remove that caused the admin interface to not work due to a Failed Opening Required error for the file /lib/ox/m2M/xmlrpcexecutor.php. If that occurs you can delete the /www/admin/plugins/oxMarket/ directory allowing access to the admin interface where you can fully remove the plugin and the openXWorkflow plugin, which should also have been removed.
If you are looking for someone to handle the upgrade for you, we can do a one-time upgrade for you or we can handle upgrades on an ongoing basis for you (insuring that you always get security fixes applied within a day of their release).
What we see over and over when it comes to web security is that security providers don’t take basic security measures with their own websites, which doesn’t give much confidence that they will make sure their customer’s security is handled properly and goes a long way to showing why web security is so bad. We can now add AT&T’s Enterprise division to that group. They provide a variety of security services including security consulting, which they could probably use for their own website as their Security Blog is running an outdated version of WordPress:
Keeping software running a website is a basic security measures as it insures that a known vulnerability in the software can be exploited. In AT&T’s case they have failed to update the software in nearly six months and more importantly they failed to update after WordPress 3.6.1 was released in September. WordPress 3.6.1 fixed three security issues including one that could “lead to remote code execution” and users were strongly encouraged to “update your sites immediately”. Considering how easy it is to update WordPress AT&T doesn’t have an excuse for not doing it.
Last month we discussed Magento’s lack of official support for PHP 5.4 despite the fact that web hosts had been making the move to at least that version and questions raised by that. Magento has now released patches to make Magento 188.8.131.52-184.108.40.206 compatible with PHP 5.4. You can get the patches on the Magento Download page in the Magento Community Edition Patches section of the page.
All of the patches modify the following files:
All of the patches except for the one 220.127.116.11-18.104.22.168 modify:
A new file is added at:
In our previous post we mentioned that we still found that Magento 1.3 would work with PHP 5.4, so older versions can still could probably be used, though you could run into an issue.
For those who can’t use the patches
we will be putting out a set of patched files, as we do with the Magento security patches, soon you can use the patched files we have put together.