A user has just uploaded a malicious file to my web server. There is nothing wrong with people uploading files, it is an image gallery and that is what they are supposed to do.
This user has uploaded the c99MadShell backdoor script. I very much doubt the user will be able to locate where the script has been uploaded as it gets moved to a folder with a difficult to guess name.
He has uploaded the file mad.php.gif. Since this is an image file extension, it was allowed.
This major problem is that the file is being executed on my server as a PHP file! No .htaccess files have been uploaded from what I can see.
Can anybody identify what the problem may be that has caused this file to be executed this way?
How are you so sure the file was actually executed? If it indeed was, I bet there is some sort of LFI (Local File Inclu(de/sion)) vulnerability in your application.
I can type the address directly into my browser complete with the .gif extension and it is being executed as PHP. I don’t understand how the vulnerability can be due to my application as I am accessing the uploaded file directly.
I am relativley confident that the person who uploaded it has not been able to use it as they won’t have been able to find the folder it was uploaded to.
This certainly does not sound great. Your server runs all GIF files through the PHP parser… first thing you need to do is to disable that (probably there’s a .htaccess file doing that).
Thanks for the link. It’s a very useful document. I have spoken to my webhost and they seem to think that anything that contains .php anywhere in the filename is being interpreted as a php file.
The issue of file uploads in PHP is a difficult one. My program requires that my users can upload image files. Almost every method of detecting file type available in PHP can be fooled one way or another. I always thought that using file extension would be the best idea, since if a script was ever hidden inside an image file then at least the web server would not try to execute the file. It looks like I was wrong.
Just rename the files, for example, use md5_file or sha1_file and use image_type_to_extension done deal. Make sure you don’t have any script that is including the images file.
These are function that I don’t like to rely on. It doesn’t seem to difficult to fool either of these functions by inserting some dummy data into the beginning of the file.
This is from the pdf file you linked to earlier:
Most image formats allow a text comment. It is possible to create a perfectly valid image file that contains some PHP code in the comment. When getimagesize() looks at the file, it sees a proper GIF or JPEG image. When the PHP interpreter looks at the file, it sees the executable PHP code inside of some binary garbage. A sample file called crocus.gif can be downloaded together with all the other examples in this article from http://www.scanit.be/uploads/php-fileupload-examples.zip . A file like that can be created in any image editor that supports editing GIF or JPEG comment, for example Gimp.
Correct you can put non-image data in a image file, but the format allows for that. This is why you do not have the web server treat such files as anything but images. (I.e. don’t pass them to PHP.) No matter what method you go with, the extra non-image data is going to go on by the check.
As long as the images are only ever treated as images the extra data they contain will not be a problem.
I wouldn’t bother. PNG, for example, works based on chunks, and you can have all sorts of combination of chunks of different sizes and have yourself a valid PNG file. A certain chunk type is tEX… And that’s not to say that other image formats can’t contain arbitrary text legally either.
As long as you don’t go including or executing random files on your server, you should be fine. Putting files outside a web accessible directory is always a good idea though. It’s possible to accidentally include files dynamically and have them execute, but IDEs these days warn you if a variable touches an include statement.
One thing to watch out, though, is that craptastic IE will read image files as HTML if they contain HTML and you view the image file directly. Easy fix is to force download.