Table 3.1 shows a complete list of the snort alerts triggered by the data analyzed. These alerts were generated using the method discussed in Section 2.8. The alerts in bold are the ones we will have a closer look at. The selection of events was done based on three criteria:
A lot of GIAC students have already analyzed these datasets and have published their findings[10]. We do not want to repeat their findings here. We will however provide a short list of the most important activities found in the log data. We will quickly describe the findings, do a severity analysis and give a reference to more information (potentially to other GCIA practicals that have analyzed this type of traffic). In some cases we will do a quick analysis and show that snort generated false positives.
There is worm traffic (e.g., Nimda and Code Red) showing up in the log files. We do not discuss this here, but direct the interested reader to [13]. For a short description of how the severities can be computed see Appendix C.
alert tcp 255.255.255.0/24 any -> $HOME_NET any (msg:"BACKDOOR Q access"; dsize:>1; flags:A+; flow:stateless; reference:arachnids,203; classtype:misc-activity; sid:184; rev:6;)
Our hypothesis is that the backdoor sends traffic to one of the broadcast addresses to see whether any machine answers. If an answer comes back from one of the machines, the packet will be a response coming from the 255.255.255.0/24 subnet.
Severity: 3 Criticality: 2, we do not have any further information about this asset. This machine did not seem to be involved in any other important traffic either. Lethality: 5, if the "Q" trojan is on a system, anything could have happened to it and potentially other systems. System Countermeasures: 2, we do not have information about the protection mechanisms on the host and therefore assume a two. Network Countermeasures: 2, there seem to be no firewalls or ACLs on the routers; however, an IDS is deployed. Reference: Pete Storm, GCIA Practical[21]
[fontsize=\tiny]
SHELLCODE x86 setgid 0 content:"|B0 B5 CD 80|"
SHELLCODE x86 setuid 0 content:"|B0 17 CD 80|"
SHELLCODE x86 NOOP content:"|90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; depth:128
SHELLCODE x86 stealth NOOP content:"|EB 02 EB 02 EB 02|"
SHELLCODE x86 0x90 unicode NOOP content:"|90 00 90 00 90 00 90 00 90 00|"
SHELLCODE x86 inc ebx NOOP" content:"CCCCCCCCCCCCCCCCCCCCCCCC"
SHELLCODE x86 NOOP" content:"aaaaaaaaaaaaaaaaaaaaa"
SHELLCODE x86 0xEB0C NOOP content:"|EB 0C EB 0C EB 0C EB 0C EB 0C EB 0C EB 0C EB 0C|"
SHELLCODE x86 0x71FB7BAB NOOP content:"q|FB|{|AB|q|FB|{|AB|q|FB|{|AB|q|FB|{|AB|"
SHELLCODE x86 0x71FB7BAB NOOP unicode content:"q|00 FB 00|{|00 AB 00|q|00 FB 00|{|00 AB 00|q|00 FB 00|{|00 AB 00|q|00 FB 00|{|00 AB 00|"
Some of the traffic triggering these rules is HTTPS (which is a false positive because the traffic is encrypted and the signatures are written to match the unencrypted traffic. Analyzing the traffic triggering these alerts, we found that almost all of the connections were from very high port numbers to other very high port numbers. If these were real shellcodes, we would expect the traffic to target well-known port numbers in order to exploit a certain service running on a target system. It does not make sense that this traffic would target high port numbers. We therefore conclude that the traffic represents false positives except for the ones targeting port 20, which are 72 of them. Even among this traffic, we suspect to find a high number of false positives. This is all binary traffic and is very likely to contain some of the sequences in the signatures. If the raw tcpdump logs would be available, we could make sure that prior to the FTP data connections, there was a command connection that requested a certain file or started an upload of a file. That would show that this traffic did not contain shell code. It is also possible that somebody is transferring shellcode via FTP and is not actively trying to exploit a system. This could be verified by looking at the offset of the traffic in the data connection. If the offset is a high one, we are dealing with someone potentially transferring shellcode in an FTP connection. If the offset is very small, it is a potential buffer overflow attack.
It would be worthwile figuring out what the rest of this traffic represents (the one from high port numbers to other high port numbers). However, with the data given, this was impossible. A hypothesis is that the traffic is RPC traffic and the shellcode tries to exploit an RCP service. Again, this would have to be verified with other sources of information.
Severity: 3 Criticality: 3, we do not have any further information about these assets. We do not know whether the attacks were successful. Lethality: 4, if this is indeed shellcode an no false positives, the attack could potentially execute commands on the target systems. Although, it is not clear what the capabilities of executing code would be. System Countermeasures: 2, we do not have information about the protection mechanisms on the host and therefore assume a two. Network Countermeasures: 2, there seem to be no firewalls or ACLs on the routers. Firewalls do not seem to be present either. Otherwise the communications underlying this attack might have been blocked. However, an IDS is deployed.)
CWD command to overflow a buffer. Analyzing some packets, we found that there are some real buffer overflow attempts and the rule triggered correctly. This is the snort rule:
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP CWD overflow attempt";
flow:to_server,established; content:"CWD"; nocase; isdataat:100,relative;
pcre:"/^CWD\s[^\n]{100}/smi"; sid:1919; rev:19;)
And this is the offending packet:
03:09:06.526507 00:03:e3:d9:26:c0 > 00:00:0c:04:b2:33, ethertype IPv4 (0x0800), length 574: IP (tos 0x0, ttl 45, id 55450, offset 0, flags [DF], length: 560, bad cksum 9bb8 (->516e)!) 195.232.55.6.1701 > 207.166.87.42.21: P [bad tcp cksum 7135 (->25e2)!] 2184450005:2184450513(508) ack 1127458918 win 5840 <nop,nop,timestamp 1040178 3948516> 0x0000: 0000 0c04 b233 0003 e3d9 26c0 0800 4500 .....3....&...E. 0x0010: 0230 d89a 4000 2d06 9bb8 c3e8 3706 cfa6 .0..@.-.....7... 0x0020: 572a 06a5 0015 8234 0fd5 4333 a866 8018 W*.....4..C3.f.. 0x0030: 16d0 7135 0000 0101 080a 000f df32 003c ..q5.........2.< 0x0040: 3fe4 4357 4420 3030 3030 3030 3030 3030 ?.CWD.0000000000 0x0050: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0060: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0070: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0080: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0090: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x00a0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x00b0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x00c0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x00d0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x00e0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x00f0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0100: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0110: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0120: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0130: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 0x0140: 3030 3030 3030 f0fc 4031 0708 985f 0808 000000..@1..._.. 0x0150: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x0160: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x0170: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x0180: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x0190: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x01a0: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x01b0: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x01c0: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x01d0: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x01e0: eb0c eb0c eb0c eb0c eb0c eb0c eb0c eb0c ................ 0x01f0: eb0c eb0c eb0c 9090 9090 9090 9090 9090 ................ 0x0200: 9090 31db 43b8 0b74 510b 2d01 0101 0150 ..1.C..tQ.-....P 0x0210: 89e1 6a04 5889 c2cd 80eb 0e31 dbf7 e3fe ..j.X......1.... 0x0220: ca59 6a03 58cd 80eb 05e8 ed0a ca59 6a03 .Yj.X........Yj. 0x0230: 58cd 80eb 05e8 edff ffff ffff ff0a uX.............
The packet contains shell code at address 0x0202. Disassembling the hex code yields the following assembly code:
00000000: 31DB xor bx,bx 00000002: 43 inc bx 00000003: B80B74 mov ax,740B 00000006: 51 push cx 00000007: 0B2D or bp,[di] 00000009: 0101 add [bx+di],ax 0000000B: 0101 add [bx+di],ax 0000000D: 50 push ax 0000000E: 89E1 mov cx,sp 00000010: 6A04 push (w) +04 00000012: 58 pop ax 00000013: 89C2 mov dx,ax 00000015: CD80 int 80 00000017: EB0E jmps file:00000027 00000019: 31DB xor bx,bx 0000001B: F7E3 mul (w) bx 0000001D: FECA dec dl 0000001F: 59 pop cx 00000020: 6A03 push (w) +03 00000022: 58 pop ax 00000023: CD80 int 80 00000025: EB05 jmps file:0000002C 00000027: E8ED0A calln +0AED 0000002A: CA596A retf 6A59 0000002D: 0358CD add bx,[bx+si-33] 00000030: 80EB05 sub bl,+05 00000033: E8EDFF calln file:00000023 00000036: FFFF ??? (w) di 00000038: FFFF ??? (w) di 0000003A: FF0A dec [bp+si]
Obviously, this shellcode is from the TESO 7350wurm.c[22] exploit. We found an in-depth analysis of this very attack on the dshield mailinglist. Stephen Hall[12] has done a very thorough analysis of this exploit for his GCIH practical. We do not repeat his elaborate findings here, but want to also mention Way Farers's post on dshield.org[7]. He mentions that the FTP exploit has two possible outcomes. Firstly a DoS attack can be launched by sending three packets of 504 bytes each. Secondly a buffer overflow can be caused, given that a prior login to the ftp service was possible; for example with an anonymous account. The packet we found was not trying to crash the service as no three packets with the size of 504 bytes were detected. Due to the fact that we already found the shellcode embedded in one of the FTP packets, this was an attack of the latter kind, trying to gain root-access on the remote system. The source was probably not spoofed as otherwise the FTP connection would not have been established3.1. This system should definitely be taken offline and analyzed for a successful intrusion. To protect other machines, they should all be patched and updated to the latest FTP daemons. We also recommend installing a local firewall and only allow people to access the FTP server who should have access to it. This might not be possible for a public FTP server. In such a case, the FTP server should only serves the content it needs to and t should not serve any other purposes. This ensures that a compromised FTP server does not leak any other information.
Severity: 7 Criticality: 4, this is an FTP server. It is possible that the access to this system is business critical. Lethality: 5, this is a root access attempt, therefore possibly compromising the system. System Countermeasures: 2, we do not have information about the protection mechanisms on the host and therefore assume a two. Network Countermeasures: 2, there seem to be no firewalls or ACLs on the routers, according to the traffic in the logs. However, an IDS is deployed.) References: Bugtraq ID 1227[1], TESO 7350wurm[22], dshield.org posting[7].
alert tcp $EXTERNAL_NET any -> $HOME_NET 5032 (msg:"BACKDOOR NetMetro File List"; flow:to_server,established; content:"--"; ...The traffic triggering this alert has source ports of 20 and 80, and a destination port of 5032. These are therefore valid FTP data and HTTP connections3.2. Matching the contents-part of the signature ("
--") easily happens in this type of data.
Severity: 0 (false positive)
alert tcp any 110 -> any any (msg:"Virus - Possible MyRomeo Worm"; flow:established; content:"ble bla"; nocase; classtype:misc-activity; sid:725; rev:6;)The signature looks for POP connections containing the characters "
ble bla". The email triggering the rule contained the following sentence:
with the purchase of an eligible Blast motorcycle.
+-----+
Severity: 0 (false positive)
alert ip any any -> any any (msg:"ATTACK-RESPONSES id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:498; rev:6;)
And the packet triggering the alert (note the uid=0(root) part):
23:59:56.156507 00:03:e3:d9:26:c0 > 00:00:0c:04:b2:33, ethertype IPv4 (0x0800), length 1514: IP (tos 0x0, ttl 46, id 25786, offset 0, flags [DF], length: 1500, bad cksum 898a (->9ea2)!) 65.118.58.104.80 > 32.245.166.236.64857: P [bad tcp cksum a34e (->b866)!] 382268946:382270406(1460) ack 2266701906 win 6432 [snip] To test for this hole, type (when logged in as a real user, not anonymous) : <BR> <tt>ftp> SITE EXEC bash -c id</tt> <P> If you get a return with '200-uid=0(root) gid=0(root)' in it, you have the problem.
Severity: 0 (false positive)
After all this analysis, it is quite disappointing how many false positives snort generated. And this was after we already sorted out some of the events because we either knew or suspected that they are false positives. Our initial recommendation for having some kind of context along with the intrusion detection system starts to make more and more sense. It would help a great deal to reduce the number of false positives. Another suggestion would be to improve snort such that it is aware of the protocol the traffic represents. In the case of the BACKDOOR NetMetro File List, the rule could be rewritten to not just look for a target port of 5032, but also make sure that the traffic is not FTP, nor HTTP, nor any other known protocol, but some kind of proprietary backdoor traffic.