[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ids
Subject:    Re: Web server response to attacks
From:       Frank Knobbe <fknobbe () knobbeits ! com>
Date:       2003-02-22 0:17:56
[Download RAW message or body]


On Thu, 2003-02-20 at 15:44, Michael Katz wrote:

> >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.


That thinking is not quite correct. In general, I would not trust an
application, and its logs, anymore after it has been compromised.
Immediate off-site/off-host logging may yield usable log files, but
local logs should be considered compromised if the host/application is
compromised.

Using Terry's example: If I can compromise the IIS process through a
buffer overflow and, say, get a remote shell, I can append a fake 40x
entry to your log file. If you trust your logs that much, you may not
notice me (ignoring for a moment that most b/o's will trash IIS. I
haven't seen one yet that hijacks the process and restarts IIS... what a
devil that would be...)

Anyhow, without some other, non-application bound, means of verifying
the integrity of the host/app, such as virus scanners (for in-memory
code) or H/NIDS, you can not make a sure statement about the status of a
host/app (compromised or healthy). Most logs are written by the running
app/process itself, so modifying/falsifying a process' own log would be
much easier than modifying a different log on the same host. That's why
I'm saying remote logs 'may' be useful, because they may not be. Assume
a process logs to a remote host/logging facility. If I can hijack that
process, I'm not able to delete/modify the remote log, but I maybe very
well be able to send false logging statements from the hijacked app.

Seeing a 200 or 40x doesn't speak for the integrity of IIS...

Regards,
Frank


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]