Hey Rainer, this is good news. We were unable to reproduce the problem you described. The user that is logged in both the event header field and in the description field of the audit for process creation is the user context from the token of the parent process, because when a new process is created it inherits the token from the parent process. To complicate things, sometimes that user is listed as "SYSTEM" in the event header and as the machine account in the event description due to a quirk of account lookup- I've filed a work item for our next release to improve that. What you're probably missing is event 600- assign primary token. Often just after a new process is created, the new process' token is replaced (in essence, the context of the new process is changed). In that case event 600 is generated. So when you are doing log forensics for process tracking, you cannot just look at event 593- you also must examine event 600. The IIS process runs as system, so it is correct for any processes created by IIS to show up as SYSTEM. If you check for event 600 you'll probably see one right after event 592, when the process token is changed from SYSTEM to IUSR_XXX as it impersonates. And then you will understand why event 593 lists IUSR. There are no problems with security or access check, as the new process' token is changed to IUSR before any other work is done. I also just did a repro of process creation on Windows 2000; I see exactly what I expected to see (administrator created cmd.exe). I'll respond further in your other messages. Thanks, Eric -----Original Message----- From: Rainer Gerhards [mailto:rgerhardsat_private] Sent: Friday, January 17, 2003 4:52 AM To: loganalysisat_private Cc: Tina Bird; Marcus J. Ranum; probertsat_private; Ben Laurie; Eric Fitzgerald 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 - 21:08:52 PST