The 'Security Digest' Archives (TM)

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #001 [More on the virus] (1 message, 2148 bytes)
SOURCE: http://securitydigest.org/exec/display?f=phage/archive/001.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

From: Gene Spafford <spaf>
To: [not phage]
Date: Thu 10:36:28 03/11/1988 EST
Subject: More on the virus
References: [Thread Prev: 000] [Thread Next: 012] [Message Prev: 000] [Message Next: 002]

I hope Keith (Bostic) has more information on this, but I thought I'd
share with you what I've been able to piece together by looking at the
binaries and netstat info left by these virus:

(Almost?) all of our Vaxen and some of our Suns here were infected with
the virus.  The virus 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 virus seems to consist of two parts.  I managed to grab the source
code for one part, but not the main component (the virus cleans up
after itself so as not to leave evidence).  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 gets a shell.

2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets
replaced by the current process id) and copies code for a "listener" or
"helper" program.  This is just a few dozen lines long and fairly
generic code.  The shell compiles this helper using the "cc" command
local to the system.

3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments).

4) 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 virus 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:

5) The newly exec'd shell attempts to compile itself from the files
copied over to the target machine.  I'm not sure what else the virus
does, if anything -- it may also be attempting to add a bogus passwd
file entry or do something to the file system.  The helper program has
an array of 20 filenames for the "helper" to copy over, so there is
room to spare.  There are two versions copied -- a version for Vax BSD
and a version for SunOS; the appropriate one is compiled.

6) The new virus is dispatched.  This virus opens all the virus 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 virus
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).

The heavy load we see is the result of multiple viruses coming in
from multiple sites.  Since local hosts files tend to have entries
for other local hosts, the virus tends to infect local machines
multiple times -- in some senses this is lucky since it helps
prevent the spread of the virus as the local machines slow down.

The virus also "cleans" up after itself.  If you reboot an infected
machine (or it crashes), the /tmp directory is normally cleaned
up on reboot.  The other incriminating files were already deleted
by the virus itself.

Clever, nasty, and definitely anti-social.  How do we track who did
it?

--spaf

END OF DOCUMENT