This document is located at the following URLs and will be updated as needed: http: //digital.net/~gandalf/Rose_Frag_Attack_Explained.htmhttp: //digital.net/~gandalf/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 attacksIntroduction ============= The " Rose attack "was conceived from a need to disrupt a network for my SANS GIAC GCFW practical: http: //www.giac.org/practical/GCFW/William_Hollis_GCFW.pdfThis attack is a combination of the SYN attack and the" Unknown "ICMP attack in the GCFW coursework: http: //www.sans.org/local/track2.phpWhen I looked at these attacks, I realized that the source address and source port could be spoofed No TCP handshake was required I.. n 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.htmlFinally, IPV6 was not tested IPV6 allows fragmentation so I suspect that some or all. o F the below attacks are applicable to ipv6.i Would Like To Thank Chris Brenton =========1 first attact fairly Simple. Send the first few bytes of a fragment packet at offset 0 (more fragments bit = 1) and the 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 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 to 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 can not 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 to OLS =============================== Laurent Constantin Was Kind Enough To Program This Attack from the Below Somewhat Unwield Manual Set of Instructions (See Instruction Starting with "Finally The (Very) Manual Way TO IMPLEMENT"
). The Program Can Be Found At the Following Url: http://digital.net/~gandalf/rose.clibrary NetWib Must Be Installed To Run Rose.c: http://www.laurentconstantin.com/en/Netw/ netwib / http: //go.to/laurentconstantinMike 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.htmlVentsislav Genchev Wrote a perl script to import this: http://citadelle.intrinatec.com/mailing/current/html/ml_bugtraq/html/ml_bugtraq/html/mlrose fragmentation manual method ================== ============== finally the first attack if you don't have get a compiler :-): a = "attack" Computer - Windows 2000, Latest Service Pack and all patchesb = the computer what attacked - Windows 2000, Lates t 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 patchesLoad WinPcap on computer A:. http: //winpcap.polito.it/load window complex.polito.it/ (you probably don't need to loading window, but it is a good utility to have arrut) load nemesis on Computer A In Directory C: /nemesis-1.4beta3>
http://www.packetfactory.net/projects/nemesis/Load netwox on computer Ahttp: //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). Thase Files Are "sized" CORRECTLY to make "legal" fragmented packets.http: //digital.net/~gandalf/ptcpdata.txtttp: //digital.net/~gandalf /Pudpdata.txthttp://digital.net/~gandalf/Picmpdata.txtBring Up nemITUrnd.xls: http: //digital.net/~gandalf/nemITUrnd.xlsChange the IP Address of the destination machine if needed.Select the rows, And Fill Down Until You Haven Thousand Rows of Packetssave As
.txt to the Directory WHERE You Put The next Nemesis Executable: C: /Nemesis-1.4beta3> rename
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 can not 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 interface 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 does not 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.htmlchuck 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 RESOUON). Compiles on redhat-9.0.chuck further explains: http://www.lemure.net/Updates.php (April 27) "Rose Attack and Other Such Nonsehey 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: http: //digital.net/~gandalf/Rose_Frag_Attack_Explained.txtI 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 Packet s (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: http://digital.net/~gandalf/newdawn.chttp:///digital.net/~gandalf/newdawn2.ci spnt some time looking at one 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: http://digital.net/~gandalf/newdawn3.chttp: //digital.net/~gandalf/newdawn4.cnew Dawn fragmentation attits ================= ====================================================================================================2 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.shtmlAttack Results for all attacks ============= ===================================== 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 bere attched from A Piii 450 MHz Machine. CPU 5 WAS Attacked from a 366 MHz Pii.whether 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): Rose.c = http://digital.net/~gandalf/rose.cthe Second Rose Attack (Parts of A Fragmented Packet Are Sent , last fragment repeated many times, 32 byte fragments) NewDawn3.c = http://digital.net/~gandalf/NewDawn3.cThe second Rose Attack (parts of a fragmented packet are sent, last fragment repeated many times, 8 byte fragments NEWDAWN4.C = http://digital.net/~gandalf/newdawn4.c(i could never get http://digital.net/~gandalf/newdawn.c or http://digital.net/~gandalf/ 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 G CC 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
0 190 9999 99999999 4000 2CPU | 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,
