Welcome to In Depth Defense. In Depth Defense LLC is a privately owned Information Security Consulting company owned and operated by Mark Baggett. In Depth Defense specializes in Penetration Testing and Incident Response. At this time In Depth Defense is not accepting any new client work, but we are happy to speak to you and point you to other resources in the community.

Mark Baggett has been active in Information Security for 18+ years. I've served in a variety of roles from software developer to CISO. You can find archives of older blog entries below and read my newer posts on http://www.pauldotcom.com, http://isc.sans.edu and http://pen-testing.sans.org








Sunday, August 16, 2009

TCP Fragment Evasion

Originally posted on http://pauldotcom.com/2009/08/tcp-frament-evasion-attacks.html

By: Mark Baggett

I recently read a very good article on tuning Snort's Stream5 preprocessor to avoid "TCP Fragment Overlap" attacks. It's a great article, but the wording confused me. I thought to myself, "TCP Fragments, that must be a mistake. The TCP Header doesn't have a 'more fragments bit', a 'fragment offset' or anything to support fragmentation. How can there be any TCP fragments?"   Typically when we talk about fragmentation attacks we think about Layer 3 attacks. Attackers manipulate the IP packet headers to pull off various insertion and evasion attacks. Examples of layer3 attacks include overlapping fragment attacks and temporal evasion (host reassembly timeout evasion). These attacks are explained pretty well in an article titled "Evading NIDS, revisited".

So what is TCP or Layer 4 "fragmentation"? Really, its overlapping or retransmitted datagrams with the same TCP Sequence number. To demonstrate the concept I fired up a virtual machine running Backtrack 3. I ran a netcat listener on my host (nc -l -p 9000) and used a netcat client in backtrack to connect to it. I fired up wireshark to watch the packets and I transfered the text "This is a test of the emergency broadcast system. If it were an actual emergency" between the two hosts. This is what Wireshark captured.

Figure #1

TCPFragmentation1.jpg



View image


Perfect. Exactly what we would expect. Since my packet doesn't exceed the MTU of the established TCP connection a single packet is transfered to the client with a single acknowledgment in return.  If it had exceeded the MTU it still wouldn't have fragmented. It would have sent more than one datagram, each with its own unique IP ID.


Then I created a fragroute configuration file with one line in it:

tcp_seg 16



This will cause fragroute to break the packets down so that they can only carry 16 bytes of TCP traffic. I start fragroute (fragroute -f ~/myfrag.conf 192.168.100.12) and transfer the same text between the hosts...

Figure #2



TCPFragmentation2.jpg


View image

Fragroute works as expected and breaks the packets down such that only 16 bits of data can be transfered in each packet. Each packet sequence number increases by the number of bytes transmitted. Sequence numbers increase in order. Also, notice that each packet has its own unique IP ID field. There is NO FRAGMENTATION. The "More Fragments bit" isn't set.   The fragment offset isn't set. No fragments. Instead, fragroute is transferring packets as if the MTU of the segment is only enough for 16 TCP bytes.



So now lets do some "tcp fragmentation overlaps". I change my fragroute.conf file to say this:



tcp_seg 16 new



This will cause fragroute to transmit frames with overlapping sequence numbers.   This attack takes advantage of the fact that the TCP layer doesn't pass data up the stack to the application until it has acknowledged the data and that packets are acknowledged in sequential order.    So if we skip datagram #3  and transmit datagrams #4, #5 and #6, duplicates of #4 and overlaps of #5 and #6 then the TCP stack needs to hold datagrams #4,#5 and #6 (as long as they are within the window size) and figure out what to do with duplicates/overlaps once it receives fragment #3.

To see this in action I fire up fragroute and retransmit the text "This is a test of the emergency broadcast system. If it were an actual emergency"  

Figure #3

TCPFragmentation3.jpg

View image



Lets look at it in the fragroute packets in figure#3.   The first two datagrams (#1 and #2) are garbage.  Their payload is random junk.  Then fragroute transmits good data in packets 4 and 5.  The payload here is the end of our payload "If this had been an actual emergency."  After the 4th packet the receiving host begins screaming to the transmitting client "HEY DUDE,  ACK 2933750986.  I didn't get that one yet".   The receiving TCP stack is complaining about not receiving the first datagram.    Then fragroute sends 2 packets with 32 TCP bytes in each.  These two datagrams include the  FIRST datagram (Notice packet #10 has the lowest sequence number and the embedded text payload).  Parts of these two packets overlap packets 1 and 2. Packet #9 overlaps 16 bytes of packet #2.  16 bytes of packet #10 overlap packet #1.  If the TCP reassembly engine favors NEW packets then it will reassemble the text as expected.  If the IDS reassembles the packets favoring the OLD packets then we can bypass the IPS. If we were drawing analogies to layer three fragment attacks holding the low sequence number datagrams is equivalent to setting the "more fragments bit" and the sequence number is the equivalent to the fragment offset. So how to fix this?  The attacks aren't new.  Snort has the STREAM5 preprocessor.  Just be sure that you tune STREAM5 just like your FRAG3 preprocessor.  

References



Snort's Stream5 and TCP overlapping fragments An article by Richard Bejtlich that sparked my interest in this topic. Its a very good article with more explanation on tuning the snort preprocessor.
Subscribe