Apache's PHP handlers

[Arno Kuhl]

For the past week I've been trying to get to the bottom of an exploit, but
googling hasn't been much help so far, nor has my service provider.
Basically a file was uploaded with the filename xxx.php.pgif which contained
nasty php code, and then the file was run directly from a browser. The
upload script used to upload this file checks that the upload filename
doesn't have a .php extension, which in this case it doesn't, so let it
through. I was under the impression apache would serve any file with an
extension not listed in its handlers directly back to the browser, but
instead it sent it to the php handler. Is this normal behaviour or is there
a problem with my service provider's apache configuration? Trying this on my
localhost returns the file contents directly to the browser as expected and
doesn't run the php code.



Cheers

Arno

[Design in Motion Webdesign]

----- Original Message -----
From: "Arno Kuhl" <***@dotcontent.net>
To: <php-***@lists.php.net>
Sent: Thursday, September 19, 2013 1:35 PM
Subject: [PHP] Apache's PHP handlers

Post by Arno Kuhl
For the past week I've been trying to get to the bottom of an exploit, but
googling hasn't been much help so far, nor has my service provider.
Basically a file was uploaded with the filename xxx.php.pgif which contained
nasty php code, and then the file was run directly from a browser. The
upload script used to upload this file checks that the upload filename
doesn't have a .php extension, which in this case it doesn't, so let it
through. I was under the impression apache would serve any file with an
extension not listed in its handlers directly back to the browser, but
instead it sent it to the php handler. Is this normal behaviour or is there
a problem with my service provider's apache configuration? Trying this on my
localhost returns the file contents directly to the browser as expected and
doesn't run the php code.
Cheers
Arno

Arno,

the php file hidden as a gif will indeed not execute if opened directly from
your website. But if opened from a page hosted elsewhere with some code like
require($path_to_your_image), the php code inside the image will be sent to
the php handler and will be executed.

Prevention is the best way to avoid hacking from image upload. Check the
file extention and the file content before upload.

Cheers.
Steven

[Arno Kuhl]

Post by Arno Kuhl
For the past week I've been trying to get to the bottom of an exploit, but
googling hasn't been much help so far, nor has my service provider.
Basically a file was uploaded with the filename xxx.php.pgif which contained
nasty php code, and then the file was run directly from a browser. The
upload script used to upload this file checks that the upload filename
doesn't have a .php extension, which in this case it doesn't, so let it
through. I was under the impression apache would serve any file with an
extension not listed in its handlers directly back to the browser, but
instead it sent it to the php handler. Is this normal behaviour or is there
a problem with my service provider's apache configuration? Trying this on
my localhost returns the file contents directly to the browser as expected
and doesn't run the php code.

--

Arno,

the php file hidden as a gif will indeed not execute if opened directly from

your website. But if opened from a page hosted elsewhere with some code like

require($path_to_your_image), the php code inside the image will be sent to
the php handler and will be executed.

Prevention is the best way to avoid hacking from image upload. Check the
file extention and the file content before upload.

Cheers.
Steven
--
Hi Steven, I agree the best way to avoid this is for the file upload script
to check the file contents and that's something I'll have to sort out,
currently it just checks the extension. But it's still a concern that a file
with any arbitrary extension can be processed as php script as long as it
has the text ".php" in the filename. I'm not worried about including the
file because that would require pre-existing malicious php code, I want to
prevent that malicious php code from running in the first place.

Cheers
Arno

[Design in Motion Webdesign]

Hi Arno,

it has nothing to do with ".php" in the file name. What the hacker did, was
uploading a .gif file with some malicious php code included to your
webserver. Then he called the .gif file from his own website by using a php
script containing some code like
require_once('Loading Image...'). At that moment
the php code inside the .gif file has been executed.

Steven

----- Original Message -----
From: "Arno Kuhl" <***@dotcontent.net>
To: "'Design in Motion Webdesign'" <***@designinmotion.be>;
<php-***@lists.php.net>
Sent: Thursday, September 19, 2013 2:43 PM
Subject: RE: [PHP] Apache's PHP handlers

Post by Arno Kuhl

Post by Arno Kuhl
For the past week I've been trying to get to the bottom of an exploit, but
googling hasn't been much help so far, nor has my service provider.
Basically a file was uploaded with the filename xxx.php.pgif which

contained

Post by Arno Kuhl
nasty php code, and then the file was run directly from a browser. The
upload script used to upload this file checks that the upload filename
doesn't have a .php extension, which in this case it doesn't, so let it
through. I was under the impression apache would serve any file with an
extension not listed in its handlers directly back to the browser, but
instead it sent it to the php handler. Is this normal behaviour or is

there

Post by Arno Kuhl
a problem with my service provider's apache configuration? Trying this on
my localhost returns the file contents directly to the browser as expected
and doesn't run the php code.

--
Arno,
the php file hidden as a gif will indeed not execute if opened directly from
your website. But if opened from a page hosted elsewhere with some code like
require($path_to_your_image), the php code inside the image will be sent to
the php handler and will be executed.
Prevention is the best way to avoid hacking from image upload. Check the
file extention and the file content before upload.
Cheers.
Steven
--
Hi Steven, I agree the best way to avoid this is for the file upload script
to check the file contents and that's something I'll have to sort out,
currently it just checks the extension. But it's still a concern that a file
with any arbitrary extension can be processed as php script as long as it
has the text ".php" in the filename. I'm not worried about including the
file because that would require pre-existing malicious php code, I want to
prevent that malicious php code from running in the first place.
Cheers
Arno
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stuart Dallas]

it has nothing to do with ".php" in the file name. What the hacker did, was uploading a .gif file with some malicious php code included to your webserver. Then he called the .gif file from his own website by using a php script containing some code like require_once('http://www.yoursite.com/images/yourimage.gif'). At that moment the php code inside the .gif file has been executed.

In possibly the most pointless way ever! In that scenario the script would be executed on the "hacker"'s server (assuming Apache is set up correctly), so there's no point in her managing to put it on your server at all!

Arno: If you can request that file using a web browser, and it gets executed as PHP on your server then there is an error in the Apache configuration.

Easy test: create a file in a text editor containing some PHP (<?php phpinfo(); ?> would be enough) and upload it to the www root of your site and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in your browser. If you see the PHP code or an error then you're fine. If you see PHP's info page then you need to change web host as quickly as possible. I don't care if they fix it - the fact their server was configured to do this by default is enough for me to never trust them again.

-Stuart

[Aziz Saleh]

The best way to handle file uploads is to:

1) Store the filename somewhere in the DB, rename the file to a random
string without extension and store the mapping in the DB as well.
2) When sending the file, set the header content to the filename and output
the content of the file via PHP (ex: by readfile).

Aziz

This way even if the file is PHP code, it will be of no issue to you.

On 19 Sep 2013, at 13:58, "Design in Motion Webdesign" <

Post by Design in Motion Webdesign
it has nothing to do with ".php" in the file name. What the hacker did,

was uploading a .gif file with some malicious php code included to your
webserver. Then he called the .gif file from his own website by using a php
script containing some code like require_once('
http://www.yoursite.com/images/yourimage.gif'). At that moment the php
code inside the .gif file has been executed.
In possibly the most pointless way ever! In that scenario the script would
be executed on the "hacker"'s server (assuming Apache is set up correctly),
so there's no point in her managing to put it on your server at all!
Arno: If you can request that file using a web browser, and it gets
executed as PHP on your server then there is an error in the Apache
configuration.
Easy test: create a file in a text editor containing some PHP (<?php
phpinfo(); ?> would be enough) and upload it to the www root of your site
and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in
your browser. If you see the PHP code or an error then you're fine. If you
see PHP's info page then you need to change web host as quickly as
possible. I don't care if they fix it - the fact their server was
configured to do this by default is enough for me to never trust them again.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Stuart Dallas]

1) Store the filename somewhere in the DB, rename the file to a random string without extension and store the mapping in the DB as well.
2) When sending the file, set the header content to the filename and output the content of the file via PHP (ex: by readfile).
Aziz
This way even if the file is PHP code, it will be of no issue to you.

What you describe it highly inefficient, clunky, and unnecessary. You've managed to get PHP and a database involved in serving a static file, for no reason other than to avoid fixing the web server configuration.

A misconfigured web server should be fixed, not worked around.

-Stuart

[Bastien Koert]

Post by Aziz Saleh

Post by Aziz Saleh
1) Store the filename somewhere in the DB, rename the file to a random

string without extension and store the mapping in the DB as well.

Post by Aziz Saleh
2) When sending the file, set the header content to the filename and

output the content of the file via PHP (ex: by readfile).

Post by Aziz Saleh
Aziz
This way even if the file is PHP code, it will be of no issue to you.

What you describe it highly inefficient, clunky, and unnecessary. You've
managed to get PHP and a database involved in serving a static file, for no
reason other than to avoid fixing the web server configuration.
A misconfigured web server should be fixed, not worked around.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

You can also run a strip_tags() call on the file upload to help prevent this

Bastien

[Arno Kuhl]

Arno: If you can request that file using a web browser, and it gets executed
as PHP on your server then there is an error in the Apache configuration.

Easy test: create a file in a text editor containing some PHP (<?php
phpinfo(); ?> would be enough) and upload it to the www root of your site
and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in your
browser. If you see the PHP code or an error then you're fine. If you see
PHP's info page then you need to change web host as quickly as possible. I
don't care if they fix it - the fact their server was configured to do this
by default is enough for me to never trust them again.

-Stuart
--

Thanks Stuart. I just tried it now, test.php.pgif displayed the info while
test.xyz.pgif returned the content, confirming the problem. My service
provider finally conceded the problem is on their side and are looking for
an urgent fix, much too complicated to consider moving service providers in
the short term.

As a side note, the sp said the issue is new and coincided with an upgrade
to fastcgi recently, I wonder if the hacker was exploiting a known issue
with that scenario?

Cheers
Arno

[Ashley Sheridan]

Post by Stuart Dallas
Arno: If you can request that file using a web browser, and it gets executed
as PHP on your server then there is an error in the Apache configuration.
Easy test: create a file in a text editor containing some PHP (<?php
phpinfo(); ?> would be enough) and upload it to the www root of your site
and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in your
browser. If you see the PHP code or an error then you're fine. If you see
PHP's info page then you need to change web host as quickly as possible. I
don't care if they fix it - the fact their server was configured to do this
by default is enough for me to never trust them again.
-Stuart
--
Thanks Stuart. I just tried it now, test.php.pgif displayed the info while
test.xyz.pgif returned the content, confirming the problem. My service
provider finally conceded the problem is on their side and are looking for
an urgent fix, much too complicated to consider moving service providers in
the short term.
As a side note, the sp said the issue is new and coincided with an upgrade
to fastcgi recently, I wonder if the hacker was exploiting a known issue
with that scenario?
Cheers
Arno

I think most importantly, validate your input!

If you're expecting an image, check to make sure it's an image. Use the
imagecopyresampled() function that's part of GD to create a duplicate of
the exact same size to ensure that it's both an image and not containing
a hidden payload (which has happened to JPEG images before)

If it's a file of another type, use a different appropriate method to
validate that. DOMDocument will deal with XML and HTML documents, you
can use zip functions to inspect Office documents (the newer types at
least), FPDF to handle PDF files, etc.

By only checking the extension you're relying on user-supplied data,
which by definition is tainted.

Thanks,
Ash
http://www.ashleysheridan.co.uk

[Tamara Temple]

Post by Stuart Dallas
Arno: If you can request that file using a web browser, and it gets executed
as PHP on your server then there is an error in the Apache configuration.
Easy test: create a file in a text editor containing some PHP (<?php
phpinfo(); ?> would be enough) and upload it to the www root of your site
and name it test.pgif. Then hit http://www.yourdomain.com/test.pgif in your
browser. If you see the PHP code or an error then you're fine. If you see
PHP's info page then you need to change web host as quickly as possible. I
don't care if they fix it - the fact their server was configured to do this
by default is enough for me to never trust them again.
-Stuart
--
Thanks Stuart. I just tried it now, test.php.pgif displayed the info while
test.xyz.pgif returned the content, confirming the problem. My service
provider finally conceded the problem is on their side and are looking for
an urgent fix, much too complicated to consider moving service providers in
the short term.
As a side note, the sp said the issue is new and coincided with an upgrade
to fastcgi recently, I wonder if the hacker was exploiting a known issue
with that scenario?
Cheers
Arno

GoDaddy's default plesk-generated configuration for FastCGI-served PHP files only looked to see if the file contained ".php" somewhere on it's path - i.e. it would happily execute 'malicilous.php.txt' as php code, even something ridiculous like 'malware.phpnoreallyiwantthistorun'.

[Arno Kuhl]

-----Original Message-----
From: Ken Robinson [mailto:***@rbnsn.com]
Sent: 19 September 2013 01:52 PM
To: <***@dotcontent.net>
Cc: <php-***@lists.php.net>
Subject: Re: [PHP] Apache's PHP handlers

Check you .htaccess file. The hackers could have modified it to allow that
type of file to be executed. I had some that modified my .htaccess file to
go to a spam site when my site got a 404 error. That was nasty.

Ken

Sent from my iPad

Post by Arno Kuhl
For the past week I've been trying to get to the bottom of an exploit,
but googling hasn't been much help so far, nor has my service provider.
Basically a file was uploaded with the filename xxx.php.pgif which
contained nasty php code, and then the file was run directly from a
browser. The upload script used to upload this file checks that the
upload filename doesn't have a .php extension, which in this case it
doesn't, so let it through. I was under the impression apache would
serve any file with an extension not listed in its handlers directly
back to the browser, but instead it sent it to the php handler. Is
this normal behaviour or is there a problem with my service provider's
apache configuration? Trying this on my localhost returns the file
contents directly to the browser as expected and doesn't run the php code.
Cheers
Arno
S

Hi Ken, .htaccess wasn't modified, this file was just uploaded and run. So
far all my service provider has told me is it was because the filename
contained ".php" in the filename, even though it's not the extension, and
that's the reason apache sent it to the php handler. I'm sure that can't be
right, otherwise it would be open to all sorts of exploits.

Cheers
Arno