The Blaster worm is probably the best possible worm we could have hoped for that uses the DCOM exploit. The Windows DCOM vulnerability is one of the worst security holes yet discovered in Windows - it can be remotely exploited to give local root on any operating system based on windows NT. Patches for the vulnerability were (as usual) not being deployed anywhere near fast enough, especially given the severity of the problem. A well-designed worm would have spread like wildfire, infecting the majority of vulnerable machines in just a few hours, and putting them under the control of the worm's owner. MSBlast is not a well-designed worm.
Three major flaws in MSBlast have come to light so far - It was intended to DDOS windowsupdate.com, and indeed does this correctly. Unfortunately for the worm, however, windowsupdate.com is simply a redirect to windowsupdate.microsoft.com , the official location of Windows Update since its inception five years ago. Days before the DDOS was due to occur, Microsoft removed the DNS record for windowsupdate.com , leaving the worm with nothing to DDOS. Windows Update continues to work just fine at its actual URL, http://windowsupdate.microsoft.com . Had the author done his homework, the worm would have attacked the correct URL, and possibly taken down Windows Update. An outage in Windows Update would have made the DCOM patch a lot harder for home users to get hold of.
Another flaw is the way MSBlast propagates. An MSBlast infection is a two-stage process - first the DCOM bug is exploited, to get the target machine running a stub. This stub tries to connect to a previously infected machine (communicating on TCP port 4444), and if successful it downloads the worm proper using TFTP. This is a fatal design flaw, as TFTP was never intended to be used on the internet, and is blocked by default by many firewalls and routers. TFTP is mostly used by systems that use BOOTP to boot, thus any network that uses BOOTP will prevent TFTP from crossing the firewall as a basic security measure (Preventing sensitive boot data from getting out, and hostile forged data getting in). TFTP traffic is very uncommon on the internet, and a clear indication of the worm's presence. Had the worm used a common protocol, like HTTP, for both communication and downloading, it could have avoided all the firewall problems (The vast majority of firewalled machines have some way of accessing the web), and would not have been quite so obvious to intrusion detection systems. The worm's use of a fixed, distinctive port to communicate with other worms (4444/tcp), and an unusual protocol to download itself (TFTP on 69/udp), means that it is easily blocked by ISPs, greatly impeding its progress, and the usefulness of installed clients.
MSBlast's greatest flaw, however, is that it was not properly tested, and affects the stability of the system it is installed on. A well-designed worm gives the user no reason to suspect that something is amiss, until they are TOSed from their ISP. By causing the system to reboot, lock up, and fill up the system log, MSBlast quickly reveals its presence to the user. Windows NT is not Windows 9x - random rebooting is seriously unusual behaviour for NT. Once the user suspects that something is amiss, the game is usually up - if they can't remove the worm themselves, they will certainly take it to someone who can. It is very likely that after removing the worm, the system will be patched to stop it being re-infected.
Thanks to these design flaws, the Blaster worm has succeeded only in raising public awareness of the importance of keeping up-to-date with security patches, and has significantly reduced the potential impact that a well-written worm exploiting the DCOM vulnerability could have had.