Re: [PHP] Apache's PHP handlers
On Sep 19, 2013, at 9:14 AM, Arno Kuhl wrote: > 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 ( 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'. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Apache's PHP handlers
On Thu, 2013-09-19 at 16:14 +0200, Arno Kuhl wrote: > 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 ( 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
RE: [PHP] Apache's PHP handlers
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 ( 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache's PHP handlers
On Thursday, September 19, 2013, Stuart Dallas wrote: > On 19 Sep 2013, at 14:39, Aziz Saleh > > wrote: > > > 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. > > 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 -- Bastien Cat, the other other white meat
Re: [PHP] Apache's PHP handlers
On 19 Sep 2013, at 14:39, Aziz Saleh wrote: > 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. 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
Re: [PHP] Apache's PHP handlers
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 Thu, Sep 19, 2013 at 9:05 AM, Stuart Dallas wrote:
> On 19 Sep 2013, at 13:58, "Design in Motion Webdesign" <
> i...@designinmotion.be> wrote:
>
> > 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 ( 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
>
>
Re: [PHP] Apache's PHP handlers
On 19 Sep 2013, at 13:58, "Design in Motion Webdesign"
wrote:
> 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 ( 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
Re: [PHP] Apache's PHP handlers
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('http://www.yoursite.com/images/yourimage.gif'). At that moment
the php code inside the .gif file has been executed.
Steven
- Original Message -
From: "Arno Kuhl"
To: "'Design in Motion Webdesign'" ;
Sent: Thursday, September 19, 2013 2:43 PM
Subject: RE: [PHP] Apache's PHP handlers
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Apache's PHP handlers
> 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Apache's PHP handlers
-Original Message- From: Ken Robinson [mailto:kenrb...@rbnsn.com] Sent: 19 September 2013 01:52 PM To: Cc: 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 On Sep 19, 2013, at 7:35 AM, "Arno Kuhl" wrote: > 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache's PHP handlers
- Original Message - From: "Arno Kuhl" To: Sent: Thursday, September 19, 2013 1:35 PM Subject: [PHP] Apache's PHP handlers 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
