Huge problem...Lost data, please help.

[influx]

Hi all,

I run a service for free teacher websites, hosted at my server, that is
very similar to a xanga or blogger blog.

I offer each user at my site the ability to upload five files (Allowed
filetypes: .html, .htm, .doc, .png, .rtf, .jpg, .jpeg, .gif, .pdf,
.ppt, .psd, .txt, and .xls) of up to 1 megabyte total.

The way I log each user's files is that I store the files, after
passing the necessary PHP tests, at a directory called _user_upload on
my website, stored in a specific username-based directory.

I had about 200 folders of uploaded files, and when I woke up this
morning, they were all gone. I use pure PHP to upload the files (and
MySQL to record file names and what-not). Has anybody heard of this
EVER happening before? There is no fishy activity at all on my
website, checked all the logs...I doubt it was hacked.

My server runs Red Hat 9 and I manage it remotely. Please, if anyone
can help me in any way...is there any way to retrieve the files in the
Red Hat 9 OS? Thanks so much.

-influx

[devinemke]

certain server/OS/filesystem configurations place limits on how many files can be stored in a single directory. i recall once on my commercial webhost hitting the 5000 file limit and the contents of the directory were invisible via FTP (the actual files were still there and available via shell).

[influx]

Hrm, I tried checking with 'ls -l' and it still doesn't show anything else.

Nobody has access to their uploaded files on my website

[pohopo]

It is because of this that I back up everything religiously.

[mtmosier]

Never had this happen to me, nor heard of it. If I were you I'd be looking at any usage of eval or system calls in your code to see if an injection attack is possible.

Easiest way to restore the files is to get them from backup of course. Otherwise whether it's possible or not is going to depend upon the filesystem type you're using. For example, with ext3 it's all but impossible. With reiserfs it's possible to get some data back, but certainly not easy. Ext2 has an undelete utility.

[influx]

Alright, I am under the impression that this may have been caused by my own incompetence with PHP and ask that somebody help in figuring out what may have caused it. PLEASE.

Here is what happens when somebody wants to upload a file.

1. Enter 'upload.php' -- lists all files uploaded, gives option to add new file, remove certain file, or remove all files (max 5 files, max 1 mb uploaded).

2. If user chooses to add new file, they enter 'upload_add.php' -- asks for file path allows them to upload.

3. After file added, redirect to 'upload_test.php' -- this file handles all three options: adding files, deleting one file, deleting all files.

I save all files in a directory on my server called _user_upload in a username-specific subdirectory. All filenames are stored in the MySQL database

I will put the code for upload_test.php here (minus superfluous material like filesize checks and whatnot), code 1 relates to adding a file, code 2 relates to deleting one file, and code 3 relates to deleting all files for specific user.

<?php
$path_prefix='../../'; //set root directory for template reference
$code=$_GET['code']; //code 1 is upload one file, code 2 is remove single file, code 3 is remove all files
$fileid=$_GET['f']; //file number
$_SESSION['username']=strtolower($_SESSION['username']); //lowercase username

if($code==1) //upload one file
{
	//Replace spaces with underscores, and no characters allowed, numbers and letters only, periods and underscores acceptable, everything lowercase
	$form_data_name = ereg_replace('[ ]+', '_', strtolower($_FILES['userfile']['name']));
	$form_data_name = ereg_replace('[^a-zA-Z0-9._]', '', $form_data_name);

$form_data_size = $_FILES['userfile']['size']; 
//get file extension in next two lines
$fileInfo = pathinfo($_FILES['userfile']['name']);
$form_data_extension = $fileInfo['extension'];

//if file doesn't match one of the extensions listed below, redirect and give err code 5
$allowExtensions = array('html', 'htm', 'doc', 'png', 'rtf', 'jpg', 'jpeg', 'gif', 'pdf', 'ppt', 'psd', 'txt', 'xls'); //add the ones you require here
$fileInfo = pathinfo($_FILES['uploadname']['name']);
if(!in_array($form_data_extension, $allowExtensions))
{
	header('Location: upload_add.php?code=5&f='.$fileid);
	exit;
}

//if file already exists in slot, delete old and upload new file
$ress=mysql_query("SELECT * FROM upload WHERE u_username='".$_SESSION['username']."'"); //fetch upload information
$row=mysql_fetch_array($ress);
$old_file_name=$row["u_file".$fileid."_name"];

if($old_file_name)
{
	unlink("../../_user_upload/".$_SESSION['username']."/".$old_file_name);
}

//check if user-specific directory exists, if not, make directory
if(!file_exists($path_prefix."_user_upload/".$_SESSION['username']."/"))
{
	mkdir($path_prefix."_user_upload/".$_SESSION['username']);
	chmod($path_prefix."_user_upload/".$_SESSION['username'], 0774); //chmod it, read/write for user, group.
}

//now that file is not malicious and has passed all tests, move it from tmp to upload directory
$targetdir = $path_prefix."_user_upload/".$_SESSION['username']."/";
move_uploaded_file($_FILES['userfile']['tmp_name'], $targetdir.$form_data_name);

$query = "UPDATE upload
SET u_file".$fileid."_name = '".$form_data_name."',
u_file".$fileid."_date = '".date("m.d.Y")."'
WHERE
u_username = '".$_SESSION['username']."'";
mysql_query($query) or die(mysql_error());

chmod($targetdir.$form_data_name, 0754); //chmod it, read/write for user, group, and world.

header('Location: upload.php?code=1&f='.$fileid); //if file uploaded successfully, redirect and give success code 1
exit;
}

if($code==2) //remove single file
{
	$ress=mysql_query("SELECT * FROM upload WHERE u_username='".$_SESSION['username']."'"); //fetch upload information
	$row=mysql_fetch_array($ress);
	$file_name=$row["u_file".$fileid."_name"];

//delete file:
if(file_exists($path_prefix."_user_upload/".$_SESSION['username']."/".$file_name))
{
	unlink($path_prefix."_user_upload/".$_SESSION['username']."/".$file_name);
}

$query = "UPDATE upload
SET u_file".$fileid."_name = '',
u_file".$fileid."_date = '00.00.0000'
WHERE
u_username = '".$_SESSION['username']."'";
mysql_query($query) or die(mysql_error());

header('Location: upload.php?code=2&f='.$fileid); //if remove single file successful, redirect and give success code 2
exit;
}

if($code==3) //remove all files
{
	//remove user directory...function found at http://aidan.dotgeek.org/lib/?file=function.rmdirr.php
	function rmdirr($dirname)
	{
		// Sanity check
		if (!file_exists($dirname))
		{
			return false;
		}

	// Simple delete for a file
	if (is_file($dirname) || is_link($dirname))
	{
		if (!file_exists($dirname))
		{
			return true;
		}
		return unlink($dirname);
	}

	// Loop through the folder
	$dir = dir($dirname);
	while (false !== $entry = $dir->read())
	{
		// Skip pointers
		if ($entry == '.' || $entry == '..')
		{
			continue;
		}

		// Recurse
		rmdirr("$dirname/$entry");
	}

	// Clean up
	$dir->close();
	return rmdir($dirname);
}

if(rmdirr($path_prefix."_user_upload/".$_SESSION['username']))
{
	$query = "UPDATE upload
	SET u_file1_name = '',
	u_file1_date = '00.00.0000',
	u_file2_name = '',
	u_file2_date = '00.00.0000',
	u_file3_name = '',
	u_file3_date = '00.00.0000',
	u_file4_name = '',
	u_file4_date = '00.00.0000',
	u_file5_name = '',
	u_file5_date = '00.00.0000'
	WHERE
	u_username='".$_SESSION["username"]."'";
	mysql_query($query) or die(mysql_error());
}
header('Location: upload.php?code=3'); //if remove all files successful, redirect and give success code 3
exit;
}
?>

I really hope that isn't too much, but I would really like a few people to look at it and see if it's safe/secure, if chmod permissions are alright, if this is the best way to implement, etc.

Thanks a ton.
-influx

[mtmosier]

I only really looked at the beginning and the code 3 section. Looks to me that if $_SESSION['username'] were empty you could delete the entire directory. Could you post the code where you check that the user is logged in and has a valid username during this page request?

[influx]

Sure thing, on every member page I require the following database connect script, and inside this I include the check_login script:

db_connect.php:

<?php
require_once 'DB.php';

$db_engine = 'mysql';
$db_user = 'idiot';
$db_pass = 'tart';
$db_host = 'blah.net';
$db_name = 'website';

$datasource = $db_engine.'://'.
			  $db_user.':'.
			  $db_pass.'@'.
		 	  $db_host.'/'.
	  		  $db_name;

$db_object = DB::connect($datasource, TRUE);

/* assign database object in $db_object, 

if the connection fails $db_object will contain

the error message. */

// If $db_object contains an error:

// error and exit.

if(DB::isError($db_object)) {
	die($db_object->getMessage());
}

$db_object->setFetchMode(DB_FETCHMODE_ASSOC);

// we write this later on, ignore for now.

include('check_login.php');
?>

check_login.php:

<?php
session_start();

if (!isset($_SESSION['username']) || !isset($_SESSION['password'])) {
	$logged_in = 0;
	return;
} else {
	// remember, $_SESSION['password'] will be encrypted.

if(!get_magic_quotes_gpc()) {
	$_SESSION['username'] = addslashes($_SESSION['username']);
}

// addslashes to session username before using in a query.
$pass = $db_object->query("SELECT password FROM users WHERE username = '".$_SESSION['username']."'");

if(DB::isError($pass)) {
	$logged_in = 0;
	unset($_SESSION['username']);
	unset($_SESSION['password']);
	// kill incorrect session variables.
}

$db_pass = $pass->fetchRow();

// now we have encrypted pass from DB in 
//$db_pass['password'], stripslashes() just incase:
$db_pass['password'] = stripslashes($db_pass['password']);
$_SESSION['password'] = stripslashes($_SESSION['password']);

//compare:
if($_SESSION['password'] == $db_pass['password']) { 
	// valid password for username
	$logged_in = 1; // they have correct info
				// in session variables.
} else {
	$logged_in = 0;
	unset($_SESSION['username']);
	unset($_SESSION['password']);
	// kill incorrect session variables.
}
}

// clean up
unset($db_pass['password']);

$_SESSION['username'] = stripslashes($_SESSION['username']);
?>

Thanks.

Please NOTE: I set the SESSION username and password upon logging in using a different file.

[influx]

Shoot, could it be possible that somebody's session expired after opening the upload.php page, and unknowingly clicked the 'REMOVE ALL' button (code 3)?

If that happened, would their $SESSION['username'] be NULL? Thus, getting rid of the whole user_upload directory?

Thanks.

[mtmosier]

Assuming they could run upload_test.php without being logged in (if $logged_in were not checked for upload_test.php), then yes, that could happen. But I'm assuming that wouldn't be possible from the code you posted.

You could always give it a try to be sure. On a test environment go to upload_test.php?code=3 and see what happens.

(I also assume you previously tested your check_login to make sure it works if there is no username or password set.)

[influx]

Yeah, but is there any way that $_SESSION['username'] could be stored as NULL? Even though I check their login information at every page, could their session somehow timeout right before clicking the link?

I am almost sure I wasn't hacked, it's not even a big site and it's fairly secure. And plus, everything else remains untouched, just a really clean erase of the _user_upload directory.

A few questions though:

1. My access_log is one gigabyte, and I want to view it using putty on my remote linux server. To view the last few 100 lines (past 24 hours or so) from the access_log, what command would I have to type?

2. Is my upload script alright in general? Is it secure enough...is it a bad idea to store them in such obvious directories? (i.e: _user_upload/myusername)

3. I set the chmod permissions on each directory/file in the upload script. Are these permissions alright to use? Should I consider different r, w, e permissions?

[mtmosier]

Even though I check their login information at every page, could their session somehow timeout right before clicking the link?

Yes, their session can timeout before clicking the link. However it cannot timeout halfway through page processing. As long as you check the session information during the processing of upload_test.php then session timeout shouldn't affect you here.

To view the last few 100 lines (past 24 hours or so) from the access_log, what command would I have to type?

tail -1000l access_log

Is my upload script alright in general?

$ress=mysql_query("SELECT * FROM upload WHERE u_username='".$_SESSION['username']."'");

I'm sure you limit the possible characters in username, but if you didn't this would be a sql injection attack. You should always use mysql_real_escape_string.

$query = "UPDATE upload
SET u_file".$fileid."_name = '".$form_data_name."',
u_file".$fileid."_date = '".date("m.d.Y")."'
WHERE
u_username = '".$_SESSION['username']."'";

If you don't check that $fileid is valid this would be vulnerable to sql injection.

mysql_query($query) or die(mysql_error());

Displaying the error to the user helps make sql injection attacks easier.

header('Location: upload.php?code=1&f='.$fileid);

Should url encode any values you put into a url. If you display f on that page this would be an xss attack.

$ress=mysql_query("SELECT * FROM upload WHERE u_username='".$_SESSION['username']."'"); //fetch upload information
$row=mysql_fetch_array($ress);
$file_name=$row["u_file".$fileid."_name"];

//delete file:
if(file_exists($path_prefix."_user_upload/".$_SESSION['username']."/".$file_name))
{
    unlink($path_prefix."_user_upload/".$_SESSION['username']."/".$file_name);
}

You didn't check that the result was valid, or that $file_name contained anything. You could unlink your user directory here. Which, being a directory, would do nothing. But still...

Is it secure enough...

I don't recall seeing any code beyond "Hello World" which couldn't do with some more security. 🙂 Anyway, I may have missed something, but I didn't see any problems which I can see causing the issue you asked about. Keep in mind I'm not a security expert though.

is it a bad idea to store them in such obvious directories? (i.e: _user_upload/myusername)

That depends on whether you believe in security through obscurity or not. I don't. So long as you protect your scripts and files as needed you should be fine.

Are these permissions alright to use?

I see nothing wrong with them, but that really depends on a great many details I'm sure you don't want to get into here.

[influx]

Thanks a lot, mtmosier, for your input.

I just realized, could the Googlebot have caused this to occur? I was looking at my access log and I noticed that around the time of the deletion of all the user-upload directories, Google was crawling my site...everywhere. I just recently put up a 'Google Sitemap' to their new service and don't have a robots.txt file anywhere restricting their access to the pages. So if Google had the sitemap, is it possible that it somehow spurred the removal of all user's directories, by crawling through the website, one-by-one?

Now, back to what you wrote, I have a few questions:

1) About the SQL injection method you were talking about, could you reiterate what exactly it does? There are no spaces allowed in usernames, they must be three characters long, and can only contain a-z0-9 and underscores. Could my site still be vulnerable to injection?

2) You are absolutely right about the $fileid vulnerability. I could check to see that file id is only 1, 2, 3, 4, or 5. What would happen if somebody manually changed it to 99? It couldn't hurt...it would just give them a MySQL error. Right?

3) I am considering to ease the possibility of this ever occurring again (because I still have no idea what caused it), I will get rid of the code 3 remove all feature. I will just make them remove each file one-by-one. That can't be too difficult and will make it a lot easier for me. Is this a bad idea?

4) Why would I consider URL-encoding $fileid in the url? Would it thwart an 'xss' attack? It won't change anything, will it?

5) Should I set the permissions to only allow a super user to delete files in the /_user_upload directory? Had I set the permissions on very restricted, would this have even been able to happen in the first place (whether or not I was hacked or had a flaw in my code?)

Thanks a lot, again. This has been a great help.
-influx

[mtmosier]

If this page requiers a user to be logged in, then I don't see how google could affect it. There aren't any links publicly available which automatically log people in without entering a password, are there?

1. As long as you limit the username as you describe, you shouldn't have a problem here. However best practice is to always escape values included in sql queries. In this case the idea would be what if in the future the username requirements changed to something less restrictive, and the person making that change (not necessarily you) forgot/didn't know to update this page as well?

2. Basically the idea is that instead of changing it to 99, an attacker would change it to something like "1_name = ''--". Check the manual for a discussion on sql injection.

3. Anything that makes life easier for you and does not cause too great an inconvience is a good idea I'd say. Security wise, there's no reason that feature couldn't be in there and be secured.

4. You're right, I have no idea what I was saying. 🙂 Good practice is to always encode values passed in the url, but I'm not aware of any security related issues here. Sorry.

5. The user the web server runs as needs permission to write and delete files, so I don't see how that would be plausible.

[influx]

Some more questions, thanks a LOT for your response:

1) Are both my chmod permissions set correctly for folders and files? I am told to be very careful with these.

2) Is my upload script vulnerable with propagating either 'code 1' or 'code 2' through the URL? I mean, can they tamper with the 'code number' as you mentioned earlier to replace it with something completely different? Should I use $POST instead of $GET to send either 'code 1' (remove file) or 'code 2' (add file)? It's not possible to execute an "SQL Injection" manually changing the code number, right?

3) Is the script foolproof? Some vulnerabilities I see possible are changing the $fileid or the $code.

4) Could they still upload malicious files and execute them on the server? Even if I only accept the following filetypes: .html, .htm, .doc, .png, .rtf, .jpg, .jpeg, .gif, .pdf, .ppt, .psd, .txt, and .xls?

5) I have a feeling this could have been the result of the Googlebot because I recently uploaded a Sitemap to their new web app Google Sitemaps...and around the time I lost all the data was when they were crawling my website. Should I disallow Googlebot into the 'member/upload' directory on my site using a robots.txt?

Thanks in advance fellas...I really appreciate the help.

Cheers,
-influxer

[maxpup979]

note: I didnt follow this thread too closely. But I have had exactly the same thing happen to me. A spider crawling my site was following delete links, and deleting every single file.

The quick and dirty fix is to only allow deletes to be triggered by forms.
Good luck!

[influx]

maxpup979 wrote:

The quick and dirty fix is to only allow deletes to be triggered by forms.
Good luck!

What do you mean? Could you give a quick example?