Microsoft's JScript is a very powerful and flexible language.However, great flexibility leads to a great potential for obfuscation.We have seen many examples of JScript obfuscation in the past, such asstring concatenation and dynamic decoding, and will likely see more inthe future.
The most recent and a potentially problematic example uses one ofthe simplest obfuscation methods: Unicode escaping. Normally, Unicodeescaping is used to send Unicode characters that might not travel wellacross networks, such as characters that could be transformed accordingto the system locale. From a security perspective, Unicode escaping iswidely used to deliver executable code in Web exploits.
What was previously unknown to us is that Unicode escapes can beapplied to function names, variables, and all kinds of other code. Thiswas demonstrated by the recent virus that we detect as JS.Bicycle.As the virus author noted in a post to a Virus eXchange (VX) site,there are some limitations: statements, operators, braces, parentheses,and numbers cannot be encoded. Although it is still very effective,these exceptions made the first variant easy to detect.
Unfortunately, it seems that the author found a way to "improve" thecode. By moving the body of the virus into an "eval()" statement, theentire block—including the "eval" itself—can be replaced by Unicodeescapes. Fortunately, we found a way to detect that, too.
A good script tokenizer is obviously necessary for an anti-malwareengine, as it's the best way to detect this type of virus. Such anengine can automatically perform decoding (including Unicode escaping)"under the covers," leaving us with a plaintext version of the viruscode every time.
Having such an engine is especially important now, as script-basedmalware in web-based exploits will never go away, and we can reallyshow our skills when we detect complex viruses quickly.
I have no doubt that a variety of obfuscations will be found in the future.