Somebody's Trying to Tell Me Something

Underground: Hacking, Madness and Obsession on the Electronic Frontier by Suelette Dreyfus, is part of the HackerNoon Books Series. You can jump to any chapter in this book here. 10, 9, 8, 7, 6, 5, 4, 3, 2, 1.

Chapter 1 — 10, 9, 8, 7, 6, 5, 4, 3, 2, 1.

Somebody's out there, somebody's waiting; Somebody's trying to tell me something.

— from `Somebody's Trying to Tell Me Something', 10, 9, 8, 7, 6, 5, 4, 3, 2, 1.

Monday, 16 October 1989 Kennedy Space Center, Florida 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.

Monday, 16 October, 1989 NASA's Goddard Space Flight Center, Greenbelt, Maryland 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:

"Worms Aginst Nuclear Killers!

Your System Has Been Officically Wanked.

You talk of times of peace for all, and then prepare for war."

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:

deleted file <filename1>

deleted file <filename2>

deleted file <filename3>, etc

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.

By Tuesday morning, Galileo's keepers were holding their breath. The countdown for the shuttle launch was ticking toward 12.57 p.m. The anti-nuclear protesters seemed to have gone quiet. Things looked hopeful. Galileo might finally go.

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:

Worms Against Nuclear Killers!

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, called [.SECURITY]CHECK_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.

Inside shuttle mission control, NASA spokesman Brian Welch announced, The spacecraft Galileo … has achieved Earth escape velocity'.18 Monday, 30 October 1989 NASA's Goddard Space Flight Center, Greenbelt, Maryland 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.

The word was `OILZ'.

About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books.

This book is part of the public domain. Suelette Dreyfus (2003). Underground: Hacking, Madness and Obsession on the Electronic Frontier. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/4686/pg4686.html

This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org, located at https://www.gutenberg.org/policy/license.html.