News regarding the VML exploit is flying around and reports from the security community indicate that exploit distribution is on the rise and infections are only getting worse as the world waits for October 10th. Meanwhile, we thought we'd offer our readers an example scenario of what can happen as a result of exploits like this. This one is fairly bad, but with arbitrary code execution things could certainly get worse.
Our story today starts with a visit to an IP owned by California company InterCage, Inc. InterCage has hosted cutting-edge exploits in the past (they were hosting such a prolific number of WMF exploits early this year that there were calls for IT departments to simply block every IP owned by InterCage), and Microsoft identified the /yes/agent.html file on the server at this InterCage IP as a distribution point for VML exploit code.
When IE loads this file, a javascript function selects one of three possible HTML files to load in an iframe. Based on comments in the script, it appears to have been modified from a banner ad rotation script. Which HTML file it returns depends on the user's operating system (based on the user agent string), and attempts to connect on an XP Professional system have consistently returned an iframe pointing to the same file (named YesXP.html).
Each of the three files contains code to exploit the VML vulnerability and run an executable with the rights of current user. They differ only in the data used to overflow the buffer and the string appended to the end of the data.
YesXP.html worked its magic on the buffer, and soon enough my system was infected. Because of the buffer overflow an executable named Yes.exe is launched, which quickly downloads and installs a variant of the UrSnif trojan. This is a nasty thing to have on your system, as you'll see in a moment.
When it loads up, the initial file (bend.exe) drops a device driver from within its data section. This file (hide_evr2.sys) hooks/patches the service descriptor table and intercepts calls to zwQueryDirectoryFile, zwEnumerateValueKey, and zwQuerySystemInformation. The driver then uses them to hide the existence of its files and its service from programs such as the services dialog, task manager, command line directory listing, and windows explorer. From this point on, an average end user will have no idea that the trojan is even running on their system.
bend.exe also copies itself into the windows directory under the name 9129837.exe (The name would seem random, but is quite fixed - and is in fact a recognizable feature of the UrSnif trojan), and creates the service '!!!!' which loads the hide_evr2.sys driver file. The trojan then sets itself up to run automatically every time the computer starts up with a simple registry entry in the run key referencing 9129837.exe.
Now that the trojan is hidden and entrenched, it can settle in to its day to day operation. This consists of injecting code into other processes via remote threads and write_proc_mem, allowing it to subvert other, usually good, programs running on your system into acting on its behalf.
We have also noted it opening the system certificate store and exporting copies of the user’s security certificates in PFX format. As one researcher put it, there's "something phishy" going on here. Depending on the issuing authority and server configuration, getting their hands on your security certificates (private ones in particular) could allow someone to impersonate you while connecting to certain secure servers and web sites. These useful certificates will probably be a rarity among the public, but the authors of UrSnif seem to have taken more of a trawler approach to phishing.
But it doesn't stop there. 9129837.exe contains code to sniff network traffic, monitoring all your FTP, POP3, IMAP, and ICQ traffic. This traffic is combed for logins and passwords, which are encrypted for transport using crypt32.dll - the Windows Cryptography API. This won't catch bank passwords, but it will allow whoever receives the information to read and send email from your non-webmail accounts (connecting to Yahoo via IMAP or POP3 doesn't count as webmail - at least as far as UrSnif is concerned).
This brings us to one of the more intriguing actions taken by UrSnif. 9129837.exe begins sending out rapid-fire HTTP GET requests to 81.95.147.107. These come at intervals between 4 and 12 seconds, and keep right on going as long as you care to watch them. 81.95.147.107 is owned by an organization known as the Russian Business Network, located in St. Petersburg. My first thought was that my computer was now welcoming a host of new malware with arms wide open, as fast as 9129837.exe could download it. When I looked at the packet capture and the files being created, however, I realized something else was going on.
The requests were for /cgi-bin/options.cgi, and they passed a numeric user_id variable, numeric version_id variable, and a hard-coded lower-case alphabetic passphrase as GET parameters. The response was always the same. 7,160 Bytes - non-executable - but with partially-formed HTML tags protruding from the content. Every one is carefully stored by 9129837.exe in a sequentially numbered file (options[1], options[2], and so on). Every commercial scanner I ran on the files came back with a clean report, but there is still something a bit ominous in the regular, methodical capture and storage of each response from the Russian Business Network. Either this is the result of a bug (which are not uncommon in trojans), or this is a very interesting way of communicating with its home server, and it's just waiting for the response to change.
Now this is just one scenario...the exploit allows any program whatsoever to be run on a targeted system. We are in the process of analyzing the malware dropped across a broad range of sites which are serving up VML exploits, and as soon as the numbers are ready we'll put up the broader picture of how many people are facing attacks like this, and how many are facing other types.
P.S. In case anyone stumbles across what may be the same pages hosted elsewhere, or just wants to determine if the precise scenario outlined above just happened to them, here are the md5 hashes of some of the files involved.
Yes2003.html
MD5: 7d3d747e1e18214f91797093629b31d3
YesXP.html
MD5: efa3264f7d04215372b6e7d2afae0ee2
Yes2006b.html
MD5: dd6ed92c123924f6fa4aca3dd3abf97b
Yes.exe
MD5: 5a3018337f1da0de556927cf2a95c4e2
options[1]
MD5: b9d351c269a2095c288272ac3bd53df4
bend.exe/9129837.exe
MD5: 9bc1a64c39b7122bdb7b29eaed0cf00e
hide_evr2.sys
MD5: c643e06d53f23addcb16fbaddf980465