The following alert was received from a Symantec Endpoint Protection (SEP) device
<179>Jul 10 09:25:14 sep-papw01 SymantecServer: XXX,SHA-256: ,MD-5: ,"Denial of Service 'IP Fragmentation Overlap' attack detected. Description: An IP Fragmentation Overlap attack exploits IP's packet reassembly feature by creating packet fragments with overlapping offset fields, making it impossible for your system to reassemble the packets properly.",Local: 0.0.0.0,Local: XXXX,Remote: ,Remote: XXXX,Remote: 000000000000,Inbound,ICMP,,Begin: 2018-07-10 06:26:10,End: 2018-07-10 06:26:11,Occurrences: 2,Application: ,Location: XXXX,User: XXXX,Domain: XXXX,XXXX Port 0,Remote Port 0,CIDS Signature ID: 0,CIDS Signature string: ,CIDS Signature SubID: 0,Intrusion URL: ,Intrusion Payload URL:
Our main concern from the message above is "Denial of Service 'IP Fragmentation Overlap' attack detected".
If you are a new Analyst and see this message, you may wonder WTF is this? What does this mean?
Fortunately the above alert also provides a description, which is:
"An IP Fragmentation Overlap attack exploits IP's packet reassembly feature by creating packet fragments with overlapping offset fields, making it impossible for your system to reassemble the packets properly"
If you are still thinking but Nik, WTF does this mean? Then let's get into solving this mystery.
Your network interface card has a maximum number of bytes it can carry at one time. This is called the MTU or the Maximum Transmission Unit. To see your interface's current MTU, on a Linux device type:
securitynik@securitynik.lab:~# ifconfig | grep --color=always --perl-regexp "mtu.*?$" eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
Above you see, for eth0 interface I have an MTU of 1500 bytes, while on my loopback there is an MTU of 65536 bytes. While we will not be crafting packets as large as 1500 or 65536 bytes, the concept remains the same. If a packet is larger than the MTU then the packet needs to be fragmented or broken up into smaller pieces so that it can traverse your network. When the sending device or network device breaks this packet up, it needs to be reassembled by the receiving host. In order for this reassembly to work properly, data has to be placed at specific offset. If that data overlaps or there are missing fragments, it can impact the successful reassembly of the packets.
Let's craft a "normal" packet with scapy and the string "SecurityNik-IP-Fragmentation" to understand what "normal" should look like before we look at what fragment overlapping looks like.
>>> send(IP(src="1.1.1.1", dst="192.168.208.131")/"SecurityNik-IP-Fragmentation", count=1)
The above produces the following in tcpdump as shown below.
securitynik@securitynik.lab:~# tcpdump -nntvvi any host 1.1.1.1 -X IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto Options (0), length 48) 1.1.1.1 > 192.168.208.131: ip-proto-0 28 0x0000: 4500 0030 0001 0000 4000 e79f 0101 0101 E..0....@....... 0x0010: c0a8 d083 5365 6375 7269 7479 4e69 6b2d ....SecurityNik- 0x0020: 4950 2d46 7261 676d 656e 7461 7469 6f6e IP-Fragmentation
The above represents a packet which is not fragmented. We can tell its not fragmented because among the most important items for fragmentation, is the fact that we see above "offset 0" and "flags none". Another critical component of fragmentation is the IP ID field. Above this is represented by "id 1". As we look above we also see "length 48" which implies this packet is 48 bytes long. Minus the 20 bytes of IP header and we have 28 bytes of data as seen by the "28" above after "ip-proto-0". This means that the string "SecurityNik-IP-Fragmentation" takes up 28 bytes. When counting the offset, we start from 0. Therefore 0-27 will result in 28 bytes.
S e c u r i t y N i k - I P - F r a g m e n t a t i o n 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Let's now craft a fragmented packet which has 2 fragment trains to get an idea what fragmentation looks like. In this case, we will break up the string "SecurityNik-IP-Fragmentation". To be specific, the first fragment will contain "SecurityNik-IP-F" while the second fragment contains "ragmentation"
Here is scapy crafting of the packet.
>>> send(IP(src="1.1.1.1", dst="192.168.208.131", id=20, flags=0x1, frag=0)/"SecurityNik-IP-F", count=1) >>> send(IP(src="1.1.1.1", dst="192.168.208.131", id=20, flags=0x0, frag=2)/"ragmentation", count=1)
Here is tcpdump output
securitynik@securitynik.lab:~# tcpdump -nntvvi any host 1.1.1.1 -X IP (tos 0x0, ttl 64, id 20, offset 0, flags [+], proto Options (0), length 36) 1.1.1.1 > 192.168.208.131: ip-proto-0 16 0x0000: 4500 0024 0014 2000 4000 c798 0101 0101 E..$....@....... 0x0010: c0a8 d083 5365 6375 7269 7479 4e69 6b2d ....SecurityNik- 0x0020: 4950 2d46 IP-F IP (tos 0x0, ttl 64, id 20, offset 16, flags [none], proto Options (0), length 32) 1.1.1.1 > 192.168.208.131: ip-proto-0 0x0000: 4500 0020 0014 0002 4000 e79a 0101 0101 E.......@....... 0x0010: c0a8 d083 7261 676d 656e 7461 7469 6f6e ....ragmentation
From above, if we look at the first record, we see "offset 0" and "flags [+]". Notice the IP ID is also the same "id 20". Notice also the "length 36". Once again, minus the 20 byte IP header and there is "16" bytes of data. The second record (fragment) has "offset 16" and "flags [none]". This means the second record should be placed 16 bytes after the first record and there are no more fragments to follow. We know there are no more fragments because the "flags [none]".
From a more visual perspective
S e c u r i t y N i k - I P - F r a g m e n t a t i o n 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
As you can see from above, there is no overlap. The string "SecurityNik-IP-Fragmentation" looks much the same as the "normal" packet we discussed above. The "S" starts at 0 and the "r" starts at offset 16.
Now that we have the basics out of the way, let's now look at the overlap. To help, let's craft the same packet again, this time modifying the offset to ensure they overlap. Whereas above "frag=2" was used, below "frag=1" will be used. To get a better understanding of these numbers, you have to multiply then by "8". Hence the "frag=2" is offset 16 and "frag=1" will be offset "8"
And the tcpdump output
securitynik@securitynik.lab:~# tcpdump -nntvvi any host 1.1.1.1 -X IP (tos 0x0, ttl 64, id 20, offset 0, flags [+], proto Options (0), length 36) 1.1.1.1 > 192.168.208.131: ip-proto-0 16 0x0000: 4500 0024 0014 2000 4000 c798 0101 0101 E..$....@....... 0x0010: c0a8 d083 5365 6375 7269 7479 4e69 6b2d ....SecurityNik- 0x0020: 4950 2d46 IP-F IP (tos 0x0, ttl 64, id 20, offset 8, flags [none], proto Options (0), length 32) 1.1.1.1 > 192.168.208.131: ip-proto-0 0x0000: 4500 0020 0014 0001 4000 e79b 0101 0101 E.......@....... 0x0010: c0a8 d083 7261 676d 656e 7461 7469 6f6e ....ragmentation
From a more visual perspective
S e c u r i t y N i k - I P - F 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 r a g m e n t a t i o n 8 9 10 11 12 13 14 15 17 18 19 20
As we can see above, the two fragments begin to overlap at offset 8.
Why would a threat actor want to use this you may be asking? The reality is, this can be used to bypass security products such as IDS/IPS if not properly configured.
Ok. That's it for a Understanding IP Fragmentation Overlapping with Scapy
References:
https://wiki.wireshark.org/Ethernet
https://en.wikipedia.org/wiki/Ethernet_frame
https://wiki.wireshark.org/CaptureSetup/Ethernet
https://snort.org/faq/readme-frag3
https://www.plixer.com/blog/general/netflow-security-detecting-ip-fragmentation-exploits-scrutinizer/
http://pld.cs.luc.edu/courses/447/sum08/class3/novak.target_based_frag.pdf
https://www.cs.montana.edu/courses/fall2005/440/slides/slides_20051026_ip_2.pdf
http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm
No comments:
Post a Comment