News

Learning From MyDoom

• By Mike Gunderloy
• February 2, 2004

By now every many, woman, child, and dog on the Internet knows about the MyDoom virus (currently circulating in two variants, MyDoom.A and MyDoom.B). It is, after all, difficult to ignore your Inbox filling up with messages like "Server Report" and "test" and "Hi", each with its own little attachment. As I write this, the thousands (millions?) of copies of the "A" variant that managed to install themselves are busy sending requests to SCO's Web site, which has consequently vanished from the face of the earth. Tomorrow, Microsoft.com is in for similar treatment from the "B" variant.

Now, the people who put together these worms are antisocial jerks, and it's difficult to come up with a sufficiently dire punishment for them that I can still mention on a family Web site. Despite this, if you step back and take a look at the actual code involved and how it works, there are some interesting lessons to be learned. In the spirit of finding the silver lining in any cloud, here are some of the lessons that more socially-responsible developers can take home from this incident.

Learn from your mistakes. Remember the Code Red worm in 2001? That one was supposed to launch a distributed denial of service (DDOS) attach against whitehouse.gov on a certain day, removing the President from the Internet. But the virus writer on that one made a mistake: they hard-coded the IP address of the site rather than its name. That saved one DNS lookup, but meant that the whitehouse.gov administrators could avoid the attack simply by changing their server's IP address in the DNS system. The MyDoom authors didn't make this mistake; they're going after targets by name. This may take a little longer, but it's more reliable (as SCO's experience demonstrates).

Bundle functionality together. If you've got two distinct applications that need to go to all the same users, you can cut down on setup problems by installing them together. In the case of MyDoom, the DDOS attacks are only a sideshow; the worm also opens a backdoor port on infected machines, allowing anyone to control them over the Internet. By bundling both functions into a single archive, MyDoom helps ensure their market penetration.

Know when to ignore standards. MyDoom.A uses ports 3127-3198 for backdoors; MyDoom.B uses port 1080. Many of these ports are already assigned to other applications by the Internet Assigned Numbers Authority, but the MyDoom author simply ignored that, probably reasoning that it wasn't worth the hassle to get a unique port range assigned, and that usage of these ports was light anyhow. While good developers will follow the standards processes whenever possible, sometimes you need to cut a few corners to ship on time.

Avoid dependencies. A mass-mailing worm needs access to SMTP to send itself around. But given all of the different e-mail clients out there, it can be pretty difficult to determine which SMTP server is usable by any given machine. The solution? Build SMTP right into the worm. Think carefully about the systems where your software will run, and ship a unified install that includes any dependencies you require to function.

Know your customer. And just as importantly, know who your customer is not. For example, MyDoom.A avoids sending itself to people whose e-mail address is webmaster@ or postmaster@, as well as to anti-virus companies. By targeting only the customers that it wants to reach, the virus can do a better job of spreading. The social engineering in the carrier messages (some of which resembly legitimate pieces of bounced mail) helps here as well.

Use the right tool for the job. Sure, you could probably write a fine e-mail virus using C#, but the requirement to ship a 21MB runtime would probably limit its spread. Encrypted assembly code, with its small footprint, was the right choice for MyDoom. Don't fall into the trap of trying to apply your own favorite technology to every problem.

Well, they're not the deepest development lessons in history. But part of hte job of a good developer is to stay up with the industry, and to learn from other people's code. If you'd like to investigate this particular bit of malware a bit further, here are links to analyses of MyDoom.A and MyDoom.B.