IDS mailing list archives
Re: Web server response to attacks
From: Frank Knobbe <fknobbe () knobbeits com>
Date: 21 Feb 2003 18:17:56 -0600
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
Attachment:
signature.asc
Description: This is a digitally signed message part
Current thread:
- Web server response to attacks Terry Ziemniak (Feb 20)
- Re: Web server response to attacks Michael Katz (Feb 20)
- Re: Web server response to attacks Frank Knobbe (Feb 25)
- <Possible follow-ups>
- RE: Web server response to attacks Levinson, Karl (Feb 21)
- Re: Web server response to attacks Michael Katz (Feb 20)