Update (17th October 2006): Aviv posted a follow-up in his blog, with further notes on AV signatures, as well as a short note in Bugtraq. Gregg Keizer has written a short article for TechWeb, although it doesn't link to either Aviv's or this blog article. Mentions an alert being delivered by Symantec to it's DeepSight customers.
A couple weeks ago, Aviv posted to his blog about IDS/AV evasion techniques that could be applied to the Microsoft Internet Explorer VML vulnerability, describing different methods and the effect on reliability of signatures and detection mechanisms of many different antivirus engines (testing via VirusTotal). This applies to IDS and other technologies that rely on signatures for fingerprinting potential threats. Signatures are a flawed assumption: we expect everything to be fine unless it looks like what I know to be wrong. An article at "heise Security" comments about it as well. HD implemented most of the methods in the Metasploit version of the exploit, known as ie_vml_rectfill, defeating all the engines supported by VirusTotal automated scanning, likely defeating Snort and other IDS as well.
As of the need to wrap all of this techniques (and others being implemented) and provide easily accessible (and flexible) functionality for browser exploit evasion (focusing on JavaScript based exploits), a "side project" for Metasploit, named VoMM (eVade o' Matic Module), has been started. Developed and maintained by LMH from Info-pull.com and fellow Aviv Raff, it aims to provide several techniques out of the box to make browser exploits (mostly) undetectable.
The most relevant techniques being deployed:
- White-space randomization (using whitespace, tabs, etc).
- String obfuscation and encoding.
- Random comments: placement and manipulation of existing ones.
- Block randomization.
- Variables and functions names randomization.
- Integer and misc. variables obfuscation.
- Function pointer reassignment.
White-space randomization basically introduces non-intrusive (as in functionality or impact on exploit reliability) changes to the JavaScript code. Tabs, white-spaces, new lines and carriage returns (0x09 0x20 0x0a 0x0d , respectively) are added randomly, significantly affecting the structure of the binary stream.
This is effective against most signature-based engines although it leaves the strings, variables and real code unchanged. IDS can still detect it by checking for known, fixed values (for example, the name of an Active X control like RDS.DataControl and WebViewFolderIcon.WebViewFolderIcon.1). In order to avoid detection due to usage of fixed values in string variables, string obfuscation and encoding is necessary.
VoMM implements sophisticated methods for obfuscating and encoding string values. First, string values can be encoded with a simple Caesar Shift (using XOR for each character in the string).
for (i=0; i < original_string.length; ++i) {
encoded_string += String.fromCharCode(key ^ original_string.charCodeAt(i));
}Second, a decoding function is generated and then the original string value is replaced by the encoded representation plus callback to decoder.
var tar = new ActiveXObject(dec_1("&VdcWhdvGnmedsHbno/VdcWhdvGnmedsHbno/0&amp;amp;"));An important issue with the evasion techniques is that they act as a layered solution. Things like white-space randomization go after code generation, string obfuscation, etc. The main reason is that some techniques may introduce potentially detectable code, that can be covered by another method. For example, a signature could be made for fingerprinting the template decoding function. Although, white-space randomization and random comments placement plus block randomization, make it rather stealth against mostly all technologies (except complex sandboxes or similar approaches that evaluate the JavaScript itself, which could be also bypassed with HD's function pointer reassignment concept, and probably other obscure tricks).
Going back to string obfuscation, other methods that have been chosen for implementation, include 'string splitting'. The name should be self explanatory:
/* simple... */
var rand1 = 'Hello';
var rand2 = 'World';
var rand3 = rand 1 + rand2;
And a far more complex method, randomizing placement of variables as well as concatenation to build the real string: (and further splitting)
var rand4 = 'o';
var rand2 = 'Wor';
var rand1 = 'Hell';
var rand5 = rand4 + rand1;
var rand6 = 'ld';
var rand7 = rand2 + rand6;
var rand3 = rand 5 + rand6;
The last technique is word-based substitution (adding the requirement of assignment for each word and character or target string), which could add significant overhead. Although, it's still a nice experiment to work with.
Random comment placement has been mentioned earlier in this rather long article. It's simply about adding JavaScript comments at random locations without conflicting with the existing code. Also randomizing existing comments contents, probably using a word list instead of just alphanumeric sequences (thus less likely detectable, this has been pointed out by Aviv several times). Random line endings and many other nice tricks could be done. Actually, comments can be placed arbitrarily all over the code without conflicting with it's functionality:
/* comment placement randomization */
function /* random */ myfunc/*random*/(/*random*/)/*random*/ {
/*random*/alert/*random*/(/*random*/''/*random*/)/*random*/;
/*random*/} /*random*/ myfunc/*random*/(/*random*/)/*random*/;
The next technique is probably one of the most sophisticated concepts so far. It's implementation is fairly complex and still being worked on. Block randomization involves changing loops, if statements and any other possible code block randomly. Let's see how it works:
- Different kinds of loops provide the same functionality.
Thus, imagine we use a for loop in our payload. VoMM could transform it to a while loop without impacting the functionality.
var i = 0;
for (i = 0; i < 10; i++) { /* for loop */ }
while (i < 10) { i++; /* while loop */ }
do { i++; /* do..while loop */ } while (i < 10)The problem in the deployment of this concept is the complexity of parsing the payload code and transform the code blocks properly, as well as the types of code blocks that can be transformed and the manipulation possibilities. A similar effect on if statements would be changing order of checks, nesting, etc.
The next concept is variables and functions names randomization, a fundamental part as it covers the evasion for internal payload function callbacks and variables, closing the first evasion layer altogether with the variable values obfuscation techniques (ex. string encoding, integer factorization). VoMM currently uses a word list for taking random words instead of alphanumeric sequences which could be more likely detected (most probably depending if size is fixed or random).
var steep = unescape("%u0505%u0505");
steep = rubbish(steep,gaithersburg);
var badland = (conferring - 0x400000)/leviticus;
(...)
function rubbish(steep, gaithersburg) {
Simple yet powerful. Another concept that has been mentioned is integer and general variables obfuscation. Memory addresses, sizes, etc; are declared using JavaScript as hexadecimal integers. For example, this is mandatory for exploits written for stack and heap based buffer overflows.
var heapSprayToAddress = 0x05050505;
These values are hot spots for IDS and AV signatures. It's common practice that NOP sleds and widely used payloads get in their signatures before anything else. In other words, these values must be obfuscated someway. Currently we have different methods for successful obfuscation:
- XOR:
0xdead ^ 0xbabe = 0x6413 ^ 0xbabe = 0xdead - Factorization:
0xdead = 57005 = 5 * 13 * 877
irb(main):161:0> zerofactor = Factorization.new(my_test.scan(/[0][x][0-9a-fA-F]+/)[0].hex)
irb(main):162:0> zerofactor.factors
=> [[2, 23]]
irb(main):163:0> zerofactor.to_s
=> "2^23 (8388608)"
- Addition:
0xdead + 0xbeef = 0x19d9c - 0xbeef = 0xdead - Division:
0x50505050 / 5 = 0x10101010 * 5 = 0x50505050 - Subtraction:
0xdead - 0xbabe = 0x23ef + 0xbabe = 0xdead
Once the values have been calculated, the old variable value should be replaced with the proper obfuscated version, and it's different values, placed in random locations, in the same line or in the line before calculation.
var n1 = 0x10101010;
var n2 = 0x5;
var heapSprayToAddress = n1 * n2;
Finally, function pointer reassignment, as suggested by HD. It defeats signatures and probably some rather weak sandbox software, but overall serves as a way to alter the code without limits, and again, without affecting the exploit reliability. Basically, pointers to functions are defined and placed around the code, and used instead of calling the real function ("masking"):
var un = unescape;
var payLoadCode = un("%u9090%u9090");
var dw = document.write;
dw('VoMM');
These are the most important features and details of VoMM, and hopefully will give an idea of where the project is going. Still under active development, it will take some time until stable release date. The goal is state of the art evasion for browser exploits, integrated with Metasploit, fully backwards compatible and with no configuration needed.
VoMM will parse the JavaScript code and perform the necessary evasion techniques, without need of interaction. Not even markers, helpers or comments in your code. Give it plain static JS without any type of obfuscation nor evasion technique and VoMM will turn it into a mostly undetectable, stealth exploit.
Right now there's nothing similar out there and most of the concepts aren't well known (or there's no previous work nor information about them).
Feedback is always welcome, donations too and of course code and contributions (although project is not yet open to the public, including it's Wiki and current sources tree).
Thanks for reading.
