Why would someone do this ??

[Technosailor]

By the way, unless osCommerce has changed their code recently, they still require register_globals ON. The OSC people were dragging their feet for quite awhile.

Aaron

[Hierophant]

By the way, unless osCommerce has changed their code recently, they still require register_globals ON. The OSC people were dragging their feet for quite awhile.

Aaron

Only in very unstable CVS versions can you attempt to turn register_globals off in OSC. Being able to turn that off is a milestone 3 objective that is being worked on. Given the average 444 day release cycle of OSC, it should be available in September or October sometime.

[jehoshua]

Hi,

By the way, unless osCommerce has changed their code recently, they still require register_globals ON.

Yes, the osC code is written to force the user to have register_globals to ON.

Peter

[jehoshua]

Hi,

Being able to turn that off is a milestone 3 objective that is being worked on.

That's good, and I hope MS-3 is all PHP5 compatible also, although it may be later.

Given the average 444 day release cycle of OSC, it should be available in September or October sometime.

Cool.

Peter

[awasson]

Hi there,

I found this a really intriquing thread but I can't see how the bad guys were trying to use the code to gain entry to the database or other part of the server:

<? echo "\nbl3" . 'bl3 ' ; passthru("uname -a") ; ?>

This is probably due to my lack of *nix security knowledge.

I've been running the script on a few servers stand-alone and against some PHP catalogue scripts but the only information that I am receiving is information about the machine the code is hosted on, not the machines the catalogues are running on.

Any security risk is a cause for alarm, but is it possible that the perpetrator missunderstood the use of that script and wasn't actually knowledgable enough to cause a security breach in this instance?

Thanks,
Andrew

[webchick]

Hi there,

I found this a really intriquing thread but I can't see how the bad guys were trying to use the code to gain entry to the database or other part of the server

By itself, it doesn't... It's basically a fingerprinting technique.

Here's an example of what it might throw out to the browser if it works:

SunOS workstation1 5.5 Generic_103093-06 sun4m sparc SUNW,SPARCstation-5

(output will vary depending on Unix/Linux version)

If this attempt works, it means two things:

a) The attacker now has details about what type of server you're running, and can now browse around something like http://www.securityfocus.com/ to look for vulnerabilities particular to that OS

b) More importantly, the attacker knows that they can pass shell commands using passthru(), which allows them to access and execute anything that the PHP user has access to. So they could make another page on their site that says something like:

<?php passthru('rm -rf /'); ?>

And include that instead. Nasty. :\

[awasson]

Thanks webchick,

That would be nasty if it had worked.

I can validate querystring and form data fairly easily but...

The question is how do I go about checking to make sure my own servers don't allow passing shell commands remotely through cross-server-scripting attacks as well as those on hosted accounts?

Any thoughts?

This would make a good follow up article on PHP security.

[webchick]

You can prevent URLs from being used in include(), require(), etc. by disabling allow_url_fopen in php.ini. More info is available from:

http://www.php.net/manual/en/features.remote-files.php

I'm not sure what else that would screw up though. *lol*

As far as preventing one of your own users from placing a evil.evil file containing the above code, and using it as a tool to circumvent other sites, I'm not sure if that would be possible, actually. The only thing I can think of is parsing every single file on a page request, regardless of its extension, looking for <? ... ?> and, if found, parse it as PHP first, *before* it's sent to the browser. That way they'd only get the resulting text/HTML if they were able to find a script elsewhere with the <?php include($_GET['url']); ?> behaviour. But that would be an extereme performance hit, would only protect against PHP-based XSS attacks, and also requires your own server's security to be dynamite, else your server is the one that gets its files deleted. :P

[awasson]

Hmmmm, I wouldn't want to turn off allow_url_fopen because it comes in handy for dealing with XML from remote sources and that would be a big resource hit to search and parse every file with <? ?>.

Love the signature ;~)

[jehoshua]

Hi,

As far as preventing one of your own users from placing a evil.evil file containing the above code, and using it as a tool to circumvent other sites, I'm not sure if that would be possible, actually.

Yes, very difficult to monitor/control what our own users might place on a website. I recently read an interesting thread on PerlMonks, and one person has a cron job to check the files regularly, not so much the contents, just the number of files in each path and the files datetime stamps. It does show him any new files or changes to others.

Peter

[rusko]

Hi,

Interestingly, I have been having discussions of late with the web hosts I use. I was concerned because now all emails contain the virtual URL of the webroot path, which of course shows the username.

this is partially my fault, since i originally wrote the patch against php 4.x that cpanel folks later used in their easyapache package. it was *not* meant to be used by itself - we've got a sendmail binary wrapper that logs all invokations and replaces the path with a log entry id. that way we can still track down the abuser when we see the message headers, but the actual filesystem path isn't disclosed to the general public.

with that said, i don't consider this to be too big of a deal - security by obscurity is not the best choice of security paradigm and script path is both not so useful and easy to determine.

paul

[jehoshua]

Hi Paul,

this is partially my fault, since i originally wrote the patch against php 4.x that cpanel folks later used in their easyapache package. it was *not* meant to be used by itself - we've got a sendmail binary wrapper that logs all invokations and replaces the path with a log entry id. that way we can still track down the abuser when we see the message headers, but the actual filesystem path isn't disclosed to the general public.

Okay, that seems to be a much more sensible approach to the problem of tracking down abusers.

with that said, i don't consider this to be too big of a deal - security by obscurity is not the best choice of security paradigm and script path is both not so useful and easy to determine.

Hmmm, .... but if we employ 'security by obscurity' in addition to other security measures, isn't that better ? If the script path is made public, and the path includes the website login username, then the job of any hacker, is surely made that much easier. If a hacker knows the password, it is of little benefit without the username, but if a hacker knows the username, I understand it is then not impossible to brute force access into a website. The username is the first and primary 'piece' of information needed, that's why I can't understand why people would want to make it public ??

Thanks,

Peter

[Plebius]

217.59.104.226 seems to be a static ip,
or at least a dynamic ip assigned but then the guy never reboot its pc.
That ip belong to intebusiness.it and I belong to that family too.

Half the morons who try to hack my site are coming from interbusiness.it Is it something about them? Anyway, they haven't succeeded.

[Jackal05]

It looks as if the guy was trying to see if he could take advantage of the variable "products_id" and use it as a proxy.

[jehoshua]

Hi,

There are some interesting (and related to IP address,etc) comments made in this thread:

http://www.sitepoint.com/forums/showthread.php?t=180164

Peter

[len_chan]

Quick question for those who've read this thread from the beginning:

Where in the initial log file snippet posted is the attempt to run the line of code below? Would this PHP snippet have been in the default web page from a webserver controlled by the script kiddie? I don't get any web response at 217.59.104.226 currently.

This is the code that the attacker, in this case, was trying to execute on your server:

<? echo "\nbl3" . 'bl3 ' ; passthru("uname -a") ; ?>

I should visit Sitepoint more often... I found this interesting thread several weeks after it was first posted.

[jehoshua]

Hi,

Quick question for those who've read this thread from the beginning:

Where in the initial log file snippet posted is the attempt to run the line of code below ?

See the first post in this thread:

http://www.sitepoint.com/forums/show...0&page=1&pp=25

I don't get any web response at 217.59.104.226 currently.

Possibly "pippo" (http://www.sitepoint.com/forums/member.php?u=11964 ) did bring it to the attention of the ISP, and something was done about it ??

Peter