We told you so: Joomla! is unsafe

Bummer for those thinking Joomla! is to blame, because it was not: The exploit was actually located in a third party extension FLEXIcontent which again shipped with a third party library phpthumbs, which contained the exploit. The exploit allowed an attacked to upload an arbitrary file by modifying GET-parameters to an upload-script: Because the phpthumbs library is designed to match images only, uploading a script-file made the library return an error, but without removing the uploaded script - so the uploaded script remained in place.

Old exploit on well maintained site ...?

This exploit was actually already fixed a long time ago by FLEXIcontent (so they are certainly not to blame). But somehow the fix of FLEXIcontent was applied incorrectly on our site: Most of the PHP-files of FLEXIcontent were updated correctly, but the files of the phpthumb library were still outdated, ... and containing the exploit.

This proves that keeping your Joomla! core up-to-date is one thing, but it also vital to keep your third party extensions up-to-date as well - applying fixes in a controller manner, and probably scanning your server for malware periodically.

How far did they get?

When rootshells are found on a site, the question is not only how they did that, but also whether they succeeded in their goal: Gaining root-access to the server itself. The scripts uploaded by the attacker of our site contained some rootshells - one of which the Storm7Shell script. These scripts often ship with many tools to execute UNIX-commands on webservers, offering file managers, exploit detection and much more. The main purpose of those rootshells was to get deeper into the system.

So how deep did they get? Normally, a rootshell is placed on the webserver as a means to break out of the jail of the webserver (Apache, for instance) and gain access to the root-level. This involves trying out exploits on other system applications or the operating system itself. For instance, we witnessed a hacked server in the past where the rootshell was used to create a buffer-overrun expoit in /tmp, which again caused a kernel-race condition in the used Linux kernel, which again gave root.

We scanned all logs (not just the webserver logs) for suspicious activity. We next scanned the entire server for malware using the tool maldet. And to be on the safe side, we performed various checks to detect rootkits (which again are used to hide all evidence of an attack, once root-access has been obtained) - among which the tool rkhunter. Luckily we found nothing. This all took place within 2 hours, so we have a fair belief that we stopped the attacker.

To prevent it?

Hope you enjoy this blog more than we did. Our blog shows that security should always be considered extremely important, so that exploits are detected in an early stage. There are many more security tools that could prevent attacks in the first place - IDS applications, privilege restriction like SElinux, chroot() environments, etcetera. But the best advise - as always - seems to be: Stay alert and stay focussed.