Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

Re: vulnerability in glocation.cgi?

Subject: Re: vulnerability in glocation.cgi?
Date: Wed, 7 Sep 2005 10:56:47 +0200 (CEST)

Hi,


That thread dates back to January 2004, but I think I should finally deliver the rest of the story. Back in 2004 I reported some odd web accesses to one of my webserver seemingly to exploit a vulnerability in a script called "glocation". I had never heard of such a script, but the tried "ls -la" made me curious enough that I wrote a script giving some fake output on that command. Now that's what had happened:

  - After an hour "someone" obviously noticed that the return
    code changed from 404 file not found to 200. After that other
    commands were tested but no longer from a large variety of
    IP addresses but only two.
  - Next morning when I saw that, I added the tried commands to
    my script. The person came back trying more.
  - In the meanwhile the probing for glocation stopped and was
    replaced for script php.cgi, whereami.cgi and test.cgi. None
    of them ever existed on any of my servers.
    For what reason soever it seems to be necessary to get 404
    replies.
  - I asked the webmasters of a second webserver of mine (as the
    first one a name based virtual) to send me the logfiles and
    viola, the same entries. When looked closer I could see that
    each IP address fired all 11 seconds.
  - On the first server the guy had tried to upload some files
    which couldn't work as I did not forsee such an action. I
    downloaded the files after I found the entries in the logfiles.
    One was a perl based backdoor, the second revealed itself
    (with the help of google) to be a kaiten client.

  So the harmless looking probes turned up to be much more. Someone
  was setting up an ddos network. Imho.
  I had notified the ISPs of the "attacking" IP addresses so the
  probing stopped quite soon.

  I'm still wondering about the 404 stuff, but something else gives
  me quite more to think about: the proper way of handling incidents.
  The initial incident above looked so completely harmless that this
  type is usually ignored. And most of these probes may be harmless.
  But there are exceptions. Ignoring incidents sounds wrong to me.
  I do not suggest to honeyscript each funny probe but I wonder about
  the proper actions. File them to the abuse and security departments
  - of course. That may lead to some action - or not, depending on the
  abuse and security department. The guy behind that will not be caught.
  I spoke to the police (ddos is _not_ funny) but they told me from the
  beginning that in cases like that there is no hope. Partially because
  no real damage was done, but the basic problem is the ... not so good
  international collaboration. That makes me unhappy.
  I'm looking for better ways to handle that.

  What is your opinion and line of action?

  Cheers,


Chris Kronberg.

--
GeNUA mbH

<Prev in Thread] Current Thread [Next in Thread>