LOGS: GIAC GCIA Version 3.5 Practical Detect Rusma Mulyadi

Hi All,
Since I will need to submit my practical by the end of this week and I 
haven't got any feedback yet from my earlier post, I figure I will 
repost this.
Thanks,
Rusma

Rusma Mulyadi wrote:

> This is my 1st detect for the GCIA Practical.
> Feel free to comment. :)
>
> Thanks,
> Rusma
>
>
> Detect 1: Misc. Tiny Fragments
>
> Source of Trace:
> ----------------
> The source of this detect is obtained from 
> http://isc.sans.org/logs/Raw/2002.6.1 - 2002.6.18 and dated from 
> 06/30/02 to 07/18/02.
>
> Several key points to keep in mind throughout this network detect:1
> * Only packets that violate the Snort rule set appear in these log files
> * The logs have been sanitized:
> a. The IP addresses of the protected network space have been “munged”
> b. The checksums have also been modified
> c. Certain keywords have been modified
> d. All ICMP, DNS, SMTP and web traffic has been removed
>
> These log raw log files are then combined into a single file called 
> 2002.6.all using pcapmerge2, downloaded as part of tcpreplay package3.
> # pcapmerge –o 2002.6.all 2002.6.*
> -o <file>: used to specify the name of the combined output file.
>
> The next section discusses the network layout of this detect based on 
> the tcpdump4 command and its sample output below.
>
> # tcpdump –ennqr <filename>
>
> -e prints the link-level header, containing physical/MAC addresses
> -nn disables the host name and port translations
> -q quick output with less protocol information
> -r reads in the merged raw log file
>
> 17:31:16.304488 0:3:e3:d9:26:c0 0:0:c:4:b2:33 60: 211.152.3.40.80 > 
> 46.5.15.174.80: tcp 0
>
> The fields of the above tcpdump output format – delimited by 
> spaces/blanks – that will be analyzed further in this section are:
> Field# Description
> 2 Source MAC Address
> 3 Destination MAC Address
> 5 Source IP Address and Port
> 7 Destination IP Address and Port
>
> To obtain the unique source MAC addresses, the second field of the 
> sample output above is uniquely sorted. The resulted source MAC 
> addresses are printed together with their number of occurrences in the 
> entire log:
>
> # tcpdump -ennqr 2002.6.all | awk '{print $2}' | sort | uniq -c
> 32479 0:0:c:4:b2:33
> 6406 0:3:e3:d9:26:c0
>
> The third field of the output file identifies the destination MAC 
> addresses and is printed below:
>
> # tcpdump -ennqr 2002.6.all | awk '{print $3}' | sort | uniq -c
> 6406 0:0:c:4:b2:33
> 32479 0:3:e3:d9:26:c0
>
> In addition to the fact that the counts of both MAC addresses as the 
> source and destination addresses are exactly reversed, both MAC 
> addresses are also registered to Cisco Systems according to the 
> information shown below from the IEEE OUI Registration database5. 
> Therefore, these logs are generated by an intrusion detection system 
> (sniffer) that sits between two Cisco devices.
>
> 00-00-0C (hex) CISCO SYSTEMS, INC.
> 00000C (base 16) CISCO SYSTEMS, INC.
> 170 WEST TASMAN DRIVE
> SAN JOSE CA 95134-1706
>
> 00-03-E3 (hex) Cisco Systems, Inc.
> 0003E3 (base 16) Cisco Systems, Inc.
> 170 West Tasman Dr.
> San Jose CA 95134
> UNITED STATES
>
>
> To further understand the location of these devices within the network:
>
> 1. The distinct source IP addresses (field #5) coming from 0:0:c:4:b2:33
>
> # tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print
> $5}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort |
> uniq -c | sort -rn
> 32434 46.5.180.250
> 45 46.5.180.133
>
> 2. The distinct destination IP addresses (field #7) coming from 
> 0:0:c:4:b2:33
> # tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print
> $7}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort |
> uniq –c | sort -rn
> 16700 64.154.80.51
> 6339 66.128.224.70
> 686 64.154.80.50
> 522 208.45.133.13
> <snip>
> 1 12.216.161.118
> 1 12.150.245.163
> 1 12.111.145.134
>
> At this point, it seems that 0:0:c:4:b2:33 is a Cisco device that sits 
> in front of a Class C internal network (46.5.180.0/24) at this point.
>
> 3. The distinct source IP addresses (field #5) coming from 
> 0:3:e3:d9:26:c0
>
> # tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk
> '{print $5}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort
> | uniq -c | sort –rn
> 683 255.255.255.255
> 297 66.220.44.31
> 180 203.122.47.137
> 169 62.153.209.202
> <snip>
> 1 12.150.54.250
> 1 12.107.51.109
> 1 12.105.86.5
>
> Based on the variety of IP addresses sourced from 0:3:e3:d9:26:c0, we 
> can conclude that it is most likely a ‘border’ router that is located 
> between the Internet and the network in this particular trace.
>
> 4. The distinct destination IP addresses (field #7) coming from 
> 0:3:e3:d9:26:c0
>
> # tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk
> '{print $7}' | awk -F \. {'print $1 "." $2 "." $3 "." $4'} | sort
> | uniq -c | sort -rn | more
> 1714 46.5.180.250
> 908 46.5.180.133
> 381 46.5.80.149
> 36 46.5.218.182
> 28 46.5.130.100
> 26 46.5.180.135
> <snip>
> 1 46.5.0.16
> 1 46.5.0.139
> 1 46.5.0.130
> 1 46.5.0.10
>
> >From this last output, we discover that the internal network is much 
> bigger than a Class C network. Instead, it looks more like a Class B 
> network (46.5.0.0/16).
>
> The network layout of this trace can then be summarized as:
>
> Intrusion Detection Systems
> |
> |
> Internet --- Cisco Device 1 -----+------ Cisco Device 2 --- Internal
> 0:3:e3:d9:26:c0 0:0:c:4:b2:33 46.5.0.0/16
>
>
> 5. The distinct destination ports coming from 0:0:c:4:b2:33
>
> ### Total unique destination ports coming from 0:0:c:4:b2:33
> # tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print
> $7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn | wc -l
> 248
>
> ### List of unique destination ports coming from 0:0:c:4:b2:33
> # tcpdump -ennqr 2002.6.all 'ether src 0:0:c:4:b2:33' | awk '{print
> $7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn
> 29487 80:
> 851 6347:
> 552 1863:
> 410 6348:
> 95 5555:
> <snip>
> 1 10508:
> 1 10450:
> 1 10222:
> 1 100:
>
> The existence of 248 unique destination ports of the outgoing traffic 
> in the entire log file indicates a loose egress filtering. However, it 
> seems that there are filters for the well-known Microsoft Windows 
> ports (135, 137-139, and 445) because none of them are found in these 
> 248 destination ports. The top 4 outgoing traffic corresponds to http 
> (port 80), gnutella (port 6347 and 6348), MSN messenger (1863) and 
> Napster (port 5555).6 This is assuming that these ports are used by 
> their normal applications.
>
> 6. The distinct destination ports coming from 0:3:e3:d9:26:c0
>
> ### Total unique destination ports coming from 0:3:e3:d9:26:c0
> # tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk
> '{print $7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn
> | wc -l
> 717
>
> ### List of unique destination ports coming from 0:3:e3:d9:26:c0
> # tcpdump -ennqr 2002.6.all 'ether src 0:3:e3:d9:26:c0' | awk
> '{print $7}' | awk -F \. {'print $5'} | sort | uniq -c | sort -rn
> 1704 80:
> 705 21:
> 683 515:
> 591 53:
> 416 6346:
> <snip>
> 4 137:
> <snip>
> 1 61002:
> 1 6000:
> 1 41992:
> 1 40195:
> 1 3514:
>
> The existence of 717 unique destination ports in the incoming traffic 
> that includes a Windows NetBIOS port 137 in the entire log file also 
> indicates a loose ingress filtering. Although it seems that the egress 
> filtering includes a block for well-known Windows ports, it does not 
> appear to be the case with regard to the ingress filtering. The top 3 
> incoming traffic corresponds to http (port 80), ftp (port 21), printer 
> (port 515), domain name (port 53), and gnutella (port 6346).6 Again, 
> this is assuming that these ports are used by their normal applications.
>
> The limited ingress and egress filtering applied on this network is an 
> indication of a very loose network security policy implementation and 
> it fits the profile of typical .edu network.
>
>
> Detect was generated by:
> -------------------------
>
> This detect is generated using Snort Version 2.2.0 with all the rules 
> enabled. The latest rules are The snort.conf is modified to include as 
> the home network. The following command is used:
> # snort -r 2002.6.all -c ../snort/etc/snort.conf -A full
> -l alert612ALL/ -dey -k none
>
> -r <filename> read and process a tcpdump file
> -c <cfgfile> use rules specified in the configuration file
> -A <mode> alert mode (fast, full, console or none)
> -l <log dir> specify the log directory
> -d print the application layer information
> -e display the 2nd layer header info
> -y include year in timestamp of alert and log files
> -k <mode> checksum mode (all, noip, notcp, noudp, noicmp, none)
>
>
> SnortSnarf v021111.17 is then used to facilitate the alert analysis 
> process.
>
> # ./snortsnarf –d alert612view/ alert612ALL/alert
> -d <dir> specify the output directory
> This detect will focus on the Misc Tiny Fragments signature alerts as 
> summarized in Figure 1 below.
>
> Figure 1 Misc Tiny Fragments Alerts Summary
>
> An alert on this signature is generated when a fragment packet (with 
> More Fragment – M flag set) with a payload size (dsize) of less than 
> 25 bytes is received from the external network. Below is the 
> corresponding Snort rule8.
> alert ip $EXTERaNAL_NET any -> $HOME_NET any (msg:"MISC Tiny 
> Fragments"; dsize:< 25; fragbits:M; classtype:bad-unknown; sid:522; 
> rev:2;)
> The 5 alerts of interest are:
> [**] [1:522:2] MISC Tiny Fragments [**]
> [Classification: Potentially Bad Traffic] [Priority: 2]
> 07/10/02-01:06:04.854488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 
> len:0x3C
> 64.26.170.95 -> 46.5.80.149 TCP TTL:237 TOS:0x0 ID:0 IpLen:20 
> DgmLen:40 MF
> Frag Offset: 0x1FCB Frag Size: 0x0014
> [**] [1:522:2] MISC Tiny Fragments [**]
> [Classification: Potentially Bad Traffic] [Priority: 2]
> 07/10/02-20:41:23.524488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 
> len:0x3C
> 80.136.103.85 -> 46.5.80.149 TCP TTL:241 TOS:0x0 ID:0 IpLen:20 
> DgmLen:40 MF
> Frag Offset: 0x1E17 Frag Size: 0x0014
> [**] [1:522:2] MISC Tiny Fragments [**]
> [Classification: Potentially Bad Traffic] [Priority: 2]
> 07/10/02-22:48:25.114488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 
> len:0x3C
> 64.105.26.118 -> 46.5.80.149 TCP TTL:237 TOS:0x0 ID:0 IpLen:20 
> DgmLen:40 MF
> Frag Offset: 0x1ED3 Frag Size: 0x0014
> [**] [1:522:2] MISC Tiny Fragments [**]
> [Classification: Potentially Bad Traffic] [Priority: 2]
> 07/11/02-16:38:45.424488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 
> len:0x3C
> 64.105.26.164 -> 46.5.80.149 TCP TTL:237 TOS:0x0 ID:0 IpLen:20 
> DgmLen:40 MF
> Frag Offset: 0x1ED3 Frag Size: 0x0014
> [**] [1:522:2] MISC Tiny Fragments [**]
> [Classification: Potentially Bad Traffic] [Priority: 2]
> 07/15/02-21:26:14.184488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 
> len:0x3C
> 217.83.201.131 -> 46.5.80.149 TCP TTL:242 TOS:0x0 ID:0 IpLen:20 
> DgmLen:40 MF Frag Offset: 0x1EB2 Frag Size: 0x0014
>
> Using the last alert above as a sample, a Snort alert format contains:
> [**] [1:522:2] MISC Tiny Fragments [**]
>
> --> [**] [Generator ID: Signature ID: Revision Number] Signature 
> Message [**]
>
>
> [Classification: Potentially Bad Traffic] [Priority: 2]
>
> --> [Classification: Classification Type’s Short Name] [Priority: 
> Priority level]
>
>
> 07/15/02-21:26:14.184488 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800 
> len:0x3C
>
> --> Timestamp Source MAC Address -> Destination MAC Address
> --> type: encapsulation protocol (0x800 = IP)
> --> len: length of the frame (0x3C = 60)
>
>
> 217.83.201.131 -> 46.5.80.149 TCP TTL:242 TOS:0x0 ID:0 IpLen:20 
> DgmLen:40 MF Frag Offset: 0x1EB2 Frag Size: 0x0014
>
> --> Source IP Address -> Destination IP Address
> --> Protocol ID
> --> TTL: time to live
> --> TOS: type of service
> --> ID: IP / Fragment ID
> --> DgmLen: total length of datagram
> --> IP Flag: IP flags (reserved bit| Don’t Fragment | More Fragment)
> --> Frag Offset: fragment offset
> --> Frag Size: fragment size
>
> To confirm these Snort generated alerts, the log file is passed 
> through tcpdump with bpf filters to include packets with:
> 1. More Fragment flag set (ip[6] & 0x20 != 0)
> 2. total payload less than 25 bytes (ip[3]-((ip[0] & 0x0f)*4) < 25).
>
> # tcpdump -Xxvnns 1514 -r 2002.6.all '(ip[6] & 0x20 != 0) and (ip[6] &
> 0x80 ==0) and (ip[3]-((ip[0] & 0x0f)*4) < 25)'
>
> Packet 1: ip[6] == 0x6f --> fragbits:DM
> 17:50:45.374488 64.244.110.164 > 46.5.212.116: tcp (frag 0:20@30904+) 
> (ttl 237, len 40, bad cksum b1ae!)
> 0x0000 4500 0028 0000 6f17 ed06 b1ae 40f4 6ea4 E..([email protected].
> 0x0010 2e05 d474 8105 0050 0400 ff56 0400 ff56 ...t...P...V...V
> 0x0020 5004 0000 7ad3 0000 0000 0000 0000 P...z.........
>
> Packet 2: ip[6] == 0x3e --> fragbits:M
> 21:26:14.184488 217.83.201.131 > 46.5.80.149: tcp (frag 0:20@62864+) 
> (ttl 242, len 40, bad cksum 70b1!)
> 0x0000 4500 0028 0000 3eb2 f206 70b1 d953 c983 E..(..>...p..S..
> 0x0010 2e05 5095 8389 18ca 0e11 7516 0e11 7516 ..P.......u...u.
> 0x0020 5004 0000 f3d1 0000 0000 0000 0000 P.............
>
> Packet 3: ip[6] == 0x3e --> fragbits:M
> 20:41:23.524488 80.136.103.85 > 46.5.80.149: tcp (frag 0:20@61624+) 
> (ttl 241, len 40, bad cksum 5d46!)
> 0x0000 4500 0028 0000 3e17 f106 5d46 5088 6755 E..(..>...]FP.gU
> 0x0010 2e05 5095 8206 18ca 0935 7f24 0935 7f24 ..P......5.$.5.$
> 0x0020 5004 0000 d5ea 0000 0000 0000 0000 P.............
>
> Packet 4: ip[6] == 0x3e --> fragbits:M
> 22:48:25.114488 64.105.26.118 > 46.5.80.149: tcp (frag 0:20@63128+) 
> (ttl 237, len 40, bad cksum bd88!)
> 0x0000 4500 0028 0000 3ed3 ed06 bd88 4069 1a76 E..(..>[email protected]
> 0x0010 2e05 5095 8039 18ca 9d55 7d9e 9d55 7d9e ..P..9...U}..U}.
> 0x0020 5004 0000 0f81 0000 0000 0000 0000 P.............
>
> Packet 5: ip[6] == 0x3e --> fragbits:M
> 16:38:45.424488 64.105.26.164 > 46.5.80.149: tcp (frag 0:20@63128+) 
> (ttl 237, len 40, bad cksum bd5a!)
> 0x0000 4500 0028 0000 3ed3 ed06 bd5a 4069 1aa4 E..(..>....Z@i..
> 0x0010 2e05 5095 82ff 18ca a129 6dae a129 6dae ..P......)m..)m.
> 0x0020 5004 0000 24c5 0000 0000 0000 0000 P...$.........
>
> Packet 6: ip[6] == 0x3f --> fragbits:M
> 01:06:04.854488 64.26.170.95 > 46.5.80.149: tcp (frag 0:20@65112+) 
> (ttl 237, len 40, bad cksum 2cf6!)
> 0x0000 4500 0028 0000 3fcb ed06 2cf6 401a aa5f E..(..?...,.@.._
> 0x0010 2e05 5095 8047 18ca 4107 12d2 4107 12d2 ..P..G..A...A...
> 0x0020 5004 0000 0e0e 0000 0000 0000 0000 P.............
>
> Packet 7: ip[6] == 0x64 --> fragbits:DM
> 08:00:17.944488 61.205.39.211 > 46.5.80.149: tcp (frag 0:20@9368+) 
> (ttl 236, len 40, bad cksum 8e07!)
> 0x0000 4500 0028 0000 6493 ec06 8e07 3dcd 27d3 E..(..d.....=.'.
> 0x0010 2e05 5095 81d1 18ca 1c07 fa00 1c07 fa00 ..P.............
> 0x0020 5004 0000 0d00 0000 0000 0000 0000 P.............
>
> The tcpdump command results in two additional packets, i.e. Packet 1 
> and 7. This is because these two packets also have the Don’t Fragment 
> flag set in addition to the More Fragment flag. The corresponding 
> snort rule fires when only the More Fragment is set. The bpf filter is 
> then modified to fit this restriction (ip[6] & 0x60 == 0x20). Below is 
> the modified tcpdump command and only packet 2 – 5 are returned this 
> time.
> # tcpdump -Xxvnns 1514 -r 2002.6.all '(ip[6] & 0x60 == 0x20) and 
> (ip[3]-((ip[0] & 0x0f)*4) < 25)'
>
>
> Probability the source address was spoofed:
> ---------------------------------------------
>
> As will be further described in the next two sections, I believe that 
> the packets in this trace are corrupted RST packets from real Gnutella 
> traffic. Therefore, the possibility that the source addresses are 
> spoofed is very small.
> The TTL (time to live) values also appear to be consistent with the 
> source IP classes, i.e. the one sourced from the same Class A 
> (64.x.x.x) seems to have similar TTL values. Searching these 5 source 
> addresses in Geektools9 returns three different Internet Service 
> Provider companies, i.e.: Magma Communication/ Canada, Covad/ US, 
> Deutsche Telekom AG.
> Also, performing */nslookup/* on these machines shows that they are 
> alive.
> Name: pD953C983.dip.t-dialin.net
> Address: 217.83.201.131
> Name: h-64-105-26-164.lsanca54.dynamic.covad.net
> Address: 64.105.26.164
> Name: h-64-105-26-118.lsanca54.dynamic.covad.net
> Address: 64.105.26.118
> Name: p50886755.dip0.t-ipconnect.de
> Address: 80.136.103.85
> Name: ottawa-hs-64-26-170-95.d-ip.magma.ca
> Address: 64.26.170.95
>
> Thus, these 5 source addresses are mostly likely regular Gnutella 
> servents.
> In addition, RST packets are usually sent either in responses to 
> connection requests to non-existence services, to abort existing 
> connections, or to OS fingerprint systems in the target network. In 
> this particular detect, I tend to believe that the corrupted RST 
> packets are generated to abort existing Gnutella connections, and 
> therefore, the source addresses are not spoofed.
>
>
> Description of attack:
> -----------------------
>
> Tiny fragments are often to bypass the intrusion detection systems and 
> firewalls that fail to perform proper fragments reassembly. The common 
> fragmentation attacks include fragmentation overlap, fragmentation 
> overwrite, and fragmentation time-outs.10 Although most of the current 
> intrusion detection systems (e.g. Snort’s frag2 preprocessor) and 
> firewalls are capable of maintaining states and perform fragmentation 
> reassembly, these devices are still susceptible to denial of service 
> attacks while not configured properly. In addition, some systems may 
> crash or severely disrupted when receiving a lot of malformed 
> fragmented packets.11
> In this particular tiny fragments detect, there are two possible 
> explanations:
> 1. These packets are part of a larger tiny fragment attacks described 
> above. The facts that the frag id and the data length are always 0 and 
> 20 might indicate that these are crafted packets. However, there is 
> not enough information available to support this conclusion, 
> especially with only 1 fragment of the entire fragments train is 
> available in the packet trace.
> 2. These are corrupted packets and based on further description in the 
> next section, they are corrupted RST packets sent by a Gnutella 
> servent to end a connection. I incline towards this second scenario.
>
>
> Attack mechanism:
> --------------------
>
> There are several interesting similarities among the packets in this 
> detect:
> 1. The 4th and 5th bytes offset of IP header – IP/fragment ID = 0
> 2. The More Fragment flag – found in the 3 high-order bits of the 6th 
> bytes offset of IP header – is always set. The 6th bytes offset of IP 
> headers (ip[6]) of this detect are either 0x3e or 0x3f. Using the IP 
> header template:
> Hex => Decimal => IP Flags | Fragment Offset (portion)
> xDM
> 0x3e => 62 => 001 | 11110
> 0x3f => 63 => 001 | 11111
>
> IP Flags:
> x – reserved, set to 0; D – Don’t Fragment; M – More Fragment
> 3. The 9th byte offset of the IP header – Protocol = 0x06 (i.e. TCP)
> 4. The 2nd and 3rd bytes offset of the payload (since the MF flag is 
> set in the IP header) = 0x18ca or decimal 6346
> 5. The values of the 4th to 7th bytes offset of the payload is always 
> the same as those of the 8th to 11th bytes offset
> 6. The 12th and 13th bytes offset of the payload = 0x5004
> If I ignore the fact that these packets are fragments and consider the 
> payload as TCP header instead of fragment payload, point 4 – 6 above 
> can be translated into:
> 4. Destination port = 6346 (Gnutella)
> 5. Sequence number = ACK number
> 6. TCP header length = 20 bytes; TCP RST flag is set
> Hex => Offset | Reserved | Flags
> | | UAPRSF
> 0x5004 => 0101 | 0000 00 | 000100
>
> TCP Flags:
> U – Urgent; A – Ack; P – Push; R – Reset; S – Syn; F - Fin
>
> To support my suspicion that these packets are corrupted Gnutella RST 
> packets, I use tcpdump to filter all traffic sourced from / destined 
> to 46.5.80.149 in the raw log file. (Notice that all of these alerts 
> destined to the same ip address, i.e. 46.5.80.149)
> # tcpdump -nnr 2002.6.all 'dst host 46.5.80.149' | wc
> 399 3536 35076
> # tcpdump -nnr 2002.6.all 'src host 46.5.80.149' | wc
> 0 0 0
>
> While none of the logged traffics sourced from 46.5.80.149, there are 
> 399 packets destined to it. Among these 399 packets: 12
> * 380 destined to TCP port 6346 - registered to Gnutella.
> * 18 fragmented packets – without destination ports
> * 1 destined to TCP 3514 – registered to MUST Peer to Peer
>
> # tcpdump -nnr 2002.6.all 'dst host 46.5.80.149' | awk '{print $4}'
> | awk -F \. {'print $5'} | sort | uniq -c |more
> 18
> 1 3514:
> 380 6346:
>
> In addition, it appears that there are no packets sourced from the 
> five different source IP addresses in this detect other than the ones 
> triggering these Misc Tiny Fragment alerts.
>
> # tcpdump -nnr 2002.6.all 'host 64.26.170.95 or host 64.105.26.118
> or host 64.105.26.164 or 217.83.201.131 or 80.136.103.85' |wc
> 5 35 340
> At this point, I can conclude that 46.5.80.149 is a Gnutella servent. 
> Below is a sample of the packets:
> 18:21:45.164488 148.63.247.123.3536 > 46.5.80.149.6346: P 
> 2391248906:2391249078(172) win 8192 (DF)
> 0x0000 4500 00d4 9dcf 4000 6e06 6c04 943f f77b [email protected]..?.{
> 0x0010 2e05 5095 0dd0 18ca 8e87 900a 0000 0000 ..P.............
> 0x0020 5e08 2000 48d3 0000 474e 5554 454c 4c41 ^...H...GNUTELLA
> 0x0030 2043 4f4e 4e45 4354 2f30 2e36 0d0a 5573 .CONNECT/0.6..Us
> 0x0040 6572 2d41 6765 6e74 3a20 4265 6172 5368 er-Agent:.BearSh
> 0x0050 6172 6520 322e 362e 330d 0a4d 6163 6869 are.2.6.3..Machi
> 0x0060 6e65 3a20 312c 3133 2c31 3930 2c31 2c34 ne:.1,13,190,1,4
> 0x0070 3938 0d0a 506f 6e67 2d43 6163 6869 6e67 98..Pong-Caching
> 0x0080 3a20 302e 310d 0a48 6f70 732d 466c 6f77 :.0.1..Hops-Flow
> 0x0090 3a20 312e 300d 0a4c 6973 7465 6e2d 4950 :.1.0..Listen-IP
> 0x00a0 3a20 3134 382e 3633 2e32 3437 2e31 3233 :.148.63.247.123
> 0x00b0 3a36 3334 360d 0a52 656d 6f74 652d 4950 :6346..Remote-IP
> 0x00c0 3a20 3137 302e 3132 392e 3230 342e 3139 :.170.129.204.19
> 0x00d0 0d0a 0d0a ....
>
> Gnutella is a peer-to-peer protocol for distributed search and digital 
> distribution / file sharing. Each participant is called a servent and 
> acts as both a client and a server.13 A description on the protocol 
> can be found on the link below:
> http://rfc-gnutella.sourceforge.net/developer/index.html
> >From my online research, I was not able to obtain much information 
> regarding TCP RST packets to end Gnutella connections. I then decide 
> to capture some live Gnutella (port 6346) traffic on our campus 
> network to learn more on its behavior. From the captured traffic, I 
> try to find RST packets with the same sequence (tcp[4:4]) and ACK 
> numbers (tcp[8:4]).
> ### capture live Gnutella (port 6346) traffic
> # tcpdump -i bond0 -xnns 1514 ‘port 6346’
>
> ### filter RST packets with sequence # = ACK #
> # tcpdump -r gnu -xnns 1514 ‘tcp[13] = 0x04 and tcp[4:4] = tcp[8:4] 
> and dst port 6346'
> I do find quite a lot of these packets. Below are some samples 
> (checksums and source IPs are removed):
> 16:40:22.417450 x.x.x.x.4834 > 68.162.158.172.6346: R 4231098138:42
> 31098138(0) win 0
> 4500 0028 a541 0000 7f06 xxxx xxxx xxxx
> 44a2 9eac 12e2 18ca fc31 6f1a fc31 6f1a
> 5004 0000 f492 0000 0000 0000 0000
> 16:40:22.459180 x.x.x.x.4839 > 69.177.14.249.6346: R 4232152131:423
> 2152131(0) win 0
> 4500 0028 a545 0000 7f06 xxxx xxxx xxxx
> 45b1 0ef9 12e7 18ca fc41 8443 fc41 8443
> 5004 0000 58c0 0000 0000 0000 0000
> 16:40:22.622202 x.x.x.x.4837 > 24.51.185.190.6346: R 4231561837:423
> 1561837(0) win 0
> 4500 0028 a551 0000 7f06 xxxx xxxx xxxx
> 1833 b9be 12e5 18ca fc38 826d fc38 826d
> 5004 0000 df38 0000 0000 0000 0000
>
> Although RST packets are usually sent either as responses to 
> connection requests to closed ports or as ways to abort existing 
> connections based the RFC 79314, I notice that Gnutella servents often 
> send both FIN (normal way to terminate connections) and RST packets 
> when closing a connection unless the remote servents respond 
> immediately with FIN ACK packets. This duplication is particularly 
> true when a busy message (“There are too many active upload, and no 
> space in the queues”) is received from a remote servent. It seems that 
> this is intended by design to avoid a lot of TCP half-close 
> connections and to tear down the connections right away.
> Since not all of these live captured RST packets have the same 
> sequence and ACK numbers, I perform OS fingerprinting (using nmap) on 
> two of these machines and they are identified as Windows systems as 
> showed below.
> Remote operating system guess: Windows Millennium Edition (Me), Win 
> 2000, or Win XP
> Remote OS guesses: Windows NT 5 Beta2 or Beta3, Windows Millennium 
> Edition (Me), Win 2000, or WinXP, MS Windows2000 Professional RC1/W2K 
> Advance Server Beta3
>
> In addition, p0f’s RST+ signatures15 describes that “while the ACK 
> value should be zeroed, it is not strictly against the RFC, and some 
> systems either leak memory there or set it to the value of SEQ. The 
> latter variant, with non-zero ACK, is particularly common on Windows”.
>
> Thus, if the packets are really corrupted RST Gnutella packets, I can 
> be pretty confident that the source IPs are Windows machines.
>
> The next question is how do these RST packets turn into fragments?
> Comparing a sample of the real RST packets and the ones in this 
> detect, there is an obvious different is on the 4th – 7th bytes offset 
> of the IP header. It seems that the values of the first two bytes (4th 
> and 5th – 0x0000) are somehow swapped with those of the last two (6th 
> and 7th – 0x3fcb) in this detect. Since the 4th & 5th bytes offset of 
> IP header are the IP/Fragment ID and the 6th & 7th bytes offset are IP 
> Flags and Fragment Offset, swapping them around can definitely turn a 
> non-fragment packet into a fragment.
>
> Real Gnutella RST packet
> 4500 0028 a551 0000 7f06 xxxx xxxx xxxx
> 1833 b9be 12e5 18ca fc38 826d fc38 826d
> 5004 0000 df38 0000 0000 0000 0000
>
> Last packet in this detect (Packet 6)
> 4500 0028 0000 3fcb ed06 2cf6 401a aa5f
> 2e05 5095 8047 18ca 4107 12d2 4107 12d2
> 5004 0000 0e0e 0000 0000 0000 0000
>
> To support this swapping theory, I notice that my earlier tcpdump 
> filter on tiny fragment packets (less than 25 bytes payload and MF 
> flag set) returned two additional packets that have both MF (More 
> Fragment) and DF (Don’t Fragment) flags set. These two flags identify 
> 2 opposing traits of a packet and should not exist together in a 
> packet when the RFC is followed. Thus, I am pretty sure that these two 
> packets are also corrupted by the same technique.
>
>
> Correlations:
> ----------------
> There are several postings regarding ‘MISC Tiny Fragments’ detect on 
> the intrusions list:
> * Richard Haynal analyzed a different traffic trace in 
> www.incidents.org/logs/Raw/2002.9.22 and also concluded that the 
> packets in his detect are corrupted. The original posting is available 
> at: http://www.dshield.org/pipermail/intrusions/2003-April/007375.php
> * Lesa Ludwig analyzed another traffic trace in 
> http://www.incidents.org/logs/Raw/2002.10.11. Several categories of 
> fragmentation attacks are presented as part of the analysis. The 
> original posting is available at: 
> http://www.dshield.org/pipermail/intrusions/2003-January/006463.php
> Considering that the tiny fragments in this detect are corrupted 
> packets, there are no related CVE entries.
> Although I am reluctant to believe that this detect is part of a tiny 
> fragmentation attack, below are several articles on the fragmentation 
> attacks:
> * IDS Evasion Techniques and Tactics, by Kevin Timm, May 7, 2002, 
> http://www.securityfocus.com/infocus/1577
> * Protection Against a Variant of the Tiny Fragment Attack, June 2001, 
> http://rfc.net/rfc3128.html
> * An Analysis of Fragmentation Attacks, by Jason Anderson, March 15, 
> 2001, http://www.inet-sec.org/docs/DoS/fragma.html
> * Cisco PIX and CBAC Fragmentation Attack, September 11, 1998, 
> http://www.cisco.com/warp/public/770/nifrag.shtml
> * Security Considerations for IP Fragment Filtering, October 1995, 
> http://rfc.net/rfc1858.html
> Only one of the five source IP addresses in this detect has an entry 
> in myNetWatchman incident database16, i.e. 217.83.201.131 (Incident 
> ID: 112675479). However, this particular event is relatively new and 
> related to Microsoft SMB/CIFS/Sasser/Agobot/Generic Bot, which is not 
> relevant to this detect. No incident entry is found on dshield.org for 
> these five source IPs.
>
>
> Evidence of active targeting:
> -----------------------------
> Should this detect be classified as a real attack, I can be relatively 
> positive that there is an active targeting because all alerts in this 
> detect are directed to the destination IP. However, this detect is not 
> a real attack, but some corrupted packets. Thus, there is no evidence 
> of active targeting in this particular detect.
>
>
> Severity: -1
> ---------------
> severity = (criticality + lethality) - (system countermeasures + network
> countermeasures)
> = (2+1) – (2+2) = 3 – 4 = -1
>
> Criticality: 2
> Although there is no information regarding the criticality of this 
> target system, the fact that traffic destined to it is mostly 
> peer-to-peer related (as discussed earlier) lead me to conclude that 
> it’s an end-user workstation. Also, since this particular network fits 
> the profile of an .edu network, an end-user workstation with Gnutella 
> client program can be anyone’s computer (student/faculty/staff). 
> Although the criticality level may vary depending on the owner of the 
> systems, I assign the criticality value of 2 here.
>
> Lethality: 1
> There is no real attack in this particular detect. I believe that 
> these tiny fragments are corrupted Gnutella RST packets. Thus, the 
> level of damage caused is very low.
> System countermeasures: 2
> There is no information regarding the system-level defenses on the 
> target machine and I can only assume based on the fact that it is 
> running a Gnutella client program. Since the security awareness level 
> of average end users in an .edu environment is usually relatively low, 
> I assign the system countermeasures a value of 2.
>
> Network countermeasures: 2
> Based on the information in the first section of this detect, I 
> conclude that the existing network countermeasures seem to include 
> loose egress & ingress filterings and an intrusion detection system. 
> Although it seems that there are blocks for well-known Windows ports 
> as part of the egress filtering, the same blocks do not appear to be 
> applied in the ingress filtering. I therefore assign the network 
> countermeasures a value of 2.
>
>
> Defensive recommendation:
> --------------------------
> Although this detect does not include real fragmentation attacks, 
> network–level defenses can still be put in place to prevent them and 
> to further improve the current state of network security:
> * Implement stateful firewall that is capable of maintaining 
> inter-fragment state and dropping illegal and tiny fragments. If the 
> size of the initial fragment is not large enough to fit all necessary 
> header information, it should be dropped.17 Any non-initial fragments 
> should also be discarded unless the corresponding initial fragment has 
> passed the firewall.18 The amount of memory assigned to maintain the 
> fragmentation state should also be limited to reduce the possibility 
> of denial of service attacks against the firewall itself.
> * Most of today’s IDSs are capable of performing fragmentation 
> reassembly, including Snort. Assuming Snort is used in this network, 
> the frag2 preprocessor need to be enabled.
> * Applying more rigid ingress filtering by gradually moving from 
> ‘permit all, deny specifics’ to ‘permit specifics, deny all’. This 
> might not be a easy option especially if this is an actual .edu network.
> As for the host-level defenses:
> * Fragmentation attacks may also cause certain un-patched systems to 
> crash. Thus, it is required to keep each host up-to-date on its 
> security patches.
> * Assuming that the traffic categorization from the log file is a 
> decent representation of the actual traffic on the network, 
> peer-to-peer traffic is one of the most popular traffic coming into 
> and leaving the network. As peer-to-peer programs usually come with 
> spyware/ adware, the dangerous of these ‘add-on’ programs should be 
> brought up to end users’ attention. This is especially
>
>
> Multiple choice test question:
> -------------------------------
>
> ‘tcp[13] = 0x04 and tcp[4:4] = tcp[8:4] and dst port 6346'
> What kind of traffic does the above bpf filter look for?
>
> A) TCP traffic with SYN and ACK flags set, the same source and 
> destination ports, destination port = 6346
> B) TCP traffic with RST flag set, the same source and destination 
> ports, destination port = 6346
> C) TCP traffic with SYN and ACK flags set, the same SEQ and ACK 
> numbers, destination port = 6346
> D) TCP traffic with RST flag set, the same SEQ and ACK numbers, 
> destination port = 6346
>
> Answer: D
>
>
> 1 http://isc.sans.org/logs/Raw/README
> 2 http://tcpreplay.sourceforge.net/pcapmerge.html
> 3 http://www.sourceforge.net/projects/tcpreplay/
> 4 http://tcpdump.org/tcpdump_man.html
> 5 http://standards.ieee.org/regauth/oui/oui.txt
> 6 http://www.neohapsis.com/neolabs/neo-ports/neo-ports.html
> 7 http://www.snort.org/dl/contrib/data_analysis/snortsnarf/
> 8 http://www.snort.org/snort-db/?sid=522
> 9 http://www.geektools.com/whois.php
> 10 http://www.securityfocus.com/infocus/1577
> 11http://www.securiteam.com/windowsntfocus/Patch_Available_for_the__IP_Fragment_Reassembly__Vulnerability.html 
>
> 12 http://www.iana.org/assignments/port-numbers
> 13 
> http://rfc-gnutella.sourceforge.net/developer/share/intro.html#Background
> 14 http://www.faqs.org/rfcs/rfc793.html
> 15 http://www.stearns.org/p0f/p0fr.fp
> 16 http://www.mynetwatchman.com/ListIncidentsbyIP.asp
> 17 http://www.inet-sec.org/docs/DoS/fragma.html
> 18 http://www.cisco.com/warp/public/770/nifrag.shtml
>
>
> _______________________________________________
> Intrusions mailing list
> [email protected]
> http://www.dshield.org/mailman/listinfo/intrusions


_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions