strategies: username equals password. It was getting complete control
over NASA computers simply by trying a password which was identical to
the name of the computer user's account.
The SPAN team didn't want to believe it, but the evidence was
overwhelming.
Todd Butler answered a call from one NASA site. It was a gloomy call.
He hung up.
`That node just got hit,' he told the team.
`How bad?' McMahon asked.
`A privileged account.'
`Oh boy.' McMahon jumped onto one of the terminals and did a SET HOST,
logging into the remote NASA site's machine. Bang. Up it came. `Your
system has officially been WANKED.'
McMahon turned to Butler. `What account did it get into?'
`They think it was SYSTEM.'
The tension quietly rolled into black humour. The team couldn't help
it. The head-slapping stupidity of the situation could only be viewed
as black comedy.
The NASA site had a password of SYSTEM for their fully privileged
SYSTEM account. It was so unforgivable. NASA, potentially the greatest
single collection of technical minds on Earth, had such lax computer
security that a computer-literate teenager could have cracked it wide
open. The tall poppy was being cut down to size by a computer program
resembling a bowl of spaghetti.
The first thing any computer system manager learns in Computer
Security 101 is never to use the same password as the username. It was
bad enough that naive users might fall into this trap ... but a
computer system manager with a fully privileged account.
Was the hacker behind the worm malevolent? Probably not. If its
creator had wanted to, he could have programmed the WANK worm to
obliterate NASA's files. It could have razed everything in sight.
In fact, the worm was less infectious than its author appeared to
desire. The WANK worm had been instructed to perform
several tasks which it didn't execute. Important parts of the worm
simply didn't work. McMahon believed this failure to be accidental.
For example, his analysis showed the worm was programmed to break into
accounts by trying no password, if the account holder had left the
password blank. When he disassembled the worm, however, he found that
part of the program didn't work properly.
Nonetheless, the fragmented and partly dysfunctional WANK worm was
causing a major crisis inside several US government agencies. The
thing which really worried John was thinking about what a seasoned DCL
programmer with years of VMS experience could do with such a worm.
Someone like that could do a lot of malicious damage. And what if the
WANK worm was just a dry run for something more serious down the
track? It was scary to contemplate.
Even though the WANK worm did not seem to be intentionally evil, the
SPAN team faced some tough times. McMahon's analysis turned up yet
more alarming aspects to the worm. If it managed to break into the
SYSTEM account, a privileged account, it would block all electronic
mail deliveries to the system administrator. The SPAN office would not
be able to send electronic warnings or advice on how to deal with the
worm to systems which had already been seized. This problem was
exacerbated by the lack of good information available to the project
office on which systems were connected to SPAN. The only way to help
people fighting this bushfire was to telephone them, but in many
instances the main SPAN office didn't know who to call. The SPAN team
could only hope that those administrators who had the phone number of
SPAN headquarters pinned up near their computers would call when their
computers came under attack.
McMahon's preliminary report outlined how much damage the worm could
do in its own right. But it was impossible to measure how much damage
human managers would do to their own systems because of the worm.
One frantic computer manager who phoned the SPAN office refused to
believe John's analysis that the worm only pretended to erase data. He
claimed that the worm had not only attacked his system, it had
destroyed it. `He just didn't believe us when we told him that the
worm was mostly a set of practical jokes,' McMahon said. `He
reinitialised his system.' `Reinitialised' as in started up his system
with a clean slate. As in deleted everything on the infected
computer--all the NASA staff's data gone. He actually did what the
worm only pretended to do.
The sad irony was that the SPAN team never even got a copy of the data
from the manager's system. They were never able to confirm that his
machine had even been infected.
All afternoon McMahon moved back and forth between answering the
ever-ringing SPAN phone and writing up NASA's analysis of the worm. He
had posted a cryptic electronic message about the attack across the
network, and Kevin Oberman had read it. The message had to be
circumspect since no-one knew if the creator of the WANK worm was in
fact on the network, watching, waiting. A short time later, McMahon
and Oberman were on the phone together--voice--sharing their ideas and
cross-checking their analysis.
The situation was discouraging. Even if McMahon and Oberman managed to
develop a successful program to kill off the worm, the NASA SPAN team
faced another daunting task. Getting the worm-killer out to all the
NASA sites was going to be much harder than expected because there was
no clear, updated map of the SPAN network. Much of NASA didn't like
the idea of a centralised map of the SPAN system. McMahon recalled
that, some time before the WANK worm attack, a manager had tried to
map the system. His efforts had accidentally tripped so many system
alarms that he was quietly taken aside and told not to do it again.
The result was that in instances where the team had phone contact
details for managers, the information was often outdated.
`No, he used to work here, but he left over a year ago.'
`No, we don't have a telephone tree of people to ring if
something goes wrong with our computers. There are a whole
bunch of people in different places here who handle the
computers.'
This is what John often heard at the other end of the phone.
The network had grown into a rambling hodgepodge for which there was
little central coordination. Worse, a number of computers at different
NASA centres across the US had just been tacked onto SPAN without
telling the main office at Goddard. People were calling up the ad-hoc
crisis centre from computer nodes on the network which didn't even
have names. These people had been practising a philosophy known in
computer security circles as `security through obscurity'. They
figured that if no-one knew their computer system existed--if it
didn't have a name, if it wasn't on any list or map of the SPAN
network--then it would be protected from hackers and other computer
enemies.
McMahon handled a number of phone calls from system managers saying,
`There is something strange happening in my system here'. John's most
basic question was, `Where is "here"?' And of course if the SPAN
office didn't know those computer systems existed, it was a lot harder
to warn their managers about the worm. Or tell them how to protect
themselves. Or give them a worm-killing program once it was developed.
Or help them seal up breached accounts which the worm was feeding back
to its creator.
It was such a mess. At times, McMahon sat back and considered who
might have created this worm. The thing almost looked as though it had
been released before it was finished. Its author or authors seemed to
have a good collection of interesting ideas about how to solve
problems, but they were never properly completed. The worm included a
routine for modifying its attack strategy, but the thing was never
fully developed. The worm's code didn't have enough error handling in
it to ensure the creature's survival for long periods of time. And the
worm didn't send the addresses of the accounts it had successfully
breached back to the mailbox along with the password and account name.
That was really weird. What use was a password and account name
without knowing what computer system to use it on?
On the other hand, maybe the creator had done this deliberately. Maybe
he had wanted to show the world just how many computers the worm could
successfully penetrate. The worm's mail-back program would do this.
However, including the address of each infected site would have made
the admins' jobs easier. They could simply have used the GEMPAK
collection as a hitlist of infected sites which needed to be
de-wormed. The possible theories were endless.
There were some points of brilliance in the worm, some things that
McMahon had never considered, which was impressive since he knew a lot
about how to break into VMS computers. There was also considerable
creativity, but there wasn't any consistency. After the worm incident,
various computer security experts would hypothesise that the WANK worm
had in fact been written by more than one person. But McMahon
maintained his view that it was the work of a single hacker.
It was as if the creator of the worm started to pursue an idea and
then got sidetracked or interrupted. Suddenly he just stopped writing
code to implement that idea and started down another path, never again
to reach the end. The thing had a schizophrenic structure. It was all
over the place.
McMahon wondered if the author had done this on purpose, to make it
harder to figure out exactly what the worm was capable of doing.
Perhaps, he thought, the code had once been nice and linear and it all
made sense. Then the author chopped it to pieces, moved the middle to
the top, the top to the bottom, scrambled up the chunks and strung
them all together with a bunch of `GO TO' commands. Maybe the hacker
who wrote the worm was in fact a very elegant DCL programmer who
wanted the worm to be chaotic in order to protect it. Security through
obscurity.
Oberman maintained a different view. He believed the programming style
varied so much in different parts that it had to be the product of a
number of people. He knew that when computer programmers write code
they don't make lots of odd little changes in style for no particular
reason.
Kevin Oberman and John McMahon bounced ideas off one another. Both had
developed their own analyses. Oberman also brought Mark Kaletka, who
managed internal networking at Fermilab, one of HEPNET's largest
sites, into the cross-checking process. The worm had a number of
serious vulnerabilities, but the problem was finding one, and quickly,
which could be used to wipe it out with minimum impact on the besieged
computers.
Whenever a VMS machine starts up an activity, the computer gives it a
unique process name. When the worm burrowed into a computer site, one
of the first things it did was check that another copy of itself was
not already running on that computer. It did this by checking for its
own process names. The worm's processes were all called NETW_ followed
by a random, four-digit number. If the incoming worm found this
process name, it assumed another copy of itself was already running on
the computer, so it destroyed itself.
The answer seemed to be a decoy duck. Write a program which pretended
to be the worm and install it across all of NASA's vulnerable
computers. The first anti-WANK program did just that. It quietly sat
on the SPAN computers all day long, posing as a NETW_ process, faking
out any real version of the WANK worm which should come along.
Oberman completed an anti-WANK program first and ran it by McMahon. It
worked well, but McMahon noticed one large flaw. Oberman's program
checked for the NETW_ process name, but it assumed that the worm was
running under the SYSTEM group. In most cases, this was true, but it
didn't have to be. If the worm was running in another group, Oberman's
program would be useless. When McMahon pointed out the flaw, Oberman
thought, God, how did I miss that?
McMahon worked up his own version of an anti-WANK
program, based on Oberman's program, in preparation for releasing it
to NASA.
At the same time, Oberman revised his anti-WANK program for DOE. By
Monday night US Eastern Standard Time, Oberman was able to send out an
early copy of a vaccine designed to protect computers which hadn't
been infected yet, along with an electronic warning about the worm.
His first electronic warning, distributed by CIAC, said in part:
/////////////////////////////////////////////////////////////////////////
THE COMPUTER INCIDENT ADVISORY CAPABILITY C I A C
ADVISORY NOTICE
The W.COM Worm affecting VAX VMS Systems
October 16, 1989 18:37 PSTNumber A-2
This is a mean bug to kill and could have done a lot of damage.
Since it notifies (by mail) someone of each successful penetration and
leaves a trapdoor (the FIELD account), just killing the bug is not
adequate. You must go in and make sure all accounts have passwords and
that the passwords are not the same as the account name.
R. Kevin Oberman
Advisory Notice
A worm is attacking NASA's SPAN network via VAX/VMS systems connected
to DECnet. It is unclear if the spread of the worm has been checked.
It may spread to other systems such as DOE's HEPNET within a few days.
VMS system managers should prepare now.
The worm targets VMS machines, and can only be propagated via DECnet.
The worm exploits two features of DECnet/VMS in order to propagate
itself. The first is the default DECnet account, which is a facility
for users who don't have a specific login ID for a machine to have
some degree of anonymous access. It uses the default DECnet account to
copy itself to a machine, and then uses the `TASK 0' feature of DECnet
to invoke the remote copy. It has several other features including a
brute force attack.
Once the worm has successfully penetrated your system it will infect
.COM files and create new security vulnerabilities. It then seems to
broadcast these vulnerabilities to the outside world. It may also
damage files as well, either unintentionally or otherwise.
An analysis of the worm appears below and is provided by R. Kevin
Oberman of Lawrence Livermore National Laboratory. Included with the
analysis is a DCL program that will block the current version of the
worm. At least two versions of this worm exist and more may be
created. This program should give you enough time to close up obvious
security holes. A more thorough DCL program is being written.
If your site could be affected please call CIAC for more details...
Report on the W.COM worm.
R. Kevin Oberman
Engineering Department
Lawrence Livermore National Laboratory
October 16, 1989
The following describes the action of the W.COM worm (currently based
on the examination of the first two incarnations). The replication
technique causes the code to be modified slightly which indicates the
source of the attack and learned information.
All analysis was done with more haste than I care for, but I believe I
have all of the basic facts correct. First a description of the
program:
1. The program assures that it is working in a directory to which the
owner (itself) has full access (Read, Write, Execute, and Delete).
2. The program checks to see if another copy is still running. It
looks for a process with the first 5 characters of `NETW_'. If such is
found, it deletes itself (the file) and stops its process.
NOTE
A quick check for infection is to look for a process name starting
with `NETW_'. This may be done with a SHOW PROCESS command.
3. The program then changes the default DECNET account password to a
random string of at least 12 characters.
4. Information on the password used to access the system is mailed to
the user GEMTOP on SPAN node 6.59. Some versions may have a different
address.11
5. The process changes its name to `NETW_' followed by a random
number.
6. It then checks to see if it has SYSNAM priv. If so, it defines the
system announcement message to be the banner in the program:
W O R M S A G A I N S T N U C L E A R K I L L E R S
_______________________________________________________________
\__ ____________ _____ ________ ____ ____ __ _____/
\ \ \ /\ / / / /\ \ | \ \ | | | | / / /
\ \ \ / \ / / / /__\ \ | |\ \ | | | |/ / /
\ \ \/ /\ \/ / / ______ \ | | \ \| | | |\ \ /
\_\ /__\ /____/ /______\ \____| |__\ | |____| |_\ \_/
\___________________________________________________/
\ /
\ Your System Has Been Officically WANKed /
\_____________________________________________/
You talk of times of peace for all, and then prepare for war.
7. If it has SYSPRV, it disables mail to the SYSTEM account.
8. If it has SYSPRV, it modifies the system login command procedure to
APPEAR to delete all of a user's file. (It really does nothing.)
9. The program then scans the account's logical name table for command
procedures and tries to modify the FIELD account to a known password
with login from any source and all privs. This is a primitive virus,
but very effective IF it should get into a privileged account.
10. It proceeds to attempt to access other systems by picking node
numbers at random. It then uses PHONE to get a list of active users on
the remote system. It proceeds to irritate them by using PHONE to ring
them.
11. The program then tries to access the RIGHTSLIST file and attempts
to access some remote system using the users found and a list of
`standard' users included within the worm. It looks for passwords
which are the same as that of the account or are blank. It records all
such accounts.
12. It looks for an account that has access to SYSUAF.DAT.
13. If a priv. account is found, the program is copied to that account
and started. If no priv. account was found, it is copied to other
accounts found on the random system.
14. As soon as it finishes with a system, it picks another random
system and repeats (forever).
Response:
1. The following program will block the worm. Extract the following
code and execute it. It will use minimal resources. It creates a
process named NETW_BLOCK which will prevent the worm from running.
Editors note: This fix will work only with this version of the worm.
Mutated worms will require modification of this code; however, this
program should prevent the worm from running long enough to secure
your system from the worms attacks.13
////////////////////////////////////////////////////////////////////////
---
McMahon's version of an anti-WANK program was also ready to go by late
Monday, but he would face delays getting it out to NASA. Working inside
NASA was a balancing act, a delicate ballet demanding exquisite
choreography between getting the job done, following official procedures
and avoiding steps which might tread on senior bureaucrats' toes. It was
several days before NASA's anti-WANK program was officially released.
DOE was not without its share of problems in launching the anti-WANK
program and advisory across HEPNET. At 5.04 p.m. Pacific Coast Time on
17 October, as Oberman put the final touches on the last paragraph of
his final report on the worm, the floor beneath his feet began to
shake. The building was trembling. Kevin Oberman was in the middle of
the 1989 San Francisco earthquake.
Measuring 7.1 on the Richter scale, the Loma Prieta earthquake ripped
through the greater San Francisco area with savage speed. Inside the
computer lab, Oberman braced himself for the worst. Once the shaking
stopped and he ascertained the computer centre was still standing, he
sat back down at his terminal. With the PA blaring warnings for all
non-essential personnel to leave the building immediately, Oberman
rushed off the last sentence of the report. He paused and then added a
postscript saying that if the paragraph didn't make sense, it was
because he was a little rattled by the large earthquake which had just
hit Lawrence Livermore Labs. He pressed the key, sent out his final
anti-WANK report and fled the building.
Back on the east coast, the SPAN office continued to help people
calling from NASA sites which had been hit. The list of sites which
had reported worm-related problems grew steadily during the week.
Official estimates on the scope of the WANK worm attack were vague,
but trade journals such as Network World and Computerworld quoted the
space agency as suffering only a small number of successful worm
invasions, perhaps 60 VMS-based computers. SPAN security manager Ron
Tencati estimated only 20 successful worm penetrations in the NASA
part of SPAN's network, but another internal estimate put the figure
much higher: 250 to 300 machines. Each of those computers might have
had 100 or more users. Figures were sketchy, but virtually everyone on
the network--all 270000 computer accounts--had been affected by the
worm, either because their part of the network had been pulled
off-line or because their machines had been harassed by the WANK worm
as it tried again and again to login from an infected machine. By the
end of the worm attack, the SPAN office had accumulated a list of
affected sites which ran over two columns on several computer screens.
Each of them had lodged some form of complaint about the worm.
Also by the end of the crisis, NASA and DOE computer network managers
had their choice of vaccines, antidotes and blood tests for the WANK
worm. McMahon had released ANTIWANK.COM, a program which killed the
worm and vaccinated a system against further attacks, and
WORM-INFO.TEXT, which provided a list of worm-infestation symptoms.
Oberman's program, 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
Share with your friends: |