[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect Alva Lease 'Skip' Duckwall IV (fwd)
skip1 at duckwall.net
skip1 at duckwall.net
Wed Jun 16 02:05:04 GMT 2004
This is my fifth attempt to submit this message to the list.....
I think I was able to help the sans guys get this working again...
Below is my second submitted detect to this list (although it's my third
and final detect, I just didn't submit number 2 to the list). Feel free
to give me any comments, suggestions or recipes..
As a note, this is taken from a text translation of a word document.
Apparently double quotes and single quotes didn't make it through the
translation. (and no I'm not going to use the m4 style `' around strings
;-) ) I've tried to fix the important ones, but more than likely missed
some. The word document looks much better ;-)
Alva Lease 'Skip' Duckwall IV
CISSP, RHCE, SCSA
skip1 at duckwall dot net
<--------------- clip ------------------>
1. Source of trace
This trace was provided by SANS in the following location:
http://www.incidents.org/logs/raw/index.php. The file I analyzed and
found this information was a tarball called 2003.12.15.tgz. Inside this
tarball were 15 trace files named 2003.12.15.1 through 2003.12.15.15. The
packet captures dont seem to have been run through snort since theres
normal network noise like the Cisco Discovery protocol, the 802.1d
spanning tree protocol and other local LAN noise that snort would more
than likely not trigger on and thus have filtered out.
There appears to be a Cisco switch that based on the CDP traffic has the
following ports/MAC addresses in service:
192.168.1.2 00:0d:bc:17:04:ce (fastethernet0/14)
192.168.1.2 00:0d:bc:17:04:cf (fastethernet0/15)
192.168.1.2 00:0d:bc:17:04:d0 (fastethernet0/16)
192.168.1.2 00:0d:bc:17:04:d2 (fastethernet0/18)
192.168.1.2 00:0d:bc:17:04:d4 (fastethernet0/20)
192.168.1.2 00:0d:bc:17:04:d5 (fastethernet0/21)
192.168.1.2 00:0d:bc:17:04:d6 (fastethernet0/22)
192.168.1.2 00:0d:bc:17:04:d8 (fastethernet0/24)
I was unable to determine what was plugged into each of the ports based on
the information contained in the detects.
Based on the presence of the LAN noise cruft, I believe the sensor is on a
span-port on the switch.
The target networks appear to be part of a honeynet running on vmware.
>From the TTL information and the link layer information contained in the
packet trace, this is a diagram of the network as I see it.
********
*sensor*
********
|
|
|
| ************************
|------*10.10.10.1 (vmware) *
******************************* | *MAC 00:50:56:40:00:6d *
*Attacker: 10.10.10.165 *-----| ************************
*MAC 00:03:47:8c:89:c2(Intel) * | | |
******************************* | | |
| | |
************************ | | |
*Nameserver: 10.10.10.2*------------| | |
*MAC 00:50:56:40:00:64 * | |
************************ | |
| |
| |
| |
| |
**************************** | |
*172.20.201.1/ 10.10.10.165*---------------| **************
**************************** *192.168.17.1*
| **************
| |
*************** | |
*172.20.201.2 *-------| ***************
*************** | *192.168.17.2 *----|
| *************** |
***************** | |
*172.20.201.135 *-----| ***************** |
***************** | *192.168.17.66 *--|
| ***************** |
***************** | |
*172.20.201.198 *-----| ***************** |
***************** | *192.168.17.68 *--|
| *****************
***************** |
*172.20.201.198 *-----|
*****************
The hosts 10.10.10.1 and 10.10.10.2 are adjacent to the attacker since
their TTL values indicate no hop count decrement (64). Based on their
TTL, they are running linux. (see default TTL value by OS stack in
correlations)
The hosts 172.20.201.1 and 10.30.30.2 are 1 hop away from the attacker
since their TTL is 63 (1 less than 64). Based on the TTL, I believe this
box is a linux box. I am guessing that 172.20.201.1 and 10.30.30.2 are
the same machine since all ICMP network unavailable messages come from
10.30.30.2. If 172.20.201.1 was behind 10.30.30.2 on the network, the TTL
would not be 63.
The hosts 172.20.201.2, 172.20.201.135, 172.20.201.198 and 172.20.11.80
are all 2 hops away since their TTL values are either 62 or 253. Based on
their TTL values their OS is linux. The host 172.20.201.2 seems to have
some sort of packet filtering in place since there were ICMP TCP port
unavailable messages. We know this since TCP by default sends a RST+ACK
and doesnt use ICMP. The TTL value of 253 is a little odd since it only
happens on packets that reject a connection or datagram, such as ICMP port
unreachable messages or the RST+ACK packets for a non-listening TCP port.
This could possibly indicate a firewall, but I dont think this is the case
since ICMP reply messages have their TTL set to 255 so when they hit the
sensor theyre set at 253. I dont believe its normal firewall behavior to
respond to ping requests for the hosts behind the firewall. Im not sure
if this is a stack oddity or something else.
Based upon this telnet trace, we can see that the guess of linux being the
OS is accurate for 172.20.201.135.
15:05:45.992004 172.20.201.135.23 > 10.10.10.165.3236: P 31:103(72) ack 28
win 32120 [telnet WILL ECHO] (DF) (ttl 62, id 38509, len 112)
0x0000 4500 0070 966d 4000 3e06 1bd0 ac14 c987 E..p.m at .>.......
0x0010 0a0a 0aa5 0017 0ca4 2ba2 a9c0 1582 acfa ........+.......
0x0020 5018 7d78 861a 0000 fffb 010d 0a52 6564 P.}x.........Red
0x0030 2048 6174 204c 696e 7578 2072 656c 6561 .Hat.Linux.relea
0x0040 7365 2036 2e32 2028 5a6f 6f74 290d 0a4b se.6.2.(Zoot)..K
0x0050 6572
Ditto for 172.20.201.198
15:05:47.243256 172.20.201.198.23 > 10.10.10.165.3400: P 31:103(72) ack 31
win 32120 [telnet WILL ECHO] (DF) [tos 0x10] (ttl 62, id 35456, len 112)
0x0000 4510 0070 8a80 4000 3e06 276e ac14 c9c6 E..p.. at .>.'n....
0x0010 0a0a 0aa5 0017 0d48 3a94 3964 1603 21e1 .......H:.9d..!.
0x0020 5018 7d78 880a 0000 fffb 010d 0a52 6564 P.}x.........Red
0x0030 2048 6174 204c 696e 7578 2072 656c 6561 .Hat.Linux.relea
0x0040 7365 2037 2e30 2028 4775 696e 6e65 7373 se.7.0.(Guinness
0x0050 290d
I was unable to verify the existence of 192.168.17.1. Packets were sent
to this machine, however there werent any response packets from this host
anywhere in the trace. The only reason I believe it to be in its location
in the diagram is that I cannot explain why 192.168.17.2 had a TTL of 62,
meaning that it was 2 hops away from the attacker. Based on its TTL, I am
guessing the OS is linux.
Finally, hosts 192.168.17.66 and 192.168.17.68 are behind 192.168.17.2.
The TTL for 192.168.17.66 was 61, indicating it is 3 hops away from the
attacker and probably linux. The TTL for 192.168.17.68 was 125, also
indicating that it is 3 hops away from the attacker and is probably
running windows of some variety.
2. Detect was generated by:
First thing I did was merge the files into one large capture file using
mergecap from the ethereal distribuition. I ran the following command to
merge the files:
mergecap w 2003.12.15.all 2003.12.15.? 2003.12.15.1?
Then I used tcpdump to eyeball the traffic to see if anything jumped out
at me using the following command:
tcpdump r 2003.12.15.all s0 X nn e | less
It seemed there was a large amount of traffic that was being generated by
10.10.10.165, so I filtered out traffic to this host by running the
following command:
tcpdump r 2003.12.15.all s0 w 10.10.10.165 src or dst host 10.10.10.165
Doing an ls of the files shows that the traffic generated from this host
accounts for about 25% of all traffic from this series of detects, as seen
below:
-rw-r--r-- 1 root root 9871659 Jun 6 12:12 10.10.10.165
-rw-r--r-- 1 root root 39060021 Jun 6 12:58 2003.12.15.all
All the traffic occurred between 11/18/2003 18:57 and 19:33 or over the
span of 36 minutes.
To figure out how many packets the host sent, I ran the following command:
tcpdump -r 10.10.10.165 -s0 nn src host 10.10.10.165| wc l
The total number of packets was 100600. The following table provides a
breakdown by protocol:
ICMP 5131
TCP 31681
UDP 63735
ARP 53
TOTAL 100600
If nothing else, this 10.10.10.165 sure is noisy and a good place to
start. A less masochistic individual might try to filter it down further
at this point, but lets see what happens.
3. Probability source address was spoofed:
Since it appears that the traffic was generated from a vulnerability scan
against the various hosts on the honeynet (see later sections), Id say the
chance of spoofing rates somewhere between Nil and Null.
4. Description of the attack
This appears to be an all out attack on the network. With some further
analysis we might be able to determine the tool used to attack the
network.
I started looking at the ICMP traffic since it generated the fewest hits
(next to ARP). The very first ICMP packet in the detect had a readable
string in it.
14:59:07.936802 10.10.10.165 > 172.20.201.51: icmp: echo request (ttl 128,
id 2928, len 44)
0x0000 4500 002c 0b70 0000 8001 a56a 0a0a 0aa5 E..,.p.....j....
0x0010 ac14 c933 0800 c7c3 87db 2300 ac14 c933 ...3......#....3
0x0020 afdb 2300 4953 5350 4e47 5251 0000 ..#.ISSPNGRQ..
A google search for ISSPNGRQ turned up a snort rule named ISS PINGER which
looks for this string in the body of ICMP packets. ISSPNGRQ appears to be
short for ISS PiNG ReQuest. Perhaps this is a vulnerability scan by ISS
Scanner, a commercial grade vulnerability scanner?
All the ICMP packets from the host 10.10.10.165 had this string in it.
Perhaps this is a ruse from some other tool?
Looking at the TCP traffic next, I dumped all the TCP packets to a text
file and searched for ISS.
15:04:01.370769 10.10.10.165.1112 > 172.20.201.135.25: P [tcp sum ok]
1:22(21) ack 97 win 17424 (DF) (ttl 128, id 8052, len 61)
0x0000 4500 003d 1f74 4000 8006 50fc 0a0a 0aa5 E..=.t at ...P.....
0x0010 ac14 c987 0458 0019 f6a4 5627 256a 730c .....X....V'%js.
0x0020 5018 4410 923d 0000 5652 4659 203c 3137 P.D..=..VRFY.<17
0x0030 3438 3737 3033 4049 5353 3e0d 0a 487703 at ISS>..
Here is an example of an attempt to enumerate valid usernames over SMTP
using the VRFY command. The email address in question is "17487703 at ISS".
This test is more than likely just testing to see if VRFY is available on
this server. VFRY can be used to enumerate local accounts.
15:05:33.722886 10.10.10.165.2012 > 172.20.201.135.21: P [tcp sum ok]
74:97(23) ack 288 win 17233 (DF) (ttl 128, id 25466, len 63)
0x0000 4500 003f 637a 4000 8006 0cf4 0a0a 0aa5 E..?cz at .........
0x0010 ac14 c987 07dc 0015 11c8 1f33 2ab4 09a8 ...........3*...
0x0020 5018 4351 3497 0000 5041 5353 202d 6973 P.CQ4...PASS.-is
0x0030 7340 6973 732e 6973 732e 6973 730d 0a s at iss.iss.iss..
Here we see a FTP login where the password used is "-iss at iss.iss.iss".
The leading dash character is used by some ftp servers to disable FTP
continuation messages that can confuse older ftp clients.
I'm beginning to think at this point: "If it looks like a duck..."
15:05:33.813530 10.10.10.165.2012 > 172.20.201.135.21: P [tcp sum ok]
102:116(14) ack 367 win 17154 (DF) (ttl 128, id 25468, len 54)
0x0000 4500 0036 637c 4000 8006 0cfb 0a0a 0aa5 ..6c|@.........
0x0010 ac14 c987 07dc 0015 11c8 1f4f 2ab4 09f7 ..........O*...
0x0020 5018 4302 11cd 0000 4d4b 4420 6973 732e .C.....MKD.iss.
0x0030 7465 7374 0d0a test..
>From the same FTP session, an attempt to make a directory called
"iss.test".
"Walking like a duck"
>From a different FTP session:
15:20:12.348599 10.10.10.165.3933 > 172.20.201.135.21: P [tcp sum ok]
16:36(20) ack 174 win 17347 (DF) (ttl 128, id 28839, len 60)
0x0000 4500 003c 70a7 4000 8006 ffc9 0a0a 0aa5 E..<p. at .........
0x0010 ac14 c987 0f5d 0015 3d0b 5571 6152 9390 .....]..=.UqaR..
0x0020 5018 43c3 89a7 0000 5041 5353 2078 666f P.C.....PASS.xfo
0x0030 7263 6540 6973 732e 6e65 740a rce at iss.net.
A password of "xforce at iss.net" for an anonymous ftp login. X-Force is the
name of the threat analysis service that ISS offers.
"Starting to smell like a duck"
Looking at some of the UDP traffic some stuff jumps out:
15:22:49.809950 10.10.10.165.4216 > 172.20.201.2.476: [udp sum ok] udp 21
(ttl 128, id 41392, len 49)
0x0000 4500 0031 a1b0 0000 8011 0f46 0a0a 0aa5 E..1.......F....
0x0010 ac14 c902 1078 01dc 001d 4d08 5544 5020 .....x....M.UDP.
0x0020 5363 616e 2062 7920 4953 5320 2834 3531 Scan.by.ISS.(451
0x0030 29 )
Hrm. The string UDP Scan by ISS and (451) appear in the body of this UDP
packet. The number in parentheses actually increments, so I believe this
to be a count of packets sent thus far to a particular host.
"Is this Duck a Mallard or a Mandarin?"
At this point I vaguely remembered something about ISS scanner sending out
its version information in the body of some packets. I searched through
all the traffic again and found this gem:
15:04:02.332386 10.10.10.165 > 172.20.201.1: icmp: echo request (ttl 128,
id 8272, len 116)
0x0000 4500 0074 2050 0000 8001 9074 0a0a 0aa5 E..t.P.....t....
0x0010 ac14 c901 0800 ca1f babe 0000 ac14 c901 ................
0x0020 4953 5350 4e47 5251 3b20 4953 5320 5363 ISSPNGRQ;.ISS.Sc
0x0030 616e 6e65 7220 7636 2e32 312e 3230 3031 anner.v6.21.2001
0x0040 2e33 3230 2052 656c 6561 7365 206b 6579 .320.Release.key
0x0050 2320 #.
Finally, the duck screams out: I'm a duck you freak!
5. Attack mechanism
Im not going to attempt to detail each attack in this ISS vulnerability
scan, as that would chew heavily into the page limit for the practical
(and Im running long as it is). Instead Im going to provide some
highlights of a couple attacks.
Here is an attempt to gather information from SMTP:
15:04:01.292095 10.10.10.165.1112 > 172.20.201.135.25: S [tcp sum ok]
4137965094:4137965094(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl
128, id 8043, len 48)
15:04:01.296538 172.20.201.135.25 > 10.10.10.165.1112: S [tcp sum ok]
627733163:627733163(0) ack 4137965095 win 32120 <mss 1460,nop,nop,sackOK>
(DF) (ttl 62, id 34973, len 48)
15:04:01.296672 10.10.10.165.1112 > 172.20.201.135.25: . [tcp sum ok] ack
1 win 17520 (DF) (ttl 128, id 8045, len 40)
15:04:01.368067 172.20.201.135.25 > 10.10.10.165.1112: P 1:97(96) ack 1
win 32120 (DF) (ttl 62, id 34981, len 136)
0x0000 4500 0088 88a5 4000 3e06 2980 ac14 c987 E..... at .>.).....
0x0010 0a0a 0aa5 0019 0458 256a 72ac f6a4 5627 .......X%jr...V'
0x0020 5018 7d78 e59a 0000 3232 3020 3137 322d P.}x....220.172-
0x0030 3230 2d32 3031 2d31 3335 2e4d 5359 2d50 20-201-135.MSY-P
0x0040 4f50 2e49 5350 2e4e 4554 2045 534d 5450 OP.ISP.NET.ESMTP
0x0050 2053 .S
15:04:01.370769 10.10.10.165.1112 > 172.20.201.135.25: P [tcp sum ok]
1:22(21) ack 97 win 17424 (DF) (ttl 128, id 8052, len 61)
0x0000 4500 003d 1f74 4000 8006 50fc 0a0a 0aa5 E..=.t at ...P.....
0x0010 ac14 c987 0458 0019 f6a4 5627 256a 730c .....X....V'%js.
0x0020 5018 4410 923d 0000 5652 4659 203c 3137 P.D..=..VRFY.<17
0x0030 3438 3737 3033 4049 5353 3e0d 0a 487703 at ISS>..
Here the ISS Scanner attempts to verify the address 17487703 at iss.
15:04:01.380742 172.20.201.135.25 > 10.10.10.165.1112: . [tcp sum ok] ack
22 win 32120 (DF) (ttl 62, id 34983, len 40)
15:04:01.391993 172.20.201.135.25 > 10.10.10.165.1112: P [tcp sum ok]
97:117(20) ack 22 win 32120 (DF) (ttl 62, id 34985, len 60)
0x0000 4500 003c 88a9 4000 3e06 29c8 ac14 c987 E..<.. at .>.).....
0x0010 0a0a 0aa5 0019 0458 256a 730c f6a4 563c .......X%js...V<
0x0020 5018 7d78 9a2e 0000 3235 3220 3c31 3734 P.}x....252.<174
0x0030 3837 3730 3340 4953 533e 0d0a 87703 at ISS>..
According to RFC 2821 section 3.5.3: "There may be circumstances where an
address appears to be valid but cannot reasonably be verified in real
time, particularly when a server is acting as a mail exchanger for another
server or domain. "Apparent validity" in this case would normally involve
at least syntax checking and might involve verification that any domains
specified were ones to which the host expected to be able to relay mail.
In these situations, reply code 252 SHOULD be returned."
Here the mail server responds with 252 <17487703 at iss> meaning that the
mail server doesnt know if the address is valid but the mail server will
accept mail to that address and attempt to relay it.
15:04:01.392596 10.10.10.165.1112 > 172.20.201.135.25: P [tcp sum ok]
22:28(6) ack 117 win 17404 (DF) (ttl 128, id 8053, len 46)
0x0000 4500 002e 1f75 4000 8006 510a 0a0a 0aa5 E....u at ...Q.....
0x0010 ac14 c987 0458 0019 f6a4 563c 256a 7320 .....X....V<%js.
0x0020 5018 43fc 4fef 0000 5155 4954 0d0a P.C.O...QUIT..
15:04:01.401983 172.20.201.135.25 > 10.10.10.165.1112: P 117:172(55) ack
28 win 32120 (DF) (ttl 62, id 34986, len 95)
0x0000 4500 005f 88aa 4000 3e06 29a4 ac14 c987 E.._.. at .>.).....
0x0010 0a0a 0aa5 0019 0458 256a 7320 f6a4 5642 .......X%js...VB
0x0020 5018 7d78 61f0 0000 3232 3120 3137 322d P.}xa...221.172-
0x0030 3230 2d32 3031 2d31 3335 2e4d 5359 2d50 20-201-135.MSY-P
0x0040 4f50 2e49 5350 2e4e 4554 2063 6c6f 7369 OP.ISP.NET.closi
0x0050 6e67 ng
15:04:01.402103 172.20.201.135.25 > 10.10.10.165.1112: F [tcp sum ok]
172:172(0) ack 28 win 32120 (DF) (ttl 62, id 34987, len 40)
15:04:01.402244 10.10.10.165.1112 > 172.20.201.135.25: . [tcp sum ok]
15:04:01.403199 10.10.10.165.1112 > 172.20.201.135.25: F [tcp sum ok]
15:04:01.412328 172.20.201.135.25 > 10.10.10.165.1112: . [tcp sum ok] ack
29 win 32120 (DF) (ttl 62, id 34988, len 40)
The ISS Scanner sends the quit command and the mail server shuts down
gracefully.
Here is an attack on ftp:
15:05:44.054826 10.10.10.165.3069 > 172.20.201.135.21: S [tcp sum ok]
352006949:352006949(0) win 16384 <mss 1460,nop,nop,sackOK> (DF) (ttl 128,
id 26557, len 48)
15:05:44.062767 172.20.201.135.21 > 10.10.10.165.3069: S [tcp sum ok]
727593863:727593863(0) ack 352006950 win 32120 <mss 1460,nop,nop,sackOK>
(DF) (ttl 62, id 38454, len 48)
15:05:44.062908 10.10.10.165.3069 > 172.20.201.135.21: . [tcp sum ok] ack
1 win 17520 (DF) (ttl 128, id 26558, len 40)
15:05:44.146816 172.20.201.135.21 > 10.10.10.165.3069: P 1:106(105) ack 1
win 32120 (DF) [tos 0x10] (ttl 62, id 38461, len 145)
0x0000 4510 0091 963d 4000 3e06 1bcf ac14 c987 E....=@.>.......
0x0010 0a0a 0aa5 0015 0bfd 2b5e 3388 14fb 3326 ........+^3...3&
0x0020 5018 7d78 4555 0000 3232 3020 3137 322d P.}xEU..220.172-
0x0030 3230 2d32 3031 2d31 3335 2e4d 5359 2d50 20-201-135.MSY-P
0x0040 4f50 2e49 5350 2e4e 4554 2046 5450 2073 OP.ISP.NET.FTP.s
0x0050 6572 er
15:05:44.148763 10.10.10.165.3069 > 172.20.201.135.21: P [tcp sum ok]
1:17(16) ack 106 win 17415 (DF) (ttl 128, id 26559, len 56)
0x0000 4500 0038 67bf 4000 8006 08b6 0a0a 0aa5 E..8g. at .........
0x0010 ac14 c987 0bfd 0015 14fb 3326 2b5e 33f1 ..........3&+^3.
0x0020 5018 4407 a60b 0000 5553 4552 2061 6e6f P.D.....USER.ano
0x0030 6e79 6d6f 7573 0d0a nymous..
15:05:44.160219 172.20.201.135.21 > 10.10.10.165.3069: . [tcp sum ok] ack
17 win 32120 (DF) [tos 0x10] (ttl 62, id 38462, len 40)
15:05:44.161050 172.20.201.135.21 > 10.10.10.165.3069: P 106:174(68) ack
17 win 32120 (DF) [tos 0x10] (ttl 62, id 38463, len 108)
0x0000 4510 006c 963f 4000 3e06 1bf2 ac14 c987 E..l.?@.>.......
0x0010 0a0a 0aa5 0015 0bfd 2b5e 33f1 14fb 3336 ........+^3...36
0x0020 5018 7d78 0a8e 0000 3333 3120 4775 6573 P.}x....331.Gues
0x0030 7420 6c6f 6769 6e20 6f6b 2c20 7365 6e64 t.login.ok,.send
0x0040 2079 6f75 7220 636f 6d70 6c65 7465 2065 .your.complete.e
0x0050 2d6d -m
15:05:44.162314 10.10.10.165.3069 > 172.20.201.135.21: P [tcp sum ok]
17:40(23) ack 174 win 17347 (DF) (ttl 128, id 26560, len 63)
0x0000 4500 003f 67c0 4000 8006 08ae 0a0a 0aa5 E..?g. at .........
0x0010 ac14 c987 0bfd 0015 14fb 3336 2b5e 3435 ..........36+^45
0x0020 5018 43c3 2bfe 0000 5041 5353 2073 6361 P.C.+...PASS.sca
0x0030 6e6e 6572 4074 6573 742e 6e65 740d 0a nner at test.net..
Here the ISS Scanner logs in as anonymous with a password of
scanner at test.net.
15:05:44.167966 172.20.201.135.21 > 10.10.10.165.3069: . [tcp sum ok] ack
40 win 32120 (DF) [tos 0x10] (ttl 62, id 38464, len 40)
15:05:44.176967 172.20.201.135.21 > 10.10.10.165.3069: P 174:222(48) ack
40 win 32120 (DF) [tos 0x10] (ttl 62, id 38465, len 88)
0x0000 4510 0058 9641 4000 3e06 1c04 ac14 c987 E..X.A at .>.......
0x0010 0a0a 0aa5 0015 0bfd 2b5e 3435 14fb 334d ........+^45..3M
0x0020 5018 7d78 4805 0000 3233 3020 4775 6573 P.}xH...230.Gues
0x0030 7420 6c6f 6769 6e20 6f6b 2c20 6163 6365 t.login.ok,.acce
0x0040 7373 2072 6573 7472 6963 7469 6f6e 7320 ss.restrictions.
0x0050 6170 ap
15:05:44.178876 10.10.10.165.3069 > 172.20.201.135.21: P [tcp sum ok]
40:65(25) ack 222 win 17299 (DF) (ttl 128, id 26561, len 65)
0x0000 4500 0041 67c1 4000 8006 08ab 0a0a 0aa5 E..Ag. at .........
0x0010 ac14 c987 0bfd 0015 14fb 334d 2b5e 3465 ..........3M+^4e
0x0020 5018 4393 a258 0000 504f 5254 2031 302c P.C..X..PORT.10,
0x0030 3130 2c31 302c 3136 352c 332c 3235 350d 10,10,165,3,255.
0x0040 0a .
15:05:44.190342 172.20.201.135.21 > 10.10.10.165.3069: P [tcp sum ok]
222:248(26) ack 65 win 32120 (DF) [tos 0x10] (ttl 62, id 38466, len 66)
0x0000 4510 0042 9642 4000 3e06 1c19 ac14 c987 E..B.B at .>.......
0x0010 0a0a 0aa5 0015 0bfd 2b5e 3465 14fb 3366 ........+^4e..3f
0x0020 5018 7d78 e9f0 0000 3530 3020 496c 6c65 P.}x....500.Ille
0x0030 6761 6c20 504f 5254 2043 6f6d 6d61 6e64 gal.PORT.Command
0x0040 0d0a ..
This looks like it is testing whether or not Hobbits FTP port bounce
attack will work with this FTP server by testing to see if the PORT
command is allowed. The CVE for this attack is CVE-1999-0017.
According to RFC 959 (FTP): "The argument is a HOST-PORT specification for
the data port to be used in data connection. There are defaults for both
the user and server data ports, and under normal circumstances this
command and its reply are not needed. If this command is used, the
argument is the concatenation of a 32-bit internet host address and a
16-bit TCP port address. This address information is broken into 8-bit
fields and the value of each field is transmitted as a decimal number (in
character string representation). The fields are separated
by commas. A port command would be: PORT h1,h2,h3,h4,p1,p2 where h1 is
the high order 8 bits of the internet host address."
Hobbits FTP port bounce attack would change the IP given in the PORT
command to another server to allow for all sorts of mischief from
portscanning a machine to make it look like it came from the FTP server to
bypassing packet filtering rules. A link to the full text is included in
the correlations section.
So, the port requested is 0x03ff, or 1023 in decimal. The FTP server says
"Illegal PORT Command". At this point I am unsure if the command itself
is not allowed or if there is a check to see if the port used is a
non-privileged port. Either way, the test failed.
15:05:44.191736 10.10.10.165.3069 > 172.20.201.135.21: F [tcp sum ok]
65:65(0) ack 248 win 17273 (DF) (ttl 128, id 26562, len 40)
15:05:44.198336 172.20.201.135.21 > 10.10.10.165.3069: . [tcp sum ok] ack
66 win 32120 (DF) [tos 0x10] (ttl 62, id 38467, len 40)
15:05:44.199536 172.20.201.135.21 > 10.10.10.165.3069: P [tcp sum ok]
248:285(37) ack 66 win 32120 (DF) [tos 0x10] (ttl 62, id 38469, len 77)
0x0000 4510 004d 9645 4000 3e06 1c0b ac14 c987 E..M.E at .>.......
0x0010 0a0a 0aa5 0015 0bfd 2b5e 347f 14fb 3367 ........+^4...3g
0x0020 5018 7d78 0266 0000 3232 3120 596f 7520 P.}x.f..221.You.
0x0030 636f 756c 6420 6174 206c 6561 7374 2073 could.at.least.s
0x0040 6179 2067 6f6f 6462 7965 2e0d 0a ay.goodbye...
15:05:44.199667 10.10.10.165.3069 > 172.20.201.135.21: R [tcp sum ok]
352007015:352007015(0) win 0 (DF) (ttl 128, id 26565, len 40)
The FTP server was upset that the Scanner didn't say goodbye. How rude!
6. Correlations
Mergecap is part of ethereal and can be found at http://www.ethereal.com/.
Information regarding ISS including its serial number in ICMP packets can
be found at:
http://www.iss.net/security_center/advice/Intrusions/2001508/default.htm
Hobbits ftp bounce paper can be found at:
http://www.insecure.org/nmap/hobbit.ftpbounce.txt
Information on CVE CVE-1999-0017 (FTP bounce attack) can be found at:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0017
RFC 959 for FTP can be found at http://www.faqs.org/rfcs/rfc959.html
RFC 2821 for SMTP can be found at http://www.faqs.org/rfcs/rfc2821.html
Information on ISS Internet Scanner can be found at
http://www.iss.net/products_services/enterprise_protection/vulnerability_assessment/scanner_internet.php.
Information on default TTL values for various OS stacks can be found from
http://project.honeynet.org/papers/finger/traces.txt .
7. Evidence of active targeting
It would appear that ISS Scanner discovered information about the adjacent
networks and then performed a vulnerability scan on those networks. To
this end, I would say that the machines in question were actively
targeted.
8. Severity
Severity = (criticality + lethality) - (system countermeasures + network
countermeasures)
Criticality:
Since there is a VMWARE machine on the network with hosts behind it, I am
assuming this network is a honeypot. Therefore the criticality is 1.
Lethality:
Since this is a vulnerability scan, designed to find all vulnerabilities
that a particular machine had, the lethality rates a 5.
System Countermeasures:
It is unknown if the machines are patched up or if the system software is
all up to date. Therefore I am rating the countermeasures to be a 2.
Network Countermeasures:
Since it does not appear that any network countermeasures exist, I am
scoring a 1 in this area.
Severity = (1 + 5) ( 2 + 1 ) = 3
9. Defensive recommendation
As with any vulnerability, up-to-date patches and AV software are
essential.
A network gateway firewall with a default deny policy and ICMP disabled
would have prevented ISS Scanner from discovering any hosts, thus
rendering it ineffective.
A local machine-based firewall would have helped to stop the traffic as
well.
10. Multiple choice Question
Which of the following conditions indicate that your machine has been
scanned by ISS Internet Scanner?
I. ICMP packets contain the string ISSPNGRQ in the body
II. UDP port scans contain the string UDP Scan by ISS
III. Some ICMP packets contain the string ISS Scanner as well as version
information and the license information for the product.
IV. You can't detect this. It is a commercial grade stealth scanner that
has no known fingerprints.
A) I and II
B) IV
C) I
D) I, II, and III
Answer: D. ISS has made their scanner as noisy as possible in an attempt
to keep it from being used in a malicious manner.
More information about the Intrusions
mailing list