Malware in Metadata

One of the systems I have been running collects all our web malware detections for .ES domains. I usually check it out every morning, just in case I see something especially interesting or relevant. And when I find something, I like to create some statistics to have a global overview.

There are some things that I find every time I check my stats, like URLs that have been infected for more than 200 days, even being notified. That speaks of the lack of security awareness on some companies, and how some websites just get abandoned and become a hive of malware.

However one of the things that drew my attention was the detection of many PHP Backdoors with not-so-common extensions, such as JPG or MP3. Maybe a false positive? Worth taking a look!

Some of them are just typical obfuscated PHP code implementing the well known C99Shell using a different extension, in this case JPG or MP3:

Also it was possible to find JavaScript code and iframes attached at the end of legitimate JPG files:

Obviously if the web server is well configured these files will never get executed. In the first case, not even the images will be correctly interpreted, which should be quite obvious for any administrator as a sign that something is wrong.

In the case of iframes being appended, the images are correctly displayed (JPEG is a really flexible format) but the iframe will not be executed. Why is it put there? There is no reason, just automatic and noisy scripts appending this iframe at the end of any file found in the webserver once an attacker gets access, probably using automatic tools.

However there was something really interesting in some JPG files.

These strings correspond with the EXIF data of the image.

Please note the EXIF PHP code in Model information, but also the string ?/.*/e in Maker. This code translates into:

Basically, evaluates whatever it gets through the POST parameter zz1. But its an image, how does this code get executed? Thanks to the PHP exif_read_data function –

The PHP function preg_replace will interpret the content as PHP code thanks to the string ?/e (the Maker field in the EXIF data). This will execute the eval code in the second EXIF field (Model). So basically this is a backdoor that will execute any command inside the zz1 POST parameter. The ?/e pattern modifier is deprecated since PHP 5.5.0, thats good news.

So basically its a two component backdoor: a JPEG file with malicious EXIF data, and a PHP code that executes it. This PHP code can be easily inserted into any other PHP file found in the server, probably not noticed as malicious in a quick check.

The image is nicely interpreted, this code does not affect the visualization, as it is only EXIF data:

When you discover something like this, you quickly check the Internet. Unfortunately I missed that some colleagues had already discovered this technique back in June:

http://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html

The EXIF malicious code is the same in all the analysis, as well as in all the images I have found. I already know this code has been found in some targeted attacks, although it was not directly related, apparently.

The most probable explanation is that this technique was used in a single campaign, automatically infecting some hundreds of websites. Checking the profile of the infected sites, probably they were exploiting a Joomla vulnerability. However this hasnt been confirmed yet. Also, once this technique was known, it could have been reused.

Thanks to KSN, we can check in our own statistics for the geographical distribution of our detections:

It does not mean that the infected servers are necessarily in these countries, however this is most likely. Googling for this string, more than 1,300 sites are found.

This campaign teaches us a lesson: we should never underestimate any attacking vector. Usually 9 out of 10 web admins will skip considering image files as dangerous. Now we know this is not necessarily true.

Metadata has been always considered a problem in terms of privacy; however it is now another covert channel for attackers. Playing with some ideas, I havent found an easy way of reproducing this same attack using Metadata in other file formats, such as PDF, but it doesnt mean it is not possible.