The ECN No Name Newsletter is no longer being published. This is an archived issue.
[previous article] [next article]As many of you may know by now, a computer virus was released on the ARPAnet during the first week of November. This program infected most machines on the ARPAnet running Berkeley UNIX as we do here at the ECN. The program caused no damage or loss of data. It did however, consume a large amount of computer resources as it reproduced itself and consumed untold amounts of time on the part of the people working to contain and stop it. At ECN the impact of the virus was slight. Having been warned by the staff of PUCC, the ECN staff was able to stop the virus after appearing on just 25 of our more then 350 machines. At other locations it was far worse.
This program is more correctly identified as a worm rather than a virus. Worms use their hosts to reproduce without modification to the host, which is what this program did. The mechanism this worm used to reproduce was quite interesting. It took advantage of a bug in the transport mechanism used to move electronic mail between machines on a network and a bug in the program which answers requests generated by the finger command.
Once in contact with the target machine, the worm installed a helper program on the target machine. The helper allowed the worm to copy the main portion of itself over to the target machine. Once on the target machine, the worm built a new copy of itself. It then set about reading various network files on the target machine to see where it could go next. It then proceeded to try and guess at user's passwords in hopes of being able to use a user's account to further propagate itself.
The same high speed networking which made this worm possible enabled the ECN staff and others around the country to quickly combat the problem. At the ECN we made use of automated software installation tools to install new versions of the affected software quickly on all of our machines. With similar tools we were able to hunt for the worm and eliminate it on all of our infected machines in about 2 hours. While we worked here, other computing organizations around the country swapped, via electronic mail, information and suggested fixes for the bugs the worm used. With all this help, we were able to secure our machines and reconnect to the ARPAnet by noon on Thursday, after first sighting the worm at about eight that morning.
The major effect the worm had on ECN users was the additional load created on the machines it infected and the loss of our connections to the rest of campus and the ARPAnet for most of the day on Thursday. No files were damaged and no system shutdowns were needed. Compared to some other sites, we were lucky.
This incident brings up some tough questions:
Q: Are the ECN's UNIX systems safe from another worm?
A: Probably not. Although the ECN staff strives to make our systems as secure as possible, total security can only be achieved by locking our machines in vaults and not networking them at all. Bugs such as those used by this worm are very tough to spot. The bugs used had been around for years in some cases but were only noted after the worm used them.
UNIX developers and the ECN staff are looking anew at the network services we provide in search of other bugs which could be used by a worm. It will be tougher for the next worm to get in.
Q: What steps is the ECN staff taking to insure the lowest possible risk?
A: The ECN staff has kept in contact with the developers of Berkeley UNIX and those who have been researching this particular worm. We have already installed new versions of the affected software and are looking at other modifications to improve the security of our network.
This is similar to adding a deadbolt to the door of your house. It will greatly reduce the risk of someone breaking in, but it will not remove that risk completely.
Q: What can I do to help lower the risk?
A: Two things would help quite a bit: First, this worm program tried to break into user accounts by guessing at passwords. It used the information it could find out about a given user, such as name or office phone number, plus a list of common passwords and the words in the on-line dictionary the spell command uses. Armed with these it was able to guess as many as 30 to 40 passwords per machine!
A simple password is as good as leaving your house unlocked.
Fortunately, password breaking methods such as these can be combatted by changing your password often and using a tough to guess password. Try making a password out of two words (eg. shortcat), use weird capitalization (eg. bIgdOg) or better still the first letter of each word in a phrase (eg. Dykwtii = Do You Know What Time It Is). NEVER use any information about yourself which is easily obtained (ie. phone number, spouse's name, etc.) And don't use any of the example passwords shown here! The folks who write the next worm will surely check for examples such as these.
A second item you can address is your .rhosts file. Once the worm guessed a password it used the user's .rhosts file to see where else it could go. The .rhosts file is both a blessing and a curse. Keep in mind that a worm which has broken into your account will be able to get to the machines you place in your .rhosts file just as easily as you can. Our advise is to keep your .rhosts file short. List only the machines you use most often.
With some help from you, the ECN user, we can improve the security of the ECN network and make it a tough place for worms and other vermin to inhabit.
HTML