In 2011, this exploit kit won't work

And some Web sites will be a lot safer! While reviewing incidents and deobfuscating a Web site today, I discovered an installation of a particular exploit kit that won't work after New Year's Eve.  The site I found caught my attention because the code simply looks like garbage.  As the saying goes, "One man's trash is another man's treasure."  So I started digging into the obfuscation of the code and found something that I thought would be topical considering today's date.  The code in this exploit kit will actually expire at midnight on New Year's Eve local time!  In this post, I'll cover how I came across this and show you how and why the exploit kit installations will expire. 

Here is a screen shot of the code in the original state as I found it:

You may notice right off the bat that there is a Java exploit in there, but the focus of this post is in the obfuscated script that is meant to exploit the client browser.  If you have read any of my previous blog posts, you know that I tend to zero in on long streams of data in an obfuscated script.  More often than not, that is where the multiple exploits of an obfuscated script live, and also usually where the deobfuscation routine can be found.  So let's have a look at that part of the script and beautify it a bit so that we can see more clearly what is going on.

Here is a screen shot of the part we want to focus on:

The attack script is obfuscated in the var w declaration above.  We can see that variable holds a long string of digits. We can also see that there is a masked String.fromCharCode a little further down in the script.  Right away, we might assume that this is a simple character code obfuscation, but with numbers like 1001, 1361, 426..., this assumption would be incorrect.  Just looking at the script for a bit, we can see what is going on for the deobfuscation.  A loop is usingString.fromCharCode to generate characters from the difference between the latter half of w and the first half of w.  However, this is not the focus, and the funny part, of this blog posting.  

When you look at the above script, you can see that the Date() object is used to get the current date from the client JavaScript engine.  Later, we see that the object iilq, which is where the date is assigned, uses the getFullYear() method and subtracts 1 from the current year.  Up until December 31, 2010 11:59:59 local time, this resutl will be 2009.  At this point, var qgy looks like e2009al, so we can see that this variable is meant to be a masked eval.  To be used as an eval, this variable has to be unmasked, which is done in the following statement of .replace("2009","v").  The whole execution of the attack script depends on this eval. So what happens in 2011?  The varable will remain a masked eval (which will look like e2010al) because the following .replace will not work, which in turn renders the script benign! 

Here is what the attack script will look like until December 31, 2010 11:59:59:

In conclusion, we can only assume that this was an unintended mistake by the exploit kit writers and that it will probably be fixed.  However, I'm sure they were unaware of this mistake, as the obfuscation of their attacks is probably contracted out, or they use off-the-shelf software to obfuscate their kits.  Come New Year's Day, we will all be just a little safer out on the Web because of this!  Happy New Year all!!