LOGS: GIAC GCIA Version 3.4 Practical Detect Jose Faial

Dear friends,

This is the network detect required for my GCIA certification attempt. I
would like to ask you, respectfully, to put your comments and questions on
it. Please, be aware that English grammar and spelling is under review, so
be ready to find some errors.

Thank you sincerely,

   José Faial.



Part II - Network Detects

Network Detect 1 - DOS BGP spoofed connection reset attempt
[**] [1:2523:2] DOS BGP spoofed connection reset attempt [**]
[Classification: Attempted Denial of Service] [Priority: 2]
11/18-19:08:20.235607 0:4:76:45:61:39 -> 0:50:56:40:0:6D type:0x800 len:0x3E
10.10.10.195:2844 -> 172.20.11.80:179 TCP TTL:128 TOS:0x0 ID:38868 IpLen:20
DgmLen:48 DF
******S* Seq: 0x3254E63B  Ack: 0x0  Win: 0xFAF0  TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
[Xref => http://www.uniras.gov.uk/vuls/2004/236929/index.htm][Xref =>
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230]
--
[**] [1:2523:2] DOS BGP spoofed connection reset attempt [**]
[Classification: Attempted Denial of Service] [Priority: 2]
11/18-19:08:20.311264 0:50:56:40:0:6D -> 0:4:76:45:61:39 type:0x800 len:0x3C
172.20.11.80:179 -> 10.10.10.195:2844 TCP TTL:62 TOS:0x0 ID:0 IpLen:20
DgmLen:40 DF
***A*R** Seq: 0x0  Ack: 0x3254E63C  Win: 0x0  TcpLen: 20
[Xref => http://www.uniras.gov.uk/vuls/2004/236929/index.htm][Xref =>
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230]

Explanation of the Snort Alert Log:

11/18-19:08:20.311264 -    date and time of the alert
0:50:56:40:0:6D -                source MAC Address
0:4:76:45:61:39 -                 destination MAC Address
type:0x800 -                        encapsulating protocol
len:0x3C -                            length of frame 0x03c = 60
172.20.11.80  -                   source address
179  -                                  source port
10.10.10.195 -                    destination address
2844 -                                 destination port
TCP -                                  protocol type
TTL:62 -                              packet TTL
ID:0 -                                   IP ID
IpLen:20 -                            length of IP packet (bytes)
DgmLen:40 -                        length of entire datagram inc head and
payload (bytes)
DF -                                    Do Not Fragment Flag
***A*R** -                        TCP Flags set (ACK and RST)
Seq: 0x0 -                            TCP Sequence Number
Ack: 0x0 -                           TCP Acknowledgment number
Win: 0x0 -                           TCP Window Size
TcpLen: 20 -                       Length opf TCP packet header (bytes)
[Xref =>]  -                         any cross references for the alert

Source of Trace:
    The trace was taken from raw log files downloaded from Internet Storm
Center's web site at URL http://www.incidents.org/logs/RAW/2000.12.15.tgz .
The tarball contains 14 consecutive days of data generated by a snort
instance logging in binary mode. Information contained in that site explains
that true network addresses were obfuscated and checksums modified to avoid
computing the original IP addresses from it, but I failed to find one single
packet with bad checksums, indicating that IPs were obfuscated using a
technique other than  doing an simple "find-and-replace" or even no
obfuscation have been done at all. All of 14 files were merged on one single
file for processing with snort as follow:

[root@white-one logs] mergecap -w allcaps.cap 2003.12.15.*

    Many commands and procedures used in this section were learned and
influenced from posted GCIA practicals works of Peter Storm, Les Gordon and
Ian Martin (thanks guys for the great work). Those documents can be found at
GIAC Web Site's posted practical section at http://www.giac.org .

I'll try to figure out the network topology doing an analysis in the MACs
found.  A deep analysis in the MAC address found in this file shows a dozens
of different network cards. This indicates that the sensor is located
between the internal network and the gateway or the sensor may be placed in
a SPAN port of the LAN switch that is mirroring the trunking port or a VLAN,
but I'll present other possibility based on my findings later. I'll try to
figure out which MACs belongs to local computers and which ones to gateways
counting how many IP addresses are associated to each MAC. First, what are
the source MAC addresses present in the captured file and how many packets
are associated to each one:

tcpdump -ner 2003.12.15.7 | awk '{print $2}'| sort | uniq -c | sort
      1 0:9:6b:2:e9:3d
      5 0:c:29:14:1e:63
     11 0:0:e2:92:ee:f
     13 0:0:e2:94:b0:2a
     34 0:50:56:40:0:64
     35 0:b:db:17:f4:c9
     80 0:d:bc:17:4:ce
     80 0:d:bc:17:4:cf
     80 0:d:bc:17:4:d0
     80 0:d:bc:17:4:d2
     80 0:d:bc:17:4:d4
     80 0:d:bc:17:4:d5
     80 0:d:bc:17:4:d6
     80 0:d:bc:17:4:d8
    130 0:a:95:d9:95:84
    135 0:2:a5:b6:e2:e3
    146 0:e0:98:a1:7f:da
    151 0:1:3:88:29:92
    183 0:3:ff:df:95:84
    261 0:a0:c9:ba:6d:85
    463 0:8:74:5:b7:f8
   1015 0:3:47:8c:89:c2
   2261 0:c:29:9e:ef:53
   2344 0:d0:59:c6:5e:14
   3880 0:1:2:79:91:ed
  10861 0:4:76:45:61:39
  14230 0:50:56:40:0:6d

What are the destinations MACs?

tcpdump -ner 2003.12.15.7 | awk '{print $3}'| sort | uniq -c | sort
      2 0:b:db:17:f4:c9
      3 1:0:5e:0:0:2
      3 1:0:5e:0:0:5
      3 1:0:5e:0:0:6
      3 1:0:5e:7a:a:8c
      5 0:c:29:14:1e:63
      8 0:0:e2:92:ee:f
     12 0:d:bc:17:4:ce
     12 0:d:bc:17:4:cf
     12 0:d:bc:17:4:d0
     12 0:d:bc:17:4:d2
     12 0:d:bc:17:4:d4
     12 0:d:bc:17:4:d5
     12 0:d:bc:17:4:d6
     12 0:d:bc:17:4:d8
     13 0:0:e2:94:b0:2a
     16 0:1:2:79:91:ed
     29 0:50:56:40:0:64
     32 1:0:c:0:0:0
     48 1:0:c:cc:cc:cc
     49 ff:ff:ff:ff:ff:ff
     76 0:a:95:d9:95:84
     93 0:e0:98:a1:7f:da
     99 0:2:a5:b6:e2:e3
    127 0:3:ff:df:95:84
    132 0:1:3:88:29:92
    200 0:a0:c9:ba:6d:85
    239 0:c:29:9e:ef:53
    346 0:8:74:5:b7:f8
    464 1:80:c2:0:0:0
    646 0:3:47:8c:89:c2
   1454 0:d0:59:c6:5e:14
  10804 0:4:76:45:61:39
  21809 0:50:56:40:0:6d

  Let's find which ones belong to gateways looking how many IP addresses are
associated to each one. The following command was used to find this
information:

 tcpdump -ner 2003.12.15.7 ether src [SOURCE MAC] | awk '{print $6}'| awk -F
\. '{print $1 "." $2 "." $3 "." $4}' | sort -u

The ones that have more than one IP associated with are:

0:3:47:8c:89:c2 -  10.10.10.165, 192.168.117.1, 192.168.213.1
0:50:56:40:0:6d - 10.10.10.1 10.30.30.2 172.20.11.1 172.20.11.2 172.20.11.52
172.20.11.80 172.20.201.1 172.20.201.135 172.20.201.198 172.20.201.2
192.168.17.135 192.168.17.2 192.168.17.66 192.168.17.68

0:b:db:17:f4:c9 - 0.0.0.0 10.10.10.194 169.254.135.50 (think this one is
related to Windows 2000 autoconfiguration and can be ignored)

0:d0:59:c6:5e:14 - 10.10.10.141 238.122.10.140 (multicast, ignore it)

So, it appears that we have two gateways 0:3:47:8c:89:c2 and
0:50:56:40:0:6d, however packets arriving from 0:3:47:8c:89:c2 have
identical TTLs (TTL 128) and sequential IP IDs indicating that 192.168.117.1
and 192.168.213.1 are certainly spoofed:

15:09:13.500109 0:3:47:8c:89:c2 0:50:56:40:0:6d 0800 92: 192.168.117.1.137 >
172.20.201.1.137: [udp sum ok](ttl 128, id 43661, len 78)
15:09:13.500161 0:3:47:8c:89:c2 0:50:56:40:0:6d 0800 92: 192.168.213.1.137 >
172.20.201.1.137: [udp sum ok](ttl 128, id 43662, len 78)
15:09:13.688565 0:3:47:8c:89:c2 0:50:56:40:0:6d 0800 62: 10.10.10.165.1881 >
192.168.22.207.1080: S [tcp sum ok] 723317621:723317621(0) win 16384 <mss
1460,nop,nop,sackOK> (DF) (ttl 128, id 43663, len 48)
<snip>
15:09:15.000774 0:3:47:8c:89:c2 0:50:56:40:0:6d 0800 92: 192.168.117.1.137 >
172.20.201.1.137: [udp sum ok](ttl 128, id 43701, len 78)
15:09:15.000778 0:3:47:8c:89:c2 0:50:56:40:0:6d 0800 92: 192.168.213.1.137 >
172.20.201.1.137: [udp sum ok](ttl 128, id 43702, len 78)
15:09:15.018746 0:3:47:8c:89:c2 0:50:56:40:0:6d 0800 62: 10.10.10.165.1897 >
192.168.17.66.80: S [tcp sum ok] 725076644:725076644(0) win 16384 <mss
1460,nop,nop,sackOK> (DF) (ttl 128, id 43703, len 48)

Explanation of key TCPDUMP´s fields:

[15:09:15.018746]1 [0:3:47:8c:89:c2]2  [0:50:56:40:0:6d]3  0800 62:
[10.10.10.165.1897]4  [>]5  [192.168.17.66.80]6 : [S]7  [tcp sum ok]
[725076644:725076644]8  [(0)]9  [win 16384]10  [<mss 1460,nop,nop,sackOK>]11
[(DF)]12  [(ttl 128, id 43703, len 48)]13

1          date
2          source MAC address
3          destination Mac address
4          source IP address. source port
5          > direction of packet
6          destination IP address. destination port
7          TCP Flags
8          SEQ Number/Offset
9          Number of bytes in IP payload (ie TCP data)
10        TCP Window size
11        TCP Options
12        Fragment/Don´t Fragment Flag
13        TTL, IP ID and Length

Which hosts are leaving the network trought 0:50:56:40:0:6d?
tcpdump -ner 2003.12.15.7 ether dst 0:50:56:40:0:6d | awk '{print $6}' |
awk -F \. '{print $1 "." $2 "." $3 "." $4}' | sort -u
10.10.10.112 / 10.10.10.141 / 10.10.10.147 / 10.10.10.165 / 10.10.10.174 /
10.10.10.186 / 10.10.10.195 / 10.10.10.196 / 10.10.10.222 / 10.10.10.224 /
10.10.10.226 / 10.10.10.228 / 10.10.10.232 / 10.10.10.234

Where they are going to?
tcpdump -ner 2003.12.15.7 ether dst 0:50:56:40:0:6d | awk '{print $8}'|
awk -F \. '{print $1 "." $2 "." $3 "." $4}' | sort -u
10.10.10.1 / 149.134.52.149 / 172.20.11.1 / 172.20.11.2 / 172.20.11.52 /
172.20.11.80 / 172.20.201.1 / 172.20.201.135 / 172.20.201.198 / 172.20.201.2
/ 172.20.201.3 / 192.168.17.1 / 192.168.17.135 / 192.168.17.66 /
192.168.17.67 / 192.168.17.68 / 192.168.22.207 / 198.123.30.132 / 198.41.0.5

Which hosts are coming from  0:50:56:40:0:6d ?
tcpdump -ner 2003.12.15.7 ether src 0:50:56:40:0:6d | awk '{print $6}'|
awk -F \. '{print $1 "." $2 "." $3 "." $4}' | sort -u
10.10.10.1 / 10.30.30.2 / 172.20.11.1 / 172.20.11.2 / 172.20.11.52 /
172.20.11.80 / 172.20.201.1 / 172.20.201.135 / 172.20.201.198 / 172.20.201.2
/ 192.168.17.135 / 192.168.17.2 / 192.168.17.66 / 192.168.17.68

Where they are going to?
tcpdump -ner 2003.12.15.7 ether src 0:50:56:40:0:6d | awk '{print $8}'|
awk -F \. '{print $1 "." $2 "." $3 "." $4}' | sort -u
10.10.10.1 / 10.10.10.112 / 10.10.10.141 / 10.10.10.147 / 10.10.10.165 /
10.10.10.174 / 10.10.10.186 / 10.10.10.195 / 10.10.10.196 / 10.10.10.222 /
10.10.10.224 / 10.10.10.226 / 10.10.10.228 / 10.10.10.232 / 10.10.10.234

    It's interesting to note that 0:50:56:40:0:6d and 0:50:56:40:00:64 (that
is a DNS and DHCP server) are VMware cards. This information was taken from
Ethereal´s manuf file and confirmed at IEEE database located at following
web site address: http://standards.ieee.org/regauth/oui/oui.txt. This makes
me speculate which kind of gateway and DNS server would be using a VMware
card. My best guess is that 0:50:56:40:0:6d is a honeypot that runs honeyd
and simulates hosts on the 10.30.30.x, 172.20.11.x, 172.20.201.x and
192.168.17.x networks. The honeypot has a IP address in the local subnet,
which is 10.10.10.1, that connects it directly to the guest VMware OS that
runs honeyd.  My second guess is that the same host is hosting another
VMware virtual host on 10.10.10.2 that runs DHCP and DNS services. My
analysis results in a network topology similar to the figure below:



|----Target Honeynet----|
           |
           |
        VMware   10.10.10.X    |
       (Gateway)-------------- |
                               |
                     |---------------------|
                     Attacker (10.10.10.195)



    As a final note, it appears now that data was captured by a sniffer
probe like tcpdump instead (or snort running in packet capture mode only).
The capture file has a lot of packets related to Cisco protocols like CDP
(Cisco Discovery Protocol), VTP and Spanning Tree that points out some
useful information like the switch IP address (192.168.1.2), type of device,
interfaces and some of its features (performs layer 3 routing, transparent
bridging etc).

Detect was generated by:

    The detect was generated by running Snort Version 2.1.2 (Build 25) using
full ruleset base as available on May 05, 2004. The following command line
switches were used:

# snort -c /etc/snort/snort.conf -r allcaps.cap -NUX -k none -de -l
/var/log/snort

-c: tells snort to read the configuration file /etc/snort/snort.conf
-r: tells snort to read data from a captured data file instead of sniffing
it directly from the wire. For instance, the file allcaps.cap has been used
-N: disables logging. Alerts still working
-U: use UTC for timestamps
-X: dump the raw packet data starting at the link layer
-k: checksum mode to be used (all,noip,notcp,noudp,noicmp,none). For
instance, checksums were ignored
-d:  dump the Application Layer
-e:  display the second layer header info
-l: tell snort to logo to directory /var/log/snort

    The resulting output of snort processing was:
====================================================================

Snort processed 475199 packets.
Breakdown by protocol:                Action Stats:

    TCP: 372578     (78.405%)         ALERTS: 29281
    UDP: 66543      (14.003%)         LOGGED: 29281
   ICMP: 9986       (2.101%)          PASSED: 0
    ARP: 1329       (0.280%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 23582      (4.963%)
====================================================================
Wireless Stats:
Breakdown by type:
    Management Packets: 0          (0.000%)
    Control Packets:    0          (0.000%)
    Data Packets:       0          (0.000%)
====================================================================
Fragmentation Stats:
Fragmented IP Packets: 6          (0.001%)
   Rebuilt IP Packets: 0
   Frag elements used: 0
Discarded(incomplete): 0
   Discarded(timeout): 0
====================================================================

TCP Stream Reassembly Stats:
   TCP Packets Used:      0          (0.000%)
   Reconstructed Packets: 0          (0.000%)
   Streams Reconstructed: 0
====================================================================

    The traffic below:

15:08:16.623966 10.10.10.195.2551 > 172.20.11.80.179: S [tcp sum ok]
828765207:828765207(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38115, len 48)
15:08:16.659951 172.20.11.80.179 > 10.10.10.195.2551: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)
15:08:19.518648 10.10.10.195.2834 > 172.20.11.80.179: S [tcp sum ok]
843877911:843877911(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38689, len 48)
15:08:19.525274 172.20.11.80.179 > 10.10.10.195.2834: R [tcp sum ok] 0:0(0)
ack 843877912 win 0 (DF) (ttl 62, id 0, len 40)
15:08:19.787290 10.10.10.195.2844 > 172.20.11.80.179: S [tcp sum ok]
844424763:844424763(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38764, len 48)
15:08:19.813071 172.20.11.80.179 > 10.10.10.195.2844: R [tcp sum ok] 0:0(0)
ack 844424764 win 0 (DF) (ttl 62, id 0, len 40)
15:08:19.934638 10.10.10.195.2834 > 172.20.11.80.179: S [tcp sum ok]
843877911:843877911(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38781, len 48)
15:08:19.945200 172.20.11.80.179 > 10.10.10.195.2834: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)
15:08:20.235607 10.10.10.195.2844 > 172.20.11.80.179: S [tcp sum ok]
844424763:844424763(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38868, len 48)
15:08:20.311264 172.20.11.80.179 > 10.10.10.195.2844: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)
15:08:20.436254 10.10.10.195.2834 > 172.20.11.80.179: S [tcp sum ok]
843877911:843877911(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38917, len 48)
15:08:20.470553 172.20.11.80.179 > 10.10.10.195.2834: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)
15:08:20.737248 10.10.10.195.2844 > 172.20.11.80.179: S [tcp sum ok]
844424763:844424763(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38954, len 48)
15:08:20.788205 172.20.11.80.179 > 10.10.10.195.2844: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)

<snip>...

15:15:09.223696 172.20.11.80.179 > 10.10.10.195.1604: R [tcp sum ok] 0:0(0)
ack 1271144247 win 0 (DF) (ttl 62, id 0, len 40)
15:15:09.356124 10.10.10.195.1593 > 172.20.11.80.179: S [tcp sum ok]
1270559789:1270559789(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128,
id 58770, len 48)
15:15:09.397537 172.20.11.80.179 > 10.10.10.195.1593: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)
15:15:09.657037 10.10.10.195.1604 > 172.20.11.80.179: S [tcp sum ok]
1271144246:1271144246(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128,
id 58801, len 48)
15:15:09.677635 172.20.11.80.179 > 10.10.10.195.1604: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)
15:15:09.857749 10.10.10.195.1593 > 172.20.11.80.179: S [tcp sum ok]
1270559789:1270559789(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128,
id 58821, len 48)
15:15:09.895531 172.20.11.80.179 > 10.10.10.195.1593: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)
15:15:10.158650 10.10.10.195.1604 > 172.20.11.80.179: S [tcp sum ok]
1271144246:1271144246(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128,
id 58856, len 48)
15:15:10.173672 172.20.11.80.179 > 10.10.10.195.1604: R [tcp sum ok] 0:0(0)
ack 1 win 0 (DF) (ttl 62, id 0, len 40)

Has triggered the signature.

 alert tcp $EXTERNAL_NET any <> $HOME_NET 179 (msg:"DOS BGP spoofed
connection reset attempt"; flow:established; flags:RSF*; threshold:type
both,track by_dst,count 10,seconds 10; reference:cve,CAN-2004-0230;
reference:url,www.uniras.gov.uk/vuls/2004/236929/index.htm;
classtype:attempted-dos; sid:2523; rev:2;)

.and generated the reported alerts.

The signature above has the following meaning:

Send an alert if:
- TCP traffic flowing to or from $HOME_NET on port 179
        alert tcp $EXTERNAL_NET any <> $HOME_NET 179
- is part of an established connection
      flow:established
- has one of the RESET, SYN or FIN TCP flags set
     flags:RSF*
- occurs 10 times in a interval of 10 seconds for a same destination IP
    threshold:type both,track by_dst,count 10,seconds 10

Probability Source address was spoofed:

   High. Spoofing a legitimate IP address that makes part of a BGP routing
updating session is the basic element of this attack. Although, later
analysis shows this detect is in fact a false positive, I'll keep this
analysis as is for didactical purposes.

Description of Attack:
     This attack utilizes a design flaw on RFC 793 and RFC 1323 TCP
Extensions for High Performance, that allows an established TCP connection
to be broken down by a third party attacker. The attacker's intention is to
cause a Denial of Service condition on the network or user by sending
especially crafted RST or SYN packets to the victims.
    Gratuitous TCP resets as a way to disable a third party's connections is
not a new thing. In fact, this is well known for long past, but it wasn't
considered a high threat until a recent paper on this subject was published
by Paul A. Watson. Originally, it was believed that a successful denial of
service attack of this kind was not achievable in practice. The reason for
this is that "the receiving TCP implementation checks the sequence number of
the RST or SYN packet, which is a 32 bit number, giving a probability of
1/232 of guessing the sequence number correctly (assuming a random
distribution)" [quoted from
http://www.uniras.gov.uk/vuls/2004/236929/index.htm]. The researcher have
found that probability of guessing the acceptable sequence number is much
higher than 1/232 because the receiving TCP stack will accept any sequence
number in a certain range of expected sequence number (that range in also
called window). Higher the window, higher the probability. In fact, it's
also possible to perform the attack using SYN packets, because the
connection will be dropped if one of sides of a connection receives a
duplicate SYN packet that has the ISN within the range of a previously
established TCP connection window. This vulnerability relies in following
statements of RFC 793:

 "In all states except SYN-SENT, all reset (RST) segments are validated by
checking their SEQ-fields [sequence numbers]. A reset is valid if its
sequence number is in the window. In the SYN-SENT state (a RST received in
response to an initial SYN), the RST is acceptable if the ACK field
acknowledges the SYN".

And

"The principle reason for the three-way handshake is to prevent old
duplicate connection initiations from causing confusion. To deal with this,
a special control message, reset, has been devised. [.] If the TCP is in one
of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its
 user".

   Specifically, when done over TCP port 179 troughs an unprotected network
device that supports and utilize BGP (Border Gateway Protocol), aka border
routers, the attacker may cause a general failure in the routing
infrastructure by suppressing routing updates and flapping. This can result
in medium term network unavailability. BGP is potentially susceptible to
this attack because:
    a) It relies on persistent BGP connection between peers;
    b) Source and destination IP addresses as well port number are very
predictable (peers can be found using a traceroute for example)

    Other application level protocols that are potentially affected have the
following characteristics (extracted from
http://www.uniras.gov.uk/vuls/2004/236929/index.htm ):
       a) Depend on long lived TCP connections
       b) Have known or easy-to-guess IP address end points
       c) Have easy-to-guess source TCP ports

 CVE has created a candidate record for inclusion in the CVE List:
CAN-2004-0230. Extracted from its description:

"When using a large TCP Window Size, makes it easier for remote attackers to
guess sequence numbers and cause a denial of service (connection loss) to
persistent TCP connections by repeatedly injecting a TCP RST packet,
especially in protocols that use long-lived connections, such as BGP".
Attack Mechanism:
      After the publication of Paul Watson´s paper, various tools to exploit
this vulnerability were released. Most of then can be found at PacketStorm
Security web site (http://www.packetstormsecurity.nl) searching for "TCP
Reset" in the exploit section. Some of tools will compile on both Windows
and Linux, there are even Perl versions of the exploit [REF]. To better
understand how this exploit works and then compare what we learned against
the captured traces, let's briefly analyze the traffic generated by one of
available tools, AFX TCP Reset. A test lab was set up for purposing of
testing the tool. It was a simple home made LAN consisting of three
computers, two of them are peers in a lived TCP connection and the last one
the attacker. Unfortunately, I don't have the available resources needed to
run a test against a real BGP session, so I'll use simple "back-to-back"
NetCat session. Lab environment:
Computer A: Server listening on 192.168.1.128 TCP port 53 (let's try to
simulate a large DNS Zone Transfer)
Computer B: Client connecting from 192.168.1.134 source port 1026
Computer C: attacker (and windump probe) running on 192.168.1.1

Tool usage:
C:\tools>reset.exe
AFX TCP Reset
http://www.iamaphex.cjb.net
unremote@xxxxxxxxxxx

Usage: reset <src ip> <src port> <dest ip> <dest port> <window size> <send
delay> [begin seq num]

First opened NetCat shell on server:

[root@red-one root]#nc -l -p 53 -vv -n
Listening on [any] 53 ...

Connecting from client and watching the traffic:

[root@red-two root]#nc -p 1026 -vv -n 192.168.1.128 53
(UNKNOWN) [192.168.1.128] 53 (?) open

Windump out put of 3-way-handshake:

C:\tools>windump -r c:\temp\reset.dump -vv tcp[13]!=0x14 (reset.dump stores
the packets captured during this session)

02:00:03.197565 IP (tos 0x0, ttl 64, id 23154, len 60) 192.168.1.134.1026 >
192.168.1.128.53: S [tcp sum ok] 2144602788:2144602788(0) win 5840 <mss
1460,sackOK,timestamp 282838 0,nop,wscale 0> (DF)

02:00:03.198499 IP (tos 0x0, ttl 64, id 0, len 60) 192.168.1.128.53 >
192.168.1.134.1026: S [tcp sum ok] 1010057679:1010057679(0) ack 2144602789
win 5792 <mss 1460,sackOK,timestamp 4303997 282838,nop,wscale 0> (DF)

02:00:03.198664 IP (tos 0x0, ttl 64, id 23155, len 52) 192.168.1.134.1026 >
192.168.1.128.53: . [tcp sum ok] 1:1(0) ack 1 win 5840 <nop,nop,timestamp
282838 4303997> (DF)


Launching the attack:

C:\tools>reset 192.168.1.134 1026 192.168.1.128 53 5792 0 (have managed to
not chose a initial sequence number)

    After a few seconds, the server side of the connection ends abruptly
terminated, although nothing happened to the client side (this was expected
as no connection state mechanism was being used by this dumb session). So,
if no other packet was exchanged between peers during the attack period, a
reset would occur in some place between 2144602790 and 2144608582 (because
the window size of 5792). Let's try to find any packets that sit in this
range. I opened the reset.dump file using Ethereal and applied the filter
"tcp.seq >= 2144602790 and tcp.seq <= 2144608582" to the captured data, then
exported the results to another file (reset-packet.dump) for processing with
windump:

C:\tools>windump -r c:\temp\reset-packet.dump -vv -n
02:02:34.887431 IP (tos 0x0, ttl 128, id 12160, len 40) 192.168.1.134.1026 >
192.168.1.128.53: R [tcp sum ok] 2144604669:2144604669(0) ack 2144610461 win
40982

  It shows only one packet found. That's the packet that shutdown my
connection. Note that it was taken about 2 minutes and a half to close the
connection with SEQ numbers starting at 249746077 (too far from real ISN -
see the first RST packet captured below) and using a relatively small
window. For a matter of curiosity, about 300K packets were generated before
shutting down the session. Below is the first RST packet sent by the
attacker:

C:\tools>windump -r c:\temp\reset.dump -vv -c 1 tcp[13]=0x14
02:00:27.033099 IP (tos 0x0, ttl 128, id 12687, len 40) 192.168.1.134.1026 >
192.168.1.128.53: R [tcp sum ok] 249746077:249746077(0) ack 249751869 win
40982

  So, what can we learn from this simple lab that applies to the analysis of
the snort alert? Basically, that the attack is a real threat and it's pretty
simple to accomplish. It's no fiction anymore. The detected traces have
characteristics very similar to what was described by the attack: lots of
SYN packets, large window and destination port and address fixed. Even the
fact of having a varying source port is OK, because we can imagine a
scenario were the attacker would have to guess the source port as well. That
would take more time, but is feasible. A single characteristic of the trace
however, shows that it's in fact a common port scanning and a not reset
attack: connection retries. The attacker sends three packets with same
source port and sequential number. Repeating a sequence number using the
same source/destination port number is not expected for this kind of attack.
The same behavior is observed for source port 2844. See:

15:08:19.518648 10.10.10.195.2834 > 172.20.11.80.179: S [tcp sum ok]
843877911:843877911(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38689, len 48)

15:08:19.934638 10.10.10.195.2834 > 172.20.11.80.179: S [tcp sum ok]
843877911:843877911(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38781, len 48)

15:08:20.436254 10.10.10.195.2834 > 172.20.11.80.179: S [tcp sum ok]
843877911:843877911(0) win 64240 <mss 1460,nop,nop,sackOK> (DF) (ttl 128, id
38917, len 48)

   There are off course, other facts to consider:

            a) Traces were captured on November 2003, few months before the
paper and tools become available. It's not impossible, but unlikely that
attacker had the knowledge and proper tools in hand to launch a RST attack
at that time;
            b) There are no legitimate connection between the victim and any
other host using TCP 179 that would be a target for a spoofed RST attack at
that time. The packets weren't even spoofed;
            c) The target is not a router and it's wasn't running BGP;
            d) And finally, there are lots of other signals in the captured
file that shows this trace is part of vulnerability scanning launched
against the target, probably using Nessus (but I am not going to prove that,
my intention is to only prove the false positive).
Correlations:

    My searches on Google and discussion lists haven't returned one single
person relating similar detect. This fact is not a surprise, as the
signature is pretty new as well the attack tools and technique.

All related RFCs can be found at IETF web site: http://www.ietf.org

The original Paul A. Watson's research paper can be found here:

http://www.packetstormsecurity.nl/papers/protocols/SlippingInTheWindow_v1.0.
doc

NISCC Advisory is here:
http://www.uniras.gov.uk/vuls/2004/236929/index.htm

The reset tool is available at PacketStorm at following URL:
http://www.packetstormsecurity.nl/0404-exploits/reset.zip

CVE record for vulnerability:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230
Evidence of active targeting:
   The trace is part of a vulnerability assessment launched against the
target and other machines in subnets 172.20.11.0/24, 172.11.11.0/24 and
172.10.11.0/24 by the attacker. The capture file shows that the attacker is
actively targeting those machines. As a result of some sorting of port scan
plugin, Snort has generated the alerts that were in fact, false positives.

Severity:
Severity is being evaluated using the following criteria:

Severity = (Criticality + Lethality) - (System Countermeasures + Network
Countermeasures)

Each item in the equation is given a number between 1 and 5, 1 being the
lowest and 5 being the highest.

Criticality: if I guessed right, the target is a honeypot or a test lab
computer with no critical function in the network, so I'll give 1 (just as
an exercise, if this was in fact a border router I would give it 5)
Lethality: the attack in fact is a portscan phase of which appears to be a
vulnerability assessment, there is no way to known if it was a legitimate
scan done by security admin or by someone else, so I'll point the worst
scenario that's 2 (in fact the scan had no observed collateral effect on the
host).
System Countermeasures: no signal of any packet filtering in place at host
level and no signal of any TCP/IP stack hardening to avoid OS fingerprinting
as well, however no service was running at that port. I'll point 1 because
no system countermeasure could be observed.
Network Countermeasures: no network level packet filtering device appears to
be in place, however there is an IDS probe watching. I'll point 3.

Severity = (1 + 2) - (1 + 3) = -1
Security Recommendations:
Thais section is hard to evaluate, because I could not identify the real
role (if any) of this computer in the network. All findings point to a
honeypot or test lab computer, so how to secure that kind of equipment if
they are there to be attacked? Supposing this in fact a network server, many
security controls are recommended:

-          Protect it with a packet filtering device at network perimeter
-          Disable unneeded services
-          Put access control list to allow only legitimate users to connect
if possible (ex. TCPWrapers)
-          Install latest patches and security updates from vendors
-          Follow recommendations for hardening the Operating System as
available at GIAC posted practicals web site (http://www.giac.org), SANS
Reading Room (http://rr.sans.org) and SANS S.C.O.R.E
(http://www.sans.org/score). That should include hardening of TCP/IP stack
and services banners to avoid fingerprinting and increase security against
Denial of Services attacks like SYN Floods (or TCP Resets J).
Multiple choice question:

During a TCP session, what happens if one side receives a packet originated
from the other side of connection containing an initial sequence number that
falls within the range of a previously established session with that peer?

a)     It accepts  the ISN and proceeds with the three-way-hanshake of a
newer session
b)     It accepts the ISN, but it thinks the packet belongs to that
previously session and try to use it in that session
c)      It silently drops the packet
d)     It aborts the connection and informs user

Answer: d. RFC 793 states that.


_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions