Security

Tech Tip: Why MSBlast failed to take down Microsoft

By Jonathan Yarden

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 August 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. The fact is that 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, and, as an added bonus, 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 mistake. 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 difficult to stop the spread of MSBlast, because 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—Microsoft Exchange, for example. So if you're going to successfully block MSBlast, you'll need to do it on border Internet routers and then 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 there are still thousands of hosts 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 interesting solution to stop MSBlast. Sometimes there really are simple solutions to complex problems.

Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.

Editor's Picks

Free Newsletters, In your Inbox