VIRUS-L Digest Thursday, 10 Nov 1988 Volume 1 : Issue 2 Today's Topics: Houston Virus RE: About the Virus Notices ascii pictures A list of virus victims. Apple (Mac) Virus on our Campus Re: Macintosh "worms" Application -- is this a virus? (2 messages) --------------------------------------------------------------------------- Date: Wed, 9 Nov 88 16:46 EST From: Subject: Houston Virus To: virus-l@lehiibm1 Has anybody heard any about The University of Houston getting hit by a virus???--Apparently it was enough to get them on the morning news here on CBS radio, the report said the virus had been found to have ``originated in a shop in Pakistan''---This sounded like just another BRAIN hit but wasn't sure... I'd interestedif anybody out there might have any further info... Thanx, Steve - -------------- Steve Okay ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source "Why is it whenever Democrats form a firing squad They make a circle?" --David Brinkley ------------------------------ Date: Wed, 9 Nov 88 17:19 EST From: Subject: RE: About the Virus Notices To: VIRUS-L@LEHIIBM1 >From: jnet%"SSIRCAR@UMAECS" 9-NOV-1988 16:36 >Subject: About the virus notices > >Can we get a little organized around here? I have just received two messages >... >RISK concerning the virus. > -Santanu Sircar- I have to agree...the number of repeats got to be quite much during this last major outbreak... Out of 40 messages I received about the Internet Virus only about 12-13 were different /new/non-repetitive. I was even getting messages from people a few days after the fact with the Subject: WARNING!!NEW UNIX VIRUS. Can we do something about control/repetition here? Granted you can't control what somebody is going to say, or how many people are going to say it, but I think Santanu has a good idea at least when it comes to importing or crossmailing from other groups/lists ------------------------------ Date: WED NOV 09, 1988 17.47.11 EST From: "David A. Bader" Subject: ascii pictures To: "Virus Discussion List" I have received numerous flames and apologies from people about the last memo that was sent to VIRUS-L by me regarding the posting of acsii pictures. This message was directed to the user (since removed from VIRUS-L) who posted the garbage. Sorry for not me more explicit, David ------------------------------ Date: 09 Nov 88 18:49:00 EST From: Michael Brown To: Subject: A list of virus victims. I would like to compile a list of all of the universities that have been hit with virus's of some sort. Before I undergo such a task, I was wondering if anyone out there is working on such a project already. CP6-Mail: Michael Brown @CMR NET-Mail: Michael Brown Snail-Mail: Service Informatique CMR, St-Jean, Que. J0J 1R0 [Ed. I know that at least one person (Cliff Stoll?) is working on a list of RTM (Robert T. Morris, Jr.) worm victims; that is, the alleged author of the Internet Worm.] ------------------------------ Date: Wed, 9 Nov 88 11:29 MDT From: "David D. Grisham" Subject: Apple (Mac) Virus on our Campus To: virus-l@lehiibm1 Hi group, It has been a busy week with the INTERNET worm and the Apple infection I requested info from you all on. Our MACs (all, including file servers) have a nasty little bug. It has been identified as an nVir strain. I have received some notes from others fighting this, THANKS for your input. Kathy just reminded me that I have neglected to give you follow up info. This virus DOES infect VirusRx, causing a nasty transformation of your program to a useless unreadable (text?) file called, "THROW ME IN THE TRASH". It also appears to be one of the strains that upon infecting a system file contaminates every application (in a second or two). Our temporary solution: We clean with interferon 3.0 then place VirusRx on our systems NEW each day. When we get an activation from a dormant nVir or a new infection the VirusRx is turned in to "THROW ME IN THE TRASH". We then clean-up with Interferon 3.0 again, setting up VirusRx new to act as an alarm. dave **************************************************************************** * * * Dave Grisham * * Senior Staff Consultant/Virus Security Phone (505) 277-8148 * * Information Resource Center * * Computer & Information Resources & Technology * * University of New Mexico USENET DAVE@UNMA.UNM.EDU * * Albuquerque, New Mexico 87131 BITNET DAVE@UNMB * * * **************************************************************************** ------------------------------ Date: Wed, 09 Nov 88 17:23:29 EST From: Joe McMahon Subject: Re: Macintosh "worms" Application -- is this a virus? To: Virus Discussion List In-Reply-To: Message of Tue, 8 Nov 88 10:02:51 -0500 from >A local Mac user tells me that he recently discovered a new application >on his disk, called "worms". Running it pops up a little display with >worms crawling around on it. Yes. This was inspired by a Scientific American column last year (maybe the year before), which detailed how to make this type of animation work. It is simply a graphics application. I've seen it before on CompuServe. As I recall, it was a MultiFinder demo, since it could run in the background while you were doing other work. >He doesn't know where it came from. He claims that he does not share >disks with people. He is connected to an AppleTalk network, which is >connected to a FastPath. Well, it's certainly possible that: 1) Someone gave it to him when they "borrowed" his machine as a thank-you. 2) Ditto, but as a warning that his physical security is weak. 3) He actually *did* get it from somewone else and is now scared to death that he's handed the local net a worm/virus. 4) A local reversal in the entropy gradient caused a fully-fledged program to appear on his disk without any other computer being involved. ;-) >Now, in light of the Internet Worm, he's feeling suspicious about this >Macintosh Worm of unknown origin. Is it possible that it's a virus? >Has anyone else seen this application? See above. It's merely a play-toy and nothing to worry about, other than the normal "check it out and see if there are viruses (the known ones) in it". - --- Joe M. ------------------------------ Date: Thu, 10 Nov 88 12:36 GMT From: Danny Schwendener Subject: RE: Macintosh "worms" Application -- is this a virus? To: virus-l@lehiibm1 >>A local Mac user tells me that he recently discovered a new application >>on his disk, called "worms". Running it pops up a little display with >>worms crawling around on it. > >[...] >If this *IS* a virus of some sort, particularly a (ugh!) network virus, >please let me know. If it is the original, non-infected program, it isn't a virus. Worm is similar to Measles in that it is thought as animated desktop background. The difference is that Measles (and its twin brother Crabs) was written for older macs, produces small dots or crabs which eat up everything on your desktop, including windows (no physical damage) and can only be stopped by a reboot, while Worm is thought as a color Multifinder background application, where the worms dig their way through an apple logo. The program was originally posted on comp.binaries.mac, I think. - -- Danny +-----------------------------------------------------------------------+ | Mail : Danny Schwendener, ETH Macintosh Support Center | | Swiss Federal Institute of Technology, CH-8092 Zuerich | | Bitnet : macman@czheth5a UUCP : {cernvax,mcvax}ethz!macman | | Ean : macman@ifi.ethz.ch Voice : yodel three times | +-----------------------------------------------------------------------+ ------------------------------ End of VIRUS-L Digest ********************* ========================================================================= Date: Thu, 10 Nov 88 08:41:04 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: (hopefully) relavant Internet Worm discussion from RISKS The following articles contain more detailed descriptions of the recent Internet Worm; they were taken from RISKS digest volume 7 Issue 73. Ken From: RISKS FORUM Subject: RISKS DIGEST 7.73 Comments: To: RISKS-LIST@KL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Wednesday 9 November 1988 Volume 7 : Issue 73 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator --------------------------------------------------------------------------- Date: Tue, 8 Nov 88 21:40:00 PST From: geoff@fernwood.mpk.ca.us (the tty of Geoff Goodfellow) Subject: NYT/Markoff: The Computer Jam -- How it came about THE COMPUTER JAM: HOW IT CAME ABOUT By JOHN MARKOFF c.1988 N.Y. Times News Service, 8-Nov-88 Computer scientists who have studied the rogue program that crashed through many of the nation's computer networks last week say the invader actually represents a new type of helpful software designed for computer networks. The same class of software could be used to harness computers spread aroun the world and put them to work simultaneously. It could also diagnose malfunctions in a network, execute large computations on many machines at once and act as a speedy messenger. But it is this same capability that caused thousands of computers in universities, military installations and corporate research centers to stall and shut down the Defense Department's Arpanet system when an illicit version of the program began interacting in an unexpected way. ``It is a very powerful tool for solving problems,'' said John F. Shoch, a computer expert who has studied the programs. ``Like most tools it can be misued, and I think we have an example here of someone who misused and abused the tool.'' The program, written as a ``clever hack'' by Robert Tappan Morris, a 23-year-old Cornell University computer science graduate student, was originally meant to be harmless. It was supposed to copy itself from computer to computer via Arpanet and merely hide itself in the computers. The purpose? Simply to prove that it could be done. But by a quirk, the program instead reproduced itself so frequently that the computers on the network quickly became jammed. Interviews with computer scientists who studied the network shutdown and with friends of Morris have disclosed the manner in which the events unfolded. The program was introduced last Wednesday evening at a computer in the artificial intelligence laboratory at the Massachusetts Institute of Technology. Morris was seated at his terminal at Cornell in Ithaca, N.Y., but he signed onto the machine at MIT. Both his terminal and the MIT machine were attached to Arpanet, a computer network that connects research centers, universities and military bases. Using a feature of Arpanet, called Sendmail, to exchange messages among computer users, he inserted his rogue program. It immediately exploited a loophole in Sendmail at several computers on Arpanet. Typically, Sendmail is used to transfer electronic messages from machine to machine throughout the network, placing the messages in personal files. However, the programmer who originally wrote Sendmail three years ago had left a secret ``backdoor'' in the program to make it easier for his work. It permitted any program written in the computer language known as C to be mailed like any other message. So instead of a program being sent only to someone's personal files, it could also be sent to a computer's internal control programs, which would start the new program. Only a small group of computer experts _ among them Morris _ knew of the backdoor. As they dissected Morris's program later, computer experts found that it elegantly exploited the Sendmail backdoor in several ways, copying itself from computer to computer and tapping two additional security provisions to enter new computers. The invader first began its journey as a program written in the C language. But it also included two ``object'' or ``binary'' files -- programs that could be run directly on Sun Microsystems machines or Digital Equipment VAX computers without any additional translation, making it even easier to infect a computer. One of these binary files had the capability of guessing the passwords of users on the newly infected computer. This permits wider dispersion of the rogue program. To guess the password, the program first read the list of users on the target computer and then systematically tried using their names, permutations of their names or a list of commonly used passwords. When successful in guessing one, the program then signed on to the computer and used the privileges involved to gain access to additonal computers in the Arpanet system. Morris's program was also written to exploit another loophole. A program on Arpanet called Finger lets users on a remote computer know the last time that a user on another network machine had signed on. Because of a bug, or error, in Finger, Morris was able to use the program as a crowbar to further pry his way through computer security. The defect in Finger, which was widely known, gives a user access to a computer's central control programs if an excessively long message is sent to Finger. So by sending such a message, Morris's program gained access to these control programs, thus allowing the further spread of the rogue. The rogue program did other things as well. For example, each copy frequently signaled its location back through the network to a computer at the University of California at Berkeley. A friend of Morris said that this was intended to fool computer researchers into thinking that the rogue had originated at Berkeley. The program contained another signaling mechanism that became its Achilles' heel and led to its discovery. It would signal a new computer to learn whether it had been invaded. If not, the program would copy itself into that computer. But Morris reasoned that another expert could defeat his program by sending the correct answering signal back to the rogue. To parry this, Morris programmed his invader so that once every 10 times it sent the query signal it would copy itself into the new machine regardless of the answer. The choice of 1 in 10 proved disastrous because it was far too frequent. It should have been one in 1,000 or even one in 10,000 for the invader to escape detection. But because the speed of communications on Arpanet is so fast, Morris's illicit program echoed back and forth through the network in minutes, copying and recopying itself hundreds or thousands of times on each machine, eventually stalling the computers and then jamming the entire network. After introducing his program Wednesday night, Morris left his terminal for an hour. When he returned, the nationwide jamming of Arpanet was well under way, and he could immediately see the chaos he had started. Within a few hours, it was clear to computer system managers that something was seriously wrong with Arpanet. By Thursday morning, many knew what had happened, were busy ridding their systems of the invader and were warning colleagues to unhook from the network. They were also modifying Sendmail and making other changes to their internal software to thwart another invader. The software invader did not threaten all computers in the network. It was aimed only at the Sun and Digital Equipment computers running a version of the Unix operating system written at the University of California at Berkeley. Other Arpanet computers using different operating systems escaped. These rogue programs have in the past been referred to as worms or, when they are malicious, viruses. Computer science folklore has it that the first worms written were deployed on the Arpanet in the early 1970s. Researchers tell of a worm called ``creeper,'' whose sole purpose was to copy itself from machine to machine, much the way Morris's program did last week. When it reached each new computer it would display the message: ``I'm the creeper. Catch me if you can!'' As legend has it, a second programmer wrote another worm program that was designed to crawl through the Arpanet, killing creepers. Several years later, computer researchers at the Xerox Corp.'s Palo Alto Research Center developed more advanced worm programs. Shoch and Jon Hupp developed ``town crier'' worm programs that acted as messengers and ``diagnostic'' worms that patrolled the network looking for malfunctioning computers. They even described a ``vampire'' worm program. It was designed to run very complex programs late at night while the computer's human users slept. When the humans returned in the morning, the vampire program would go to sleep, waiting to return to work the next evening. [Please keep any responses short and to the point. PGN] ------------------------------ Return-Path: <@HERCULES.CSL.SRI.COM,@ames.arc.nasa.gov:mr-frog@fxgrp.UUCP> Date: Fri, 4 Nov 88 17:22:33 PST From: Dave Pare Subject: decompiled viruses Last night a massive effort to decompile the "internet virus" was made by half a dozen people working at the CSRG in Berkeley. Most of the code is complete now, and most of the guesses that people have made were right on insofar as how it works, what it targets, and how it is distributed. Precautions were taken by the author to clean up intermediate files, to use XOR functions on program strings, repeated forks, making many static procedures and using the linker to remove (presumably) suspicious-looking procedure names, naming the program "sh", etc, in order to better protect the program from detection and identification. This was definitely a deliberate action; quite a number of precautions were taken to hide the process. The program was also fairly sophisticated in concept. It doesn't appear that the primary *motivation* of the author was the overloading of the target machine. There were several bugs encountered during decompilation, (most notably a "bzero(foo, sizeof(foo))", where foo is a struct) which may have accounted for the program's obnoxious and apparently unintentional behavior. In my opinion, had the author tested this program more completely, it would have been quite a while longer before it was detected. While this incarnation of the program was a serious nuisance, a correctly-working version would have been far more insidious. It would have required a very curious system manager to notice an "innocuous" daemon listening to an unusual internet port number, or strange-looking messages in the sendmail syslog. When someone who really knows how to code finally writes one of these things, we may never find out about it until weeks or months later. Although this program doesn't modify existing programs on affected systems, future ones might -- heck, they may have already done so. Dave Pare ------------------------------ Date: Mon, 7 Nov 88 18:44:33 PST From: "Clifford Johnson" Subject: Worms/viruses/moles/etc. and the risk of nuclear war > From: Brad Templeton > People are talking as though there's some > surprising end-of-the-world potential in this event... > University systems are designed, and should be designed as > low-caution, high convenience systems... The press > will want sensationalistic answers, but if you're talking to > them, try to steer them away from all the comments about > "War Games." I was interviewed specifically on whether the worm illustrated a potential cause of nuclear Armageddon. (Bay Area TV Channel 7 (ABC), 11pm news Nov.4, lead story.) My answer was a qualified affirmative, and I think an unqualified negative irresponsible. Directly asked whether "War Games" was a good analogy, I responded that things were generally headed that way but that the Vincennes shootdown was a closer analogy to the present parlous state. (The Pentagon having concluded that no person was at fault for the mistaken shootdown, the cause was by default computer-related error.) In some circumstances, a computer virus/worm could be a determinative factor precipitating a nuclear strike. Nuclear command and control computerization involves two functionally distinct sets of systems: (a) those for *executing* a nuclear attack a la SIOP recipes; (b) those for *prompting* a strike by informing the military (or political) leaders that an attack should be launched, which includes notice of (predefined) preemptive and launch on warning contingencies. Execute command systems could be relatively closed; and hence are, or could be managed so as to be, relatively secure. Nevertheless, it gives pause that the system requires that underground officers respond immediately if valid launch codes are suddenly received through electronic communication channels. Note well that message traffic processed in the launch control capsules has greatly increased in recent years. Re the strategic and tactical warning systems, they are already based on networked/workstation systems, i.e. the IDHS (Intelligence Data Handling System), and DEFSMAC, which link the CIA, NSA, DIA, JCS, NORAD, and SIOP-CINCS. These are of the same ilk as Arpanet/Milnet, and access is very wide, albeit not public. Intelligence-gathering/data-fusion by its function requires a network open to diverse and disparate inputs, and so is vulnerable to disruption/confusion by viruses/worms et alia. While such systems may be impervious to telenet attack, and while published "bugs" like the UNIX debug option may be foreclosed in them, the potential for implanting subtle bugs/traps in the software is plain, and that is but one potential source of error. Infiltration of software companies/military programming seems easy and suggests *real* espionage possibilities that are frightening in their scope and mulitplicity. Also frightening is that the apparent failure of nodes in the tactical warning net is interpreted as notice that those nodes may have been destroyed in a nuclear attack. (NORAD and other testimony admits this.) There is manifestly the potential for accidental/malicious net malfunctions causing a catastrophic nuclear panic. As for the trends, despite first appearances, the "Star Wars" system would greatly add to U.S. vulnerability rather than to security by resting U.S. strategic execution (as well as warning) upon a huge network of systems, much harder to secure than the present execution system. The warning system also becomes much more complex. The funded National Test Bed is in essence the development of such vulnerable networks for strategic warning and execution. The pace of technology is not the *imperative* that the military claim must be followed so as to sustain deterrence. The probable futility of plugging holes in vast computer networks is at least as vital a message as the message that known holes can be effectively patched. The fact that the military widely use complex networks in nuclear planning means that a most urgent lesson is that we must avoid critical reliance on them, not merely that we should carry on under the placebo of plugging what holes are identified. ------------------------------ Date: Mon, 7 Nov 88 07:56:14 PST From: manis@grads.cs.ubc.ca (Vince Manis) Subject: The Worm Our site apparently didn't get hit, because our newly installed NSFnet router has been so flaky that it has been unusable. Just goes to show, I guess. I was struck by the fact that the biggest hole was the `debug' option in sendmail. Since it has been well-known for about 15 years that allowing anonymous remote execution is a tremendous danger, and since (I assume) sendmail, in the standard distribution, comes with it disabled, one has to ask why SA's were enabling it. I'm not entirely sure that all the blame should go to the worm's author (putatively Mr Morris). If the assumption in the previous paragraph is false, then perhaps UCB, Sun, and Mt Xinu (among others) are at least morally culpable, too. ========================================================================= Downloaded From P-80 International Information Systems 304-744-2253