News

A Trustworthy Response?

Everyone--Microsoft and its customers--needs to get more serious about the virus threat.

• By Don Jones
• 07/30/2004

<>Analysis: Microsoft recently had another opportunity to demonstrate its Trustworthy Computing philosophy when the Download.Ject virus began infecting unpatched IIS 5.0 servers and various versions of Internet Explorer. Download.Ject is a novel virus in that it attacks along two vectors: It first infects an IIS 5.0 server using a known vulnerability (which has been patched for a while; shame on affected system administrators for not maintaining their systems). The server-side infection installs a JavaScript that redirects users to another Web server. That Web server, based in Russia, exploits the IE vulnerability to install a keystroke logger, capturing passwords and lots of other sensitive information. The IE vulnerability has to do with the ActiveX Data Objects' ADODB.Stream object, which represents a file in memory.

Microsoft's first response to Download.Ject was, in hindsight, a bit lackluster. It proudly announced, near the end of June, that it had taken down the Russian Web server. While that surely made Microsoft feel good, and immediately prevented any more infections, it didn't actually solve the problem. We know from experience with NetSky and MyDoom that Download.Ject variants were (and are) inevitable, and those variants will simply redirect users to a different Web server. Microsoft's second response, on July 2, was to issue a patch for IE, which didn't fix the problem. Instead, it essentially hacks the registry to disable the ADODB.Stream object (Knowledge Base article 870669 describes how to do it manually), defeating the vector Download.Ject uses but not fixing the vulnerability. It's all too feasible that some future Download.Ject variant could re-enable the vulnerability and continue to exploit it.

That's assuming, of course, that users bother to install the patch to begin with. They won't. We know they won't, because Download.Ject couldn't have spread if it weren't for unpatched IIS 5.0 systems to begin with. It's difficult to say how many times someone has to jump up and down on a table to attract administrators' attention to the importance of patch management. And the rhetoric about Microsoft's failure to provide comprehensive patch management tools, while true, is beginning to ring hollow: Keeping up with patches is an administrator's job. It's safe to assume that if administrators can't be bothered to patch a few Web servers, they won't be bothered to patch a few thousand Web browsers, either.

Microsoft does promise a long-term, true solution in the future. Apparently the holdup is in providing a tested, supportable patch for every extant version of IE. While I'm sure Microsoft isn't holding back on us, it's still difficult to imagine the circumstances which prevent a company with thousands of programmers from creating an effective patch more quickly. Still, perhaps it's no more difficult to imagine than a world where network administrators can't be bothered to turn on Automatic Updates for their Web servers and to subscribe to Microsoft's security bulletins.

What could Microsoft or we as an industry have done differently to prevent this potentially damaging Trojan?

First, administrators need to get on top of patch management. It's difficult to believe that the examples of Slammer and Blaster—two viruses which exploited already-patched vulnerabilities—haven't been sufficient. Clearly, administrators who haven't been hit yet think they never will be. It's a shame that they won't be goaded into doing the patch management part of their job—a job which, by the way, administrators all the way back to the mainframe days have had to deal with—until their environments are brutally hacked.

Second, Microsoft needs to get a plan, and ideally a dedicated team, in place for critical incident response. For example, the first patch Microsoft issued could have included a recommendation to block access to the IP address the server-side exploit redirected users to. It's hard to tell if that would have penetrated the ennui administrators seem to have regarding Microsoft security alerts; Microsoft's Web site has been crawling with Download.Ject warnings in the past few weeks and I'm sure there are still vulnerable IIS 5.0 servers out there.

A dedicated team might also help Microsoft issue actual patches, rather than "resiliency boosts," when difficult-to-patch problems arise. Management within Microsoft also needs to be willing to put the brakes on all future development, if necessary, to get patches out as quickly as possible. That's an incredibly difficult decision to make within any company, but the sheer number of people who are affected by any Windows-targeted attack makes it a necessary decision. It's great that Microsoft went after the Russian Web server; antivirus Web sites, however, are telling me that Download.Ject was discovered in February. Symantec provided virus definitions on June 16. As I'm writing this, nearly a month later, IE still hasn't been permanently patched.

So what's the bottom line? Everyone—Microsoft and its customers—needs to get more serious about the virus threat. It's a simple miracle that effective viruses like MyDoom, Slammer, Blaster, and Download.

Ject have caused as little damage as they have. Microsoft must continue to react quickly and decisively, and its customers must stop relying on Microsoft to "make it all better," and start taking more responsibility for the security of their own systems.