A Trustworthy Response?
Everyone--Microsoft and its customers--needs to get more serious about the virus threat.
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.
With more than fifteen years of IT experience, Don Jones is one of the world’s leading experts on the Microsoft business technology platform. He’s the author of more than 35 books, including Windows PowerShell: TFM, Windows Administrator’s Scripting Toolkit, VBScript WMI and ADSI Unleashed, PHP-Nuke Garage, Special Edition Using Commerce Server 2002, Definitive Guide to SQL Server Performance Optimization, and many more. Don is a top-rated and in-demand speaker and serves on the advisory board for TechMentor. He is an accomplished IT journalist with features and monthly columns in Microsoft TechNet Magazine, Redmond Magazine, and on Web sites such as TechTarget and MCPMag.com. Don is also a multiple-year recipient of Microsoft’s prestigious Most Valuable Professional (MVP) Award, and is the Editor-in-Chief for Realtime Publishers.