|
|||||||||||
|
Re: Web server response to attacks
From: Frank Knobbe <fknobbe(at)knobbeits.com>
Date: Fri Feb 21 2003 - 19:17:56 EST On Thu, 2003-02-20 at 15:44, Michael Katz wrote: > >Along those same lines, does this apply to the general class of exploits
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,
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:01:10 EDT |
||||||||||
|
|||||||||||