Eric, Sorry for the late reply - there was just so many other work in my way... :( I am quoting more of your mail as I would typically do so that you hopefully can find the context... > 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. I set up a lab specifically for this today. I used Win2K Server (no sp, mainly to speed up the setup; not member of a domain) for this testing. Then, I went to local security policy and audit policy and turned everything on. I did not (yet) turn any file system auditing on. I then set the web server up so that I can access cmd.exe via the web. When I do so, I just see two events in this sequence: 592, process start from SYSTEM 593, process exit from IUSR No 600 event in between. Did I forget to turn something on? Any advise is appreciated, Rainer > 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/logana> lysis > _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Feb 05 2003 - 09:36:12 PST