I applaud Rainer's efforts in this matter, but I also think that there's an easier way to go about it; specifically, by performing configuration ahead of time and making an intrusion exceedingly difficult, rather than trying to react to intrusions. Using batch files, it's relatively simple to configure web servers such that they're relatively well protected. By copying executeables such as auditpol.exe, reg.exe, etc., to diskettes, and then writing the appropriate batch files, the system can be fairly well locked down. Mdutil.exe can be used to configure IIS to meet a specific standard. Finally, moving the various executables from their default location, or all together, can provide a good deal of additional protection. From my experience, dealing w/ the EventLog when attempting some exercises can be supremely difficult. Instead of reacting to an incident after it has happened, try preventing the incident, or making it difficult for an incident to actually occur. At that point, tools such as listdlls.exe and handle.exe can give the user context of a process and the command line used to launch the process. Just my $0.02... --- Rainer Gerhards <rgerhardsat_private> wrote: > OK, > > Now I have done my homework much better ;) > > On the 593 event, only the newest versions of > Windows support the image > name inside it: > > Win Version Image file name included in 593 > NT 4 No > Win2K No > XP Yes > .NET Server Yes (now called Windows > 2003 Server) > > So with XP (great server platform ;)) and Windows > 2003 Server (when > available) we can detect (happened) intrusions by > looking at the 593 > events. If they are from the IUSR_xxx account and > not for known valid > files, we most likely have become hacked. > > BTW: with Windows 2003 Server (RC1), the process is > still being tracked > as initiated by local SYSTEM. > > With NT4 and Windows 2000, this does NOT work. The > 593's don't have the > image name in them and the 592 don't have the > correct user. If that is a > dedicated machine with just IIS running, we might > still be able to use > the 592's and live with some false alarms - but that > needs to be decided > by the admin. > > Fortunately, I found another way to track those > executions. It has a > larger performance hit, but it works. I tested it on > Windows 2000 only, > so there might be some issues with other Windows > version (I'd say I > doubt so if I hadn't had today's experience... ;)). > > It works via file system auditing. I use file audit > events, specifically > "execution" type to see if IUSR_xxx accesses the > file. I can do so > because interestingly Windows logs the right user id > with the file opens > [but not with the later process creation... Well, > let me dig out my > win32 api - or is process creation first and then > the image being loaded > into memory. I think so (but not totally sure). If > so, we now know where > in its workflow IIS does the actual impersonation > ;)]. I use the 560 > Security events. To enable this, you need to > > A) go to system policies/audit policies and enable > "object access" > auditing. > If this is not enabled, file access audits will > not show up even if > enabled in NTFS > B) go to explorer (or your favourite file manager) > and select the > files/directories that > should be auditied. For example the \winnt > directory. Click > properties, click security, > click advanced, click auditing, click add, type > IUSR_xxx, click OK, > now select "Execute", > click OK (make sure you have this set to inherit) > > Now you have turned on file system auditing for the > IUSR_xxx account. > This will generate those nice 560/Security events > that show you which > files the web user accesses. Unfortunately, this is > more than you got > with process tracking, for example it includes all > DLLs (ODBC, winsock > and so on)loaded by the web application. You can > either turn off > auditing for those via the OS tool (explorer, if you > like clicking) or > some other tool to do it via the command line. Or > you can have these > events reported to the event log and then, during > your analysis of the > event log, ignore everything that is not an exe file > (or whatever else > you are after). > > Once you have done this setup, you can setup a > process to (frequently!) > read the nt event log and look for those 560's from > source "Security" in > the security event log that > > - were created from the IUSR_xxx account > - are in respect to an exe or whatever else you see > fit > - are NOT falid exes as again perl.exe or php.exe > (be sure to use the > full path!) > > If you find some of those, chances are good you have > just then been > hacked. So it would be a good time to forward that > specific event log > entry to the admin via email (or whatever else you > like). Of course, the > filter might need a little fine tuning, but it > should work pretty well. > As we all hope that those warnings will never > appear, it is a good idea > to test you filter with some test script that access > a file deemed as > "evil" ;) > > I am proposing this "IIS monitor" as a kind of last > resort to positively > detect that you have been hacked. So it should at > least save you from > the hassle of detecting a security breach too late. > Again, it most > probably won't help in preventing the incident - but > can aid in timely > response. > > As such, I hope you find the outlined procedure > useful... > > Ah, yes, it works with IIS only, at least as of my > (very limited) > testing with Apache 1.3.27 under win32. But some of > the Apache folks > might proove me to be wrong. > > Rainer Gerhards > Adiscon > > > -----Original Message----- > > From: Rainer Gerhards > > Sent: Friday, January 17, 2003 2:10 PM > > To: 'loganalysisat_private' > > Cc: Rainer Gerhards; 'Tina Bird'; 'Marcus J. > Ranum'; > > 'probertsat_private'; 'Ben Laurie'; > 'ericfat_private' > > 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 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Sat Jan 18 2003 - 21:36:40 PST