Advanced Polymorphic Worms: Evading IDS by Blending in with Normal Traffic

1. Advanced Polymorphic Worms:Evading IDS by Blending in with Normal Traffic Authors: Oleg Kolensnikov and Wenke Lee Published: Technical report, 2005, College of Computing, Georgia Institute of Technology Presented By: Sherri Sparks

2. Computer Worms • Worms are to networks as viruses are to hosts. • Worms replicate & infect network nodes in the same sense viruses replicate & infect applications on a local computer system • Worms, are unlike viruses, in the sense that they are autonomous (i.e. they are capable of spreading without human intervention)

3. Worm Developer Simple (nonobsfucated) worms Polymorphic (obsfucated) worms Advanced worms (obsfucated and anti-detection coutermeasures) Worm Detector Misuse (signature) detection Anomaly (heuristic) detection ? Historical Overview of Computer Worm Evolution Coevolutionary Adaptation & Response We are here!

4. Simple Worms • Components • Payload  Worm code body • Exploit vector  System weakness whereby the worm “gets in” (usually some underlying vulnerability in the Operating System or a common application) • NOTE: the code body and exploit vectors for simple worms are invariant • Scan / Compromise / Replicate pattern of behavior • Scan for vulnerable system • Infect system (inject payload) via exploit vector • Goto 1

5. Misuse Detection i.e. “fingerprinting” (1) • Network traffic is scanned for a sequence of bytes that matches a binary pattern unique to a particular worm payload • Pros • Simple implementation • Highly accurate for detecting existing worms • Cons • Can be fooled by polymorphism and VMM hooking techniques • Not capable of detecting new worms! • Assumes code body invarience (i.e. non polymorphic code)

6. Polymorphic Worms • Violate the misuse detectors assumption that the worm code body is invarient • A polymorphic worm is capable of mutating the appearance of its binary code from one version to the next • Difficult / Impossible to find a reliable, consistent signature across all worm versions • Semantically different, but functionally equivalent code • Analogy to English “synonyms” • Polymorphic worms may also have varient exploit vectors

7. Polymorphism Weakness: The code body is encrypted differently, but the decryptor may remain invarient making it possible to obtain a signature from the decryptor. …Unless Metamorphism is used…

8. Metamorphism NOTE: A decryptor which uses matamorphism may be even more difficult to obtain a signature because the decryptor is now varient in addition to the encrypted code body !

9. How do they do that? • Junk code insertion • Interleaving useful instructions with junk instructions (nop, inc reg / dec reg pairs) • Instruction Substitution • Using different instructions to achieve the same result • Register Renaming • Shuffeling the register set used by the polymorphic worm

10. Writing polymorphic worms is getting easier… • Why reinvent the wheel? • …When ready made polymorphic “toolkits” exist for drag n’ drop worm creation ;) • ADMutate • CLET • JempiScodes

11. Anomaly Detection • Heuristic Detectors • Work by recognizing deviations in “normal” system or network patterns or which are indicative of worm behaviors • Average size and rate of normal packets • Byte frequency districtutions • Time information • Useful for detecting polymorphic worms where it is difficult to obtain a reliable signature • Pros • Can identify compromises by new, previously unknown worms! • Cons • Can identify general worm activity but not specific worms • Sometimes difficult to define “normal” activity • Problems with false positives

12. Taking it to the next level… • Introducing Advanced Polymorphic Worms • Attack the heuristics used by anomaly based IDS • The goal of this paper is to show proof of concept that this is possible: i.e.to show that it is feasible to gather a normal traffic profile and use it to evade an anomaly based IDS

13. Experimental Design • 3 Components • Implementation of a “test” polymorphic worm • Design & implementation of a “traffic blender” capable of generating network traffic that can defeat the heuristics used by anomaly based IDS • Testing of the polymorphic worm / traffic blender against several known network IDS

14. Implementation of the “test” polymorphic worm • Exploit Vector • Windows Media Services Exploit (MS03-022) • Simple buffer overflow exploit on port 80 • Malformed HTTP request packets cause overflow • Polymorphic Worm Design • Simple decryptor / loader design using existing toolkits and technologies • Implemented w/ Visual C++ .NET using CLET engine

15. Traffic Blender Design (1) • Goal: Exploit statistical properties of network traffic used by IDS to differentiate between “normal” and “attack” traffic. These include… • Maximum & average size and rate of packets • Byte frequency distributions • Ranges for values present at different offsets • Time information • Precedence / Antecedents (i.e. when a packet must be followed by a specific response or sequence of packets) • The authors choose 3 metrics for blending • Byte frequencies • Ranges for values at different offsets • Packet size

16. Traffic Blender Design (2)“Exploit Invarients” • Parts or properties that must be present for an exploit to work. • In this case, the exploit is based upon a malformed HTTP request packet…Thus, • Exploit invariants include the “POST” request line and strings such as “Content-type”, “Content-length”, and “Mx_stats_logline) • The position of exploit invariant strings in the packet may be either fixed or not fixed

17. Traffic Blender Design (3)“Rules” • Obtained by analyzing 4 anomaly based IDS • The input binary is “encoded” such that it adheres to the following rules… • Easy to encode the worm body • May be difficult to encode the “decryptor” which must consist of executable assembly instructions! • Rule 1 • The output must only consist of bytes that have non-zero frequency in normal traffic • Rule 2 • The frequency of bytes in the output must be equal or close to the bytes’ frequencies in normal traffic • Rule 3 • The output must use the bytes within the allowed range for any given offset, if possible

18. View of Blended Exploit Buffer

19. Testing The Traffic Blender Worm • Tested against 4 anomaly IDS • NETAD • PAYL distance-based Anomaly IDS • Service-specific Anomaly IDS • Abstract Payload Execution (APE) • All tested IDS were evaded using the traffic blending worm

20. Paper Strengths • Innovative and Interesting “offensive” slant for an academic paper ;) • It is refreshing to see some “good guys” capable of thinking like the “bad guys”! • Serves as an early warning and gives researchers a “head start” on detection for next generation worms!

21. Paper Weaknesses • Could have used a bit more background information • Related work should have been at the beginning of the paper! • Do polymorphic worms exist in the “wild” or are they only theoretical at this point? • Designed their worm based only upon a-priori knowledge of the heuristics used by the IDS they tested it against (a little circular here ;)

22. Future Extensions • Blind testing of their “traffic blender” against other IDS for which the exact heuristics are unknown • More representative of success of such a worm “in the wild” since it is unlikely a wild worm would have reverse engineered the heuristics of all network IDS • Further study of how “exploit invariants” affect a worm’s ability to “blend in” • Is this a significant problem for a worm in a majority of exploits? …Or is it a more isolated, theoretical problem when considered in the practical realm? • How would “traffic blending” affect the rate of worm propagation on the internet ?

23. ?