Manage Learn to apply best practices and optimize your operations.

Does TCP/IP reassembly pose a TCP/IP packet format risk?

An obscure process called TCP/IP reassembly may pose an enterprise network security risk. Learn about this TCP/IP packet format security issue.

Researchers at Black Hat 2013 claimed that many network security products, ranging from NGFWs to IPS, depend on what they call TCP/IP reassembly; if those products are incapable of performing this function, they can be bypassed. What exactly do they mean by this and how can an organization determine if their security products stand up in this area?

Ask the expert

Perplexed about network security? Send your network security-related questions today! (All questions are anonymous)

Applications that require a logical network connection typically communicate via the Transmission Control Protocol (TCP). In a nutshell, TCP works by conducting a three-way handshake. After the logical connection between the two hosts is established, segments of payload data are transmitted back and forth. However, not all segments are of equal size or take the same network path when traveling from one host to the other. Additionally, intermediate network devices are sometimes configured to process maximum segment sizes and if any network device along a given path receives a segment that is too large to process, segmentation occurs. This is when a large segment is broken into smaller units to speed up the process. When the destination node receives all intended segments from the sending node, often times the totality of the segments for a given session is out of chronological order. Only after using a concept known as sequence numbers can reassembly of the segments occur.

The whitepaper referenced in the question discusses several vulnerabilities regarding TCP/IP reassembly. In order to demonstrate the vulnerability of intrusion prevention systems (IPSes), for example, several older, known exploits were run against a series of systems that should have the ability to detect the exploit in the absence of TCP/IP manipulation. Once an IPS did detect one of the known exploits, TCP/IP reassembly manipulation was conducted, sending the same code against the same series of IPSes but this time in multiple units. In many cases, the IPSes did not detect -- and therefore could not block -- the same exploit they had blocked prior to TCP/IP reassembly manipulation.

An organization can determine how its security products stand up in this area by conducting tests similar to the one outlined above. Throw commonly known exploits -- using a tool like Metasploit -- against an IPS that you know your IPS can detect, and then send the same exploits against the same IPS with TCP/IP reassembly manipulation in play. If your IPS successfully blocks these attempts, you can take comfort in the fact that your IPS is not fooled by the manipulation of some of the features within TCP/IP. If it fails, the best course of action is to review your IDS device configurations and deployment techniques to determine whether a change can improve the performance. Failing that, I suggest contacting the vendor, as a missing software update or other issue may be in play.

This was last published in April 2014

Dig Deeper on Network intrusion detection and prevention (IDS-IPS)