How is a website hacked by a "maliciously encoded image that contained a PHP script hidden inside it"?

Question

My ad server has been hacked over the weekend.

It seems to be a widespread problem, according to this article.

There is something in there that got me thinking...

Attackers used one attack to get login rights to his server, and then uploaded a maliciously encoded image that contained a PHP script hidden inside it, he said. By viewing the image, attackers forced the script to execute on the server

How is this possible? Does it rely on the image being opened with GD or similar? Do they upload a script posing as an image, and somehow include it?

Tubercle

Answer 1

It can be as simple as uploading a file like

GIF89a<?php
echo 'hi';

If your upload script tests the content type via fileinfo or mime_content_type() it is recognized as "GIF image data, version 89a" since GIF89a is the only pattern/magic number that is required to identify a file as gif.
And the OpenX upload script apparently kept the proposed filename, i.e. it was possible to save this "image" as foo.php on the server. Now, if you requested that file via http://hostname/uploaddir/foo.php the script was executed as a php script because webservers usually/often determine the content type only by the filename extension, e.g. via

<FilesMatch "\.php$">
    SetHandler application/x-httpd-php
</FilesMatch>

php then echoes the leading GIF89a and executes the <?php ...code... block.
Putting the <?php block into a gif comment is slightly more sophisticated but basically the same thing.

Summitry

see secunia.com/advisories/37475 : "The vulnerability is caused due to the banner-edit.php script allowing the upload of files with arbitrary extensions to a folder inside the webroot." – Summitry

Wow, even the file utility in Linux is fooled by this! – Irreligious

Answer 2

Your server is parsing that file for w/e reason. The attackers are putting the PHP into the image comment.

How are you validating the file is an image? If you do it solely on mime type, then I believe they can fake the image header and include whatever they want after that. VolkerK has a practical example

In the perfect world, I wouldn't serve any public facing images via PHP for fear of such an issue.

Serve the image directly using the server; A good suggestion is to save those images to a directory where they can be served without PHP.

I think that's the gist of it, someone correct me if I'm wrong.

Schindler

How does one add code to an image via the comments? I'm interested in making an image to test some of my other sites. – Tubercle

So basically, you're saying the same as me, right? The image gets included. How else would the server execute it? – Dabchick

Any standard image editor will be able to do it. Here's how you add a comment in GIMP: img192.imageshack.us/img192/4104/createanewimage001.png – Schindler

@The The point is not how you're able to embed the PHP code. It's why is the server executing it. – Dabchick

see secunia.com/advisories/37475 : "The vulnerability is caused due to the banner-edit.php script allowing the upload of files with arbitrary extensions to a folder inside the webroot." – Summitry

It might be even worthwhile to load the image data via imagegif() or similar and then save that file with a fixed filename extension, though it puts considerably more strain on the server. – Summitry

Answer 3

The only possibility I see for a server compromise is the image being included instead of read through e.g. readfile and other stream functions.

Dabchick

You are right, but maybe I'm missing something, why would anyone include an image? Maybe some poor PHP based cache control that instead of echo readfile($file) after custom headers it just includes. – Tubercle

@Tubercle I don't know why someone would do that, but I've seen it on SO. – Dabchick

Yeah, I've seen this kind of mistake, too, in production code. That's as bad as it can get. – Summitry