Monday, 20 August 2018: Magento 2 Backend Development I training in BirkStaete Soest, Nederland » More information

Yireo site almost hacked

Last Wednesday we noticed extra activity on the Yireo site, and we went throught the logs quickly - only to find that various rootshells were added in a tucked-away folder in our Joomla! site. Our site was hacked. Luckily we could simply remove the hack-files and the exploit, and be done with it.

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.

Written by Jisse Reitsma op 19 April 2012

Looking for a training in-house?
Let's get to it!