Stonesoft's "Advanced Evasion Techniques"

[Jollity]

I have been sent some marketing material by a firewall manufacturer called Stonesoft. They make a big deal of blocking what they call "advanced evasion techniques" - they say these are a set of different methods to evade the protection against external attacks provided by a modern firewall. They do not seem to provide many details of the methods - they cite the the need for responsible disclosure - what I have found talks about techniques like sending packets deliberately out of order to confuse the IPS. The provide a free test suite to test whether your existing firewall is vulnerable to these technique. I have not tried this yet, has anyone else?

 

I am currently looking at new firewalls for my school, and I am not sure whether I should be giving any weight to StoneSoft's claims. There seems some plausibility to what they are saying, but I have found a lack of 3rd party discussion of the issue. Closest I have seen is this stack exchange post from 2010.

[Geoff]

The only use I've see for deliberately sending out of order packets is that some firewalls will keel over trying to reassemble the data stream for Deep Packet Inspection. So you can consider it as a DoS technique. As a result most stateful firewalls will throw away out of order packets by default. This will manifest in tcp session timeouts and retrys and will result in poor throughput at the application layer.

 

So no, without more information from Stonesoft it just looks like marketing hype to me.

[dsuprina]

After reading your post, I wanted to reply to help you understand what Stonesoft is doing and why AETs (Advanced Evasion Techniques) should be a concern to you. Before I start, in the interest of full disclosure I should state that I am a Stonesoft engineer. That said, my aim is only to help you and other readers of your posting understand the true nature of what an AET is and what needs to be done to protect against them.

An evasion is, as you noted, a deliberate attempt to confuse a security protection system. More precisely, it is the modification of a packet stream so as to prevent a given firewall or IPS from correctly re-constructing the actual data stream being conveyed so that when compared against signatures of malware, no match is found. Simple enough. And an “Advanced Evasion” is the purposeful attempt to do this using multiple evasions at once.

You mentioned one such evasion – the sending of packets out of order – as being commonly cited. The Evader tool (at Evader | Stonesoft Evader) offers several dozen common evasions that can be tried, as well as a few recommendations for combinations to try to effectively disguise traffic and slip it past current security engines. For example, simply setting the TCP receive window size to 7, which is a perfectly legal parameter to negotiate during session setup, will cause a Cisco engine to completely miss common malware payloads. Some engines do flag small segment size as a potential attack, but all it takes is a few small segments shipped in reverse order to cause a SourceFire system to fail to correctly apply its signatures. Of the 300-plus currently known evasions, which can be combined in approximately 800 million combinations (so I am told by development), it’s not too difficult to find multiple combinations that will work with each common FW and IPS. For a handful of these evasions that is what the Evader utility does… allows you to explore this for yourself. There’s no cost other than your time.

To be sure, some of the evasions are, strictly speaking, making use of illegal, undefined, or obsolete configuration parameters within the various protocols that might be used. But what is surprising is the number of perfectly legal protocol options – like the use of priority data within TCP or filename obfuscation within SMB (something like …/abc/../xyz) that can cause the software and ASICs in so many security engines real heartburn.

The solution to the problem is that before any malware signature is compared against a data stream, that data stream must be fully normalized. That is, all the obfuscations must be removed. And it has to be done at all protocol layers together, not sequentially. This can and does increase processor and memory requirements for security engines, as there is no escaping the necessity to fully unwind and completely extract the actual message content, no matter how many packets it is sent in, or their order, or chaff that is injected, or overlapped, or means used to skip data ahead of adjacent bytes in that stream.

If you like, I reach out to me and I can show you this using real hardware. The company has a rack of current FW and IPS systems pre-configured with their latest updates, and against which we can try various evasion combinations.

 

As for the real world risks that evasions present we can only infer. This is because by definition a successful evasion will permit a payload to pass through a security engine without detection. Verizon’s Data Breach report for 2012 provides hints of what is happening, including that the number of attacks has been rising while the number of those incidents detected by targeted firms has been falling. This is not a contradiction but indicative of a world where we all too often find out about breaches after the infection, not during the attempt.

 

HTH –

Darren Suprina