| <<< RAINBO::$2$DJA6:[NOTES$LIBRARY]WOMANNOTES-V2.NOTE;1 >>>
-< Topics of Interest to Women >-
================================================================================
Note 279.0 VIRUS Attacking Sun and VAX running Unix 1 reply
MARMAT::JERRY "Perfessor Quintessence" 251 lines 7-NOV-1988 10:15
--------------------------------------------------------------------------------
From: CIMNET::STRUDL::SCHOELLER "Lisa Robinson Schoeller 291-7523
MET-2/L2 04-Nov-1988 1003" 4-NOV-1988 10:06
To: cimnet::cmpd_all
Subj: Here's some information on the latest computer virus that made
national news. It seems to be attacking Sun and VAX running Unix.
<<< HUMAN::DISK$HUMAN_WRKD:[NOTES$LIBRARY]DIGITAL.NOTE;1 >>>
================================================================================
Note 655.7 Computer Virus? 7 of 7
TWIRL::HCROWTHER "Harry Crowther = USIS = 223-1110" 234 lines 4-NOV-1988 08:55
--------------------------------------------------------------------------------
[The following is part of RISKS_DIGEST Note 75.0. It is understood that
this virus only effects UNIX systems. According to this note, it could
not have effected VMS systems.]
--------------------------------------------------------------------------------
RISKS-LIST: RISKS-FORUM Digest Thursday 3 November 1988 Volume 7 : Issue 69
----------------------------------------------------------------------
Date: Thu, 3 Nov 88 06:46 EST
From: [email protected]
Subject: Virus on the Arpanet - Milnet
Re Arpanet "Sendmail" Virus attack November 3, 1988
Hi Gang!
It's now 3:45 AM on Wednesday 3 November 1988. I'm tired, so don't believe
everything that follows...
Apparently, there is a massive attack on Unix systems going on right now.
I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem.
Symptom: hundreds or thousands of jobs start running on a Unix system
bringing response to zero.
Systems attacked: Unix systems, 4.3BSD unix & variants (eg: SUNs) any
sendmail compiled with debug has this problem. See below.
This virus is spreading very quickly over the Milnet. Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites. I suspect that well over 50 sites have
been hit. Most of these are "major" sites and gateways.
Method:
Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility. This utility can send a message into another program.
Step 1: from a distant Milnet host, a message is sent to Sendmail
to fire up SED, (SED is an editor) This is possible in certain
versions of sendmail (see below).
2: A 99 line C program is sent to SED through Sendmail.
3: The distant computer sends a command to compile this C program.
4: Several object files are copied into the Unix computer.
There are 3 files: one targeted to Sun
one targeted to SUN-3
one targeted to vax (ultrix probably, not vms)
5: The C program accepts as address other Milnet sites
6: Apparently, program scans for other Milnet/arpanet addresses and
repeats this process.
The bug in Sendmail:
When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it.
Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug.
It exists only where the system manager recompiled Sendmail and enabled
debugging.
This is bad news.
Cliff Stoll dockmaster.arpa
------------------------------
Date: Thu, 03 Nov 88 09:52:18 EST
From: Gene Spafford <[email protected]>
Subject: More on the virus
Organization: SERC, Department of Computer Sciences, Purdue Univ.
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.
--spaf
------------------------------
Date: Thu, 3 Nov 1988 14:27:22 PDT
From: Peter Neumann <[email protected]>
Subject: More on the virus attack
Remember that the above are preliminary messages relating to an event in
progress. There seem to be many unanswered questions. Perhaps someone will
contribute a definitive report to the next issue of RISKS.
Examination of the code suggests a fairly sophisticated person writing
relatively high quality (although undocumented) code, exploiting several flaws
that exist(ed) on many UNIX systems, and written with considerable good
practice in self-checking, reliability, etc. From the evidence thus far, I
would guess it that this was a deliberate attack, not an accidental experiment
run astray.
Although it was primarily a denial of service attack, it did some remarkable
things, taking advantage of many different approaches. The spawned
processes appear to have been doing attacks on encrypted passwords to enable
ftps (in case the .rhost attack would not work -- cf. the Stanford breakins
described in CACM and SEN by Brian Reid). Separate versions to run on Suns
and Vaxens were apparently propagated in DES encrypted form, decrypted, and
both programs tried to see which one would work.
We quoted Henry Petroski here over a year ago to the effect that we do not
learn from our successes, but that we have an opportunity to learn from our
failures. Once again we are presented with the opportunity to learn that many
of our computer systems have serious security vulnerabilities, and that we need
to take pains to defend against the really malicious attacks. Strangely some
people take heart in the fact that the security attacks to date (whether
penetrations, exploitations of privilege, Trojan horses, or legitimate viruses)
have been relatively modest in scale, perhaps to justify the absence of
concern. I am afraid that it will take a Chernobyl- or Three-Mile-Island-like
disaster before the community at large wakes up. PGN
------------------------------
Date: Thu, 3 Nov 88 16:32:25 EST
From: [email protected] (Matt Bishop)
Subject: More on the virus
... This program introduced itself through a bug in sendmail. At these sites,
sendmail was compiled and installed with a debugging option turned on. As near
as I can figure (I don't have access to the sendmail sources), by giving a
specific option to the "debug" command in sendmail (there are lots of those,
controlling what exactly you get information about) you can cause it to execute
a command. As sendmail runs setuid to root, guess what privileges the command
is executed with. Right.
Apparently what the attacker did was this: he or she connected to sendmail
(ie, telnet victim.machine 25), issued the appropriate debug command, and had
a small C program compiled. (We have it. Big deal.) This program took
as an argument a host number, and copied two programs -- one ending in
q.vax.o and the other ending in .sun.o -- and tried to load and execute them.
In those cases where the load and execution succeeded, the worm did two things
(at least): spawn a lot of shells that did nothing but clog the process table
and burn CPU cycles; look in two places -- the password file and the internet
services file -- for other sites it could connect to (this is hearsay, but I
don't doubt it for a minute.) It used both individual .rhost files (which it
found using the password file), and any other remote hosts it could locate
which it had a chance of connecting to. It may have done more; one of our
machines had a changed superuser password, but because of other factors we're
not sure this worm did it.
This last part is still sketchy; I have the relevant sun.o file and will
take it apart to see just what it was supposed to do. As of now, it appears
there was no serious damage (just wasted CPU cycles and system administrator
time).
Two obvious points:
1. Whoever did this picked only on suns and vaxen. One site with a lot
of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
but the attempt to get the other machines didn't work.
2. This shows the sorry state of software and security in the UNIX world.
People should NEVER put a program with debugging hooks in it, especially
when the hook is (or can be made) to execute an arbitrary command. But
that is how the sendmail which was used was distributed!
One more interesting point: initially, I thought an application of the
"principle of least privilege" would have prevented this penetration. But
the attacker used a world-writeable directory to squirrel the relevant programs
in, so -- in effect -- everything could have been done by any user on the
system! (Except the superuser password change, of course -- if this worm
did in fact do it.)
I think the only way to prevent such an attack would have been to turn
off the deug option on sendmail; then the penetration would fail. It goes to
show that if the computer is not secure (and like you, I don't believe there
ever will be such a beastie), there is simply no way to prevent a virus (or,
in this case, a worm) from getting into that system.
I know this is somewhat sketchy, flabby, and fuzzy, but it's all I know
so far. I'll keep you posted on developments ...
Matt
------------------------------
|