Re: Web server response to attacks

From: Michael Katz (mike@procinct.com)
Date: 02/20/03

  • Next message: Adam Powers: "RE: Protocol Anomaly Detection IDS - Honeypots"
    Date: Thu, 20 Feb 2003 13:44:54 -0800
    To: <focus-ids@lists.securityfocus.com>
    From: Michael Katz <mike@procinct.com>
    
    

    At 2/20/2003 10:48 AM, Terry Ziemniak wrote:

    >I was reviewing some IIS logs with a co-worker. There were typical Nimda
    >attack signatures (cmd.exe) in the log. He asked an interesting question:
    >can you tell the whether the attack was successful based on the HTTP return
    >code? I had always assumed that a 403/404 to this type of a requests meant
    >it was blocked. But as I have never actually seen the logs from a
    >successful exploit, I am wondering if that is true.

    For directory traversal attempts to access and execute cmd.exe (like
    Nimda), a successful attack will result in a HTTP status code of 200,
    indicating that it was successful. A 403 code, however, may reveal useful
    information, as well. It may indicate that ACLs have been applied to
    cmd.exe, but the directory traversal may have worked (it could also mean
    other things, as well). Note that if the server was subject to this
    vulnerability, the attacker could sanitize the logs, so it's important to
    have information from other sources, if possible (like IDS or previous
    vulnerability scans showing whether the server was vulnerable).

    >Along those same lines, does this apply to the general class of exploits
    >(meaning OS/web server executable and dll exploits)? For Code Red I and II,
    >as well as tomorrow's new web server exploit d'jour, can I assume a 400
    >level response from my web server means that the attack was not
    >successfully?

    For some successful attacks, you may never see a log entry. These buffer
    overflows interrupt the server before the log entry is written.

    That said, if there is a log entry and that entry is 40x, then it is
    usually safe to assume that the attack was not successful.

    Michael Katz
    mike@procinct.com
    Procinct Security

    -----------------------------------------------------------
    Does your IDS have Intelligent Attack Profiling?
    If not, see what you're missing.
    Download a free 15-day trial of StillSecure Border Guard.
    http://www.securityfocus.com/stillsecure



    Relevant Pages

    • Re: Strange Log File Entries
      ... looks like an old worm. ... probably not successful. ... your web server configured correctly, per the hardening windows 2000 and IIS ... successfully blocked that worm attack. ...
      (microsoft.public.inetserver.iis.security)
    • Re: Strange Log File Entries
      ... >> my the IP address of my IIS server. ... looks like an old worm. ... > successfully blocked that worm attack. ... the commands were successful despite the 502.] ...
      (microsoft.public.inetserver.iis.security)
    • Re: strange entry in IIS log
      ... you got hit and the attack was successful. ... This is CodeRed virus which attack using buffer overflow technique. ... >>> web access I decided to open iis on our server. ... >>> Please reply to newsgroups only. ...
      (microsoft.public.inetserver.iis.security)
    • Re: the 100 year lie (ndc)
      ... "ll the Bush haters... ... attacks was actually successful so that they could blame ... It was my opinion at that time. ... My point was, more specifically, if there had been a successful attack, there certainly would have been no silence and I still believe that many people here look for opportunities to seize on what they perceive to be Bush's failings. ...
      (rec.music.gdead)
    • Re: Firewall security: Re: Problems with simple Samba file share
      ... There might be attacks from China. ... > china is as unlikely to succeed as an attack from the USA. ... > case is a successful attack known, and if a successful attack were to ... Statistics don't matter. ...
      (comp.os.linux.misc)