Talk: Reassemble or GTFO! – IDS Evasion Strategies
Ever since network intrusion technology was introduced, attackers have tried to evade detection. The tactics for evasion changed over time, but there really was no point in the past when evasion was not discussed. This is especially true for all things HTTP, because web applications transmit a rich set of data between server and client (and vice versa). The aim of evasion is to confuse the sensor and to thwart the inspection process itself. Designers have come up with ways to normalise data by reassembly of packets or rewriting content to establish matching with a baseline in terms of data formatting. Attackers usually supply data to an IDS that will never be factored in at the receiving end (evasion by insertion), or by confusing an IDS’s very process of reconstructing the data stream. The attacks can be very simple or very sophisticated, mostly dictated by the degrees of freedom of the protocol being inspected.
From the insertion of rogue null bytes, to over-lapping, and over-writing the contents of packets, mean that an IDS has very little chance of being able to catch all bad traffic. Many IDS systems are geared to dealing with a high traffic volume, and any reassembly is going to be both difficult and taxing on system resources, whilst slowing the network down. With very little enumeration a potential attacker can utilise a number of reassembly evasion techniques to aid in the escape of otherwise prohibited traffic. This is especially interesting for any device dealing with or implementing data loss protection.
Arron M. Finnon, a.k.a. “Finux”, will explain IDS evasion in-depth during his talk at DeepSec 2011. Finux follows DeepSec’s „IDS tradition“ since we held talks about next generation network intrusion technology in 2008, 2009 and 2010. No matter what your relation to IDS is, you should know which tactics attackers use against your sensors. IDS is not a plug’n play technology, even if evasion tactics are not taken into account (most clients will happily stretch protocol specifications to their limits). However knowing what is thrown against your network will help to keep your radar less prone against false positives.