Packet fragmentation versus the Intrusion Detection System (IDS) Part 1

by Don Parker [Published on 11 April 2007 / Last Updated on 11 April 2007]

Packet fragmentation and how it can affect the IDS.

If you would like to read the next part in this article series please go to Packet fragmentation versus the Intrusion Detection System (IDS) Part 2.

Packet fragmentation versus the Intrusion Detection System (IDS) Part I

Intrusion Detection Systems (IDS) have long had a problem with packet fragmentation. This was true five years ago and it is still a problem today. For years the IDS has suffered from several key ailments. Chief amongst them is in how they deal with packet fragmentation. There has been great progress made over the years in how an IDS will deal with packet reassembly, however the problem still remains. Over the past years IDS vendors have grown smarter when it comes to packet fragmentation, and how their IDS's reassemble these fragments.

During the course of this series I will use the following tools:

  • Fragrouter
  • Metasploit Framework
  • Snort
  • tcpdump.exe

Fragrouter will be used as our main packet fragmentation tool for this article, but we will also look at Metasploit Framework’s built in fragmentation abilities as well. These fragmented attacks will be tested against the Snort IDS, and lastly we shall be using the tcpdump.exe packet sniffer to collect packets.

What we will now do in part one of the article series is set up our test lab so that we can use fragrouter. First up, we will need to add a new route on the Windows 2000 Pro (W2K) box that we will be launching the attacks from. The router we will need to add is that of all packets sent to our victim W2K computer need to go via the SuSE box running fragrouter. This way the exploit sent via the attacking computer will be first sent to the SuSE box running fragrouter for fragmentation and will then be forwarded on to the victim computer. Seeing as this explanation can be a tad confusing let’s take a look at the diagram below.


Figure 1

Because fragrouter requires that it acts as the middleman, we are required to use this type of layout. Now we will go ahead and add the route change as seen in the diagram below.

Please bear in mind again that the computer running fragrouter must be on a separate network and as such the IP’s shown below would be different for your usage.


Figure 2

Well so far things have been pretty painless in terms of setup. It is always frustrating for me when I am trying to learn something, and I end up getting sidetracked by having to fix or learn something else. Now as it impacts the attacking computer, all we have to do is make sure that we have Metasploit Framework installed. This is what we will use to simplify our attacks. Not everyone is comfortable in compiling exploit code, so by using Metasploit we are able to neatly side-step that issue. Compiling exploit code though is not that difficult once you have seen it done. If you do not yet know how to do so, I would encourage you to learn how. That, or feel free to email me and I will send you the compiler syntax for an exploit that is freely available via Securiteam, and many other places.

We now need to set up our victim computer. You will need to download Snort and have it installed with winpcap. Snort should install by default to the root of your C drive, and winpcap will also install itself seamlessly. If you are going to be using the latest version of Snort then please ensure that you download the rules as well. Newer versions of Snort no longer come with the rules, and you will need to download those separately. Once you have downloaded the rules please copy the rules folder over to the main Snort directory as seen below. There will already be a rules folder there. Simply delete it and add your just downloaded rules folder there.


Figure 3

Now one key point that I should mention here is that ultimately we will want to see what our fragmented traffic looks like as it hits the victim computer. To do that we will need to install tcpdump from MicroOLAP. This program will allow us to capture and later inspect the packets as they arrive at our victim computer. It is important to show theory put into practice as it will help cement lessons learned. That is why we will look at the fragmented packets. It will help us recognize them for what they are should we encounter them at some point in the future, and odds are, we will. There is still the SuSE computer that we have to set up. You will need the fragrouter installed on it for one, as well as its dependencies. Those should all be in the folder that you download. Once downloaded you will need to “cd” to the fragrouter directory and install it via the following commands:

./configure
make
make install

That was fairly simple and straight forward. You will now need to invoke fragrouter with the following command “./fragrouter –F1”. This will give you the simplest setting for fragrouter, and one that we will use shortly. We now have all of the pieces in place, barring any mental hiccups on my part. Let’s take an attempt at packet fragmentation then.

On with the show

We will now take a stab at the beast, as it were. Please ensure that you have Metasploit Framework up and running either via the web interface or DOS prompt. The web interface is better as it involves less typing. Secondly, have Snort up and running on the victim computer so that we can see what it detects on our first pass at packet fragmentation. Please see the screenshot below for the switches I used to invoke it.


Figure 4

Lastly, start up fragrouter on the SuSE computer which will actually be doing the fragmentation of the exploit as sent via the Metasploit Framework. Please see the screenshot below for the syntax used to invoke it.


Figure 5

All set? Let’s get to it then. Seen below is a screenshot of Metasploit obtaining a shell on the victim computer. Once you have obtained shell access, go to your victim computer and stop Snort. Do a “control c” to stop it in the DOS prompt that it is running in.


Figure 6

Once you have stopped Snort, go back to the attacking computer and click on “session::break”. This will sever the connection between the attacking computer and the victim. Lastly, let’s also stop fragrouter by again doing a “control c” in the term window that it is running in. What we now need to do is take a look at the output of Snort to see what, if anything, it detected. Let’s take a look at the screenshot below.


Figure 7

My instance of Snort logged seven items and two alerts. Interesting is the chunk of data beneath the “Action Stats”. There was a total of 271 fragmented IP packets sent during our attack session. That is a fairly high number of fragments as compared to the total of zero fragmented packets I saw when using Metasploit Framework on the victim computer. Without using fragrouter as a middleman earlier on to establish a benchmark, I had many, many less. Let’s now take a look to see what Snort actually logged as alerts. Please see the screenshot below.


Figure 8

Snort detected the attack as two instances of “NETBIOS DCERPC Remote Activation bind attempt”, which in reality is what the attack was. I used the MS03-026 exploit which targets TCP port 135. We now know that our attempt at “simple” fragmentation to evade Snort failed miserably. That is reason for celebration as we would indeed hope that a modern IDS would catch such a generic fragmentation attempt.

Wrap Up

In this second part we went ahead and configured our VMware lab settings so that we could use fragrouter to fragment our attack against a victim computer. This was done in order to see if a modern IDS such as Snort would catch our attempt at fragmentation. Snort did indeed see through our attempts at fragmentation. Fragrouter however has quite a few more tricks up its sleeve than the simplistic fragmentation attack we used. In part two we will take fragrouter through its paces in more sophisticated fragmentation attacks and see how Snort does. See you in part two.

If you would like to read the next part in this article series please go to Packet fragmentation versus the Intrusion Detection System (IDS) Part 2.

See Also


The Author — Don Parker

Don Parker specializes in matters of intrusion detection, and incident handling. He has also enjoyed a role as guest speaker at various network security conferences, and writing for various online and print media on matters of computer security.