We often find new techniques employed by malware authors. Some are very interesting, others are pretty funny, and then there are those that really stump us in their creativity and effectiveness. This post is about the latter.
Everyone who writes code in PHP knows what the eval() function is for. It evaluates a string as PHP code. In other words, it executes the code. But there are certainly many other ways to run a code, which are not always so obvious. The most popular and commonly used one is the preg_replace() function.
According to its description, the preg_replace functions “performs a regular expression search and replace.” Unfortunately, when using the “e” modifier, this function also runs the code. Yes, there are more ways of running the code without using the eval() function. Example could be the create_function(), or the assert() function. All these options of running the code makes malware analysis all that more complex a process.
That being said, even with our insights we continue to find ingenious ways that malware authors are employing for their backdoors.
It started with following line of code injected at the top of a legitimate php file:
It took me a little while to understand how this could work (and thanks to Ante Kresic for helping me here), but in the end, I realized that the problem is in the callback functions. Can you see why?
The malware author set the callback function to be the variable “login” that is controlled by the attacker. So he can set login to be the system or exec functions, allowing him to execute commands on the server.
Take a look at this example:
Yes, he just ran the “system” command using this technique. And he can execute any other commands he wants on the server, with that 1 line of code. To make matters worse, that little payload was not detected by any anti-virus or security software that we tested.
What’s the Big Deal?
Most security tools and articles online recommend webmasters look for a certain subset of functions that are often used for malicious purposes. Like eval, preg_replace, base64_decode and a few other combinations. Well, guess what, attackers know that too and look at what they are starting to employ, good functions for bad purposes.
Also, note that they are not just restricted to the array_diff_ukey() function, but any other function that allows for callbacks.
There goes the neighborhood…