On Monday I formally joined the Tor project and it certainly has been an interesting week. Yesterday, on both the Tor internal and public mailing lists, we received several reports of spam emails advertising Tor. Of course, this wasn’t anything to do with the Tor project and the included link was to an IP address (it varied across emails). On visiting this webpage (below), the user was invited to download tor.exe which was not Tor, but instead a trojan which if run would recruit a computer into the Storm (aka Peacomm and Nuwar) botnet, now believed to be the worlds largest supercomputer.

Ben Laurie, amongst others, has pointed out that this attack shows that Tor must have a good reputation for it to be considered worthwhile to impersonate. So while dealing with this incident has been tedious, it could be considered a milestone in Tor’s progress. It has also generated some publicity on a few blogs. Tor has long promoted procedures for verifying the authenticity of downloads, and this attack justifies the need for such diligence.

One good piece of advice, often mentioned in relation to the Storm botnet, is that recipients of spam email should not click on the link. This is because there is malicious Javascript embedded in the webpage, intended to exploit web-browser vulnerabilities to install the trojan without the user even having to click on the download link. What I did not find much discussion of is how the exploit code actually worked.

Notably, the malware distribution site will send you different Javascript depending on the user-agent string sent by the browser. Some get Javascript tailored for vulnerabilities in that browser/OS combination while the rest just get the plain social-engineering text with a link to the trojan. I took a selection of popular user-agent strings, and investigated what I got back on sending them to one of the malware sites.

The Javascript is lightly obfuscated, by xoring it with a constant value, which is included in the webpage. This value changes over time, perhaps to make it harder to build signatures for detecting the malicious code. After decoding I found three different variants. One for Internet Explorer v3–7, one for Firefox v2/Opera v7 and a final one specifically for Internet Explorer 5 on Windows 2000. Web crawlers, wget/curl, Safari, Netscape and Konqueror were not sent any Javascript, nor were Opera v8–9 or Firefox v0.8–1.5.

The Firefox attack exploits a buffer overflow in the Windows Media Player Plug-in (described in Microsoft Security Bulletin MS06-006) and the exploit code appears to be based on a proof of concept written by Matthew Murphy. It works by overflowing the SRC attribute of an <EMBED> element, and causing it to invoke the Media Player plugin.

In contrast, the Internet Explorer exploit is far more sophisticated (9KB vs 3KB), which seems predictable given the larger market share. The Javascript exploits a wide variety of vulnerabilities, including ones in WinZip, Apple QuickTime and the WebViewFolderIcon, ADODB.Stream and Shell.Application IE features.

The origin of this code is unclear, but Christian Seifert et al of the Honeynet project have written a comprehensive analysis of a similar, if not identical, exploit. The IE5/Windows 2000 variant does all of the above but also tries a variant of H D Moore’s Microsoft Management Console exploit (more details are in Microsoft Security Bulletin MS06-044)

One strange phenomena I noticed is that occasionally the page returned will be inconsistent to the type expected. Sometimes it will just be a no-Javascript page, and other times it will be Javascript for a different platform. I don’t have a convincing theory to explain this, but one hypothesis is that the web server is a proxy, and under high-load it returns a cached result.

I also noted that the anti-virus vendor Kaspersky Lab appears to have angered the botnet owners. The two IE exploit Javascript segments include a spurious function kaspersky(suck,dick){}; function kaspersky2(suck_dick,again){}. Quite what Kaspersky have done to deserve this treatment I do not know. Perhaps they have been particularly effective at removing Storm infections. Such hidden messages have become fairly common, insulting either anti-virus vendors or competing malware authors.

A final observation I made is that the URLs in the spam advertising Tor now show a fake YouTube video page. It is clear that the people behind the botnet are continually refining their tactics (even the text about codec downloads only appeared in a later variant). Does this mean that the Tor spoofing strategy didn’t work well, so was canceled, or did we see an initial experiment which is a taste of things to come?

Update: 2007-09-09
Storm has switched strategies yet again, and now fakes a NFL game tracker site. Interestingly, this site no longer returns any malicious Javascript, for any of the user-agent strings I tried (a fact also noted by F-Secure).

Regarding the origin of the malicious Javascript, Aviv Raff from Finjan reports that the exploits are from the MPack kit.