Re: Web server response to attacks

[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