Upload Security- help with protecting against executable files

[clkwebdesign]

I have a bit of a dilemma at my job, our website was recently hacked and someone was able to (what we think happened) upload a file that put JavaScript on a bunch of our web pages. This script inserted a frame on pages that were named index, home and main with .html and .php extensions. This code pulled information in from a known malware website.

 

We have since changed all our login names and passwords and removed the code but the threat still remains. We think the problem is with the upload code, the code is very basic right now, all it does is disallow certain file extensions, which we all know isn't very helpful. I can rename extensions or add extra extensions to the end of files and the upload still works.

 

There is not enough budget available for us to fix the aforementioned problems, but what we think will work is changing the chmod on uploaded files to 0666 so the files cannot be executed.

 

I'm planing on using the PHP chmod() function to do this but my question is; Will this work to protect against executable files?

 

I'm not sure how the hacker did this in the first place so I have no idea what type of file was used to to put this code on all of our pages (two directories deep). This happen all at the same time so I am positive it wasn't done by hand.

[Psycho]

We think the problem is with the upload code, the code is very basic right now, all it does is disallow certain file extensions, which we all know isn't very helpful. I can rename extensions or add extra extensions to the end of files and the upload still works.

 

I always advocate using "White Lists" (list of acceptable values) instead of using "Black Lists" (list of unacceptable values). The problem with a black list (disallowing certain file extensions) is that it you can't be 100% certain there are not other items that could be a problem. If you were to only allow .txt files to be uploaded it probably wouldn't be an issue. But, if you are only excluding some file types are you sure there are not others that can be executed by the web server (e.g. .php4)? Just set a list of safe file types and only allow those to be uploaded.

 

Secondly, wherever these files are uploaded you should restrict direct access to those files by the user. If the user needs access to the files you should identify the file by ID and only allow the user to download the file using a download script.

[roopurt18]

I have a bit of a dilemma at my job, our website was recently hacked and someone was able to (what we think happened) upload a file that put JavaScript on a bunch of our web pages. This script inserted a frame on pages that were named index, home and main with .html and .php extensions. This code pulled information in from a known malware website.

 

You need to find out exactly how they hacked you or you may just end up wasting your efforts, especially since you say there is no budget.

 

I don't see how taking away the execute permission from uploaded files is going to protect you.  Most of the time (and it depends on your application), when uploaded files are viewed again later they are not execute but just served by Apache or IIS.  They only get executed if:

+ the file itself is a scripting file, such as PHP,

+ if a PHP script calls exec() or a similar command on the file

+ or if someone executes it from the shell or command line

 

Turning off the execute bit will only protect you from the last two of those and not the first.  Even your extension check should protect against the first one since the extension has to be one that the web server associates with the PHP parser.  For example, if you reject all files with a .php extension but I upload PHP code with a .txt extension, when requested by Apache it will not go through the PHP parser because the .txt extension is not associated with PHP by Apache (unless you changed your configuration).

 

Does your site allow for users to post comments?  It's more likely that you are not escaping output from the database before passing it to the browser.  If this is the case, someone may have posted JavaScript as a comment that modified the DOM on page load.

[Andy-H]

http://www.phpfreaks.com/forums/index.php/topic,252960.0.html

 

Is that the same problem, I have seen 3 of these same injection attacks posted here in the past two days... ?

[Andy-H]

Just googled you and my anti-virus blocked an attack.

 

http://securityresponse.symantec.com/security_response/writeup.jsp?docid=2008-080702-2357-99

 

 

[cringe]

Like someone else said, compare the file extention to a whitelist. (assuming they uploaded a file via PHP).

 

$ext_whitelist = array('gif', 'jpeg', 'png');
$path = '/path/to/myScript.php' ;
$file_ext = strtolower(pathinfo($path, PATHINFO_EXTENSION)); 
if (! in_array($file_ext, $ext_whitelist) {
   // invalid
}

 

And when you move the file from the uploaded folder to a permanent folder, it's a good idea to rename the file slightly, prepend some random characters onto the end before the file extension. Hackers can't run the file easily if they don't know where you put it and what you renamed it too.

 

CR

[clkwebdesign]

Thanks for all the replies I appreciate this, I'm new to PHP and have inherited a poorly assembled CMS.. my job duties have quickly gone from installing the CMS, creating CSS websites and PHP templates to fix the CMS with lots of holes in as little time as you can.

 

I always advocate using "White Lists" (list of acceptable values) instead of using "Black Lists" (list of unacceptable values).

 

Okay the more I read up on this the more I know I phrased my first statement wrong, we are using a white list of sort, this is what it looks like:

 

if ($ext == "pdf" || $ext == "doc" || $ext == "txt" || $ext == "PDF" || $ext == "DOC" || $ext == "PNG")
		{
		$good_file=1;
		}
else {
		$good_file=0;
		$error[] = "The file extension must be .pdf, .doc, or .txt<br>";
		}

 

The code puts the file name in an array, explodes it then looks for the first period and reads whats after it. Just noticed the upload reads upper case and lowercase as to unique names- which is one more thing I'm going to fix if I can, other wise I'll be wasting time making exceptions.

 

Secondly, wherever these files are uploaded you should restrict direct access to those files by the user. If the user needs access to the files you should identify the file by ID and only allow the user to download the file using a download script.

 

We are sort of doing this, it could be more secure if we put the files above the web level, that's one thing we might need to change.

 

You need to find out exactly how they hacked you or you may just end up wasting your efforts, especially since you say there is no budget.

 

Yes I agree, I have no idea were to start though.

 

Does your site allow for users to post comments?  It's more likely that you are not escaping output from the database before passing it to the browser.  If this is the case, someone may have posted JavaScript as a comment that modified the DOM on page load.

 

Our CMS is only accessible by password, which we have changed, but because of the login, the original developer saw no need to escape the output from the database, we are using escaping for the impute text. Should we be escaping both?

 

http://www.phpfreaks.com/forums/index.php/topic,252960.0.html

Is that the same problem, I have seen 3 of these same injection attacks posted here in the past two days... ?

 

Its similar but not the same web address, ours was from copyolist.com/image/index.php and it added an iframe to the site.. I have the code somewhere, I saved it, can't seem to find it right now though.

 

 

Just googled you and my anti-virus blocked an attack.

 

I was unsure of what you meant by this, so I googled the username that I registered with and I saw this link too. My username on this forum is far from my actual web address, maybe I should ask to change my user name?

 

And when you move the file from the uploaded folder to a permanent folder, it's a good idea to rename the file slightly, prepend some random characters onto the end before the file extension.

 

Good idea, for photo galleries, how would I hide this path from the hacker? Users have the ability to edit their files after they are uploaded, should I put the white list in the edit section too in case the hacker renames the file extension after uploading or is there a better way to check a file to see if it is what the extension says it is?

 

Thanks for all the help, I hope I can return the favor to others some day.

 

[roopurt18]

Our CMS is only accessible by password, which we have changed, but because of the login, the original developer saw no need to escape the output from the database, we are using escaping for the impute text. Should we be escaping both?

 

You should always sanitize data appropriately for whatever database you are using; each database has its own sanitizing function which I'm sure is what you're using.

 

However, sanitizing the data for the database is not the same as sanitizing it for output.  If comment posted includes JavaScript, the db-sanitize makes it safe to store in the database.  But when you query it and send it to the user's browser they still get JavaScript.  If you don't want that sort of thing to happen you need to call htmlentities() or striptags() (or another function) on database data before sending it to the browser.

 

Some people will tell you to "clean" the data in this fashion only upon insertion or updating of your database.

 

For example:

<?php
$name = $_POST['name'];
$stmt = sprintf( "insert into sometable ( name ) values ( %s )", db_sanitize( htmlentities( $name ) ) );
$pdo->query( $stmt );
?>

 

The logic here is that since htmlentities() was called on the data before insertion into the database, it is safe to display to the browser.  I don't have time to go into the details of why but this is a terrible way to do things.

 

1) Call the appropriate db_sanitize() method for your database before data insertion

2) Call the appropriate escape() method for your output medium before output (i.e. call htmlentities() if displaying to a browser)