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