Is it possible to execute PHP with extension file.

Question

Site legit file image_upload.php was used to upload file 89471928047.php.jpg Which was simple file upload form that copy tmp file to same images folder. How they managed to execute it and upload other files trough it. Someone know how this is possible? PHP version was 5.1.6 that being updated exactly hour ago or after by schedule with host to 5.3.8... what a, coincidence?

Answer 1

Check your .htaccess file

Using AddType in your .htaccess file, you can add many other extensions from which PHP can be ran. This is generally how .html extensions can be used while still using PHP within themselves. So, yes, it's possible:

AddType application/x-httpd-php .jpg

You can test this if you like.

1. Create a directory with two files: .htaccess and test.php.jpg
2. Set content of .htaccess to AddType application-x-httpd-php .jpg
3. Set content of test.php.jpg to <?php echo 'foo'; ?>
4. Access test.php.jpg through localhost

If all goes as planned, "foo" will be output to your screen. You could expand upon this to move /tmp files around if you like.

Definitely something you want to be very careful with.

Check exposed calls to include/require

Another way this could have been done is through a call to require() or include() (or any of the _once() methods) where by the hacker was able to load in his badfile.php.jpg file that had been uploaded under the guise of an innocent image:

<?php

  include $_GET["file"];

?>

In the above case (simplified example), the hacker could pass in a path to his .php.jpg file and have its contents loaded in and processed as PHP code.

Other (frightening) ideas

Require, Include, and their related methods aren't the only ways you can process external scripts - unfortunately you can use eval() as well. I would hope that you have none of this going on though. If you did have any scripts on your server that were using any one of the file functions to read the contents of another script, and then eval() to evaluate that content as PHP, this could also provide a gaping security hole in your website.

Answer 2

The problem is caused by your server using the default /etc/httpd/conf.d/php.conf:

rpm -ql php-5.1.6-39.el5_8
/etc/httpd/conf.d/php.conf
/usr/lib64/httpd/modules/libphp5-zts.so
/usr/lib64/httpd/modules/libphp5.so
/var/lib/php/session
/var/www/icons/php.gif

The content of /etc/httpd/conf.d/php.conf is:

#
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
#
<IfModule prefork.c>
  LoadModule php5_module modules/libphp5.so
</IfModule>
<IfModule worker.c>
  # Use of the "ZTS" build with worker is experimental, and no shared
  # modules are supported.
  LoadModule php5_module modules/libphp5-zts.so
</IfModule>

#
# Cause the PHP interpreter to handle files with a .php extension.
#
AddHandler php5-script .php
AddType text/html .php

Please note the last line AddHandler php5-script .php . This is causing that problem and needs to be replaced with a more secure configuration

You can read more about it and how to apply a fix here ( see last reply):

http://core.trac.wordpress.org/ticket/11122

also see this:

https://bugzilla.redhat.com/show_bug.cgi?id=885839

Answer 3

Your image_upload.php is insecure, check the following:

1. does it allow only image extensions? Otherwise it would be possible to upload directly a PHP file. (I think you're covered on this one, but double check).
2. does it check that the uploaded file is indeed an image? Here the answer is no, it doesn't check the contents. Add this check! With this single step you'd close the initial breach.

To check if it's an image you can run getimagesize on the file, it will return FALSE if it's not an image.

How is it possible to execute that file? First, how do you know it has been executed? Did you see side effects?

1. One way is that they could have tampered other files
2. A second way, perhaps more probable is that they used unsanitized inputs from your scripts to either include or eval the code. In this case you can find proof only by looking at the logs.

How to look at the logs?

Check the date and time of the uploaded file and start to look around there for suspicious activity (look at strange url parameters). Once you've find one or more IP address, doing evil things, grep the log for that (those) IPs, to see the whole story.

Another important info to know is, did you write the site or use a CMS or similar and in this case what is it and what version? You've to check published vulnerabilities and upgrade in case.