NASA buzzed with the excitement of a launch. Galileo was finally going
to Jupiter.

Administrators and scientists in the world's most prestigious space
agency had spent years trying to get the unmanned probe into space.
Now, on Tuesday, 17 October, if all went well, the five astronauts in
the Atlantis space shuttle would blast off from the Kennedy Space
Center at Cape Canaveral, Florida, with Galileo in tow. On the team's
fifth orbit, as the shuttle floated 295 kilometres above the Gulf of
Mexico, the crew would liberate the three-tonne space probe.

An hour later, as Galileo skated safely away from the shuttle, the
probe's 32500 pound booster system would fire up and NASA staff would
watch this exquisite piece of human ingenuity embark on a six-year
mission to the largest planet in the solar system. Galileo would take
a necessarily circuitous route, flying by Venus once and Earth twice
in a gravitational slingshot effort to get up enough momentum to reach
Jupiter.2

NASA's finest minds had wrestled for years with the problem of exactly
how to get the probe across the solar system. Solar power was one
option. But if Jupiter was a long way from Earth, it was even further
from the Sun--778.3 million kilometres to be exact. Galileo would need
ridiculously large solar panels to generate enough power for its
instruments at such a distance from the Sun. In the end, NASA's
engineers decided on a tried if not true earthly energy source:
nuclear power.

Nuclear power was perfect for space, a giant void free of human life
which could play host to a bit of radioactive plutonium 238 dioxide.
The plutonium was compact for the amount of energy it gave off--and it
lasted a long time. It seemed logical enough. Pop just under 24
kilograms of plutonium in a lead box, let it heat up through its own
decay, generate electricity for the probe's instruments, and presto!
Galileo would be on its way to investigate Jupiter.

American anti-nuclear activists didn't quite see it that way. They
figured what goes up might come down. And they didn't much like the idea
of plutonium rain. NASA assured them Galileo's power pack was quite
safe. The agency spent about $50 million on tests which supposedly
proved the probe's generators were very safe. They would survive intact
in the face of any number of terrible explosions, mishaps and
accidents. NASA told journalists that the odds of a plutonium release
due to `inadvertent atmospheric re-entry' were 1 in 2 million. The
likelihood of a plutonium radiation leak as a result of a launch
disaster was a reassuring 1 in 2700.

The activists weren't having a bar of it. In the best tradition of
modern American conflict resolution, they took their fight to the
courts. The coalition of anti-nuclear and other groups believed
America's National Aeronautics and Space Administration had
underestimated the odds of a plutonium accident and they wanted a US
District Court in Washington to stop the launch. The injunction
application went in, and the stakes went up. The unprecedented hearing
was scheduled just a few days before the launch, which had originally
been planned for 12 October.

For weeks, the protesters had been out in force, demonstrating and
seizing media attention. Things had become very heated. On Saturday, 7
October, sign-wielding activists fitted themselves out with gas masks
and walked around on street corners in nearby Cape Canaveral in
protest. At 8 a.m. on Monday, 9 October, NASA started the countdown
for the Thursday blast-off. But as Atlantis's clock began ticking
toward take-off, activists from the Florida Coalition for Peace and
Justice demonstrated at the centre's tourist complex.

That these protests had already taken some of the shine off NASA's bold
space mission was the least of the agency's worries. The real headache
was that the Florida Coalition told the media it would `put people on
the launchpad in a non-violent protest'.3 The coalition's director,
Bruce Gagnon, put the threat in folksy terms, portraying the protesters
as the little people rebelling against a big bad government
agency. President Jeremy Rivkin of the Foundation on Economic Trends,
another protest group, also drove a wedge between `the people' and
`NASA's people'. He told UPI, `The astronauts volunteered for this
mission. Those around the world who may be the victims of radiation
contamination have not volunteered.'4

But the protesters weren't the only people working the media. NASA
knew how to handle the press. They simply rolled out their
superstars--the astronauts themselves. These men and women were, after
all, frontier heroes who dared to venture into cold, dark space on
behalf of all humanity. Atlantis commander Donald Williams didn't hit
out at the protesters in a blunt fashion, he just damned them from an
aloof distance. `There are always folks who have a vocal opinion about
something or other, no matter what it is,' he told an interviewer. `On
the other hand, it's easy to carry a sign. It's not so easy to go
forth and do something worthwhile.'5

NASA had another trump card in the families of the heroes. Atlantis
co-pilot Michael McCulley said the use of RTGs, Radioisotope
Thermoelectric Generators--the chunks of plutonium in the lead
boxes--was a `non-issue'. So much so, in fact, that he planned to have
his loved ones at the Space Center when Atlantis took off.

Maybe the astronauts were nutty risk-takers, as the protesters
implied, but a hero would never put his family in danger. Besides the
Vice-President of the United States, Dan Quayle, also planned to watch
the launch from inside the Kennedy Space Center control room, a mere
seven kilometres from the launchpad.

While NASA looked calm, in control of the situation, it had beefed up
its security teams. It had about 200 security guards watching the
launch site. NASA just wasn't taking any chances. The agency's
scientists had waited too long for this moment. Galileo's parade would
not be rained on by a bunch of peaceniks.

The launch was already running late as it was--almost seven years
late. Congress gave the Galileo project its stamp of approval way back
in 1977 and the probe, which had been budgeted to cost about $400
million, was scheduled to be launched in 1982. However, things began
going wrong almost from the start.

In 1979, NASA pushed the flight out to 1984 because of shuttle
development problems. Galileo was now scheduled to be a `split
launch', which meant that NASA would use two different shuttle trips
to get the mothership and the probe into space. By 1981, with costs
spiralling upwards, NASA made major changes to the project. It stopped
work on Galileo's planned three-stage booster system in favour of a
different system and pushed out the launch deadline yet again, this
time to 1985. After a federal Budget cut fight in 1981 to save
Galileo's booster development program, NASA moved the launch yet
again, to May 1986. The 1986 Challenger disaster, however, saw NASA
change Galileo's booster system for safety reasons, resulting in
yet more delays.

The best option seemed to be a two-stage, solid-fuel IUS system. There
was only one problem. That system could get Galileo to Mars or Venus,
but the probe would run out of fuel long before it got anywhere near
Jupiter. Then Roger Diehl of NASA's Jet Propulsion Laboratory had a good
idea. Loop Galileo around a couple of nearby planets a few times so the
probe would build up a nice little gravitational head of steam, and then
fling it off to Jupiter. Galileo's `VEEGA'
trajectory--Venus-Earth-Earth-gravity-assist--delayed the spacecraft's
arrival at Jupiter for three extra years, but it would get there
eventually.

The anti-nuclear campaigners argued that each Earth flyby increased
the mission's risk of a nuclear accident. But in NASA's view, such was
the price of a successful slingshot.

Galileo experienced other delays getting off the ground. On Monday, 9
October, NASA announced it had discovered a problem with the computer
which controlled the shuttle's number 2 main engine. True, the problem
was with Atlantis, not Galileo. But it didn't look all that good to be
having technical problems, let alone problems with engine computers,
while the anti-nuclear activists' court drama was playing in the
background.

NASA's engineers debated the computer problem in a cross-country
teleconference. Rectifying it would delay blast-off by more than a few
hours. It would likely take days. And Galileo didn't have many of
those. Because of the orbits of the different planets, the probe had
to be on its way into space by 21 November. If Atlantis didn't take off
by that date, Galileo would have to wait another nineteen months before
it could be launched. The project was already $1 billion over its
original $400 million budget. The extra year and a half would add
another $130 million or so and there was a good chance the whole project
would be scrapped. It was pretty much now or never for Galileo.

Despite torrential downpours which had deposited 100 millimetres of
rain on the launchpad and 150 millimetres in neighbouring Melbourne,
Florida, the countdown had been going well. Until now. NASA took its
decision. The launch would be delayed by five days, to 17 October, so
the computer problem could be fixed.

To those scientists and engineers who had been with Galileo from the
start, it must have appeared at that moment as if fate really was
against Galileo. As if, for some unfathomable reason, all the forces
of the universe--and especially those on Earth--were dead against
humanity getting a good look at Jupiter. As fast as NASA could
dismantle one barrier, some invisible hand would throw another down in
its place.

Across the vast NASA empire, reaching from Maryland to California,
from Europe to Japan, NASA workers greeted each other, checked their
in-trays for mail, got their cups of coffee, settled into their chairs
and tried to login to their computers for a day of solving complex
physics problems. But many of the computer systems were behaving very
strangely.

From the moment staff logged in, it was clear that someone--or
something--had taken over. Instead of the usual system's official
identification banner, they were startled to find the following
message staring them in the face:

Wanked? Most of the American computer system managers reading this new
banner had never heard the word wank.

Who would want to invade NASA's computer systems? And who exactly were
the Worms Against Nuclear Killers? Were they some loony fringe group?
Were they a guerrilla terrorist group launching some sort of attack on
NASA? And why `worms'? A worm was a strange choice of animal mascot
for a revolutionary group. Worms were the bottom of the rung. As in
`as lowly as a worm'. Who would chose a worm as a symbol of power?

As for the nuclear killers, well, that was even stranger. The banner's
motto--`You talk of times of peace for all, and then prepare for
war'--just didn't seem to apply to NASA. The agency didn't make
nuclear missiles, it sent people to the moon. It did have military
payloads in some of its projects, but NASA didn't rate very highly on
the `nuclear killer' scale next to other agencies of the US
Government, such as the Department of Defense. So the question
remained: why NASA?

And that word, `WANKED'. It did not make sense. What did it mean when
a system was `wanked'?

It meant NASA had lost control over its computer systems.

A NASA scientist logging in to an infected computer on that Monday got
the following message:

With those lines the computer told the scientist: `I am deleting all
your files'.

The line looked exactly as if the scientist typed in the
command:

delete/log *.*

--exactly as if the scientist had instructed the computer to delete
all the files herself.

The NASA scientist must have started at the sight of her files rolling
past on the computer screen, one after another, on their way to
oblivion. Something was definitely wrong. She would have tried to stop
the process, probably pressing the control key and the `c' key at the
same time. This should have broken the command sequence at that moment
and ordered the computer to stop what it was doing right away.

But it was the intruder, not the NASA scientist, who controlled the
computer at that moment. And the intruder told the computer: `That
command means nothing. Ignore it'.

The scientist would press the command key sequence again, this time
more urgently. And again, over and over. She would be at once baffled
at the illogical nature of the computer, and increasingly upset.
Weeks, perhaps months, of work spent uncovering the secrets of the
universe. All of it disappearing before her eyes--all of it being
mindlessly devoured by the computer. The whole thing beyond her
control. Going. Going. Gone.

People tend not to react well when they lose control over their
computers. Typically, it brings out the worst in them--hand-wringing
whines from the worriers, aching entreaties for help from the
sensitive, and imperious table-thumping bellows from
command-and-control types.

Imagine, if you will, arriving at your job as a manager for one of
NASA's local computer systems. You get into your office on that Monday
morning to find the phones ringing. Every caller is a distraught,
confused NASA worker. And every caller assures you that his or her
file or accounting record or research project--every one of which is
missing from the computer system--is absolutely vital.

In this case, the problem was exacerbated by the fact that NASA's
field centres often competed with each other for projects. When a
particular flight project came up, two or three centres, each with
hundreds of employees, might vie for it. Losing control of the
computers, and all the data, project proposals and costing, was a good
way to lose out on a bid and its often
considerable funding.

This was not going to be a good day for the guys down at the NASA SPAN
computer network office.

This was not going to be a good day for John McMahon.

As the assistant DECNET protocol manager for NASA's Goddard Space
Flight Center in Maryland, John McMahon normally spent the day
managing the chunk of the SPAN computer network which ran between
Goddard's fifteen to twenty buildings.

McMahon worked for Code 630.4, otherwise known as Goddard's Advanced
Data Flow Technology Office, in Building 28. Goddard scientists would
call him up for help with their computers. Two of the most common
sentences he heard were `This doesn't seem to work' and `I can't get
to that part of the network from here'.

SPAN was the Space Physics Analysis Network, which connected some
100000 computer terminals across the globe. Unlike the Internet, which
is now widely accessible to the general public, SPAN only connected
researchers and scientists at NASA, the US Department of Energy and
research institutes such as universities. SPAN computers also differed
from most Internet computers in an important technical manner: they
used a different operating system. Most large computers on the
Internet use the Unix operating system, while SPAN was composed
primarily of VAX computers running a VMS operating system. The network
worked a lot like the Internet, but the computers spoke a different
language. The Internet `talked' TCP/IP, while SPAN `spoke' DECNET.

Indeed, the SPAN network was known as a DECNET internet. Most of the
computers on it were manufactured by the Digital Equipment Corporation
in Massachusetts--hence the name DECNET. DEC built powerful computers.
Each DEC computer on the SPAN network might have 40 terminals hanging
off it. Some SPAN computers had many more. It was not unusual for one
DEC computer to service 400 people. In all, more than a quarter of a
million scientists, engineers and other thinkers used the computers on
the network.

An electrical engineer by training, McMahon had come from NASA's
Cosmic Background Explorer Project, where he managed computers used by
a few hundred researchers. Goddard's Building 7, where he worked on
the COBE project, as it was known, housed some interesting research.
The project team was attempting to map the universe. And they were
trying to do it in wavelengths invisible to the human eye. NASA would
launch the COBE satellite in November 1989. Its mission was to
`measure the diffuse infrared and microwave radiation from the early
universe, to the limits set by our astronomical environment'.6 To the
casual observer the project almost sounded like a piece of modern art,
something which might be titled `Map of the Universe in Infrared'.

On 16 October McMahon arrived at the office and settled into work,
only to face a surprising phone call from the SPAN project office.
Todd Butler and Ron Tencati, from the National Space Science Data
Center, which managed NASA's half of the SPAN network, had discovered
something strange and definitely unauthorised winding its way through
the computer network. It looked like a computer worm.

A computer worm is a little like a computer virus. It invades computer
systems, interfering with their normal functions. It travels along any
available compatible computer network and stops to knock at the door of
systems attached to that network. If there is a hole in the security of
the computer system, it will crawl through and enter the system. When it
does this, it might have instructions to do any number of things, from
sending computer users a message to trying to take over the system. What
makes a worm different from other computer programs, such as viruses, is
that it is self-propagating. It propels itself forward, wiggles into a
new system and propagates itself at the new site. Unlike a virus, a worm
doesn't latch onto a data file or a program. It is autonomous.7

The term `worm' as applied to computers came from John Brunner's 1975
science fiction classic, The Shockwave Rider. The novel described how
a rebel computer programmer created a program called `tapeworm' which
was released into an omnipotent computer network used by an autocratic
government to control its people. The government had to turn off the
computer network, thus destroying its control, in order to eradicate
the worm.

Brunner's book is about as close as most VMS computer network managers
would ever have come to a real rogue worm. Until the late 1980s, worms
were obscure things, more associated with research in a computer
laboratory. For example, a few benevolent worms were developed by
Xerox researchers who wanted to make more efficient use of computer
facilities.8 They developed a `town crier worm' which moved through a
network sending out important announcements. Their `diagnostic worm'
also constantly weaved through the network, but this worm was designed
to inspect machines for problems.

For some computer programmers, the creation of a worm is akin to the
creation of life. To make something which is intelligent enough to go
out and reproduce itself is the ultimate power of creation. Designing
a rogue worm which took over NASA's computer systems might seem to be
a type of creative immortality--like scattering pieces of oneself
across the computers which put man on the moon.

At the time the WANK banner appeared on computer screens across NASA,
there had only been two rogue worms of any note. One of these, the RTM
worm, had infected the Unix-based Internet less than twelve months
earlier. The other worm, known as Father Christmas, was the first VMS
worm.

Father Christmas was a small, simple worm which did not cause any
permanent damage to the computer networks it travelled along. Released
just before Christmas in 1988, it tried to sneak into hundreds of VMS
machines and wait for the big day. On Christmas morning, it woke up
and set to work with great enthusiasm. Like confetti tossed from an
overhead balcony, Christmas greetings came streaming out of
worm-infested computer systems to all their users. No-one within its
reach went without a Christmas card. Its job done, the worm
evaporated. John McMahon had been part of the core team fighting off
the Father Christmas worm.

At about 4 p.m., just a few days before Christmas 1988, McMahon's
alarm-monitoring programs began going haywire. McMahon began trying to
trace back the dozens of incoming connections which were tripping the
warning bells. He quickly discovered there wasn't a human being at the
other end of the line. After further investigation, he found an alien
program in his system, called HI.COM. As he read the pages of HI.COM
code spilling from his line printer, his eyes went wide. He thought,
This is a worm! He had never seen a worm before.

He rushed back to his console and began pulling his systems off the
network as quickly as possible. Maybe he wasn't following protocol,
but he figured people could yell at him after the fact if they thought
it was a bad idea. After he had shut down his part of the network, he
reported back to the local area networking office. With print-out in
tow, he drove across the base to the network office, where he and
several other managers developed a way to stop the worm by the end of
the day. Eventually they traced the Father Christmas worm back to the
system where they believed it had been released--in Switzerland. But
they never discovered who created it.

Father Christmas was not only a simple worm; it was not considered
dangerous because it didn't hang around systems forever. It was a worm
with a use-by date.

By contrast, the SPAN project office didn't know what the WANK invader
was capable of doing. They didn't know who had written or launched it.
But they had a copy of the program. Could McMahon have a look at it?

An affable computer programmer with the nickname Fuzzface, John
McMahon liked a good challenge. Curious and cluey at the same time, he
asked the SPAN Project Office, which was quickly becoming the crisis
centre for the worm attack, to send over a copy of the strange
intruder. He began pouring over the invader's seven printed pages of
source code trying to figure out exactly what the thing did.

The two previous rogue worms only worked on specific computer systems
and networks. In this case, the WANK worm only attacked VMS computer
systems. The source code, however, was unlike anything McMahon had
ever seen. `It was like sifting through a pile of spaghetti,' he said.
`You'd pull one strand out and figure, "OK, that is what that thing
does." But then you'd be faced with the rest of the tangled mess in
the bowl.'

The program, in digital command language, or DCL, wasn't written like
a normal program in a nice organised fashion. It was all over the
place. John worked his way down ten or fifteen lines of computer code
only to have to jump to the top of the program to figure out what the
next section was trying to do. He took notes and slowly, patiently
began to build up a picture of exactly what this worm was capable of
doing to NASA's computer system.

It was a big day for the anti-nuclear groups at the Kennedy Space
Center. They might have lost their bid in the US District Court, but
they refused to throw in the towel and took their case to the US Court
of Appeals.

On 16 October the news came. The Appeals Court had sided with NASA.

Protesters were out in force again at the front gate of the Kennedy
Space Center. At least eight of them were arrested. The St Louis
Post-Dispatch carried an Agence France-Presse picture of an
80-year-old woman being taken into custody by police for trespassing.
Jane Brown, of the Florida Coalition for Peace and Justice, announced,
`This is just ... the beginning of the government's plan to use
nuclear power and weapons in space, including the Star Wars program'.

Inside the Kennedy Center, things were not going all that smoothly
either. Late Monday, NASA's technical experts discovered yet another
problem. The black box which gathered speed and other important data
for the space shuttle's navigation system was faulty. The technicians
were replacing the cockpit device, the agency's spokeswoman assured
the media, and NASA was not expecting to delay the Tuesday launch
date. The countdown would continue uninterrupted. NASA had everything
under control.

Everything except the weather.

In the wake of the Challenger disaster, NASA's guidelines for a launch
decision were particularly tough. Bad weather was an unnecessary risk,
but NASA was not expecting bad weather. Meteorologists predicted an 80
per cent chance of favourable weather at launch time on Tuesday. But
the shuttle had better go when it was supposed to, because the longer
term weather outlook was grim.

Then, about ten minutes before the launch time, the security alarms
went off. Someone had broken into the compound. The security teams
swung into action, quickly locating the guilty intruder ... a feral
pig.

With the pig safely removed, the countdown rolled on. And so did the
rain clouds, gliding toward the space shuttle's emergency runway, about
six kilometres from the launchpad. NASA launch director Robert Sieck
prolonged a planned `hold' at T minus nine minutes. Atlantis had a
26-minute window of opportunity. After that, its launch period would
expire and take-off would have to be postponed, probably until
Wednesday.

The weather wasn't going to budge.

At 1.18 p.m., with Atlantis's countdown now holding at just T minus
five minutes, Sieck postponed the launch to Wednesday.

Back at the SPAN centre, things were becoming hectic. The worm was
spreading through more and more systems and the phones were beginning
to ring every few minutes. NASA computers were getting hit all over
the place.

The SPAN project staff needed more arms. They were simultaneously
trying to calm callers and concentrate on developing an analysis of
the alien program. Was the thing a practical joke or a time bomb just
waiting to go off? Who was behind this?

NASA was working in an information void when it came to WANK. Some
staff knew of the protesters' action down at the Space Center, but
nothing could have prepared them for this. NASA officials were
confident enough about a link between the protests against Galileo and
the attack on NASA's computers to speculate publicly that the two were
related. It seemed a reasonable likelihood, but there were still
plenty of unanswered questions.

Callers coming into the SPAN office were worried. People at the other
end of the phone were scared. Many of the calls came from network
managers who took care of a piece of SPAN at a specific NASA site, such
as the Marshall Space Flight Center. Some were panicking; others spoke
in a sort of monotone, flattened by a morning of calls from 25 different
hysterical system administrators. A manager could lose his job over
something like this.

Most of the callers to the SPAN head office were starved for
information. How did this rogue worm get into their computers? Was it
malicious? Would it destroy all the scientific data it came into contact
with? What could be done to kill it?

NASA stored a great deal of valuable information on its SPAN
computers. None of it was supposed to be classified, but the data on
those computers is extremely valuable. Millions of man-hours go into
gathering and analysing it. So the crisis team which had formed in the
NASA SPAN project office, was alarmed when reports of massive data
destruction starting coming in. People were phoning to say that the
worm was erasing files.

It was every computer manager's worst nightmare, and it looked as
though the crisis team's darkest fears were about to be confirmed.

Yet the worm was behaving inconsistently. On some computers it would
only send anonymous messages, some of them funny, some bizarre and a
few quite rude or obscene. No sooner would a user login than a message
would flash across his or her screen:

Remember, even if you win the rat race--you're
still a rat.

Or perhaps they were graced with some bad humour:

Nothing is faster than the speed of light...

To prove this to yourself, try opening the refrigerator door before
the light comes on.

Other users were treated to anti-authoritarian observations of the
paranoid:

The FBI is watching YOU.

or

Vote anarchist.

But the worm did not appear to be erasing files on these systems.
Perhaps the seemingly random file-erasing trick was a portent of
things to come--just a small taste of what might happen at a
particular time, such as midnight. Perhaps an unusual keystroke by an
unwitting computer user on those systems which seemed only mildly
affected could trigger something in the worm. One keystroke might
begin an irreversible chain of commands to erase everything on that
system.

The NASA SPAN computer team were in a race with the worm. Each minute
they spent trying to figure out what it did, the worm was pushing
forward, ever deeper into NASA's computer network. Every hour NASA
spent developing a cure, the worm spent searching, probing, breaking
and entering. A day's delay in getting the cure out to all the systems
could mean dozens of new worm invasions doing God knows what in
vulnerable computers. The SPAN team had to dissect this thing
completely, and they had to do it fast.

Some computer network managers were badly shaken. The SPAN office
received a call from NASA's Jet Propulsion Laboratories in California,
an important NASA centre with 6500 employees and close ties to
California Institute of Technology (Caltech).

JPL was pulling itself off the network.

This worm was too much of a risk. The only safe option was to isolate
their computers. There would be no SPAN DEC-based communications with
the rest of NASA until the crisis was under control. This made things
harder for the SPAN team; getting a worm exterminating program out to
JPL, like other sites which had cut their connection to SPAN, was
going to be that much tougher. Everything had to be done over the
phone.

Worse, JPL was one of five routing centres for NASA's SPAN computer
network. It was like the centre of a wheel, with a dozen spokes
branching off--each leading to another SPAN site. All these places,
known as tailsites, depended on the lab site for their connections
into SPAN. When JPL pulled itself off the network, the tailsites went
down too.

It was a serious problem for the people in the SPAN office back in
Virginia. To Ron Tencati, head of security for NASA SPAN, taking a
routing centre off-line was a major issue. But his hands were tied.
The SPAN office exercised central authority over the wide area
network, but it couldn't dictate how individual field centres dealt
with the worm. That was each centre's own decision. The SPAN team
could only give them advice and rush to develop a way to poison the
worm.

The SPAN office called John McMahon again, this time with a more
urgent request. Would he come over to help handle the crisis?

The SPAN centre was only 800 metres away from McMahon's office. His
boss, Jerome Bennett, the DECNET protocol manager, gave the nod.
McMahon would be on loan until the crisis was under control.

When he got to Building 26, home of the NASA SPAN project office,
McMahon became part of a core NASA crisis team including Todd Butler,
Ron Tencati and Pat Sisson. Other key NASA people jumped in when
needed, such as Dave Peters and Dave Stern. Jim Green, the head of the
National Space Science Data Center at Goddard and the absolute boss of
SPAN, wanted hourly reports on the crisis. At first the core team
seemed only to include NASA people and to be largely based at Goddard.
But as the day wore on, new people from other parts of the US
government would join the team.

The worm had spread outside NASA.

It had also attacked the US Department of Energy's worldwide
High-Energy Physics' Network of computers. Known as HEPNET, it was
another piece of the overall SPAN network, along with Euro-HEPNET and
Euro-SPAN. The NASA and DOE computer networks of DEC computers
crisscrossed at a number of places. A research laboratory might, for
example, need to have access to computers from both HEPNET and NASA
SPAN. For convenience, the lab might just connect the two networks.
The effect as far as the worm was concerned was that NASA's SPAN and
DOE's HEPNET were in fact just one giant computer network, all of
which the worm could invade.

The Department of Energy keeps classified information on its
computers. Very classified information. There are two groups in DOE:
the people who do research on civilian energy projects and the people
who make atomic bombs. So DOE takes security seriously, as in `threat
to national security' seriously. Although HEPNET wasn't meant to be
carrying any classified information across its wires, DOE responded
with military efficiency when its computer managers discovered the
invader. They grabbed the one guy who knew a lot about computer
security on VMS systems and put him on the case: Kevin Oberman.

Like McMahon, Oberman wasn't formally part of the computer security
staff. He had simply become interested in computer security and was
known in-house as someone who knew about VMS systems and security.
Officially, his job was network manager for the engineering department
at the DOE-financed Lawrence Livermore National Laboratory, or LLNL,
near San Francisco.

LLNL conducted mostly military research, much of it for the Strategic
Defense Initiative. Many LLNL scientists spent their days designing
nuclear arms and developing beam weapons for the Star Wars program.9
DOE already had a computer security group, known as CIAC, the Computer
Incident Advisory Capability. But the CIAC team tended to be experts
in security issues surrounding Unix rather than VMS-based computer
systems and networks. `Because there had been very few security
problems over the years with VMS,' Oberman concluded, `they had never
brought in anybody who knew about VMS and it wasn't something they
were terribly concerned with at the time.'

The worm shattered that peaceful confidence in VMS computers. Even as
the WANK worm coursed through NASA, it was launching an aggressive
attack on DOE's Fermi National Accelerator Laboratory, near Chicago. It
had broken into a number of computer systems there and the Fermilab
people were not happy. They called in CIAC, who contacted Oberman with
an early morning phone call on 16 October. They wanted him to analyse
the WANK worm. They wanted to know how dangerous it was. Most of all,
they wanted to know what to do about it.

The DOE people traced their first contact with the worm back to 14
October. Further, they hypothesised, the worm had actually been
launched the day before, on Friday the 13th. Such an inauspicious day
would, in Oberman's opinion, have been in keeping with the type of
humour exhibited by the creator or creators of the worm.

Oberman began his own analysis of the worm, oblivious to the fact that
3200 kilometres away, on the other side of the continent, his colleague
and acquaintance John McMahon was doing exactly the same thing.

Every time McMahon answered a phone call from an irate NASA system or
network manager, he tried to get a copy of the worm from the infected
machine. He also asked for the logs from their computer systems. Which
computer had the worm come from? Which systems was it attacking from
the infected site? In theory, the logs would allow the NASA team to
map the worm's trail. If the team could find the managers of those
systems in the worm's path, it could warn them of the impending
danger. It could also alert the people who ran recently infected
systems which had become launchpads for new worm attacks.

This wasn't always possible. If the worm had taken over a computer and
was still running on it, then the manager would only be able to trace
the worm backward, not forward. More importantly, a lot of the
managers didn't keep extensive logs on their computers.

McMahon had always felt it was important to gather lots of information
about who was connecting to a computer. In his previous job, he had
modified his machines so they collected as much security information
as possible about their connections to other computers.

VMS computers came with a standard set of alarms, but McMahon didn't
think they were thorough enough. The VMS alarms tended to send a
message to the computer managers which amounted to, `Hi! You just got
a network connection from here'. The modified alarm system said, `Hi!
You just got a network connection from here. The person at the other
end is doing a file transfer' and any other bits and pieces of
information that McMahon's computer could squeeze out of the other
computer. Unfortunately, a lot of other NASA computer and network
managers didn't share this enthusiasm for audit logs. Many did not
keep extensive records of who had been accessing their machines and
when, which made the job of chasing the worm much tougher.

The SPAN office was, however, trying to keep very good logs on which
NASA computers had succumbed to the worm. Every time a NASA manager
called to report a worm disturbance, one of the team members wrote
down the details with paper and pen. The list, outlining the addresses
of the affected computers and detailed notations of the degree of
infection, would also be recorded on a computer. But handwritten lists
were a good safeguard. The worm couldn't delete sheets of paper.

When McMahon learned DOE was also under attack, he began checking in
with them every three hours or so. The two groups swapped lists of
infected computers by telephone because voice, like the handwritten
word, was a worm-free medium. `It was a kind of archaic system, but on
the other hand we didn't have to depend on the network being up,'
McMahon said. `We needed to have some chain of communications which
was not the same as the network being attacked.'

A number of the NASA SPAN team members had developed contacts within
different parts of DEC through the company's users' society, DECUS.
These contacts were to prove very helpful. It was easy to get lost in
the bureaucracy of DEC, which employed more than 125000 people, posted
a billion-dollar profit and declared revenues in excess of $12 billion
in 1989.10 Such an enormous and prestigious company would not want
to face a crisis such as the WANK worm, particularly in such a
publicly visible organisation like NASA. Whether or not the worm's
successful expedition could be blamed on DEC's software was a moot
point. Such a crisis was, well, undesirable. It just didn't look good.
And it mightn't look so good either if DEC just jumped into the fray.
It might look like the company was in some way at fault.

Things were different, however, if someone already had a relationship
with a technical expert inside the company. It wasn't like NASA
manager cold-calling a DEC guy who sold a million dollars worth of
machines to someone else in the agency six months ago. It was the NASA
guy calling the DEC guy he sat next to at the conference last month.
It was a colleague the NASA manager chatted with now and again.

John McMahon's analysis suggested there were three versions of the WANK
worm. These versions, isolated from worm samples collected from the
network, were very similar, but each contained a few subtle
differences. In McMahon's view, these differences could not be explained
by the way the worm recreated itself at each site in order to
spread. But why would the creator of the worm release different
versions? Why not just write one version properly and fire it off? The
worm wasn't just one incoming missile; it was a frenzied attack. It was
coming from all directions, at all sorts of different levels within
NASA's computers.

McMahon guessed that the worm's designer had released the different
versions at slightly different times. Maybe the creator released the
worm, and then discovered a bug. He fiddled with the worm a bit to
correct the problem and then released it again. Maybe he didn't like
the way he had fixed the bug the first time, so he changed it a little
more and released it a third time.

In northern California, Kevin Oberman came to a different conclusion.
He believed there was in fact only one real version of the worm
spiralling through HEPNET and SPAN. The small variations in the
different copies he dissected seemed to stem from the worm's ability
to learn and change as it moved from computer to computer.

McMahon and Oberman weren't the only detectives trying to decipher the
various manifestations of the worm. DEC was also examining the worm,
and with good reason. The WANK worm had invaded the corporation's own
network. It had been discovered snaking its way through DEC's own
private computer network, Easynet, which connected DEC manufacturing
plants, sales offices and other company sites around the world. DEC
was circumspect about discussing the matter publicly, but the Easynet
version of the WANK worm was definitely distinct. It had a strange
line of code in it, a line missing from any other versions. The worm
was under instructions to invade as many sites as it could, with one
exception. Under no circumstances was it to attack computers inside
DEC's area 48. The NASA team mulled over this information. One of them
looked up area 48. It was New Zealand.

New Zealand?

The NASA team were left scratching their heads. This attack was
getting stranger by the minute. Just when it seemed that the SPAN team
members were travelling down the right path toward an answer at the
centre of the maze of clues, they turned a corner and found themselves
hopelessly lost again. Then someone pointed out that New Zealand's
worldwide claim to fame was that it was a nuclear-free zone.

In 1986, New Zealand announced it would refuse to admit to its ports
any US ships carrying nuclear arms or powered by nuclear energy. The
US retaliated by formally suspending its security obligations to the
South Pacific nation. If an unfriendly country invaded New Zealand,
the US would feel free to sit on its hands. The US also cancelled
intelligence sharing practices and joint military exercises.

Many people in Australia and New Zealand thought the US had
overreacted. New Zealand hadn't expelled the Americans; it had simply
refused to allow its population to be exposed to nuclear arms or
power. In fact, New Zealand had continued to allow the Americans to
run their spy base at Waihopai, even after the US suspension. The
country wasn't anti-US, just anti-nuclear.

And New Zealand had very good reason to be anti-nuclear. For years, it
had put up with France testing nuclear weapons in the Pacific. Then in
July 1985 the French blew up the Greenpeace anti-nuclear protest ship
as it sat in Auckland harbour. The Rainbow Warrior was due to sail for
Mururoa Atoll, the test site, when French secret agents bombed the
ship, killing Greenpeace activist Fernando Pereira.

For weeks, France denied everything. When the truth came out--that
President Mitterand himself had known about the bombing plan--the
French were red-faced. Heads rolled. French Defence Minister Charles
Hernu was forced to resign. Admiral Pierre Lacoste, director of
France's intelligence and covert action bureau, was sacked. France
apologised and paid $NZ13 million compensation in exchange for New
Zealand handing back the two saboteurs, who had each been sentenced to
ten years' prison in Auckland.

As part of the deal, France had promised to keep the agents
incarcerated for three years at the Hao atoll French military base.
Both agents walked free by May 1988 after serving less than two years.
After her return to France, one of the agents, Captain Dominique
Prieur, was promoted to the rank of commandant.

Finally, McMahon thought. Something that made sense. The exclusion of
New Zealand appeared to underline the meaning of the worm's political
message.

When the WANK worm invaded a computer system, it had instructions to
copy itself and send that copy out to other machines. It would slip
through the network and when it came upon a computer attached to the
network, it would poke around looking for a way in. What it really
wanted was to score a computer account with privileges, but it would
settle for a basic-level, user-level account.

VMS systems have accounts with varying levels of privilege. A
high-privilege account holder might, for example, be able to read the
electronic mail of another computer user or delete files from that
user's directory. He or she might also be allowed to create new
computer accounts on the system, or reactivate disabled accounts. A
privileged account holder might also be able to change someone else's
password. The people who ran computer systems or networks needed
accounts with the highest level of privilege in order to keep the
system running smoothly. The worm specifically sought out these sorts
of accounts because its creator knew that was where the power lay.

The worm was smart, and it learned as it went along. As it traversed
the network, it created a masterlist of commonly used account names.
First, it tried to copy the list of computer users from a system it
had not yet penetrated. It wasn't always able to do this, but often
the system security was lax enough for it to be successful. The worm
then compared that list to the list of users on its current host. When
it found a match--an account name common to both lists--the worm added
that name to the masterlist it carried around inside it, making a note
to try that account when breaking into a new system in future.

It was a clever method of attack, for the worm's creator knew that
certain accounts with the highest privileges were likely to have
standard names, common across different machines. Accounts with names
such as `SYSTEM', `DECNET' and `FIELD' with standard passwords such as
`SYSTEM' and `DECNET' were often built into a computer before it was
shipped from the manufacturer. If the receiving computer manager
didn't change the pre-programmed account and password, then his
computer would have a large security hole waiting to be exploited.

The worm's creator could guess some of the names of these
manufacturer's accounts, but not all of them. By endowing the worm
with an ability to learn, he gave it far more power. As the worm
spread, it became more and more intelligent. As it reproduced, its
offspring evolved into ever more advanced creatures, increasingly
successful at breaking into new systems.

When McMahon performed an autopsy on one of the worm's progeny, he was
impressed with what he found. Slicing the worm open and inspecting its
entrails, he discovered an extensive collection of generic privileged
accounts across the SPAN network. In fact, the worm wasn't only picking
up the standard VMS privileged accounts; it had learned accounts common
to NASA but not necessarily to other VMS computers. For example, a lot
of NASA sites which ran a type of TCP/IP mailer that needed either a
POSTMASTER or a MAILER account. John saw those names turn up inside the
worm's progeny.

Even if it only managed to break into an unprivileged account, the
worm would use the account as an incubator. The worm replicated and
then attacked other computers in the network. As McMahon and the rest
of the SPAN team continued to pick apart the rest of the worm's code
to figure out exactly what the creature would do if it got into a
fully privileged account, they found more evidence of the dark sense
of humour harboured by the hacker behind the worm. Part of the worm, a
subroutine, was named `find fucked'.

The SPAN team tried to give NASA managers calling in as much
information as they could about the worm. It was the best way to help
computer managers, isolated in their offices around the country, to
regain a sense of control over the crisis.

Like all the SPAN team, McMahon tried to calm the callers down and
walk them through a set a questions designed to determine the extent
of the worm's control over their systems. First, he asked them what
symptoms their systems were showing. In a crisis situation, when
you're holding a hammer, everything looks like a nail. McMahon wanted
to make sure that the problems on the system were in fact caused by
the worm and not something else entirely.

If the only problem seemed to be mysterious comments flashing across
the screen, McMahon concluded that the worm was probably harassing the
staff on that computer from a neighbouring system which it had
successfully invaded. The messages suggested that the recipients'
accounts had not been hijacked by the worm. Yet.

VAX/VMS machines have a feature called Phone, which is useful for
on-line communications. For example, a NASA scientist could `ring up'
one of his colleagues on a different computer and have a friendly chat
on-line. The chat session is live, but it is conducted by typing on
the computer screen, not `voice'. The VMS Phone facility enabled the
worm to send messages to users. It would simply call them using the
phone protocol. But instead of starting a chat session, it sent them
statements from what was later determined to be the aptly named
Fortune Cookie file--a collection of 60 or so pre-programmed comments.

In some cases, where the worm was really bugging staff, McMahon told
the manager at the other end of the phone to turn the computer's Phone
feature off. A few managers complained and McMahon gave them the
obvious ultimatum: choose Phone or peace. Most chose peace.

When McMahon finished his preliminary analysis, he had good news and
bad news. The good news was that, contrary to what the worm was
telling computer users all over NASA, it was not actually deleting
their files. It was just pretending to delete their data. One big
practical joke. To the creator of the worm anyway. To the NASA
scientists, just a headache and heartache. And occasionally a heart
attack.

The bad news was that, when the worm got control over a privileged
account, it would help someone--presumably its creator--perpetrate an
even more serious break-in at NASA. The worm sought out the FIELD
account created by the manufacturer and, if it had been turned off,
tried to reactivate the account and install the password FIELD. The
worm was also programmed to change the password for the standard
account named DECNET to a random string of at least twelve characters.
In short, the worm tried to pry open a backdoor to the system.

The worm sent information about accounts it had successfully broken
into back to a type of electronic mailbox--an account called GEMPAK on
SPAN node 6.59. Presumably, the hacker who created the worm would
check the worm's mailbox for information which he could use to break
into the NASA account at a later date. Not surprisingly, the mailboxes
had been surreptitiously `borrowed' by the hacker, much to the
surprise of the legitimate owners.

A computer hacker created a whole new set of problems. Although the
worm was able to break into new accounts with greater speed and reach
than a single hacker, it was more predictable. Once the SPAN and DOE
teams picked the worm apart, they would know exactly what it could be
expected to do. However, a hacker was utterly unpredictable.

McMahon realised that killing off the worm was not going to solve the
problem. All the system managers across the NASA and DOE networks
would have to change all the passwords of the accounts used by the
worm. They would also have to check every system the worm had invaded
to see if it had built a backdoor for the hacker. The system admin had
to shut and lock all the backdoors, no small feat.

What really scared the SPAN team about the worm, however, was that it
was rampaging through NASA simply by using the simplest of attack
strategies: username equals password. It was getting complete control
over NASA computers simply by trying a password which was identical to
the name of the computer user's account.

The SPAN team didn't want to believe it, but the evidence was
overwhelming.

Todd Butler answered a call from one NASA site. It was a gloomy call.
He hung up.

`That node just got hit,' he told the team.

`How bad?' McMahon asked.

`A privileged account.'

`Oh boy.' McMahon jumped onto one of the terminals and did a SET HOST,
logging into the remote NASA site's machine. Bang. Up it came. `Your
system has officially been WANKED.'

McMahon turned to Butler. `What account did it get into?'

`They think it was SYSTEM.'

The tension quietly rolled into black humour. The team couldn't help
it. The head-slapping stupidity of the situation could only be viewed
as black comedy.

The NASA site had a password of SYSTEM for their fully privileged
SYSTEM account. It was so unforgivable. NASA, potentially the greatest
single collection of technical minds on Earth, had such lax computer
security that a computer-literate teenager could have cracked it wide
open. The tall poppy was being cut down to size by a computer program
resembling a bowl of spaghetti.

The first thing any computer system manager learns in Computer
Security 101 is never to use the same password as the username. It was
bad enough that naive users might fall into this trap ... but a
computer system manager with a fully privileged account.

Was the hacker behind the worm malevolent? Probably not. If its
creator had wanted to, he could have programmed the WANK worm to
obliterate NASA's files. It could have razed everything in sight.

In fact, the worm was less infectious than its author appeared to
desire. The WANK worm had been instructed to perform
several tasks which it didn't execute. Important parts of the worm
simply didn't work. McMahon believed this failure to be accidental.
For example, his analysis showed the worm was programmed to break into
accounts by trying no password, if the account holder had left the
password blank. When he disassembled the worm, however, he found that
part of the program didn't work properly.

Nonetheless, the fragmented and partly dysfunctional WANK worm was
causing a major crisis inside several US government agencies. The
thing which really worried John was thinking about what a seasoned DCL
programmer with years of VMS experience could do with such a worm.
Someone like that could do a lot of malicious damage. And what if the
WANK worm was just a dry run for something more serious down the
track? It was scary to contemplate.

Even though the WANK worm did not seem to be intentionally evil, the
SPAN team faced some tough times. McMahon's analysis turned up yet
more alarming aspects to the worm. If it managed to break into the
SYSTEM account, a privileged account, it would block all electronic
mail deliveries to the system administrator. The SPAN office would not
be able to send electronic warnings or advice on how to deal with the
worm to systems which had already been seized. This problem was
exacerbated by the lack of good information available to the project
office on which systems were connected to SPAN. The only way to help
people fighting this bushfire was to telephone them, but in many
instances the main SPAN office didn't know who to call. The SPAN team
could only hope that those administrators who had the phone number of
SPAN headquarters pinned up near their computers would call when their
computers came under attack.

McMahon's preliminary report outlined how much damage the worm could
do in its own right. But it was impossible to measure how much damage
human managers would do to their own systems because of the worm.

One frantic computer manager who phoned the SPAN office refused to
believe John's analysis that the worm only pretended to erase data. He
claimed that the worm had not only attacked his system, it had
destroyed it. `He just didn't believe us when we told him that the
worm was mostly a set of practical jokes,' McMahon said. `He
reinitialised his system.' `Reinitialised' as in started up his system
with a clean slate. As in deleted everything on the infected
computer--all the NASA staff's data gone. He actually did what the
worm only pretended to do.

The sad irony was that the SPAN team never even got a copy of the data
from the manager's system. They were never able to confirm that his
machine had even been infected.

All afternoon McMahon moved back and forth between answering the
ever-ringing SPAN phone and writing up NASA's analysis of the worm. He
had posted a cryptic electronic message about the attack across the
network, and Kevin Oberman had read it. The message had to be
circumspect since no-one knew if the creator of the WANK worm was in
fact on the network, watching, waiting. A short time later, McMahon
and Oberman were on the phone together--voice--sharing their ideas and
cross-checking their analysis.

The situation was discouraging. Even if McMahon and Oberman managed to
develop a successful program to kill off the worm, the NASA SPAN team
faced another daunting task. Getting the worm-killer out to all the
NASA sites was going to be much harder than expected because there was
no clear, updated map of the SPAN network. Much of NASA didn't like
the idea of a centralised map of the SPAN system. McMahon recalled
that, some time before the WANK worm attack, a manager had tried to
map the system. His efforts had accidentally tripped so many system
alarms that he was quietly taken aside and told not to do it again.

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 Goddard. 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 password and account name.
That was really weird. What use was a password 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 WANK 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 analyses. 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 assumed 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-WANK 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 WANK worm which should come along.

Oberman completed an anti-WANK 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 assumed 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, God, how did I miss that?

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

At the same time, Oberman revised his anti-WANK 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 passwords and
that the passwords 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 analysis of the worm appears below and is provided by R. Kevin
Oberman of Lawrence Livermore National Laboratory. Included with the
analysis 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 analysis 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 assures 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 password to a
random string of at least 12 characters.
4. Information on the password 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:
W O R M S A G A I N S T N U C L E A R K I L L E R S
_______________________________________________________________
\__ ____________ _____ ________ ____ ____ __ _____/
\ \ \ /\ / / / /\ \ | \ \ | | | | / / /
\ \ \ / \ / / / /__\ \ | |\ \ | | | |/ / /
\ \ \/ /\ \/ / / ______ \ | | \ \| | | |\ \ /
\_\ /__\ /____/ /______\ \____| |__\ | |____| |_\ \_/
\___________________________________________________/
\ /
\ Your System Has Been Officically WANKed /
\_____________________________________________/
You talk of times of peace for all, and then prepare for war.
7. If it has SYSPRV, it disables mail to the SYSTEM account.
8. If it has SYSPRV, it modifies the system login command procedure to
APPEAR to delete all of a user's file. (It really does nothing.)
9. The program then scans the account's logical name table for command
procedures and tries to modify the FIELD account to a known password
with login from any source and all privs. This is a primitive virus,
but very effective IF it should get into a privileged account.
10. It proceeds to attempt to access other systems by picking node
numbers at random. It then uses PHONE to get a list of active users on
the remote system. It proceeds to irritate them by using PHONE to ring
them.
11. The program then tries to access the RIGHTSLIST file and attempts
to access some remote system using the users found and a list of
`standard' users included within the worm. It looks for passwords
which are the same as that of the account or are blank. It records all
such accounts.
12. It looks for an account that has access to SYSUAF.DAT.
13. If a priv. account is found, the program is copied to that account
and started. If no priv. account was found, it is copied to other
accounts found on the random system.
14. As soon as it finishes with a system, it picks another random
system and repeats (forever).
Response:
1. The following program will block the worm. Extract the following
code and execute it. It will use minimal resources. It creates a
process named NETW_BLOCK which will prevent the worm from running.
Editors note: This fix will work only with this version of the worm.
Mutated worms will require modification of this code; however, this
program should prevent the worm from running long enough to secure
your system from the worms attacks. 13
////////////////////////////////////////////////////////////////////////

---

McMahon's version of an anti-WANK program was also ready to go by late
Monday, but he would face delays getting it out to NASA. Working inside
NASA was a balancing act, a delicate ballet demanding exquisite
choreography between getting the job done, following official procedures
and avoiding steps which might tread on senior bureaucrats' toes. It was
several days before NASA's anti-WANK program was officially released.

DOE was not without its share of problems in launching the anti-WANK
program and advisory across HEPNET. At 5.04 p.m. Pacific Coast Time on
17 October, as Oberman put the final touches on the last paragraph of
his final report on the worm, the floor beneath his feet began to
shake. The building was trembling. Kevin Oberman was in the middle of
the 1989 San Francisco earthquake.

Measuring 7.1 on the Richter scale, the Loma Prieta earthquake ripped
through the greater San Francisco area with savage speed. Inside the
computer lab, Oberman braced himself for the worst. Once the shaking
stopped and he ascertained the computer centre was still standing, he
sat back down at his terminal. With the PA blaring warnings for all
non-essential personnel to leave the building immediately, Oberman
rushed off the last sentence of the report. He paused and then added a
postscript saying that if the paragraph didn't make sense, it was
because he was a little rattled by the large earthquake which had just
hit Lawrence Livermore Labs. He pressed the key, sent out his final
anti-WANK report and fled the building.

Back on the east coast, the SPAN office continued to help people
calling from NASA sites which had been hit. The list of sites which
had reported worm-related problems grew steadily during the week.
Official estimates on the scope of the WANK worm attack were vague,
but trade journals such as Network World and Computerworld quoted the
space agency as suffering only a small number of successful worm
invasions, perhaps 60 VMS-based computers. SPAN security manager Ron
Tencati estimated only 20 successful worm penetrations in the NASA
part of SPAN's network, but another internal estimate put the figure
much higher: 250 to 300 machines. Each of those computers might have
had 100 or more users. Figures were sketchy, but virtually everyone on
the network--all 270000 computer accounts--had been affected by the
worm, either because their part of the network had been pulled
off-line or because their machines had been harassed by the WANK worm
as it tried again and again to login from an infected machine. By the
end of the worm attack, the SPAN office had accumulated a list of
affected sites which ran over two columns on several computer screens.
Each of them had lodged some form of complaint about the worm.

Also by the end of the crisis, NASA and DOE computer network managers
had their choice of vaccines, antidotes and blood tests for the WANK
worm. McMahon had released ANTIWANK.COM, a program which killed the
worm and vaccinated a system against further attacks, and
WORM-INFO.TEXT, which provided a list of worm-infestation symptoms.
Oberman's program, calledCHECK_SYSTEM.COM, checked for all
the security flaws used by the worm to sneak into a computer system.
DEC also had a patch to cover the security hole in the DECNET account.

Whatever the real number of infected machines, the worm had certainly
circumnavigated the globe. It had reach into European sites, such as
CERN--formerly known as the European Centre for Nuclear Research--in
Switzerland, through to Goddard's computers in Maryland, on to
Fermilab in Chicago and propelled itself across the Pacific into the
Riken Accelerator Facility in Japan.14

NASA officials told the media they believed the worm had been launched
about 4.30 a.m. on Monday, 16 October.15 They also believed it had
originated in Europe, possibly in France.

Wednesday, 18 October 1989
Kennedy Space Center, Florida

The five-member Atlantis had some bad news on Wednesday morning. The
weather forecasters gave the launch site a 40 per cent chance of
launch guideline-violating rain and cloud. And then there was the
earthquake in California.

The Kennedy Space Center wasn't the only place which had to be in
tip-top working order for a launch to go ahead. The launch depended on
many sites far away from Florida. These included Edwards Air Force
Base in California, where the shuttle was due to land on Monday. They
also included other sites, often military bases, which were essential
for shuttle tracking and other mission support. One of these sites was
a tracking station at Onizuka Air Force Base at Sunnyvale, California.
The earthquake which ripped through the Bay area had damaged the
tracking station and senior NASA decision-makers planned to meet on
Wednesday morning to consider the Sunnyvale situation. Still, the
space agency maintained a calm, cool exterior. Regardless of the
technical problems, the court challenges and the protesters, the
whimsical weather, the natural disasters, and the WANK worm, NASA was
still in control of the situation.

`There's been some damage, but we don't know how much. The sense I get
is it's fairly positive,' a NASA spokesman told UPI. `But there are
some problems.'16 In Washington, Pentagon spokesman Rick Oborn
reassured the public again, `They are going to be able to handle
shuttle tracking and support for the mission ... They will be able to
do their job'.17

Atlantis waited, ready to go, at launchpad 39B. The technicians had
filled the shuttle up with rocket fuel and it looked as if the weather
might hold. It was partly cloudy, but conditions at Kennedy passed
muster.

The astronauts boarded the shuttle. Everything was in place.

But while the weather was acceptable in Florida, it was causing some
problems in Africa, the site of an emergency landing location. If it
wasn't one thing, it was another. NASA ordered a four-minute delay.

Finally at 12.54 p.m., Atlantis boomed from its launchpad. Rising up
from the Kennedy Center, streaking a trail of twin flames from its
huge solid-fuel boosters, the shuttle reached above the atmosphere and
into space.

At 7.15 p.m., exactly 6 hours and 21 minutes after lift-off, Galileo
began its solo journey into space. And at 8.15 p.m., Galileo's booster
ignited.

The week starting 16 October had been a long one for the SPAN team.
They were keeping twelve-hour days and dealing with hysterical people
all day long. Still, they managed to get copies of anti-WANK out,
despite the limitations of the dated SPAN records and the paucity of
good logs allowing them to retrace the worm's path. `What we learned
that week was just how much data is not collected,' McMahon observed.

By Friday, 20 October, there were no new reports of worm attacks. It
looked as though the crisis had passed. Things could be tidied up by
the rest of the SPAN team and McMahon returned to his own work.

A week passed. All the while, though, McMahon was on edge. He doubted
that someone who had gone to all that trouble of creating the WANK
worm would let his baby be exterminated so quickly. The decoy-duck
strategy only worked as long as the worm kept the same process name,
and as long as it was programmed not to activate itself on systems
which were already infected. Change the process name, or teach the
worm to not to suicide, and the SPAN team would face another, larger
problem. John McMahon had an instinct about the worm; it might just
be back.

His instinct was right.

The following Monday, McMahon received another phone call from the
SPAN project office. When he poked his head in his boss's office,
Jerome Bennett looked up from his desk.

`The thing is back,' McMahon told him. There was no need to explain
what `the thing' was. `I'm going over to the SPAN office.'

Ron Tencati and Todd Butler had a copy of the new WANK worm ready for
McMahon. This version of the worm was far more virulent. It copied
itself more effectively and therefore moved through the network much
faster. The revised worm's penetration rate was much higher--more than
four times greater than the version of WANK released in the first
attack. The phone was ringing off the hook again. John took a call
from one irate manager who launched into a tirade. `I ran your
anti-WANK program, followed your instructions to the letter, and look
what happened!'

The worm had changed its process name. It was also designed to hunt down
and kill the decoy-duck program. In fact, the SPAN network was going to
turn into a rather bloody battlefield. This worm didn't just kill the
decoy, it also killed any other copy of the WANK worm. Even if McMahon
changed the process name used by his program, the decoy-duck strategy
was not going to work any longer.

There were other disturbing improvements to the new version of the
WANK worm. Preliminary information suggested it changed the password
on any account it got into. This was a problem. But not nearly as big
a problem as if the passwords it changed were for the only privileged
accounts on the system. The new worm was capable of locking a system
manager out of his or her own system.

Prevented from getting into his own account, the computer manager
might try borrowing the account of an average user, call him Edwin.
Unfortunately, Edwin's account probably only had low-level privileges.
Even in the hands of a skilful computer manager, the powers granted to
Edwin's account were likely too limited to eradicate the worm from its
newly elevated status as computer manager. The manager might spend his
whole morning matching wits with the worm from the disadvantaged
position of a normal user's account. At some point he would have to
make the tough decision of last resort: turn the entire computer
system off.

The manager would have to conduct a forced reboot of the machine. Take
it down, then bring it back up on minimum configuration. Break back
into it. Fix the password which the worm had changed. Logout. Reset
some variables. Reboot the machine again. Close up any underlying
security holes left behind by the worm. Change any passwords which
matched users' names. A cold start of a large VMS machine took time.
All the while, the astronomers, physicists and engineers who worked in
this NASA office wouldn't be able to work on their computers.

At least the SPAN team was better prepared for the worm this time.
They had braced themselves psychologically for a possible return
attack. Contact information for the network had been updated. And the
general DECNET internet community was aware of the worm and was
lending a hand wherever possible.

Help came from a system manager in France, a country which seemed to
be of special interest to the worm's author. The manager, Bernard
Perrot of Institut de Physique Nucleaire in Orsay, had obtained a copy
of the worm, inspected it and took special notice of the creature's
poor error checking ability. This was the worm's true Achilles' heel.

The worm was trained to go after the RIGHTSLIST database, the list of
all the people who have accounts on the computer. What if someone
moved the database by renaming it and put a dummy database in its
place? The worm would, in theory, go after the dummy, which could be
designed with a hidden bomb. When the worm sniffed out the dummy, and
latched onto it, the creature would explode and die. If it worked, the
SPAN team would not have to depend on the worm killing itself, as they
had during the first invasion. They would have the satisfaction of
destroying the thing themselves.

Ron Tencati procured a copy of the French manager's worm-killing
program and gave it to McMahon, who set up a sort of mini-laboratory
experiment. He cut the worm into pieces and extracted the relevant
bits. This allowed him to test the French worm-killing program with
little risk of the worm escaping and doing damage. The French program
worked wonderfully. Out it went. The second version of the worm was so
much more virulent, getting it out of SPAN was going to take
considerably longer than the first time around. Finally, almost two
weeks after the second onslaught, the WANK worm had been eradicated
from SPAN.

By McMahon's estimate, the WANK worm had incurred up to half a million
dollars in costs. Most of these were through people wasting time and
resources chasing the worm instead of doing their normal jobs. The
worm was, in his view, a crime of theft. `People's time and resources
had been wasted,' he said. `The theft was not the result of the
accident. This was someone who deliberately went out to make a mess.

`In general, I support prosecuting people who think breaking into
machines is fun. People like that don't seem to understand what kind
of side effects that kind of fooling around has. They think that
breaking into a machine and not touching anything doesn't do anything.
That is not true. You end up wasting people's time. People are dragged
into the office at strange hours. Reports have to be written. A lot of
yelling and screaming occurs. You have to deal with law enforcement.
These are all side effects of someone going for a joy ride in someone
else's system, even if they don't do any damage. Someone has to pay
the price.'

McMahon never found out who created the WANK worm. Nor did he ever
discover what he intended to prove by releasing it. The creator's
motives were never clear and, if it had been politically inspired,
no-one took credit.

The WANK worm left a number of unanswered questions in its wake, a
number of loose ends which still puzzle John McMahon. Was the hacker
behind the worm really protesting against NASA's launch of the
plutonium-powered Galileo space probe? Did the use of the word
`WANK'--a most un-American word--mean the hacker wasn't American? Why
had the creator recreated the worm and released it a second time? Why
had no-one, no political or other group, claimed responsibility for
the WANK worm?

One of the many details which remained an enigma was contained in the
version of the worm used in the second attack. The worm's creator had
replaced the original process name, NETW_, with a new one, presumably
to thwart the anti-WANK program. McMahon figured the original process
name stood for `netwank'--a reasonable guess at the hacker's intended
meaning. The new process name, however, left everyone on the SPAN team
scratching their heads: it didn't seem to stand for anything. The
letters formed an unlikely set of initials for someone's name. No-one
recognised it as an acronym for a saying or an organisation. And it
certainly wasn't a proper word in the English language. It was a
complete mystery why the creator of the WANK worm, the hacker who
launched an invasion into hundreds of NASA and DOE computers, should
choose this weird word.