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

From: Rainer Gerhards (rgerhardsat_private)
Date: Wed Feb 05 2003 - 04:57:19 PST

  • Next message: Balazs Scheidler: "Re: [logs] How are people bringing DMZ syslog msgs into the central server?"

    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,
    > 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 
    >> lysis
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Wed Feb 05 2003 - 09:36:12 PST