Your web server's image processor could be malware hiding in plain sight.
I'm going to describe an interesting type of malware the Malware Intelligence Team recently uncovered during a recent research operation.
At the time of writing, there were 11,320 cases of it detected and neutralized on 265 websites across 183 servers.
It is a particularly ingenious and potentially destructive type of malware: it is designed to appear as a legitimate image processor, and can act as a backdoor to your web server.
A backdoor is malicious software that lets a hacker get back into your server even after you detect and remove their access credentials. When a hacker gets into your site, the first thing they do is upload a backdoor.
Some backdoors can survive system upgrades, if they are skillfully written. As a result, a web server can be vulnerable forever, or until it is scanned and the malware detected and removed.
Our research team found two versions of this malware:
Both were uploaded to particular locations, such as:
/public_html/catalog/controller/affiliate/image.php
/public_html/admin/controller/design/image.php
/wp-content/index.php
At first glance, the first two locations seem normal. But the third is suspicious, because it is under the /wp-content directory.
This variant employs standard malware practices. It is obfuscated, the tactic most used by malware authors to hide malicious PHP code and its functions from a web hoster.
Even so, you can see something is wrong. It uses system-level functions such as eval, base64_decode, and gzinflate.
The presence of these functions doesn't mean the file is malware, only that it might be. The same goes for base64_decode and gzinflate, which have legitimate uses when used by conscientious programmers.
(I wrote about the problem of telling whether a file is good or bad in my earlier article, File System Friend or Foe? - How to Tell if a File is Good or Bad.)
In short, it depends on the context. There are no hard-and-fast rules that say the presence of system-level functions means the code is malicious. This is why we use advanced heuristics and signature-matching methods to detect malware.
This is simply the same code without obfuscation. In this case, the code seems innocent—it's using the function and variable names you'd expect to see in a real web server image processor. But look closer, and you'll see it's far from innocent.
Why does it seem legitimate, at first glance?
Look at the code at the top, lines 10-20. It uses width and height variables to process an image POSTed by the attacker. Why? To make HTTP requests appear in access logs as legitimate requests.
Notice how sensible default values for width and height (1024 × 768) are hard-coded for when an attacker chooses not to provide them. Lines 21-25 use these values to generate an image.
So, a cursory glance at the file would reveal nothing but a standard piece of image-processing code.
Our team's suspicion of this file started growing when we noticed create_function() being used in the middle of the code.
Looking closer, we saw that this was the core of a malicious payload, attempting to disguise itself by lurking within normal-looking portions of code.
See how it pulls a value out from the img POST parameter with $_POST['img'].
It inserts this value between two $imagewatermark parameters, like so:
$lmagewatermark.$_POST['img'].$imagewatermark
Next, it unravels layers of obfuscation on the merged value:
urldecode(gzinflate(urldecode(
The de-obfuscated value is then assigned to the $watermark variable.
Finally, create_function('',$watermark); creates a function that executes the de-obfuscated value as PHP code.
The latest versions of PHP have deprecated create_function(), for good reason: it is a popular way for malware authors to emulate functions like eval, assert, system, and others. Such functions allow arbitrary code to be passed through and executed by the web server's PHP module.
The author of this example avoids using these functions, knowing they would cause the file to be flagged as suspicious. By using create_function(), the malware can bypass scanners. It also looks inoffensive to the untrained eye when reviewing files manually.
As a web hoster that cares for the security of your websites, you are probably using a paid or free security solution to defend against hackers.
When a new kind of hacking campaign surfaces, most security companies get their hands on samples of the associated malware as soon as possible, to develop protection mechanisms against it. For the malware sample discussed here, the scenario is different.
Usually, a VirusTotal scan for a malicious file would turn up a few alerts from the main security vendors. But our sample was judged safe by 56 security solution engines. The hash for the sample is:
35bfc4692e7ccedfe9a868588d98c3c539d2255d9396c1fc4d480e849b326a10
If you have this kind of file in your web server, you most likely have a hacker's backdoor to your website, even if you've paid for a security solution to protect it.
But not Imunify360 customers.
Malicious backdoors pose serious threats to the security of a website.
An old proverb says,
"...better the devil you know, than the one you don't."
Known or detected malicious files are less of a threat than unknown ones.
The Malware Intelligence Team at Imunify360 do our best to stay one step ahead of hackers, by detecting and neutralizing threats as soon as they appear in the wild.
If you need to protect your web servers, please get in touch.
Thanks to Alexey Parfenov, Andrey Kucherov and Greg Zemskov for their help in writing this article.