Eric, Just a quick reply. I fully understand the "fat" vs. "thin" issue. The key point with my effort today was that I were NOT doing forensics ;) I tried to figure it out for (near) rel-time analysis, running alongside with the active IIS. The idea is to have a "last resort" warning issued immediately (or some seconds after) a successful attack. The "fat" logs in XP/Win 2003 Server allow me to do this with the evaluation of just a single event. So the real time alerter uses much less ressources - it does not need to correlate. If I need to correlate the other events first, I would probably use up to much ressources to run it on an active host. Just to clarify, Rainer > -----Original Message----- > From: Eric Fitzgerald [mailto:ericfat_private] > Sent: Friday, January 17, 2003 8:05 PM > To: Rainer Gerhards; loganalysisat_private > Cc: Tina Bird; Marcus J. Ranum; probertsat_private; Ben Laurie > Subject: RE: NT Event Log and Web Server Attacks > > > 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
This archive was generated by hypermail 2b30 : Sat Jan 18 2003 - 22:11:01 PST