Re: Strange Attack On A Webserver I Work On

From: Matthew J. Sahagian (gent_at_dotink.org)
Date: 10/27/04

  • Next message: Jason Stewart: "Re: Strange Attack On A Webserver I Work On" 
    Date: Wed, 27 Oct 2004 12:02:34 -0400
To: focus-linux@securityfocus.com

    >Matthew,
    > I see two possible scenarios here.
    >
    >(a) Zombie network. This is unlikely due to the text/html and PHP
    >handlers either not executing code (html) or not being able to
    >correctly parse (php) the code.
    >
    >(b) An errant search/replace find(1) or similar. Its well within
    >reason to believe that the kiddie who rooted your box had a UDP
    >flooder AND a replacement HTML file, and accidently
    >keyed-in/tab-completed the wrong filename when doing the replace. I've
    >seen some horrid keying mistakes on compromised equipment.
    >
    >My guess lies with the latter. She probably realized the mistake,
    >said screw it, cleaned the logs with an automated cleaner and cut her
    >losses.
    >
    >Any hints in the .bash_history file? You'd be surprised how many
    >kiddies forget to clean that file.
    >
    >Regards,
    >TJ Easter

    I started to think about a Zombie network a little bit later, as it seems to be the only thing that would make sense aside fromt he script kiddy screwing up. Do you know if it's at all possible, or if there have ever been any vulnerabilities in PHP or PHP based software (PHPNuke for example, lots of users on the server use this) to execute the code? I know it would execute properly through apache as it's not PHP code, it's a binary files.... but maybe there's a way to force it to execute using the built in system() command or something? Just a thought.

    Cleaning up is not the problem, as I mentioned within my first e-mail (to all users who suggested how we go about that). I was moreso wondering what the purpose of this was, as it just sorta quirked me.

    As far as the logs go, I've checked everything from .bash history to apache access logs -- nothing. Like I said though, I'm not the main administrator, I just do small tasks here and there, and as it seems many of those logs have been wiped... not sure by whom yet. But what is there is clean or at least clean of this attack.

    Anyway, thanks for all the ideas and stuff. I think I'm gonna settle on zombie, I really think this was too automated to be a key in screw up, I'm under the impression the script itself is what puts this software in place (and possibly tries to figure out how to execute it later).

    Cheers,
    Matt

  • Next message: Jason Stewart: "Re: Strange Attack On A Webserver I Work On"

    Relevant Pages

    • Re: How do we get there from here?
      ... > then sub the whole of that generated markup into the template? ... layed out on the fly, a simple IMG tag, or even an entire HTML document. ... PHP scripting provides 10 times the features of both of these ... idea as tokens can eliminate a huge amount of maintance, ...
      (comp.databases.pick)
    • Re: query string passing woes........ help... please....
      ... |> | offer any help other than saying that my validation could be FAR more ... I'm a total newbie at php. ... The easiest way for you would be to make the html form called form.php ... $_SESSION array using the same names. ...
      (alt.php)
    • Re: HELP - Cant change Include Path
      ... Here is my php.ini path for the php.ini in both php and sql dirs: ... which did work on the remote linux server and sent me some mail ... Although my gmail acct picked the mail up as ... an attachment instead of as html - but gmail is really wierd about ...
      (comp.lang.php)
    • Re: How do we get there from here?
      ... server-side-scripted html. ... This is a simple example with very little php scripting. ... means that the version of the php pre-processor on your web server must ... >>> The browser never sees anything not sent to it by the script. ...
      (comp.databases.pick)
    • Re: PHP-Yes, HTML-No --- Why?
      ... People who know and people who care are two entirely different worlds. ... I doubt that a single person has ever been fired, not paid or told to change the URLs in he web design because they ended in .php. ... But once you have code great HTML, great CSS, great PHP, and you server is quick, smooth and working well, it doesn't make sense to just stop making your site better. ... Ergo there is no concession on presentation at all and our web sites are already "better". ...
      (comp.lang.php)