The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: 'Phage List' - Archives (1988 - 1989)
DOCUMENT: phage #035 [Steps in the virus, as best we know them (and fixes)] (1 message, 2226 bytes)
NOTICE: recognises the rights of all third-party works.


From: (Rich Kulawiec)
To: phage
Date: Fri 14:32:27 04/11/1988 EST
Subject: Steps in the virus, as best we know them (and fixes)
References: [Thread Prev: 065] [Thread Next: 041] [Message Prev: 032] [Message Next: 038]

I don't claim that all of this is definitive, or accurate; it's the
best I know right now after working on this for quite a while.  Please
don't flame me if I'm wrong about something; I'm simply trying to help.

1. Virus arrives via shell script using sendmail.  Uses debug mode
of sendmail to extract itself into temporary file in /usr/tmp,
named something like x1234567,l1.c.
This temporary file is a small C program, sort of like
a second-stage bootstrap.

(Telltale sign is a line like this:

	sed "1,/^$/d" | sh

in your sendmail log, on a message originating from /dev/null.)

	Fix: disable "debug" mode of sendmail
	This was sent out by Keith Bostic of Berkeley yesterday.

2. The second stage boot compiles small (40 line) C driver and executes it
with arguments giving the Internet originating point of the virus.  This
then sucks over the x1234567,vax.o and x1234567,sun3.o files.  It compiles
them into the file /usr/tmp/sh.

(Telltale sign: files with names like those given above in /usr/tmp.)

	Fix: Create /usr/tmp/sh as a directory.  This works because the
	script that creates /usr/tmp/sh from one of the .o files checks
	to see if /usr/tmp/sh exists, but not to see if it's a directory.
	Locally, we call this fix "the condom".

3. The driver executes /usr/tmp/sh, which does one or more of the
following items:

	a. Check /etc/hosts to find other targets; use netstat -r
	in some way to ascertain which hosts are currently accessible
	and/or nearby and/or something else.

	c. Attempt to infiltrate systems via fingerd; there is another
	bug, discovered independently here and at U. Rochester (at
	least) which involves overwriting a buffer inside fingerd.
	If fingerd is setuid X, the program will gain access to X.

		Fix: plug fingerd bug or disable.  We have a patch to
	fingerd, but I don't have it on my desk right now.  Frankly,
	fingerd is not an essential service, so if all else fails,
	just turn off the setuid bits. Miek Rowan and Mike Spitzer of PUCC
	found this one locally.

	c. Attempt to infiltrate systems via telnetd

		Whatever bug it's trying to exploit, we don't have it.
	I'm not really sure what it's trying to do.

	d. Attempt to infiltrate systems via rexecd

		Same comment as (c).

	e. Use /usr/dict/words to crack passwords

		Apparently, it will spend quite a bit of time
	trying this once it starts.

	f. Attempt to infiltrate systems via .rhosts and hosts.equiv.

		These last two seem to be related; if it breaks into
	an account, it attempts to see where else it can go by using
	.rhosts and hosts.equiv.  The virus broke half a dozen
	fairly easy passwords here, and appears to apply a moderately
	good approach to cracking passwords using the wordlist; we
	also know that it got here, to, from via a .rhosts file.

	Fix: modify rsh/rlogin to disable .rhosts. WE DID NOT apply
	this fix, because of the tremendous difficulties that it would
	cause.  We don't think, at this time, that it's necessary
	if the other steps are taken.

4. Another fix: add a dummy module, say _worm.o, to libc.a, which
	is produced from:

		int pleasequit = -1;

The virus doesn't correctly initialize this value, so when it compiles
with libc.a and runs, the fact that this value is set to -1 will cause
it to exit.  Kevin Braunsdorf of PUCC found this, at least here.

5. A note: the .o files are profiled -- is it possible that the virus
escaped while being tested?

6. I have applied "unas" to the virus vax.o file and will make it available
for anonymous FTP on shortly; the file is about 400 kbytes,
and will be called 'virus.dis'.  Just FTP in as anonymous/guest, and grab it,
if you'd like to go through it.  I have been doing this all night, but my
Vax assembly language skills are not good, so perhaps others with more
insight will do more.

7. Another note; if gcore an instance of the virus and XOR it with 81 hex,
you'll find all the text strings that are in it.  Sam Kimery of ECN found
this last night.

Rich Kulawiec, PUCC.