From: IN%"POSTMASTER@EMBL.BITNET" "General PostMaster" 7-FEB-1990 17:32:55.99 To: HARPER@cc.Helsinki.FI CC: Subj: Automatic response to : GET SOFTWARE:BIOBIT.1 Received: from jnet-daemon by cc.Helsinki.FI; Wed, 7 Feb 90 17:32 EET DST Received: From EMBL(NETSERV) by FINUHB with Jnet id 4738 for HARPER@FINUH; Wed, 7 Feb 90 17:31 O Date: Wed, 07 Feb 90 16:03:49 From: EMBL Network File Server Subject: Automatic response to : GET SOFTWARE:BIOBIT.1 To: HARPER@cc.Helsinki.FI Reply-to: General PostMaster Organisation: European Molecular Biology Laboratory Postal-address: Meyerhofstrasse 1, 6900 Heidelberg, W. Germany MMMMMMMMMM MMM MMMMMMMMMM MMMMMMMMMM MMM MMMMMMMMMMM MMMMMMMMMM MMMMMMMMMM MMMMMMMMMM MMMMMMMMMMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMMMMMMM MMM MMM MMM MMMMMMMM MMM MMM MMMMMMMM MMM MMM MMM MMMMMMMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMMMMMMMMM MMM MMMMMMMMMM MMMMMMMMMM MMM MMM MMMMMMMMMM MMM MMMMMMMMMM MMMMMMMMMM MMM MMM %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -= INDEPENDANT NEWSLETTER PRODUCED BY HELSINKI UNIVERSITY =- << EDITED BY ROBERT HARPER >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% * Greetings from the Finland station This is the first edition of BIOBIT. Let me explain the name. It is a newsletter that is aimed at "BIOlogists" and it will contain BITS and peices of information that are available on the net. BIOBIT will act as an information broker, and hopefully it will help you to utilize BITNET more effectively. It is intended to be informative, and exhaustive about the subjects under discussion... but hopefully not exhausting. The first issue of BIOBIT is about VIRUSES... the kind that infect computers and wreck havoc on hard disks. There is a introduction to VIRUS-L list, and how to subscribe to it. I also include a listing of some of the files that are available from VIRUS-L that might be of help to you in protecting your computer against viral infections. Prevention is better than cure. And finally there is an article which summarises what has been happening in the computer virus world. If you have data or databases that might be at risk then I am sure that by reading the following article you will at least be informed as to what kind of attacks are likely, and also be able to take some sort of preventive measures. BIOBIT will appear on an irregular basis and if you have any comments or suggestions you can e-mail them to either HARPER@FINFUN or BIOBIT@com.kpo.fi Robert Harper (Helsinki University Finland) network address: HARPER@FINFUN %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Information about the VIRUS-L and how to subscribe to it %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Welcome! This is the monthly introduction posting for VIRUS-L, primarily for the benefit of any newcomers. Apologies to all subscribers who've already read this in the past (you'll only have to see it once a month and you can, if you're quick, press the purge key...:-). What is VIRUS-L? It is an electronic mail discussion forum for sharing information about computer viruses. Discussions should include (but not necessarily be limited to): current events (virus sightings), virus prevention (practical and theoretical), and virus questions/answers. The list is non-moderated and non-digested. That means that any message coming in goes out immediately. Weekly logs of submissions are kept for those people who prefer digest format lists (see below for details on how to get them). What isn't VIRUS-L? A place to spread hype about computer viruses; we already have the Press for that. :-) A place to sell things, to panhandle, or to flame other subscribers. If anyone *REALLY* feels the need to flame someone else for something that they may have said, then the flame should be sent directly to that person and/or to the list moderator (that'd be me, ). How do I get on the mailing list? Well, if you're reading this, chances are *real good* that you're already on the list. However, perhaps this document was given to you by a friend or colleague... So, to get onto the VIRUS-L mailing list, send a mail message to . In the body of the message, say nothing more than SUB VIRUS-L your name. LISTSERV is a program which automates mailing lists such as VIRUS-L. As long as you're either on BITNET, or any network accessible to BITNET via gateway, this should work. Within a short time, you will be placed on the mailing list, and you will get confirmation via e-mail. How do I get OFF of the list? If, in the unlikely event, you should happen to want to be removed from the VIRUS-L discussion list, just send mail to saying SIGNOFF VIRUS-L. People, such as students, whose accounts are going to be closed (like over the summer...) - PLEASE signoff of the list before you leave. Also, be sure to send your signoff request to the LISTSERV and not to the list itself. Note that the appropriate node name is LEHIIBM1, not LEHIGH; we have a node called LEHIGH, but they are *NOT* one and the same. How do I send a message to the list? Just send electronic mail to and it will automatically be redistributed to everyone on the mailing list. By default, you will NOT receive a copy of your own letters. If you wish to, send mail to saying SET VIRUS-L REPRO I can't submit anything to the list - what's wrong? There have been a few cases where people found that they were unable to send anything in to VIRUS-L even though they were registered subscribers (only subscribers can participate). Let me try to explain. The LISTSERV program differentiates lowercase from UPPERCASE. So, if you've subscribed to the list as (for example) OPUS@BLOOM.COUNTY.EDU and your mail is actually coming through as Opus@Bloom.County.EDU, then the LISTSERV will think that you're not subscribed to the list. BITNET usernames and node names are automatically uppercased by the LISTSERV, but other network addresses are not. If your site (or you) should happen to make a change to, say, the system mailer such that it changes the case of your mail, there will be problems. If you're having problems submitting (you'll know this because the LISTSERV will say "Not authorized to send to VIRUS-L..."), try unsubscribing and re-subscribing. If that doesn't work, send me mail (LUKEN@LEHIIBM1.BITNET), and I'll try to fix things up. What does VIRUS-L have to offer? All submissions to VIRUS-L are stored in weekly log files which can be downloaded by any user on (or off) the mailing list; readers who prefer digest format lists should read only the weekly logs. There is also a small archive of some of the public anti-virus programs which are currently available. This archive, too, can be accessed by any user. All of this is handled automatically by the LISTSERV here at Lehigh University (). How do I get files from the LISTSERV? Well, you'll first want to know what files are available on the LISTSERV. To do this, send mail to saying INDEX VIRUS-L. Note that filenames/extensions are separated by a space, and not by a period. Once you've decided which file(s) you want, send mail to saying GET filename filetype. For example, GET VIRUS-L LOG8804 would get the file called VIRUS-L LOG8804 (which happens to be the monthly log of all messages sent to VIRUS-L during April, 1988). Note that, starting June 6, 1988, the logs are weekly. The new file format is VIRUS-L LOGyymmx where yy is the year (88, 89, etc.), mm is the month, and x is the week (A, B, etc.). Readers who prefer digest format lists should read the weekly logs and sign off of the list itself. Subsequent submissions to the list should be sent to me for forwarding. Also available is a LISTSERV at SCFVM which contains more anti-virus software. This LISTSERV can be accessed in the same manner as outlined above, with the exceptions that the address is and that the commands to use are INDEX PUBLIC and GET filename filetype PUBLIC. What is uuencode/uudecode, and why do I need them? Uuencode and uudecode are two programs which convert binary files into text (ASCII) files and back again. This is so binary files can be easily transferred via electronic mail. Many of the files on this LISTSERV are binary files which are stored in uuencoded format (the file types will be UUE). Both uuencode and uudecode are available from the LISTSERV. Uudecode is available in BASIC and in Turbo Pascal here. Uuencode is available in Turbo Pascal. Also, there is a very good binary-only uuencode/uudecode package on the LISTSERV which is stored in uuencoded format. Why have posting guidelines? To keep the discussions on-track with what the list is intended to be; a vehicle for virus discussions. This will keep the network traffic to a minimum and, hopefully, the quality of the content of the mail to a maximum. No one wants to read personal flames ad nausium, or discussions about the pros and cons of digest-format mailing lists, etc. What are the guidelines? As already stated, there will be no flames on the list. Anyone sending flames to the entire list must do so knowing that he/she will be removed from the list immediately. Same goes for any commercial plugs or panhandling. Submissions should be directly or indirectly related to the subject of computer viruses. Responses to queries should be sent to the author of the query, not to the entire list. The author should then send a summary of his/her responses to the list at a later date. "Automatic answering machine" programs (the ones which reply to e-mail for you when you're gone) should be set to *NOT* reply to VIRUS-L. Such responses sent to the entire list are very rude and will be treated as such. When sending in a submission, try to see whether or not someone else may have just said the same thing. This is particularly important when responding to someone else's posting (which should be sent to that person *anyway*). It's very easy to get multiple messages saying the exact same thing. No one wants this to happen. Thank-you for your time and for your adherance to these guidelines. Comments and suggestions, as always, are invited. Please address them to me, or . Ken van Wyk %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Here is a list of files available at LISTSERV@LEHIIBM1, and some instructions on how to obtain them. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% * VIRUS-L FILELIST for LISTSERV at LEHIIBM1. * * * This file lists the programs that are stored on LISTSERV and can be * retrieved by VIRUS-L users. * * If an entry shows nrecs=0 the file is not available. * * rec last - change * filename filetype GET PUT -fm lrecl nrecs date time File description * -------- -------- --- --- --- ----- ----- -------- -------- --------------- * ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: * * The GET/PUT authorization codes shown with each file entry describe * who is authorized to GET or PUT the file: * * ALL = Everybody * N/A = Not Applicable * LCL = Local users, as defined at installation time * PRV = Private, ie list members * OWN = List owners * NAD = Node Administrators, ie official BITNET/EARN contacts * CTL = LISTSERV Controllers (Also called "Postmasters") * *: OWN = 'LUKEN@LEHIIBM1', /* Ken Van Wyk, Lehigh University */ *: 'LUJCE@LEHIIBM1' /* Jim Eshleman, Lehigh University */ * * ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: TEST FILE OWN OWN F 80 1 88/05/04 09:14:13 Test File UUENCODE PAS ALL OWN V 78 181 88/05/04 09:25:20 uuencode UUDECODE PAS ALL OWN V 74 203 88/05/04 09:25:34 uudecode UUDECODE BAS ALL OWN V 71 75 88/05/06 09:36:00 BASIC uu UU213 UUE ALL OWN V 62 906 88/05/06 09:36:15 fast uu FSP UUE ALL OWN V 61 969 88/05/04 09:32:27 Flu_Shot+ FSP_12 UUE ALL OWN V 61 1019 88/05/06 08:38:57 New FSP PKX35A35 UUE ALL OWN V 35 6 88/05/04 09:41:11 pkxarc COREWARS TXT ALL OWN F 80 553 88/05/04 13:42:02 Mac stuff DIRTY DOZEN ALL OWN V 67 1453 88/05/05 08:24:10 Bad Guys NOBRAIN C ALL OWN V 80 593 88/05/05 08:24:34 AntiBrain CHECKMEM C ALL OWN V 75 20 88/05/05 08:24:23 AntiBrain RISKS LOG ALL OWN V 80 7789 88/05/05 16:01:46 Risks log CHKUP14 UUE ALL OWN V 62 1080 88/05/13 13:53:06 Checkup %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The following paper was sent to me by Stephen Kiel, a graduate (and ex-student employee) of Lehigh University. The paper was done while Steve was finishing up work on a Masters degree in Electrical Engineering at Georgia Tech. VIRUS-L readers may recognize some of the quotes which Steve used as having been taken from VIRUS-L. Many thanks, Steve, and best of luck in recuperating from your 1200 mile bicycle ride home to NJ! :-) Steve no longer has network access since leaving Georgia, but hopes to be rejoining VIRUS-L upon taking up his new job at Bell Labs. Ken %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% THE INFECTION OF PC COMPATIBLE COMPUTERS Stephen E. Kiel Raymond K. Lee Georgia Institute of Technology Summer Quarter 1988 INTRODUCTION The recent publicity over computer viruses has produced mixed reactions and much confusion inside, as well as outside, of the computing industry. The conflicting opinions are caused either by a misunderstanding of what viruses are or a lack of understanding of their potential problems. This paper answers those questions and in addition, gives a description of currently suggested methods for IBM PC's and compatibles for detecting, preventing, and eliminating viruses. A highly technical discussion is not the objective, but rather a broad overview is given along with sources of additional information and assistance. THE BEGINNING On November 3, 1983, an idea was conceived of by Fred Cohen as an experiment to be presented at a weekly seminar on computer security [1]. The idea was simple enough: design a computer program that could modify other programs to include a possibly evolved copy of itself. This evolved copy would then modify other programs and thus continue the propagation and evolution. The program could easily be spread by unknowing users throughout a computer system or network. It only took eight hours of expert work on a heavily loaded VAX 11/750 to complete the first of such programs and prepare it for demonstration. The program was inserted into the beginning of a new program on the system called 'vd,' which displayed Unix structures graphically. A new program was chosen so that details of its operation and its performance characteristics would be unknown. Users were introduced to vd via the system bulletin board. The program inside of vd used the authorizations of every user using it to infect their programs. In all of the experiments, the program that was initially inserted into vd was granted all system rights in under an hour. The shortest time was under five minutes, with the average time under 30 minutes. Even people who knew that the experiments were taking place were unable to defend themselves. Once the surprising results of the experiments were announced, the administrators of the VAX 11/750 decided that no further computer experiments would be performed on their system. Precautions were taken to keep the experiment under control. No damage was done and only reports were sent back on the program's progress. Also, traces were generated to insure that the program could not spread without detection. All files were purged of the program after the experiment was completed. It is unfortunate that an apparent fear reaction on the part of the system administrators prohibited any further testing. DEFINING A VIRUS A name for programs exhibiting the behavior described above was thought of by Len Adleman: 'viruses.' A computer virus can generally be defined as a program which hides in computer systems, usually in larger programs, whose mission is to replicate and spread until the occurrence of some designated event. When this event takes place, the program can then perform some action specified by its creator. The term 'virus' is very appropriate since computer viruses (here after referred to as simply 'viruses') behave much like their biological counterparts. Once in a computer system, a virus can remain quiet for an incubation and contagion period, during which it infects other files. After some prespecified event, such as a period of time or a number of infections, the virus can come to life and begin an attack. All the while, the offspring of the virus are infecting other files and systems, also waiting to be triggered to attack. The software that controls the computer and the devices connected to it is known as the DOS, an acronym for disk operating system. DOS commands are the core of the operating system and instruct the computer to start, stop, or continue an operation. The most popular DOS for IBM PC compatible computers is Microsoft Corporation's MS-DOS. Personal computer viruses typically infect three special MS-DOS files: IBMBIO.COM, IBMSYS.COM, and COMMAND.COM. These files are found on every system disk and become part of memory each time the operating system is loaded into the computer. The system files IBMBIO.COM and IBMSYS.COM are hidden and read-only and are not easily infected. The COMMAND.COM file, which is the default command processor of MS-DOS, is both visible and modifiable. A number of viruses have been discovered which infect this file. These three files are copied to other disks and run on other machines often enough that a virus in any of these files can spread very quickly. The action performed by viruses will vary. It could be simply the flashing of a harmless message on the screen. A virus in Aldus Publishing's FreeHand, a graphics program for the Macintosh, printed the message, "We would like to take this opportunity to convey our universal message of peace to all Macintosh users around the world" [2]. The company had to recall about 5,000 infected packages. Unfortunately, all viral behavior is not benign like this message printing or the simple infection tracing found in the experiment discussed in the opening paragraphs of this paper. There have even been reports of viruses which can slightly modify spreadsheets and other data [3]. Viruses have been found which reformat hard disks and destroy data. The destructive behavior is only limited to the warped imagination of its creator. Because of the hidden dangers involved, apparently safe software packages carrying such viruses have become known as "Trojan Horses." A viral outbreak of this sort took place last fall in the microcomputer labs at Lehigh University in Bethlehem, Pa. [4]. This particular outbreak, described below, generated a lot of publicity and caused both corporations and colleges alike to become concerned about the potential damage that viruses can inflict. THE LEHIGH VIRUS The Lehigh virus was typical of many other viruses. It sat in the COMMAND.COM file and was thus loaded into the computer whenever it was booted. The virus hid inside this file in a temporary storage space called the stack space. After infecting the same file on a number of other disks, the virus would wipe out all data and program files on the disk it was on. Backup copies were similarly infected, some users were attacked more than once. Once the outbreak had come to light, work began immediately to identify what was happening and to find a cure. Fortunately, the virus' creator made a mistake: the date on the COMMAND.COM file was altered by the infection. (It is relatively simple to keep the date from changing, so the absence of a changed file date does not guarantee that a file is virus-free.) Upon examination of the file, the contaminated stack space was discovered. Since this space is normally all zeros, student lab consultants wrote a simple program that looked at the stack space and wrote zeros over any code that was present. The virus was then erased from approximately 600 disks. If it was not for the creator's date mistake, it would have taken much longer for the Lehigh Computing Center to kill its virus. It is doubtful that any new viruses that crop up will make a similar mistake. As everything else related to computers increases in complexity, so will viruses. SIZING UP THE PROBLEM It is unknown exactly how many disks and computer systems are infected in the world. Some experts and officials are trying to keep track of the world's viruses by documenting their characteristics and occurances. For example, four versions of the Israeli virus and seven versions of the Brain virus [5] have been found. The Israeli virus was supposed to do some kind of damage on May 13, 1988, the fortieth anniversary of the founding of Israel. The Brain virus was originally written to warn would-be software pirates of a software package for physicians written by Basit Farooq Alvi, a 19-year-old from Pakistan. The Brain has since evolved to data destruction. VIRUS HYPE Fueling the scare is indeed a problem and has led to what has become known as the "Virus Hype." The press and media has been notorious for spreading rumors and partial truths about viruses. Besides causing undue panic and fear amongst computer users, the virus writer is getting notoriety and fame. This is shown in a statement from Stephen D. Morrison, a student from the University of Manitoba. When asked about the future of viruses, he responded with the following: "The scenario could be a mad-hacker, plugging away at a keyboard in the back of a dimly lit office, creating a virus like no virus ever seen before." This view angers professionals in the computing field. Ivars Balkits, an official from Computing Services at the University of California - Davis, stated, "Depicting the virus writer as a gothic/romantic figure (like pirates have been, like gangsters have been, like gang members now are) contributes to the problem. Continuing to fictionalize the virus writer as a mad scientist, a Doctor Frankenstein whose genius gives us a secret thrill, whose lawlessness challenges us, is just the wrong way to go." Another approach to stopping the hype and actually tracking the viruses is "The Dirty Dozen" maintained by Eric Newhouse [6]. This is a file, originally started by Tom Neff, which lists unlawfully copied or modified programs that have appeared on various IBM bulletin boards across the country. Newhouse hopes that this list will act as a "clearing-house" for the latest examples of "bogusware," i.e. software that is damaging to one or more parties. Currently there are almost 50 destructive programs listed. In addition to the list of bad software, the Dirty Dozen contains definitions of viruses and other destructive programs, instructions on what to do if a virus causes damage to a system, and a glossary of many of the confusing acronyms and terms used in the computer field. A list of addresses to send additions and corrections to the Dirty Dozen, along with comments to Eric Newhouse, is included in APPENDIX 1. Copies of the Dirty Dozen can also be obtained from the bulletin boards in the list mentioned above, as well as from many different electronic bulletin boards across the country. DETECTION Fred Cohen, now a member of the Electrical Engineering faculty at the University of Cincinnati, stated in a lecture at the IBM Watson Research Laboratory in Hawthorne, NY, that there are three ways to detect a virus: by its appearance, by its behavior, or by the changes it causes. Detection by appearance is undecidable since all viruses do not "look" alike. It is extremely difficult to look at a good-sized program written in assembly language and tell what it does. With an executable program, it is nearly impossible. Detection by behavior involves examining programs as they are executing and is also not very promising. Besides being disruptive by slowing down execution times, it produces too many false positives and false negatives. Initially, viruses were caught by having a monitor program watch for certain internal MS- DOS and BIOS system calls which are normally used to access system hardware, but now that is no longer the case. BIOS is an acronym for basic input/output services. Since hardware varies from machine to machine, the BIOS is used to abstract the operating system from the specific hardware it's running on. The BIOS directly controls all of the input/output devices, such as the monitor and the disk drives, according to instructions received from MS-DOS or an executing program. Unfortunately, viruses can bypass MS-DOS and BIOS system calls. It is relatively simple to go to a computer store and purchase literature that describes where MS-DOS and the BIOS keep the information they need about a disk, and also tells what port addresses do what on a PC. In order to insure compatibility between different brands of PC's, every computer manufacturer has to use the same BIOS data areas and the same port addresses. It is no mystery to find out exactly what a program has to do to get its hands on the hardware. Detection by change is easy to forge and can be very costly. Early viruses were found to simply append themselves onto files and thus change the file size or possibly change the file date, as in the Lehigh virus, viruses have become much more elusive. Existing files can have viruses implanted inside without changing their file length or modification date. It is also not very beneficial to use an erased hard disk as an indicator of viral presence. PREVENTION STRATEGIES "Prevention is the best medicine" is a phrase heard many times before, but this small advice is very true in the case against viruses. The key is education. There must be an awareness among users from the hobbyist to system managers of the potential dangers of viruses. Obviously, paranoia is not the goal but a general understanding must be achieved. With today's ever growing dependence on computers, ignorance will cost a heavy price, if it has not already. Therefore, steps must be taken to curtail the likelihood of viral destruction. Governmental legislation needed is already in progress: a House bill, the Computer Virus Eradication Act of 1988, was introduced in June that will make infesting computers with viruses a federal crime. A copy of this pending bill is in APPENDIX 2. Several other legislative acts have also been proposed. Currently, 48 states have computer crime laws. Fortunately, there are some guidelines that, if followed, will go a long way in keeping one's computer system virus-free. Of course, these guidelines are only as effective as the extent to which users are willing to implement them. These guidelines are divided into three areas - protection of diskettes, protection for the computer, and protection of systems interconnected by a local area network (LAN). DISK PROTECTION The first thing to do is not to use the original or master diskettes to execute the programs. Copies of all the original source disks should be made and used instead. The originals should then be stored in a safe place, out of sight. Although it is inconvenient, it is better to have the storage place far away from the computer or system itself. If there ever is any question as to the integrity of one of these copied files or disks, it can always be compared against the safely stored-away master copy. It is a very good idea to start using the write/protect tabs that so often get thrown away. These little stickers, usually black or aluminum colored gummed paper tags, can really save the day when it comes to inadvertent writes. Once a tab is in place, it is impossible for the computer to write on the disk. Besides being found on every system disk, the COMMAND.COM file is also a favorite hiding place for viruses. This file, as well as most others, can and should be made read-only without affecting its use. This can be easily done with the MS-DOS "ATTRIB.COM" program. Many other utility programs, such as those listed following the paper in APPENDIX 3, can also accomplish this task. COMPUTER PROTECTION The goal of virus protection can only be accomplished by limiting computer access. This strategy is simple: keep the computer "clean" by keeping the virus out. First and foremost, only tested software should be used. Also, a computer should never be booted up with an unfamiliar disk. This means that a user must be especially cautious and extremely careful with public-domain or shareware programs. Most viruses have a hibernation or incubation period, so even a seemingly good disk from a friend, co-worker, or other source can be infected. To protect a computer's existing files, it is advisable to establish a good method for backing up files on a regular basis. One strategy is to do incremental backups three times a week and perform a complete backup every two months. File attribute (FAT) tables can and should also be backed up. The intervals between backups should correspond to the amount of activity on the computer. When the computer is not in use, turn it off and lock it up. When a machine is left turned on and unattended, there is no way to know what has been installed or run on it while it was unsupervised. This implies that a computer should never be used unless the user personally boots it up. As far as locks are concerned, it is usually negligible to have a key lock installed. Software locks on PC's are easy to bypass and should not be trusted. LANS AND VIRUSES Beside interconnecting users, LAN's can provide a excellent route of propagation for viruses. In response to their initial virus attack, the computing center at Lehigh University has been taking many steps to reduce the possibilities of any new outbreaks. According to Kenneth van Wyk, a senior consultant at Lehigh, additional precautions to those mentioned above should be taken. The procedures in effect at Lehigh University's PC laboratories, which can also be applied to other distributed computing environments, are the following: 1) All public microcomputers contain dual floppy drives and are connected to LANs (Novell on 3COM boards). The hard disks were removed. 2) All boot disks are notchless and contain nothing other than the operating system boot files and the Novell software needed for the LAN. 3) All Novell hard disks on the file servers are read- only, with the exception of a "scratch" area where users can place their temporary files. 4) The "scratch" areas get erased periodically by Lehigh's student employees. 5) Users logging into the LAN are not automatically placed in the scratch directory. VACCINES With the growing publicity and concern over viruses, there has been a sudden upspring of so called "vaccines". It may even seem that the number of these programs are quickly catching up to the number of known viruses. Keep in mind, however, that none of these programs are 100% cures, and that many take a different approach in trying to solve the same problem. Probably the best attitude to take regarding these "vaccines" is the that of the Paul Mace Software Company - "Understand, the people who make these (viruses) are clever and we haven't seen their worst. We're clever too, and will keep on improving the vaccine." Several of the software/hardware products of this nature that are designed for personal computer use at home and in industry are listed in APPENDIX 4. AFTER THE ATTACK Even though precautions are taken, the worst sometimes happens: a virus evades the lines of defense and wreaks havoc. Even if a hard disk does manage to crash, regardless of whether it was virus-induced or not, all is not necessarily lost. Some investment of time may be needed, but the data can usually be recovered. There is no better remedy for a crash of any kind than a recent backup. Unfortunately, if the virus was backed up along with the rest of the disk, restoring the backup contents may bring the virus back to life. If this happens and another crash occurs from the restoration, it is time to do either a lot of detective work or seek professional help. Once a crash has occurred, the first step is to remain calm. The strong urge to shout and destroy nearby office furniture has to be suppressed. After this is done, the damage must be surveyed. The crash is probably a result of the virus doing one of the following: 1) Formatting the disk 2) Scrambling the FAT (File Attribute) table 3) Erasing files 4) Corrupting the disk's boot sector The amount of data that can be recovered depends on the cause of the crash. At this point if you do not know what you are doing, it is well worth the time and money to find someone who does. Recovering data from a crashed disk is a highly technical matter. Further information on the above causes and their remedies are provided in APPENDIX 5. Any improper attempts by an inexperienced user can result in permanent data loss. FURTHER INFORMATION One of the best ways to learn more about viruses and related topics is through VIRUS-L, an electronic mail discussion forum for sharing information about computer viruses. The computer that handles this forum is located at Lehigh University and is a result of the need for more information about viruses after the Lehigh outbreak. There are currently several hundred subscribers to the list from academic and corporate institutions from all over the world. Discussions on the list include current events, virus "sightings," practical and theoretical virus prevention methods, and questions/answers about viruses. The discussions on this list are extremely informative and educational. The list is non-moderated and non-digested, which means that any message sent to the forum goes out immediately to all subscribers. All submissions to VIRUS-L are stored in weekly log files which can be down-loaded for later reference. Also, there is a small archive of some of the public anti-virus programs which are currently available. In order to get on the mailing list, a user must have access to the BITNET network, which is possible through ARPANET, Internet, and several other networks. If this is the case, than the user only has to send the message "SUB VIRUS-L " to . Questions and comments about VIRUS-L can sent to the list's moderator, Kenneth van Wyk, at the addresses listed in APPENDIX 6. SUMMARY Computer viruses, like their biological counterparts, are constantly changing. It is impossible to predict the course that future viruses will take. According to William H. Murray of Ernst & Whinney, "if you can conceive it, and if it could be done by any other program, then it can be done by a virus." The prevention and protection methods discussed here are not infallible since they will need to adapt to the dynamic nature of viruses. This paper is meant to serve as a useful introduction to the nature of viruses and how they must be confronted. If this information is understood, the warnings heeded, and the basic precautions taken, the probability of a virus attack should be lessened. APPENDIX 1: The Dirty Dozen Eric Newhouse, the editor of the Dirty Dozen, can be contacted for more information at the following addresses: 1) The Crest RBBS/CAMS (160/50 MB), 213-471-2518, 1200/2400. (This is Eric Newhouse's bulletin board) 2) The West LA PC-STORE (50 MB), 213-559-6954, 300/1200/2400. 3) Camelot PC-Board (80 MB), 213-204-6158, 300/1200/2400 - leave E-mail to "NORMAN TEETER" and it will be relayed. 4) The Source - leave E-mail to "Doctor File Finder" (Mike Callahan) in IBM SIG #4 and it will be relayed. APPENDIX 2: The Computer Virus Eradication Act of 1988 Whoever knowingly -- (1) inserts into a program for a computer information or commands, knowing or having reason to believe that such information or commands will cause loss to users of a computer on which such program is run or to those who rely on information processed on such computer; and (2) provides such program to others in circumstances in which those others do not know of the insertion or its effects; or attempts to do so, shall, if any of such conduct affects interstate or foreign commerce, be fined under this title or imprisoned not more than 10 years, or both. Entered July 14th 1988 by Mr. Wally Herger (Congressman from CA) for himself and Mr. Bob Carr (Congressman from MI); referred to Committee on the Judiciary. APPENDIX 3: Disk Utility Programs 1) PC-Tools, Central Point Software. $80. 2) Mace+ Utilities, Paul Mace. $100. 3) Advanced Norton Utilities, Peter Norton. $150. APPENDIX 4: Vaccine Products 1) Antidote by Quaid Software, Toronto, Canada. Detects viruses but allows the user to correct the problem. $60. 2) C-4(Cylene-4) by InterPath Corp., Santa Clara, CA. A program that resides in ROM and looks out for viruses. If found, computer activity halts and C-4 warns the user. $30. 3) Data Physician by Digital Dispatch Inc., Minneapolis, MN. Protects and remove viruses from MS-DOS based computers. 4) Disk Defender by Director Technologies Inc., Evanston, IL. An add on board that will guard the hard disk. 5) Disk Watcher by RG Software Systems, Willow Grove, PA. A memory resident utility that "watches" the disk drives to prevent accidental writes or formats. $80. 6) Dr. Panda Utilities by Panda Systems, Wilmington, DE. A set of programs that checks files from BBS and other software before letting them used. $80. 7) FluShot by Byte's BIX. A free utility. Contact BYTE magazine or BIX for more information. FREE. 8) Mace Vaccine by Paul Mace Software, Ashland, OR. It provides write protection for system files. $20. 9) NTIVIRUS by Orion Microsystems, Quebec, Canada. Monitors the system files for viruses. $30. 10) Passcode System by Dynamics Security Inc., Cambridge, MA. Complete hardware software protection system. $200-$2000 depending the size and components needed. 11) Syringe,Canary,Infect by Sophco, Boulder, CO. Three programs that will "quarantine" a bad disk, test and remove viruses. $30. 12) Vaccinate by Sophco. A "milder virus" that will warn the user of other viruses. $195. 13) Virusafe by ComNetco Inc., Bernardsville, NJ. Checks the system memory for viruses then prevents them from being used. $250. 14) VirAlarm by Lasertrieve Inc., Metuchen, NJ. Stores programs on CD-ROM after making sure they are virus- free. 15) Virus Implant Protection by LeeMah DataCom Security Corp., Hayward, CA. Uses a dedicated PC to "monitor unauthorized activities" on other networked computers. 16) Vaccine by FoundationWare, Cleveland, OH. "5 levels" of protection from write-protect to checksums. $189. APPENDIX 5: Recovery from a Disk Crash Recovering information on a formatted disk depends on the method of formatting. If the disk was low-level formatted, then the contents of the files and the directories referencing them have been over-written. The only hope of recovery is a backup. If the disk was high-level formatted, then the disk contents have not been erased and are recoverable to some degree. Unformatting programs have been written to reconstruct the contents on the disk. Since MS-DOS breaks up or fragments large files and stores the pieces wherever there is room on the disk, complete recovery is only possible if the unformatting programs have a "picture" of the disk before the crash. This picture is generally taken by a utility accompanying the unformatting program. Several of these programs are listed above in APPENDIX 3. If the FAT table has been scrambled, it can be rebuilt. Two of the three disk utility programs listed below, Norton Utilities and PC-Tools, include editors that allow an experienced user to piece together a FAT table. This is not easy and requires a large amount of experience and a high degree of proficiency. The other alternative involves finding a FAT backup program and making periodic backups. A number of FAT backup programs are public domain and can thus be obtained from a trusted friend or trusted computer bulletin board. If files were erased and the FAT tables are still intact, then the files may simply have to be unerased. All three of the disk utility programs listed in APPENDIX 3 can do this. When a file is erased, the first character of its name is usually changed to a non-printable character to indicate that it is no longer a valid directory entry. Everything else is left intact. Since the contents of erased programs are over-written by newer programs, it is best to unerase the files the most recent files first. If this is not done, a previously erased program may grab part of a newer file. The last cause of a disk crash is when the boot sector is either erased or formatted. In this case, the data is still safe on the disk, but the disk cannot be booted from. Another system disk in a floppy drive can be used to boot the system. Before proceeding any further, backup the hard disk in case any damage is done trying to restore the disk to boot status. The first thing to try is running the MS-DOS "SYS.COM" program. This program will copy the system files from one disk to another. After this is done, COMMAND.COM will have to be copied to the crashed disk using a simple "COPY" command. Information on this procedure is available in the MS-DOS manual. If this does not work, Mace+ Utilities has a function called "restore boot sector" which should be tried. If all else fails, the disk should be first backed up and then low-level reformatted. Instructions for this procedure should either come with the computer or are available from a computer store. After this is done, the MS-DOS program "FDISK.COM" be run to prepare the disk for high-level formatting. This formatting is done with the DOS "FORMAT.EXE" program. The DOS manual should be consulted before running any of these MS-DOS commands or programs. When everything is completed, the backup can be restored. APPENDIX 6: VIRUS-L The moderator of VIRUS-L, Kenneth van Wyk, can be contacted for more information at the following addresses: 1) on Internet 2) on BITNET 3) Kenneth van Wky User Services Senior Consultant Lehigh University Computing Center Bethlehem, PA 18015 (215) 758-3900 REFERENCES [1] Fred Cohen, "Computer Viruses", PhD dissertation, University of Southern California, 1985. [2] P. Honan, "Beware: It's Virus Season", Personal Computing, July 1988, p36. [3] P. Karon, "The Hype Behind Computer Viruses", PC Week, May 31, 1988, p49. [4] Fred Cohen, "On The Implications of Computer Viruses and Methods of Defense", University of Cincinnati, unpublished. [5] J. Pournelle, "Computing at Chaos Manor", BYTE, July 1988, pp198-200. [6] E. Newhouse, "The Dirty Dozen", Issue #8a, February 21, 1988. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% End of BIOBIT No1.... Rob Harper