Security

Why did MSBlast fail to take down Microsoft?

The main purpose of the MSBlast worm was to make infected machines launch a denial of service on Microsoft's Windows Update site. But even though this attack was ultimately unsuccessful, it could still lead to future attacks.


I'd like to say that most identified worms will eventually go away. But from what I've seen, once released onto the Internet, worms continue to infect new hosts. I still see a great deal of older worm signatures hanging out on the Internet, including SQL Slapper and Nimda. I'm sure that MSBlast and its variations will be eating away at Internet traffic for a long time.

Like clockwork, most worms are released after a known vulnerability is announced. MSBlast, like most other worms, came shortly after the announcement of a DCOM Remote Procedure Call (RPC) vulnerability in Windows NT, 2000, and XP systems. MSBlast does the typical things worms today do: It scans for IP addresses and then infects the vulnerable machines that it finds.

On Aug. 16, MSBlast began flooding Windowsupdate.com with a denial of service attack. One important difference between MSBlast and previous worms is that MSBlast uses DNS. This minor enhancement means that simply changing the IP address for Windowsupdate.com wasn't sufficient to keep it from being targeted.

The good news was that MSBlast didn't hurt Microsoft because it didn't have the correct hostname for the Windows Update Web site. In fact, MSBlast was programmed to attack the wrong Web site.

The Windows Update Web site is Windowsupdate.microsoft.com, not Windowsupdate.com. Microsoft had been redirecting HTTP requests from Windowsupdate.com to the correct location but wisely stopped this. As an added bonus, it removed DNS for this entirely so the MSBlast worm wouldn't issue requests and clog up Internet traffic. The result was that MSBlast basically did nothing to affect Microsoft, except perhaps infect new machines and generally cause headaches for network and system administrators worldwide.

We'll probably never know whether the authors of MSBlast intended to have their worm thwarted like this, but I find it difficult to believe this was a mistake. Anyone who's clever enough to release a worm onto the Internet isn't likely to make such a ridiculous error. And you can be sure the next worm from whoever wrote this one isn't going to be easily sidestepped.

The use of DNS in worms makes them considerably more difficult to deal with. That's why it's tough to stop the spread of MSBlast—you can't simply block a TCP and UDP port without considering how it affects legitimate services. For example, blocking TCP port 135 on routers will stop MSBlast but also other software that makes use of the DCOM service, such as Microsoft Exchange. If you're going to successfully block MSBlast, you'll need to do it on border Internet routers and accept that some of your Microsoft products are not going to work across the Internet.

So this time, a worm failed to live up to its hype. However, don't be too sure it won't be worse the next time. Remember that thousands of hosts are still infected with MSBlast, scanning like mad to infect other machines.

But it was an interesting week. Who could have expected that a worm (Nachi) would be released that disables MSBlast and tries to fix vulnerable machines? For now, MSBlast has not made much of a dent at Microsoft or caused too many problems for the Internet. And although the Nachi worm isn't exactly what I would call a "success," it's an intriguing solution for stopping MSBlast. Sometimes, there really are simple solutions to complex problems.

This article was originally published in the Internet Security Focus e-newsletter.

Editor's Picks

Free Newsletters, In your Inbox