Decoding a PHP SuperGlobals exploit program

Back in April I released an article called "Byte encoding exploits in PHP files", at the time we had not seen a PHP exploit coded in that way so scanning tools like "Maldet" didn't pick it up even though to a human the code looked like an exploit due to the coding style. When we detected the exploit I wrote the article after doing some research and discovering virtually nothing on the subject, if you haven't read the article then its worth a read now because it created a lot of interest, especially in Eastern European countries (where I suspect the exploit originated from) according to the Google Analytics we reviewed in the weeks that followed release of the article.

Then within a month of the article being released the exploit attempts dropped off, manual detection of suspect files showed the exploit code being widely used previously, had changed. The modified versions of the files included less of the byte encoding and more generic PHP code. But things don't stand still and today another exploit was manually detected in log scans. Our normal scanning tools failed to pick the most recent exploit attempt but looking at the files with human eyes they are obviously suspect! The "new" coding style the hackers used in one file is based around the PHP "super globals" language feature. I had not heard the term myself till I started checking the syntax of the "GLOBALS[] array on the php.net web site. Using "global" in a PHP app is quite common and even using "$GLOBALS[]" is not that unusual, but a file full of them is not a coding style any professional uses to release code.

Two files were downloaded by the hackers, one called diff50.php and the other (yet to be decoded as its totally different again) diff.php. The entry point was either a an out of date WordPress plugin like Gravity Forms or an out of date theme file. The reason we cannot be clear on the entry vector is the possibility the time stamps on the directories of the site may have been manipulated but the exploits were found in the various "uploads" directory of a WordPress site.

On analysing this file I Initially thought the first line was a bootstrap code sequence but it quickly became obvious it was a character mapping array, mapping the hex coding to ASCII characters as shown below using a simple decoder.

The first thing I did was rename 'v5fd1710b' to 'MAP', this made the particular array easy to spot and reduced the code. Then I set about reversing the variable encoding back to clearer text and see what is actually being set.

This became obvious when I echoed out the assignment lines one at a time:

This indicates the code assigns program keywords to global variables which can be executed. Another way to dump the variable assignments is to use:

print_r( $GLOBALS );

Follow this with a return 0; to prevent the rest of the code executing and it becomes obvious what some of the variable names are and what is assigned to them, so the print_r output yielded the following:

Then next bit of analysis was to look at the two Arrays "$rb2ea" and "$o6cb" as well as any function calls and function definitions, the later is easy as the "function" keyword must be used. Function calls however can be coded using the @$GLOBALS[] structure and the file has a couple of these:

The first line is the last assignment which gets the $_POST variables, the second gets the $_COOKIE variable, this tells me the script is called with parameters so its most likely the malicious code is remote and downloaded as needed. PHP function definitions, like most languages are constructed as follows:

function NAME ( param, more_params ) { code };

while the function call just excludes the keyword "function", So the lines above decode to:

We find 4 characters, an opening "(", some parameters and finally a closing ")" with semi-colon. From the naming of the function its purpose is not immediately obvious, but if we look back at the keywords we decoded earlier, ea6c is in fact "ini_set" so the resultant call is:

ini_set(error_log,NULL);

and converting all the ones we find in the file yields the file so far:

The function's two parameters were changed using text substitution, I don't know yet what the parameters are so "$param1" and "$param2" are safe bets, while the chr() and ord() functions were decoded from our list of global variables earlier. One immediate observation is we have two global variables with the same names as the functions, the code in the function is also not clear so we can use our substitutions above to reverse this back to more legible code.

I've added the print_r() statements to help decode variable names and see what is set and as a safe guard the "eval()" call is disabled.

The final analysis shows that the program's data is collected from Cookies and POST data, manipulated into a base64 format and then executed using the PHP eval() function. As we don't have the Cookie data or POST data further analysis is not possible. But the script allows code to be downloaded and executed so that makes it an open tool to be used at will. The trigger for us was excessive email traffic and in most cases these exploits are used to send spam mail.

Where to from here?

The fact the files came down means the clients themes and plugins need updating. A manual scan of the directories showed no other files but the coding style will enable a tool similar to the earlier exploit from two months ago to be used to find this type of code. A full cleanup of the site's files and manual checking shows no other exploits.

Sid has 35 years experience in IT & Electronic Engineering. His extensive skill set including; Systems Engineering, Networking, Virtualization & SAN support. Spending most of his day developing Systems/Virtualization Engineering of a large Cloud Infrastructure & developing software applications.