Joomla

The Joomla Extension Directory Finally Moves Off of Joomla 1.5

When it comes to the security of websites what we see is that basic security measures are often not taken and unfortunately all too often those measures are not being taken by those who should know better and have the ability to make it easier to accomplish them. Take for instance the Joomla, until yesterday the Extension Directory portion of their website, an important section of the website, was still running Joomla 1.5:

That is despite the fact that support for that version ended back in September of 2012. It obviously doesn’t look good when the developers of software can’t even keep on a supported release of their own software.

Thankfully, the Extension Directory has now been moved to Joomla 3.3:

Unfortunately it doesn’t appear that even their inability to get off of Joomla 1.5 for so long has lead them to provide anything to make it easier to move off that version, which many others still remain on.

Hackers Still Trying To Exploit Joomla 1.5 Vulnerability Fixed Six Years Ago

We were recently checking something in our analytics and noticed that a rather odd URL had been accessed. The URL, http://www.whitefirdesign.com/blog/?option=com_user&view=reset&layout=confirm, was for a section of our website running WordPress but the URL parameter, ?option=com_user&view=reset&layout=confirm, was for something Joomla related based on the “com_user” portion. A quick search identified that this was an attempt to exploit a vulnerability in older versions of Joomla. What is interesting about this is that the vulnerability was fixed in Joomla 1.5.6, which was released in August of 2008. Since most hacking attempt will not show up in analytics – due to them not requesting the tracking code – we were curious to see if there had been other attempts to exploit this that would show up in our access logs. We found that in the last six months there were attempts to exploit the vulnerability on 48 days. So hackers still feel there are enough Joomla website that haven’t been updated in six years to try to exploit it regularly.

There are a couple of quick takeaways from this. One is that is that if you still have websites running Joomla 1.5, for which support ended in September of 2012, you should make sure they have been upgraded to the last version, 1.5.26, and had the additional security fix applied so that they are protected against attempts to exploit any vulnerabilities in older versions. The other is that you don’t need concerned just because there has been an attempt to exploit a vulnerability on your website, considering that in this case a hacker tried to a vulnerability in very old versions of Joomla on a website running WordPress.

Trustwave is Untrustworthy

When it comes to IT security companies, what we see over and over is that they have little to no concern for security (and also often have little to no understanding of proper security practices). So it isn’t surprising that despite billions being spent on IT security, IT security continues to be in such poor shape. This leads to situation like the massive breach of Target’s systems last year. While that was big news, what didn’t get much attention was the company who declared Target compliant with standards for handling credit card transactions shortly before the breach, Trustwave. Trustwave has a history of declaring companies compliant shortly before they suffer major breaches and for being lax in their assessments.

We recently spotted another example of their highly questionable practices of Trustwave. We were contacted about doing a migration of a Joomla-based website still running version 1.5, for which support ended in September 2012. While taking a look at the website, we noticed a seal for Trustwave Trusted Commerce:

Considering that the website is running software that is no longer supported and therefore cannot be considered secure, we were curious to see if Trustwave was claiming it was secure. It would be quite easy for them to find that the website is running Joomla 1.5 if they wanted to as the source code of every page on the website the following line is included:

<meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />

If you click on the seal you get this page:

Trustwave Trusted Commerce Statement

At the top of the page Trustwave proclaims that “Your credit card and identity information are secure.”, which they shouldn’t be saying for a website that is running unsupported software.

As we looked closer we noticed the small text disclaimer at the bottom of the page were they say “Trustwave Holdings, Inc. makes no representation or warranty as to whether [redacted] systems are secure from either an internal or external attack or whether cardholder data is at risk of being compromised.”. So they are basically telling you that despite saying “your credit card and identity information are secure”, there not actually saying that at all.

It is highly inappropriate for them to mislead the public like they are doing with this seal, but unfortunately our experience is that this kind of thing is considered acceptable in the security industry.

Major African Bank Running Outdated and Very Insecure Version of Joomla

Recently we have had a lot of blog posts highlighting major organizations running outdated and insecure versions of Drupal, but we don’t want to give the impression that it is only with Drupal based websites that major organizations are failing to keep the software up to date on. So we wanted to find an example of a website running Joomla to highlight as well and we quickly found a very concerning example. The third website listed on Joomla’s showcase of websites running Joomla is the website of Guaranty Trust bank, which is Nigeria’s largest bank and has assets of over 12 billion USD. As you can see with our Joomla Version Check web browser extension, available for Firefox and Chrome, their websites is running a fairly out of date version of Joomla:

That version is over two years out of date and there have been twelve subsequent updates with security fixes. One of the security vulnerabilities fixed in a subsequent version is of particular concern. The vulnerability, which we discussed before, allows a new user account to be created with “Administrator” privileges through privilege escalation. If user registration is disabled this will not work, but in this case it does appear that user registration is enabled. It is important to note that account access portions of Guaranty Trust Banks’ website are separate from the main website, so they are not directly impacted by the lax security of the main website. But it does raise the question of how well they secure the other portions of their website if they are not doing something this basic. Also, if someone could exploit one of the vulnerabilities in the version of Joomla on the main website they could change the links directing people to the account access portion of the website to another location and use that to gather login credentials.

Due to how potentially serious the security issue with their website is we attempted to contact Guaranty Trust Bank as soon as we saw the version they are running, but we were unable to get far. For one of their listed email addresses we got back message that the mail box was full. For the other we were told to “liaise with our Corporate Affairs Unit at the head office”, but our reply asking how to do that was met with a message that the email address we were replying to did not exist.

Migrating From Joomla 1.5 Won’t Necessarily Clean Up a Hack

Fairly often we have people contacting us about doing an upgrade of software on a website, which they are hoping will resolve a hacking or other security issue. Unfortunately in most instances they don’t tell us that is why they want an upgrade done. In the worst case this could cause the upgrade to get messed up if the hack has made modifications to things that are affected by the upgrade. In many cases the upgrade isn’t going to fully resolve the issue and may not have any impact at all. For example, if a website was running Joomla 1.6, 1.7, or 2.5.0-2.5.2 and it got hacked due to the privilege escalation vulnerability in those versions, which allows someone registering a new account to escalate their account to “Administrator” level, upgrading would prevent new accounts with those privileges from being created but the existing accounts would still exist. Those accounts can be deleted, but you have to know they exist to do that. The upgrade also might overwrite other modifications the hacker(s) made to the website, but it might not.

For website still running Joomla 1.5 the website cannot be upgraded to a newer version. Instead a more complicated migration, which move content from the Joomla 1.5 installation to a new install of Joomla 2.5 or 3. Despite support for that version ending in September of 2012, the version is still widely used and we recently have been contacted about a lot of hacked website that are still running Joomla 1.5. Since the migration leaves a lot of the website behind it would reasonable to wonder if a migration will resolve the hack. A website we were just dealing is reminder that isn’t the case.

There are three major areas where parts of the hack could move over during the migration. First a common place for placing malicious files is in a website’s images folder, which is something that will move over to new website. Another common area where malicious code is placed is in theme files. While Joomla 1.5 themes are not directly compatible with newer versions of Joomla, some can be easily converted to the new version either by hand or with automated tools. The third area, which is where malicious code was in this situation, is the in the database. In this case the malicious HTML code had been added to the content of a number of articles, which was moved over during the migration.

The malicious HTML code (shown below) was relatively harmless; it just added a link to a spam page to the page and used JavaScript code to hide the link. While this won’t harm someone visiting the page, it can lead to Google placing a “This site may be hacked” label in their search results and the lowering the website’s ranking. It was also causing the AVG antivirus software to alert for Exploit Blackhat SEO (type 1703), which is likely to scare away some visitors.

Source Code of Hidden Spam Hack

Outdated Versions of Joomla 2.5.x and 3.x Widely Used

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

Joomla Version: 2.5.x: 12.30%, 2.5.0: 0.53%, 2.5.1: 1.60%, 2.5.2: 0.53%, 2.5.3: 0.53%, 2.5.4: 4.28%, 2.5.6: 6.95%, 2.5.7: 3.74%, 2.5.8: 5.88%, 2.5.9: 10.16%, 2.5.11: 9.09%, 2.5.13: 1.07%, 2.5.14: 9.63%, 2.5.15: 0.53%, 2.5.16: 3.74%, 2.5.17: 15.51%, 2.5.18: 13.90%

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

Joomla Version 3.x: 6.35%, 3.0.2: 3.17%, 3.0.3: 6.35%, 3.0.4: 1.59%, 3.1.1: 14.29%, 3.1.4: 1.59%, 3.1.5: 14.29, 3.2.0: 6.35%, 3.2.1: 26.98%, 3.2.2: 19.05%

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.

WordPress Version: 2.5: 0.93%, 2.9: 0.46%, 3.0: 0.93%, 3.1: 1.39%, 3.2: 2.78%, 3.3: 6.02%, 3.4: 6.02%, 3.5: 15.28%, 3.6: 10.65%, 3.7: 15.74%, 3.8: 39.81%

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.

MediaWiki Version: 1.14: 3.77%, 1.15: 7.55%, 1.16: 9.43%, 1.17: 9.43%, 1.18: 7.55%, 1.19: 18.87%, 1.20: 9.43%, 1.21: 15.09%, 1.22: 16.98%, 1.23: 1.89%

Joomla Hack Cleanup Providers Don’t Care About the Security of Their Own Websites

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.

PennZac (http://www.pennzac.com/)

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.

itoctopus (http://www.itoctopus.com/)

WordPress 2.8.5 is over four years out of date and there have been 17 subsequent versions with security updates.

Joomla 1.5 Still Widely Used Despite Support Ending in September of 2012

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. Joomla Version: 1.0: 2.15%, 1.5: 30.96%, 1.6: 0.99%, 1.7: 3.48%, 2.5: 50%, 3.0: 1.16%, 3.1: 5.30%, 3.2: 4.30%, 3.x: 1.66%

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.

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”

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.