[logs] RE: NT Event Log and Web Server Attacks

ericfat_private

Image path name was added to a number of events in Windows XP due to
popular demand.

Which brings up another subject that I like to call "fat" vs. "thin"
audits.

Analysts like "fat" audits- where one event contains everything one
would conceivably want to know about some occurrence on the system.
Unfortunately "fat" events have several drawbacks: they require lots of
processing to gather, translate, and format the information, which may
require really convoluted code paths as well as modifications of
standard APIs to carry information back and forth (and the hope that no
intervening functions mess up your data).  Also, "fat" audits often
require the machine to keep additional copies of state information
(process name, etc.) lying around, increasing memory usage and overall
bloat of the security system.  Lastly, "fat" audits sometimes require
delay in reporting the original interesting occurrence while waiting for
some of the data that will be logged.

On the other hand, developers like "thin" audits- where each audit is
only generated at one point in the code, and only contains information
available at that point in the code.  This is the easiest to develop and
maintain.  However, it requires that related audits must be able to be
correlated with each other, which is why we have data items like "Logon
ID" and "Handle ID" in our audits.

In Windows we've typically followed the "thin" model.  However, where
practical, we've added extra information that might be redundant with
other audits but is still useful.  As a side effect there are some
inconsistencies- some audits such as process termination events now have
image path name, for example, but some other audits that might benefit
from it still don't.

In this case, you need to correlate 592, 600, and 593 based on process
ID. One or more of these, depending on the platform, will have the
executable image path name in it, and the 600 and 593 events will have
the user context information.

In the long run, we're going to continue with the "thin" model, but
we're working on reduction and analysis scripts- so that instead of
trying to perform all the necessary correlation in your scripts, it'll
be done for you.

Eric

-----Original Message-----
From: Rainer Gerhards [mailto:rgerhardsat_private] 
Sent: Friday, January 17, 2003 5:10 AM
To: loganalysisat_private
Cc: Rainer Gerhards; Tina Bird; Marcus J. Ranum; probertsat_private;
Ben Laurie; Eric Fitzgerald
Subject: RE: NT Event Log and Web Server Attacks

Arrghhh...

Did Tina have on of those "don't type faster than you think" quotes in
her sig... Actually, I verfified what I wrote under Windows XP (not the
typical server platfrom). On the Win2K server boxes, there is a little
problem with the 593 event: it does not have the exe file name in it. I
verified this on Germany W2K Server SP3 Buuild 2195. Obviously the file
name got added in XP (and so hopefully is in .NET server or Windows 2003
Server as it is called now.) I am just posting this for all who might be
banging their had finding the file name...

Seems not to be my day. Maybe I should can my posts and re-read and
finally post them tomorrow ;)

Sorry,
Rainer Gerhards

> -----Original Message-----
> From: Rainer Gerhards
> Sent: Friday, January 17, 2003 2:04 PM
> To: Rainer Gerhards
> Subject: RE: NT Event Log and Web Server Attacks
> 
> 
> Unfortunately, I need to post a correction on this issue.
> That correction does also address some issues with NT Event 
> logging & IIS in general, so maybe Eric would like to jump in?
> 
> The fact to correct is the user that is logged in nt event
> log. Interestingly, when the process (the exe file) is 
> started, that is not the expected IUSR_xxx account, but the 
> build-in SYSTEM account. I have verified (with cmd.exe) this 
> is not only the case for script processors like perl, but 
> with any program (well, at least cmd.exe...).
> 
> The reason seems to be that IIS triggers the 592 event
> (process creation) while NOT being impersonated as the actual 
> user this request runs under. Then, in some stage further 
> down the workflow, IIS impersonates as the actual user 
> (IUSR_xxx in our case). It is still impersonated when the end 
> process is logged via event 593, which therefore specifies 
> the IUSR_xxx as the user in question.
> 
> In my personal view, IIS should log the 592 event under the
> actual user, too and not under the system context. This also 
> raises the question (which I do not intend to discuss) if IIS 
> is really able to ensure NTFS ACLS under all circumstances - 
> or if a failing stage (the one looking up ACLs) of IIS could 
> lead to the execution of a file that the actual user (e.g. 
> IUSR_xxx) is not intended to. This for sure would require a 
> vulnerability in the ACL lookup stage, but there could be 
> some over time...
> 
> Actually, this finding makes the intrusion detection rule
> harder. We know need to rule out other occasions where the 
> build-in SYSTEM account (validly) executes programs. This 
> seems not to be very practical. So we can resort to using the 
> 593 (process termination). They still do have the name of the 
> file being executed and also have the correct user id in 
> them. The only problem here is that we won't detect processes 
> that were started by the intruder but NEVER ENDED. Anyhow, I 
> am looking to catch (not yet known, maybe not even existing) 
> vulnerabilities and their exploits in IIS that will be used 
> to start an intrusion. One of the most common things I can 
> think of is calling cmd.exe. That one most probably 
> terminates. Most of the attacks I know start with calling 
> cmd.exe or a similar program. One, that terminates. Only 
> after a number of requests, a non-terminating program like a 
> remote shell or a tftp server is started. Of course, if a 
> buffer overrun is used to execute a non-terminating program, 
> or a looping batch file is executed, chances are good we will 
> NOT see any process termination events. In any case, the 593 
> still provides a good warning sign, altough the 592 would be 
> better (if it had the correct user id in it...).
> 
> I will probably play a little more with this issue and post
> new results - if any.
> 
> My apologies for the initial mistake and the time it took to
> post this correction. I hope I miss-lead nobody ;)
> 
> Rainer Gerhards
> Adiscon
>  
> > -----Original Message-----
> > From: Rainer Gerhards
> > Sent: Friday, January 17, 2003 12:26 PM
> > To: Rainer Gerhards
> > Subject: NT Event Log and Web Server Attacks
> > 
> > 
> > Hi all,
> > 
> > I just wanted to let the list know of a way to detect
> > intrusions via IIS. It may work for other web servers, too.
> > 
> > We have just build a new rule to use the nt event log to
> > detect (so far unknown) attacks... Well effectively, we 
> > detect intrusions after they happend. So the intruder most 
> > probably already got in. This will not save you from the 
> > intrusion, but at least you know you need to react.
> > 
> > For it to work, we assume the following:
> > 
> > 1. IIS process tracking is activated (and hopefully works
> > reliable enough ;))
> > 2. The web site is accessed by anonymous users, only
> > 3. The server is a dedicated web server
> > 
> > If 2 or 3 are not the case, we can probably still use the
> > same idea, but the filter needs to be more advanced.
> > 
> > It is important to know that anonymous requests are run in
> > the security context of a specifically designated NT account. 
> > In most cases this is the IUSR_xxx account where xxx is 
> > typically the machine name. This account can be configured in 
> > the IIS admin console. So you need to lookup the details there.
> > 
> > What we now do is we look at the event log in short
> > intervals. When we detect a program start (security event 
> > log, source "Security", event id 592) AND the user is the 
> > IUSR_xxx account AND it is not a program we know IIS needs to 
> > run (e.g. perl.exe is run for PERL scripts; php.exe is for 
> > PHP scripts) then chances are very high that someone has 
> > successfully intruded our machine via IIS. So it would 
> > probably be a good idea to forward the event log record to an 
> > admin in charge (via email or whatever).
> > 
> > I hope this is helpful. As always, comments are very welcome.
> > I would particularly like to know if that works with Apache 
> > under win32 ;)
> > 
> > Rainer Gerhards
> > Adiscon
> > 
> 
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis