Errors in PHP Logs - Possible hacking attempts?

[billjust]

I've been getting odd entries in our PHP error logs that look something like this:
[05-Feb-2008 07:51:26] Cannot connect to [url]www.ourwebsite.comhttp:80[/url] - (52687668)
[05-Feb-2008 07:51:26] Cannot open http://www.ourwebsite.comhttp://bizzarewebsitename.com/.images/pictureofme?
[05-Feb-2008 07:51:26] Could not fetch: http://www.ourwebsite.comhttp://bizzarewebsitename.com/.images/pictureofme?

Obviously 'ourwebsite' and 'bizzarewebsitename' is different, but the rest is the same. I'm not sure if this is someone hacking our site or just try to relay through it or something, but I don't think it's working for them. Does anyone know how to interpret this and what I could do to stop this traffic?

Thanks in advance!

[bradgrafelman]

Look on the line number given for any include(), file_get_contents(), etc. where you take user-supplied input to define the path.

You should never simply take a user-supplied variable (e.g. from $GET, $POST, $_COOKIE, etc.) and simply stick it in a path argument - this will allow malicious users to have your webserver retrieve and serve up content from other sites.

[billjust]

Thanks for the response. As you can probably guess, I'm a bit of a neophyte when it comes to php (we had an outside guy code the site). When you say to look on the line number, where is that indicated in the logs? Is it that '52687668'?

[Weedpacket]

Um, I doubt your logfile has fifty two million lines in it (it might, but I doubt it). I seriously doubt that any of your PHP scripts have fifty two million lines in them.

Have you quoted the entire error message? PHP's error messages typically look more like

[06-Feb-2008 19:32:03] PHP Warning:  Cannot open '/foo/bar/wibble.txt' for reading in /foo/bar/blag.php on line 42

[billjust]

Actually, that's literally all that comes up in the php log. Now, since you mentioned it, I did a bit more investigation and this is where it gets interesting. In my Apache access logs, I see these entries like these at the same time:
92.233.77.31 - - [06/Feb/2008:04:10:00 -0600] "GET /print.php?file=http://bizzarewebsitename.com/.images/pictureofme? HTTP/1.1" 200 863 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)"

That print.php reference is part of an on-the-fly PDF creator we use. Basically, we have certain pages with links in them that users can click on to automatically create a pdf of that page for file saving or printing. Only the entries involving the print.php command have these weird websites next to them. Can I assume our coder did not follow the proper programming procedures that Brad cites above?

[NogDog]

Yeah, it looks like possibly something in the PHP is taking that file value and trying to process it as is. Usually for something like that where you are using a GET value to process a file, I would do something like:

$dir = 'directory/with/legitimate/files/';
$file = $dir . basename($_GET['file']); // gets just the file name with no directory stuff
if(file_exists($file))
{
   // do something with $file
}
else
{
   // invalid file specified in GET data
}

[billjust]

Thanks for the response. Attached is our code in the print.php file. It looks very similar to what you've suggested. Is there some difference we can make that would prevent our problem?

$file= 'http://'.$_SERVER['SERVER_NAME'].$_GET['file'];
$product_name = !empty ($_GET['product_name']) ? $_GET['product_name'] : 'product.pdf';

if ($file != '')
{
	global $g_config;
	$g_config = array(
					  'cssmedia'     => 'print',
					  'renderimages' => true,
					  'renderforms'  => false,
					  'renderlinks'  => true,
					  'mode'         => 'html',
					  'debugbox'     => false,
					  'draw_page_border' => false
					  );

$media = Media::predefined('A4');
$media->set_landscape(false);
$media->set_margins(array('left'   => 0,
						  'right'  => 0,
						  'top'    => 5,
						  'bottom' => 0));
$media->set_pixels(800);

global $g_px_scale;
$g_px_scale = mm2pt($media->width() - $media->margins['left'] - $media->margins['right']) / $media->pixels;

global $g_pt_scale;
$g_pt_scale = $g_px_scale * 1.43; 

$pipeline = PipelineFactory::create_default_pipeline("","");
$pipeline->configure($g_config);
$pipeline->destination = new DestinationDownload($product_name);
$pipeline->process($file, $media); 
}
else
{
	echo "File not found";
}

[Weedpacket]

billjust wrote:

It looks very similar to what you've suggested.

Not really; you're taking the entire string the client and sent you and trying to use it without ever checking to see if it's legitimate.

If they enter "http://bizzarewebsitename.com/.images/pictureofme?" into the field, all you do is stick "http://www.ourwebsite.com" on the front and have faith that the result is genuine.

Incidentally, if you're reading a file off your own server, then using an http: connection is a wasteful way to read it.

[billjust]

Our coder came back with a nice adjustment that I think should suit our purposes. Any thoughts?

$file = @$_GET['file'];
$product_name = !empty ($_GET['product_name']) ? $_GET['product_name'] : 'product.pdf';

if ($file != '')
{
	global $g_config;
	if (stristr($file, 'http://') || stristr($file, 'ftp://'))
	{
		exit();
	}	
	$file = 'http://'.$_SERVER['SERVER_NAME']. $file;

[NogDog]

I would add one more thing to that inner if statement:

if (stristr($file, 'http://') || stristr($file, 'ftp://') || [color=red]strstr($file, '..')[/color])

This prevents someone from trying to view files in other directories above the intended one, e.g.: "../../../../etc/passwd".

[bradgrafelman]

Why is $file a URL if the file in question resides on the same server? This question relates back to Weedpacket's point in post #8 of this thread.

If you're not using $file for a redirect and are instead loading data from it, including it (which you should definitely NOT be including/requiring it, since it doesn't look like $file is a PHP script that is to be executed, especially since you're taking user-supplied parameters for the filepath), etc., then it should not be a URL.

[billjust]

Thanks- I will look into why we are doing that. Now that we've corrected things, we still get attempts to open print.php (I changed the name of the updated file to something else so it doesn't even get hit with these attempts). These attempts are filling up our Apache logs. Is there something I can do to prevent these entries from even hitting our server logs (a wildcard exclude statment on the print.php file or something)? I realize this is more of an Apache question, but everyone has been so helpful here so I thought I'd ask.
Thanks!

[bradgrafelman]

Only thing I could think of is to redirect all requests (e.g. using a RewriteRule in a .htaccess file) to the old print.php URL to a valid URL (e.g. an error message).