The result was that in instances where the team had phone contact details for managers, the information was often outdated.

'No, he used to work here, but he left over a year ago.'

'No, we don't have a telephone tree of people to ring if something goes wrong with our computers. There are a whole bunch of people in different places here who handle the computers.'

This is what John often heard at the other end of the phone.

The network had grown into a rambling hodgepodge for which there was little central coordination. Worse, a number of computers at different NASA centres across the US had just been tacked onto SPAN without telling the main office at G.o.ddard. People were calling up the ad-hoc crisis centre from computer nodes on the network which didn't even have names. These people had been practising a philosophy known in computer security circles as 'security through obscurity'. They figured that if no-one knew their computer system existed--if it didn't have a name, if it wasn't on any list or map of the SPAN network--then it would be protected from hackers and other computer enemies.

McMahon handled a number of phone calls from system managers saying, 'There is something strange happening in my system here'. John's most basic question was, 'Where is "here"?' And of course if the SPAN office didn't know those computer systems existed, it was a lot harder to warn their managers about the worm. Or tell them how to protect themselves. Or give them a worm-killing program once it was developed.

Or help them seal up breached accounts which the worm was feeding back to its creator.

It was such a mess. At times, McMahon sat back and considered who might have created this worm. The thing almost looked as though it had been released before it was finished. Its author or authors seemed to have a good collection of interesting ideas about how to solve problems, but they were never properly completed. The worm included a routine for modifying its attack strategy, but the thing was never fully developed. The worm's code didn't have enough error handling in it to ensure the creature's survival for long periods of time. And the worm didn't send the addresses of the accounts it had successfully breached back to the mailbox along with the pa.s.sword and account name.

That was really weird. What use was a pa.s.sword and account name without knowing what computer system to use it on?

On the other hand, maybe the creator had done this deliberately. Maybe he had wanted to show the world just how many computers the worm could successfully penetrate. The worm's mail-back program would do this.

However, including the address of each infected site would have made the admins' jobs easier. They could simply have used the GEMPAK collection as a hitlist of infected sites which needed to be de-wormed. The possible theories were endless.

There were some points of brilliance in the worm, some things that McMahon had never considered, which was impressive since he knew a lot about how to break into VMS computers. There was also considerable creativity, but there wasn't any consistency. After the worm incident, various computer security experts would hypothesise that the w.a.n.k worm had in fact been written by more than one person. But McMahon maintained his view that it was the work of a single hacker.

It was as if the creator of the worm started to pursue an idea and then got sidetracked or interrupted. Suddenly he just stopped writing code to implement that idea and started down another path, never again to reach the end. The thing had a schizophrenic structure. It was all over the place.

McMahon wondered if the author had done this on purpose, to make it harder to figure out exactly what the worm was capable of doing.

Perhaps, he thought, the code had once been nice and linear and it all made sense. Then the author chopped it to pieces, moved the middle to the top, the top to the bottom, scrambled up the chunks and strung them all together with a bunch of 'GO TO' commands. Maybe the hacker who wrote the worm was in fact a very elegant DCL programmer who wanted the worm to be chaotic in order to protect it. Security through obscurity.

Oberman maintained a different view. He believed the programming style varied so much in different parts that it had to be the product of a number of people. He knew that when computer programmers write code they don't make lots of odd little changes in style for no particular reason.

Kevin Oberman and John McMahon bounced ideas off one another. Both had developed their own a.n.a.lyses. Oberman also brought Mark Kaletka, who managed internal networking at Fermilab, one of HEPNET's largest sites, into the cross-checking process. The worm had a number of serious vulnerabilities, but the problem was finding one, and quickly, which could be used to wipe it out with minimum impact on the besieged computers.

Whenever a VMS machine starts up an activity, the computer gives it a unique process name. When the worm burrowed into a computer site, one of the first things it did was check that another copy of itself was not already running on that computer. It did this by checking for its own process names. The worm's processes were all called NETW_ followed by a random, four-digit number. If the incoming worm found this process name, it a.s.sumed another copy of itself was already running on the computer, so it destroyed itself.

The answer seemed to be a decoy duck. Write a program which pretended to be the worm and install it across all of NASA's vulnerable computers. The first anti-w.a.n.k program did just that. It quietly sat on the SPAN computers all day long, posing as a NETW_ process, faking out any real version of the w.a.n.k worm which should come along.

Oberman completed an anti-w.a.n.k program first and ran it by McMahon. It worked well, but McMahon noticed one large flaw. Oberman's program checked for the NETW_ process name, but it a.s.sumed that the worm was running under the SYSTEM group. In most cases, this was true, but it didn't have to be. If the worm was running in another group, Oberman's program would be useless. When McMahon pointed out the flaw, Oberman thought, G.o.d, how did I miss that?

McMahon worked up his own version of an anti-w.a.n.k program, based on Oberman's program, in preparation for releasing it to NASA.

At the same time, Oberman revised his anti-w.a.n.k program for DOE. By Monday night US Eastern Standard Time, Oberman was able to send out an early copy of a vaccine designed to protect computers which hadn't been infected yet, along with an electronic warning about the worm.

His first electronic warning, distributed by CIAC, said in part:

THE COMPUTER INCIDENT ADVISORY CAPABILITY C I A C

ADVISORY NOTICE

The W.COM Worm affecting VAX VMS Systems

October 16, 1989 18:37 PSTNumber A-2

This is a mean bug to kill and could have done a lot of damage.

Since it notifies (by mail) someone of each successful penetration and leaves a trapdoor (the FIELD account), just killing the bug is not adequate. You must go in and make sure all accounts have pa.s.swords and that the pa.s.swords are not the same as the account name.

R. Kevin Oberman

Advisory Notice

A worm is attacking NASA's SPAN network via VAX/VMS systems connected to DECnet. It is unclear if the spread of the worm has been checked.

It may spread to other systems such as DOE's HEPNET within a few days.

VMS system managers should prepare now.

The worm targets VMS machines, and can only be propagated via DECnet.

The worm exploits two features of DECnet/VMS in order to propagate itself. The first is the default DECnet account, which is a facility for users who don't have a specific login ID for a machine to have some degree of anonymous access. It uses the default DECnet account to copy itself to a machine, and then uses the 'TASK 0' feature of DECnet to invoke the remote copy. It has several other features including a brute force attack.

Once the worm has successfully penetrated your system it will infect .COM files and create new security vulnerabilities. It then seems to broadcast these vulnerabilities to the outside world. It may also damage files as well, either unintentionally or otherwise.

An a.n.a.lysis of the worm appears below and is provided by R. Kevin Oberman of Lawrence Livermore National Laboratory. Included with the a.n.a.lysis is a DCL program that will block the current version of the worm. At least two versions of this worm exist and more may be created. This program should give you enough time to close up obvious security holes. A more thorough DCL program is being written.

If your site could be affected please call CIAC for more details...

Report on the W.COM worm.

R. Kevin Oberman

Engineering Department

Lawrence Livermore National Laboratory

October 16, 1989

The following describes the action of the W.COM worm (currently based on the examination of the first two incarnations). The replication technique causes the code to be modified slightly which indicates the source of the attack and learned information.

All a.n.a.lysis was done with more haste than I care for, but I believe I have all of the basic facts correct. First a description of the program:

1. The program a.s.sures that it is working in a directory to which the owner (itself) has full access (Read, Write, Execute, and Delete).

2. The program checks to see if another copy is still running. It looks for a process with the first 5 characters of 'NETW_'. If such is found, it deletes itself (the file) and stops its process.

NOTE

A quick check for infection is to look for a process name starting with 'NETW_'. This may be done with a SHOW PROCESS command.

3. The program then changes the default DECNET account pa.s.sword to a random string of at least 12 characters.

4. Information on the pa.s.sword used to access the system is mailed to the user GEMTOP on SPAN node 6.59. Some versions may have a different address.11

5. The process changes its name to 'NETW_' followed by a random number.

6. It then checks to see if it has SYSNAM priv. If so, it defines the system announcement message to be the banner in the program: