Underground by Suelette Dreyfus (top rated books of all time txt) 📕

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