IP fragmentation attack
This one is really interesting. But let have a brief explanation of IP fragmentation concepts.
The process of breaking up a single IP datagram into two or more IP datagrams of smaller size is called IP fragmentation. This comes from the fact that every datalink medium has a limit on the size of the transmitting frame called MTU (Maximum Transmission Unit). Since IP datagrams are encapsulated in datalink frames, MTU affects larger IP datagrams and forces them to be splitted into pieces each of which smaller than MTU size.
To solve this issue we have 3 choices in mind which only one of them is applicable:
1- To keep IP datagram size smaller than MTU. This is not applicable since no one know what datalink mediums a packet traverses until end of the journey. You may send a packet through a 802.3 datalink medium with MTU equal to 1500 and the packet be routed to different mediums such as Token ring on the way. Each of datalink mediums own their specific MTU.
2- To set the IP datagram size equal or smaller than the directed attached medium (In our case 802.3) and hand away all further fragmentation of datagrams to routers. Meaning that routers decide if the current datagram should be re-fragmented or not. This one is a really ugly solution. The problem is, this offloads a lot of work on to routers, and in the worst case, can also result In packets being segmented by several IP routers one after another, resulting in very peculiar fragmentation.
3- To preview all datalink medium up to destination and choose the smallest MTU belongs to this route. This way we make sure that the fragmentation can be done by the ending hosts and there is no re-fragmentation anymore. This solution, called Path MTU Discovery, allows a sender to fragment/segment a long internet packet, Rather than relying on routers to perform IP-level fragmentation. This is more efficient and more scalable. It is therefore the recommended method in the current Internet.
Fragmentation process:
Three fields in the IP header implement fragmentation and reassembly.
This is IP header and "Flags" field along with "Fragment Offset" participate in fragmentation process.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-->| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags:
A 3 bits field which says if the datagram is a part of a fragmented data or not.
Bit 0: reserved, must be zero
Bit 1: (AF) 0 = May Fragment, 1 = Don't Fragment.
Bit 2: (AF) 0 = Last Fragment, 1 = More Fragments.
0 1 2 13 bits
+---+---+---+ +-----------------------------+
| | D | M | | Fragment Offset |
| 0 | F | F | +-----------------------------+
+---+---+---+
Fragment Offset specify the fragment's position within the original
Datagram, measured in 8-byte units.
Accordingly, every fragment except the last must contain a multiple of 8 bytes of data. It is obvious that Fragment Offset can hold 8192 (2^13) units but we don't have a datagram with 8192 * 8 = 65536 bytes of data because "Total Length" field of IP header keep total length of ip header + payload. IP header is at-least a 20 bytes portion so the maximum value for "Fragment Offset" restricted to 8189 which leaves room for 3 bytes in the last fragment.
Because an IP internet is connectionless, fragments from one datagram may be interleaved With those from another at the destination. "Identification field" uniquely identifies The fragments of a particular datagram.
The source system sets "Identification" in each datagram to a unique value For all datagrams using the same source IP address, destination IP address, And "Protocol" values for the lifetime of the datagram on the internet. This way the destination can distinguish which incoming fragments belong to a unique datagram and buffer all of them until the last fragment received. The last fragment sets the "More Fragment" bit to 0 and this alert the receiving station to start defragmentation process if all fragment offsets are presented.
Look at the following figure to grasp what happens in a fragmentation process:
Two important points here:
1- In some datalink protocols such as Ethernet, Only the first fragment contains the full upper layer header. Meaning that other fragments look like beheaded datagrams.
2- Additional overhead imposed over network because all fragments contains their own IP header. Additional overhead = (number_of_fragments - 1) * (ip_header_len);
A real-life fragmentation example:
I used ethereal protocol analyzer to capture ICMP echo request packets. To simulate this open up a terminal and type ping ip_dest -n 1 -l 65000.
The results seems like this:
No. Time Source Destination Protocol Info
1 0.000000 87.247.163.96 66.94.234.13 ICMP Echo (ping) request
2 0.000000 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480)
3 0.002929 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=2960)
4 6.111328 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=4440)
5 6.123046 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=5920)
6 6.130859 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=7400)
7 6.170898 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=8880)
8 6.214843 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=10360)
9 6.239257 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=11840)
10 6.287109 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=13320)
11 6.302734 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=14800)
12 6.327148 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=16280)
13 6.371093 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=17760)
14 6.395507 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=19240)
15 6.434570 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=20720)
16 6.455078 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=22200)
17 6.531250 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=23680)
18 6.550781 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=25160)
19 6.575195 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=26640)
20 6.615234 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=28120)
21 6.634765 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=29600)
22 6.659179 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=31080)
23 6.682617 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=32560)
24 6.699218 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=34040)
25 6.743164 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=35520)
26 6.766601 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=37000)
27 6.783203 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=38480)
28 6.806640 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=39960)
29 6.831054 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=41440)
30 6.850586 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=42920)
31 6.899414 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=44400)
32 6.915039 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=45880)
33 6.939453 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=47360)
34 6.958984 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=48840)
35 6.983398 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=50320)
36 7.023437 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=51800)
37 7.046875 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=53280)
38 7.067382 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=54760)
39 7.090820 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=56240)
40 7.130859 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=57720)
41 7.151367 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=59200)
42 7.174804 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=60680)
43 7.199218 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=62160)
44 7.214843 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=63640)
45 7.258789 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=65120)
The first packet details:
No.Time Source Destination Protocol Info
1 0.000000 87.247.163.96 66.94.234.13 ICMP Echo (ping) request
Frame 1 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: OmronTat_00:00:00 (00:00:0a:00:00:00), Dst: 40:0f:20:00:0c:00 (40:0f:20:00:0c:00)
Internet Protocol, Src: 87.247.163.96 (87.247.163.96), Dst: 66.94.234.13 (66.94.234.13)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x6b7d
Identifier: 0x0600
Sequence number: 0x0200
Data (1472 bytes)
The second packet details:
No. Time Source Destination Protocol Info
2 0.000000 87.247.163.96 66.94.234.13 IP Fragmented IP protocol (proto=ICMP 0x01, off=1480)
Frame 2 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: OmronTat_00:00:00 (00:00:0a:00:00:00), Dst: 40:0f:20:00:0c:00 (40:0f:20:00:0c:00)
Internet Protocol, Src: 87.247.163.96 (87.247.163.96), Dst: 66.94.234.13 (66.94.234.13)
Data (1480 bytes)
Note that Only the first fragment contains the ICMP header and all remaining fragments generated without ICMP header.
And finally we are ready to deal with IP fragmentation exploits.
1- IP fragment overlapped This exploit identified when two fragments contained within the same IP datagram have offsets that indicate that they share positioning within the datagram. This could mean that fragment A is being completely overwritten by fragment B, or that fragment A is partially being overwritten by fragment B. Some operating systems do not properly handle fragments that overlap in this manner and may throw exceptions or behave in other undesirable ways upon receipt of overlapping fragments. This is the basis for the so called teardrop Denial Of Service Attacks.
2- IP Fragmentation Buffer Full This exploit identified when there is an extraordinary amount of incomplete fragmented traffic detected on the protected network. This could be due to an excessive number of incomplete fragmented datagrams, a large number of fragments for individual datagrams or a combination of quantity of incomplete datagrams and size/number of fragments in each datagram. This type of traffic is most likely an attempt to bypass security measures or Intrusion Detection Systems by intentional fragmentation of attack activity.
3- IP Fragment Overrun - Datagram Too Long This exploit identified when a reassembled fragmented datagram would exceed the declared IP data length or the maximum datagram length. By definition, no IP datagram should be larger than 65,535 bytes. Systems that try to process these large datagrams may crash. This type of fragmented traffic may be indicative of a denial of service attempt.
4- IP Fragment Overwrite - Data is Overwritten Overlapping fragments may be used in an attempt to bypass Intrusion Detection Systems. In this scenario, part of an attack is sent in fragments along with additional random data; future fragments may overwrite the random data with the remainder of the attack. If the completed datagram is not properly reassembled at the IDS, the attack will go undetected. Triggers when a fragment overlap occurs which results in existing data being overwritten.
5- IP Fragment Too Many Datagrams This exploit identified when there is an excessive number of incomplete fragmented datagrams detected on the network. This is most likely either a denial of service attack or an attempt to bypass security measures.
6- IP Fragment Incomplete Datagram when a datagram can not be fully reassembled due to missing data. This may indicate a denial of service attack or an attempt to defeat packet filter security policies.
7- IP Fragment Too Small
when any fragment other than the final
fragment is less than 400 bytes, indicating that the fragment is likely
intentionally crafted. Small fragments may be used in denial of
service attacks or in an attempt to bypass security measures or
detection.
References
External links