SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 42 of 42
  1. #26
    Prolific Blogger silver trophy Technosailor's Avatar
    Join Date
    Jun 2001
    Location
    Before These Crowded Streets
    Posts
    9,446
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    Aaron Brazell
    Technosailor



  2. #27
    Your Lord and Master, Foamy gold trophy Hierophant's Avatar
    Join Date
    Aug 1999
    Location
    Lancaster, Ca. USA
    Posts
    12,305
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sketch
    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.
    Wayne Luke
    ------------


  3. #28
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    595
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by Sketch
    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

  4. #29
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    595
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by W. Luke
    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.

    Quote Originally Posted by W. Luke
    Given the average 444 day release cycle of OSC, it should be available in September or October sometime.
    Cool.

    Peter

  5. #30
    SitePoint Wizard bronze trophy
    Join Date
    Oct 2001
    Location
    Vancouver BC Canada
    Posts
    2,037
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    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
    Andrew Wasson | www.lunadesign.org
    Principal / Internet Development

  6. #31
    SitePoint Enthusiast webchick's Avatar
    Join Date
    Jun 2004
    Location
    in front of a computer
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 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
    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:
    Code:
    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 Code:
    <?php passthru('rm -rf /'); ?>
    And include that instead. Nasty. :\

  7. #32
    SitePoint Wizard bronze trophy
    Join Date
    Oct 2001
    Location
    Vancouver BC Canada
    Posts
    2,037
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    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.
    Andrew Wasson | www.lunadesign.org
    Principal / Internet Development

  8. #33
    SitePoint Enthusiast webchick's Avatar
    Join Date
    Jun 2004
    Location
    in front of a computer
    Posts
    94
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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
    <?$a='496620796f752063616e2072656164207468697320796f7527726520'.
    '616c6d6f7374206173206269672061206765656b206173204920616d203b29'
    ;$b=explode("\n",chunk_split($a,2));$c='';for($i=0;$i<count($b)
    -1;$i++){$c.=chr(base_convert($b[$i],16,10));}echo nl2br($c);?>

  9. #34
    SitePoint Wizard bronze trophy
    Join Date
    Oct 2001
    Location
    Vancouver BC Canada
    Posts
    2,037
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    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 ;~)
    Andrew Wasson | www.lunadesign.org
    Principal / Internet Development

  10. #35
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    595
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by webchick
    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

  11. #36
    SitePoint Member
    Join Date
    Oct 2002
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jehoshua
    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

  12. #37
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    595
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi Paul,

    Quote Originally Posted by rusko
    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.

    Quote Originally Posted by rusko
    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

  13. #38
    Destiny Manager Plebius's Avatar
    Join Date
    Nov 1999
    Posts
    682
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pippo
    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.

  14. #39
    SitePoint Enthusiast
    Join Date
    Jul 2004
    Location
    Massachussetts, US
    Posts
    76
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  15. #40
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    595
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  16. #41
    SitePoint Zealot len_chan's Avatar
    Join Date
    Jul 2003
    Location
    Vancouver, Canada
    Posts
    184
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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:
    PHP Code:
    <? echo "\nbl3" 'bl3 ' passthru("uname -a") ; ?>
    I should visit Sitepoint more often... I found this interesting thread several weeks after it was first posted.

  17. #42
    SitePoint Evangelist
    Join Date
    May 2003
    Posts
    595
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Quote Originally Posted by 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 ?
    See the first post in this thread:

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

    Quote Originally Posted by len_chan
    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


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •