hacked joomla site

A tale of a hacked Joomla site

Well not just one site but one hundred all on the same server, all running under the same user and some defaced.

Shit happens and when it does you know you are in for some long hours fixing the problem.

On this server there were a mix of Joomla 1.0, 1.5 and 1.7 web sites some of which were live sites and others were old demo and test installations long since forgotten and woefully out of date.

Removing the defacement is actually pretty easy to do but that will often just mean that the naughty little toe rag will come back tomorrow and do it all again. You need to find the entry point to your server and kill it forever.

I have many scripts that I have written over the years to scan the files on the server but this time I started by using the excellent php file scanner that is included in AdminTools Professional from akeebabackup.com. (You just know that if Nicholas wrote it then it will be good)

AdminTools identified several files as being suspicious and on closer inspection they were all encrypted scripts of some type. Deleting is the simplest option but I like to take a closer look at them to see if they are an off the shelf c99 script or something custom for this server.

After downloading the scripts to my computer I can open them in a text editor and take a look at them in a safer environment. They can look like gobbledygook at first but with the right tools we can usually find out exactly what they are and what they can do.

Not surprisingly all the scripts are the same. Hackers often place their tools in multiple places on your site so that if you find one you might stop searching. Don't!!

The first line of the script says

 

So now I know how the hacker was able to upload the c99 shell scripts but can I find out what they were doing with the c99 shell script? The logs won't help us here so it's back to scanning the server.

Quite often we can't find anything as the defacement was performed using the tools in the c99 shell script but in this case there was something a little odd or clever depends on how you look at it. Each time I removed the defacements from site1 they were back again in seconds. I had removed all the instances of the shell script so it wasn't the hacker putting them back as quickly as I could delete them. So how was he doing it?

At first I suspected he had created a cron job but I couldn't see any evidence of one so I carried on scanning the server but this time not just the php files. Now I included all files especially the images. (Yes you can embed malicious code in an image).

Finally I found that one of the images on demosite3 wasn't actually an image but another script with code which checked the filesize of index.php on site1 and if the size didn't match the size of the hacked version it rewrote the file with the hacked version. So that as soon as I had fixed the index.php on site1 and someone visited demosite3 the hacked index.php magicaly reappeared all while the hacker was having a beer.

Now that I am sure the server is clean of all scripts it's time to look and see how that simple file uploader got there in the first place. From looking at the logs I can see that this file has been on the server for several months and I know that all the joomla installations are at the latest version and all the extensions are up to date with no currently known security vulnerabilities. However several of the extensions did have vulnerabilities in the past. So I can only conclude that the file was added using a known vulnerability before they were fixed on the server. You don't really imagine that vulnerable code is discovered and fixed at exactly the same second do you?

"Just because you keep your server secure and your software up to date you may have been exploited yesterday, ready to be hacked tomorrow."

The web was meant to be read, not squished.
This isn't the way to test a responsive design.