[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect Rusma Mulyadi

Wed Sep 1 01:36:40 GMT 2004

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 at 30904+) 
(ttl 237, len 40, bad cksum b1ae!)
0x0000 4500 0028 0000 6f17 ed06 b1ae 40f4 6ea4 E..(..o..... at .n.
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 at 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 at 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 at 63128+) (ttl 
237, len 40, bad cksum bd88!)
0x0000 4500 0028 0000 3ed3 ed06 bd88 4069 1a76 E..(..>..... at i.v
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 at 63128+) (ttl 
237, len 40, bad cksum bd5a!)
0x0000 4500 0028 0000 3ed3 ed06 bd5a 4069 1aa4 E..(..>....Z at 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 at 65112+) (ttl 
237, len 40, bad cksum 2cf6!)
0x0000 4500 0028 0000 3fcb ed06 2cf6 401a aa5f E..(..?...,. at .._
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 at 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 E..... at .n.l..?.{
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