Return-Path: Received: from IBM1.CC.Lehigh.EDU by abacus (SunOS 4.1/SMI-4.1-01) with sendmail 4.1/SMI-4.1-01 id AA26340; Thu, 14 May 92 14:12:01 +0200 Message-Id: <9205141212.AA26340@abacus> Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 3461; Thu, 14 May 92 07:56:16 EDT Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.08) with BSMTP id 1440; Thu, 14 May 92 07:56:00 EDT Date: Thu, 14 May 1992 07:47:41 EDT Reply-To: VIRUS-L@IBM1.CC.LEHIGH.EDU Sender: Virus Discussion List Comments: Warning -- original Sender: tag was krvw@CERT.ORG From: "The Moderator Kenneth R. van Wyk" Subject: VIRUS-L Digest V5 #105 Comments: To: VIRUS-L@ibm1.cc.lehigh.edu To: Multiple recipients of list VIRUS-L Status: R VIRUS-L Digest Thursday, 14 May 1992 Volume 5 : Issue 105 Today's Topics: COPS for Novell? (PC) (Novell) Question about Dark Avenger (PC) Question about Michelangelo (PC) Problems with PKatz's software ... (PC) Re: JOES DEMISE virus (PC) Re: Starship (PC) Re: Question about Michaelangelo (PC) Re: Question about Michaelangelo (PC) Re: JOES DEMISE virus (PC) Re: EEPROM virus prevention Re: Virus Differences Re: Is a "good virus" a bad idea? Computer Virus advice via a 900 number FAQ questions? Request for assistance re workshop itinerary Re: Lines of defense against viruses Re: Lines of defense against viruses Review of Dr. Solomon's Anti-Virus Toolkit (PC) VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU. Ken van Wyk -------------------------------------------------------------------------------- Date: 12 May 92 08:50:29 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: COPS for Novell? (PC) (Novell) Is anybody aware of a Novell NetWare-oriented program to check the security of a Novell LAN? Like the usage of obvious passwords, shared directories left writable by several people, possible virus infection paths, etc.? Something like COPS does for Unix? And, if there is no such thing yet, don't you think that it's more than the time to create it? Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Tue, 12 May 92 18:13:40 +0000 From: BONDIR@vaxb.gbus.virginia.edu Subject: Question about Dark Avenger (PC) I am confused about the recent column in InfoWorld describing the Dark Avenger engine. Just as one can have self-extracting archives, so the engine self-encrypts and self-extracts. Because the encryption varies each time, the encrypted virus is essentially immune to detection by anti-virus programs that scan for characteristic strings. What I don't understand is this: surely the executable, self-extracting part of the program must be invariable - it can't be encrypted, because obviously it couldn't execute while encrypted. So why aren't such viruses easy to detect simply by scanning for the self-decrypting executable portion? R. Bondi ------------------------------ Date: Tue, 12 May 92 15:39:58 -0400 From: padgett@hobbes.dnet.mmc.com (A. Padgett Peterson) Subject: Question about Michelangelo (PC) The multiple infection example cited is one of the reasons that I created the FixMBR program (FixDBR is still under construction). My opinion is and has been that the executable code in the MBR is 1) Simple and 2) Untrustworthy following infection. For that reason I found it easier to simply replace the code (a la FDISK/MBR) then to try to find the original. What FixMBR does do is search for the original partition table (usu in the virus code, but not always), verify that the table matches the disk (intelligent rebuild of the table is another RSN but rarely necessary), and replacement of the MBR with my SafeMBR (integrity checking & personal plug) code. I find this much easier than trying to figure out if the code in sector 7 (or 3 or 9...) is the original MBR or yet another infection. Warmly, Padgett ------------------------------ Date: Tue, 12 May 92 21:16:44 -0400 From: "A. Andrew Brennan" Subject: Problems with PKatz's software ... (PC) I don't believe that Katz has email access (someone please tell me that I'm wrong) but there presently exists a major problem with the PKWare stuffs. Basically, everyone is waiting with baited breath for the PKZip 2.xx release - something that has been hitting the soon- to-be-released rumor mills for a while. I remember seeing a file that claimed to be beta for 1.93 and have seen 2.01 files on a few locations - never there very long. At the same time, in one of the relatively recent virus writing soft docs/mags/fanzines there were two pieces. The first of these discussed the "alteration" of viral code to beat the signature scanners - not necessarily the heuristic scans, but who uses them except when they already think there might be something wrong? The second article went over the verification code and registration information that is used by PKWare. How to dupe it, etc. such that people think that they are getting the package "straight from Katz." Between the two of these articles alone, there exists an obvious problem - even uglier when the market is waiting for the "product" that the v-code writers are "producing." Unfortunately, I don't have the articles in my hand at the present - they're offline somewhere ... probably on an unlabelled disk. It's just the recent problems with bogus PKZip 2.01s that brought it back to my mind. andrew. (brennaaa@duvm.ocs.drexel.edu) ------------------------------ Date: 13 May 92 07:41:07 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: JOES DEMISE virus (PC) MLPOWE01@ULKYVM.LOUISVILLE.EDU (Michael Powell) writes: > About a week ago, a message was posted on VALERT concerning a potential > new virus called "Joes Demise." I posted the information found in the > alert note on a local BBS. A few days later, I received the following > reply. To me, it doesn't sound like the symptoms mentioned as "Joes > Demise" but it does sound like something is possibly wrong. Let me know I got a copy of "Joes Demise" (why this name?!). See below for a description of it. The problems that you are mentioning does not seem to be caused by it. > >Does this 'new' virus show up like the Michaelangelo did by using the > >DOS mem command to see what memory one has? I know that I am bound to Yes. The MEM command will report that some DOS memory is missing, just like with Michelangelo. Probably 2 Kb will be missing. (I haven't tested whether MEM computes the ammount exactly. If this is the case, it will report 1952 bytes missing.) > >have a virus of some type that thus far nothing has been able to detect. > >I know this because DOS's mem shows only 654336 bytes instead of the In this case, only 1024 bytes are reported as missing, so it is clearly not Joes Demise virus. > >655??? (can't remember offhand). 655360. > >Plus things get totally screwy on my > >monitor; letters suddenly changing to something else etc... Thus far > >it has not caused any problems. The Joes Demise virus (how about a better name?) does not cause such effects. However, the situation described is almost certainly caused by the virus - decreased memory, video effects, a self-checking program reporting that it has been modified - all those when combined are typical symptoms for a virus infection... Anyway, the promised description of the virus. It is a memory resident, buggy-stealth (it's not semi-stealth and is not fully stealth due to bugs), COM and EXE files fast infector. Infects on Exec and OpenFileHandle functions. Does not infect overlays. The true length of the virus is 981 bytes. When an infected file is run under DOS version below 3.0, it displays a message "This program requires MS-DOS 3.00 or later" and terminates with errorlevel 1. The message is output by the virus and can be seen as plaintext in its body. It's not surprising that F-Prot's heuristic check does not detect the virus - the infected files begin with a DOS version check and terminate with a message if the version is not OK - pretty much like the DOS programs! The virus occupies 1952 bytes of memory, allocated on the top of the last MCB. CHKDSK will probably report that 2 Kb are missing. The virus detects whether it is present in memory by usning INT 21h/ AH=0B3h and checking for 9051h being returned in AX. The virus will not infect a file named ??????D.COM, therefore COMMAND.COM will not be infected. Infection attempt will be made only for files with extensions .COM and .EXE (both when copied or executed), although the virus distinguishes the file type by the magic number in the first two bytes. It checks only for MZ, not for ZM. The virus recognizes the infected COM files by checking for 50h 8Ch in their first two bytes. However, the actual first two bytes of the virus are different, which leads to multiple infections of one and the same file. COM files larger than 64256 bytes are not infected. For EXE files, the upper limit is 256 Kb. The infected EXE files are recognized by the value 95Ch in the SP field of the header (at offset 10h). The virus prepends itself to COM files smaller than 953 bytes and appends itself to any other files. At least this is what it tries to do. But the code is quite buggy and sometimes some garbage is added to the files. The virus padds the EXE files up to the next multiple of 16 when it infects them. 1009 bytes are added to the EXE files padded in this way. As the person who originally posted a message about this virus observed, the virus tries to be stealth and to disinfect the infected files when they are executed. However, it contains too many bugs (most of them - in the design). Due to them, it fails to re-infect the disinfected files once they have terminated. It also fails to disinfect them when they are opened. Therefore, it cannot be called fully stealth. The virus contains no intentionally destructive code or any payload at all. Well, this was what I was able to grasp from a preliminary disassembly. I hope that if I got something wrong, the other people who are dissecting this virus will correct me. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 13 May 92 11:14:23 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Starship (PC) 8326442@AWIWUW11.BITNET (Martin Zejma) writes: > I inspected various PC / MS-DOS versions ranging from 3.2 to 5.00, and only > the ones before / including 3.3 use 'create file' in the COPY and XCOPY >command, since 4.00 an undocumented nice function (6Ch) is used , which accepts > a file name as input ( at DS:SI ) , and as output comes the handle in AX. > So simple copying won't work, and recalling your posting, Vesselin, it seems > that your test computer runs at least version 3.3 , too. Correct, and in one of my previous postings I mentioned that the virus does not seem to like DOS 5.0. Now I see why; thanks for the explication. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 13 May 92 10:53:56 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Question about Michaelangelo (PC) AMN@VMS.BRIGHTON.AC.UK (Anthony Naggs) writes: > The solution is hard, unless you are using MS-DOS 5 in which case FDISK /MBR > should fix things for you. Otherwise you will have some problems, what > you have to do is keep the partition information stored at the end of the > virus & match it with a suitable MBR partition table boot sector. As > this seems to be a very common problem I shall write a small program to > assist & post it and details of how to use it over the weekend. Don't bother. At least two such programs are already available. Check for TBRESC19.ZIP on Simtel20 and for SHRDOG.ZIP on our ftp site. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 13 May 92 10:41:52 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Question about Michaelangelo (PC) mccd@rosie.uh.edu (Reza Golshan ACUS 743-1587) writes: > The following is the information that we released after some > modifications, for the University of Houston(Park) community on March/2/92. The information is not quite correct, see below. > If your IBM_PC(compatible) is being infected by both the Michelangelo > and Stoned, a reinfection by the Michelangelo would make the Michelangelo's > removal impossible. First, it should be mentioned that in this case the disk becomes non-bootable and second, of course it is possible to remove the virus! > At this stage, by using an antivirus software, the Michelangelo virus > is then removed, which would be; > [ EVENT ] [ AREA 1] [ AREA 2 ] [AREA 3] > ***************************************************************************** * > Michelangelo Stoned Michelangelo nil > Removal > ^______________________________________________| It depends on the disinfector. With some extremely silly disinfectors, which do not attempt to wipe out the virus code, the picture will be: [ EVENT ] [ AREA 1] [ AREA 2 ] [AREA 3] ****************************************************************************** Michelangelo Stoned Michelangelo Stoned Removal ^______________________________________________| > Do not proceed with the cleaning of the Stoned at this point and it > is highly recommended that you contact the Academic Computing User Services Much faster is just to boot from the system DOS 5.0 diskette and to run FDISK /MBR. This will remove the virus. > When the antivirus program is run again the Michelangelo would be > detected, and removing Michelangelo would be refused by the antivirus program > since there is no original bootsector to replace it. It is possible at this Yes, if the anti-virus program is silly (but not extrememly silly). If it is intelligent enough, it should be able to detect that no valid master boot sector is present and to create one. > point that the disk would be beyond repair(Due to the possible loss of the > file allocation table), however, if you are at this point, you may call the > ACUS or the Administrative Computing for help. The SYS.COM can be used > in this case in an attempt to transfer back the system, in addition to some If this is what the Administrative Computing is going to advise you, forget about them. SYS.COM does not touch the MBR (where the virus is) at all. > other procedures that might be necessary to take to recover the files. Those No need to recover the files, since they are not damaged. > procedures are beyond the scope of this briefing and should be handled by > our consultants only. Just running DOS 5.0 FDISK /MBR will do the job. > A friend of mine's machine recently stopped booting from the HD, so we > ran scan, and it reported that he was infected by Stoned. We cleaned > that, ran scan again, and it reported that he was bitten by Mich. We > tried cleaning that, and even though clean reported that it was > successful, upon rescan it was still there. Even Norton Anti-virus > Michaelangelo didn't clean it correctly. Any explanations and > solutions? The explanation was included in your message... Read it again. :-) And your experience shows that NAV and CLEAN (at least the versions you used) are silly programs for the reason explained above. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 13 May 92 07:41:07 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: JOES DEMISE virus (PC) MLPOWE01@ULKYVM.LOUISVILLE.EDU (Michael Powell) writes: > About a week ago, a message was posted on VALERT concerning a potential > new virus called "Joes Demise." I posted the information found in the > alert note on a local BBS. A few days later, I received the following > reply. To me, it doesn't sound like the symptoms mentioned as "Joes > Demise" but it does sound like something is possibly wrong. Let me know I got a copy of "Joes Demise" (why this name?!). See below for a description of it. The problems that you are mentioning does not seem to be caused by it. > >Does this 'new' virus show up like the Michaelangelo did by using the > >DOS mem command to see what memory one has? I know that I am bound to Yes. The MEM command will report that some DOS memory is missing, just like with Michelangelo. Probably 2 Kb will be missing. (I haven't tested whether MEM computes the ammount exactly. If this is the case, it will report 1952 bytes missing.) > >have a virus of some type that thus far nothing has been able to detect. > >I know this because DOS's mem shows only 654336 bytes instead of the In this case, only 1024 bytes are reported as missing, so it is clearly not Joes Demise virus. > >655??? (can't remember offhand). 655360. > >Plus things get totally screwy on my > >monitor; letters suddenly changing to something else etc... Thus far > >it has not caused any problems. The Joes Demise virus (how about a better name?) does not cause such effects. However, the situation described is almost certainly caused by the virus - decreased memory, video effects, a self-checking program reporting that it has been modified - all those when combined are typical symptoms for a virus infection... Anyway, the promised description of the virus. It is a memory resident, buggy-stealth (it's not semi-stealth and is not fully stealth due to bugs), COM and EXE files fast infector. Infects on Exec and OpenFileHandle functions. Does not infect overlays. The true length of the virus is 981 bytes. When an infected file is run under DOS version below 3.0, it displays a message "This program requires MS-DOS 3.00 or later" and terminates with errorlevel 1. The message is output by the virus and can be seen as plaintext in its body. It's not surprising that F-Prot's heuristic check does not detect the virus - the infected files begin with a DOS version check and terminate with a message if the version is not OK - pretty much like the DOS programs! The virus occupies 1952 bytes of memory, allocated on the top of the last MCB. CHKDSK will probably report that 2 Kb are missing. The virus detects whether it is present in memory by usning INT 21h/ AH=0B3h and checking for 9051h being returned in AX. The virus will not infect a file named ??????D.COM, therefore COMMAND.COM will not be infected. Infection attempt will be made only for files with extensions .COM and .EXE (both when copied or executed), although the virus distinguishes the file type by the magic number in the first two bytes. It checks only for MZ, not for ZM. The virus recognizes the infected COM files by checking for 50h 8Ch in their first two bytes. However, the actual first two bytes of the virus are different, which leads to multiple infections of one and the same file. COM files larger than 64256 bytes are not infected. For EXE files, the upper limit is 256 Kb. The infected EXE files are recognized by the value 95Ch in the SP field of the header (at offset 10h). The virus prepends itself to COM files smaller than 953 bytes and appends itself to any other files. At least this is what it tries to do. But the code is quite buggy and sometimes some garbage is added to the files. The virus padds the EXE files up to the next multiple of 16 when it infects them. 1009 bytes are added to the EXE files padded in this way. As the person who originally posted a message about this virus observed, the virus tries to be stealth and to disinfect the infected files when they are executed. However, it contains too many bugs (most of them - in the design). Due to them, it fails to re-infect the disinfected files once they have terminated. It also fails to disinfect them when they are opened. Therefore, it cannot be called fully stealth. The virus contains no intentionally destructive code or any payload at all. Well, this was what I was able to grasp from a preliminary disassembly. I hope that if I got something wrong, the other people who are dissecting this virus will correct me. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 12 May 92 08:26:19 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: EEPROM virus prevention seborg@csrc.ncsl.nist.gov (Brian Seborg) writes: [description of an EEPROM-based scanner deleted] > if not a red light. Since the flash EPROMs function as the boot > device, there is no possibility of boot sector infection, or infection > of any kind by any infected disks. It's a bit too strong to claim that "infection of any kind is not possible"... Since what you describe is nothing more than a scanner, this means that any virus unknown to the scanner will be able to infect the disk. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Tue, 12 May 92 09:43:49 +0100 From: Norman Paterson Subject: Re: Virus Differences In Virus-L Digest V5 #101 Fridrik proposes a taxonomy scheme for viruses. While no-one can object to it on the grounds that Fridrik doesn't know about viruses, I would object on the grounds of practicality. The trouble with many classification schemes is that they are too subjective. In the beginning they make sense only to their inventor. Then others, after some period of study, gradually adopt the style of thinking behind them, and begin to see them in the same way as the originator. But by this time the originator has found some "difficult cases" and has shifted his ground slightly. And in fact, when although we think we all agree about the scheme, we all have slightly different interpretations of it, and it is not as consistent as we would like. Eventually there are so many exceptions that we are forced to scrap it and start over, which is quite expensive. An objective scheme which is not subject to individual interpretation is better from a taxonomy point of view. Such a scheme can be formally specified in such a way that software can be developed to implement it. If the same software is used around the world, we will all get the same answers, and all save time otherwise spent deciding which category a virus fits into. One way to specify an Automatic Taxonomer is to define a measure of distance or similarity between two strings of characters. For this approach we need: o A distance (or similarity) measure o A set of calibration strings o A set of taxonomy strings Notice that these things are all formal, though the process of choosing which particular ones to use is not. That's where expert opinion would come in. How does it work? Read on... The distance measure can compute the distance between any two strings. There are several ways to do this. I have my favourite, and no doubt you have yours! The calibration strings act as reference points. Given any string v, we can compute the distance between v and each calibration string. This gives us a vector in n dimensions, where n = the number of calibration strings. Thus, the calibration strings effectively define an n-dimensional space in which any string v is a point. The taxonomy strings are models which act as the centres of taxonomical groups. So if we want a group for Scores, we need to have a model of the "ideal" Scores virus. Using the distance measure and the calibration strings, we can compute the n-dimensional coordinates of these models. Now we are all set up. Suppose a new virus appears. We pop it into the analyser, which measures its distance from the calibration strings. This reduces it to a n-dimensional point. We measure its distance (in n dimensions) to each of the taxonomy strings. The nearest one is where it belongs. Out comes the answer. A few further points: 1 In publishing the Automatic Taxonomer, it is not necessary to publish the taxonomy strings. Only their coordinates in n dimensions are needed. So there is no risk of releasing viruses or similar things into the public domain, and the bad guys can't benefit. 2 As new viruses arrive, the taxonomy will need to extend. This can be done by choosing new distance measure, new calibration strings, new taxonomy strings or any combination of these. In any case, it is no more than issuing a new release of any software. So when we say that a certain virus is of type X, we must add " according to such-and-such an edition of the Automatic Taxonomer". 3 Some method of preparing the virus to insert into the Taxonomer would have to be specified. 4 I believe there is a field of study for this called "Cluster Analysis". I don't know anything about it. 5 Is there any connection between this and DNA comparisons? - -Norman ------------------------------ Date: Tue, 12 May 92 14:19:51 +0000 From: Meessen@slig.ucl.ac.be (Christophe Meessen) Subject: Re: Is a "good virus" a bad idea? The idear is in fact the concept of code moving it self dynamically by mean of the network form one computer to the other. Some sort of NNTP protocol but with code instead of news. Upgrading software to the latest version would be automatic. (Yeah !) Anti-viral programs, UID programs, etc... Object Oriented Programing may help to dynamicaly use new objects with new methods and features. Computer software in the world could evolve more rapidly. Suppose one single system all over the world: a Network Open System. Any enrichment of the system would be automaticaly shared to every body. Some sort of world wide cluster. To biggest problem, as reported in this group, is the opening of doors to pathological code as virus actualy are. To avoid such problems, we will have to reinforce detection of such codes and find new protections. This system will have to be more intelligent than actual virus replication. This is the cost we'll have to pay for the benefits we can get of such a system. I think that the benefits will be much greater than the costs and that we will come to such a system as networks gets bigger and faster. In my place there are lots of UNIX stations. I dream of such a system wich will automaticaly upgrade and control every station system. It would keep local system specificity. As NNTP protocol: we only read what we are concerned with. I'm shure this will become reality in a few years. Chris. ------------------------------ Date: Mon, 11 May 92 22:27:31 -0400 From: youman@umiacs.UMD.EDU (Charles Youman) Subject: Computer Virus advice via a 900 number Page A4 of the Washington Post Sunday, May 10, 1992 carried an ad for a 900 number to call for advice on computer viruses. The bold print says "Computer Education Hotline" "Computer Virus" "Consultants Straight Talk" "What is a computer virus?" "How are you infected?" "Safeguard Your Computer" "MICHAELANGELO" "TROJAN HORSE" "STEALTH." Some of the fine print notes $2 per minute, average call 2-3 minutes, taped messages change weekly. The value of this "service" is so dubious to me, I'm not going to give them the free publicity of the published phone number. In terms of distributing useful advice, what is the policy with respect to redistributing the Virus List FAQ? One idea that occurred to me would be publish it (probably two or three questions at a time) in the monthly newsletter of the local (Washington, DC) chapter of the ACM. The source of the material would be acknowledged, along with any copyright notices, if appropriate. Is the FAQ copyrighted and who would be the point of contact for permission to republish? How do the contributors to the FAQ feel about this? Regards, Charles E. Youman ------------------------------ Date: Mon, 11 May 92 11:10:43 -0400 From: Brian Seborg Subject: FAQ questions? Jim Bradley had a few common questions which should be included in the FAQ if they are not already. Here are the questions and my answers, if anyone else wants to jump in, feel free! :-) Hopefully, the compendium will be added to the FAQ: Jim had the following questions: Q:"o Can I contract a virus on my PC by performing a "dir" of an infected floppy disk?" A: If you assume that the PC you are using is virus free before you perform the DIR command, then the answer is NO WAY! :-) However, when you perform a DIR, the contents of the boot sector of the diskette is loaded into a buffer for use when determining disk layout etc., and certain anti-virus products will scan these buffers. If a boot sector virus has infected your diskette, the virus code will be contained in the buffer which may cause some anti-virus packages to give the message "xyz virus found in memory, shut down computer immediately". In fact, the virus is not a threat at this point since control of the CPU is never passed to the virus code residing in the buffer. But, even though the virus is really not a threat at this point, this message should not be ignored. If you get a message like this, and then reboot from a clean DOS diskette and scan your hard-drive and find no virus, then you know that the false positive was caused by the fact that the infected boot-sector was loaded into a buffer, and the diskette should be appropriately disinfected before use. The use of DIR will NOT infect a clean system, even if the diskette it is being performed on does contain a virus. Q: "o Can data and document files be vectors of PC viruses?" A: In general for data files the answer is not usually. However, if a data file is a program, and the program is compiled and run, or the data file contains instructions which are interpretable by some other program (such as a Lotus macro), then theoretically one could argue that data files could be considered vectors for a virus. This assumes some level of cooperation from an inside party, or from an inside program. For document files, the answer depends on how one defines "document". As you may have seen, there has been a discussion on this topic here in Virus-L over the past few issues. If one begins to define "document file" in new ways so that documents could contain animation done by internal code, etc. (which does not seem that far fetched) then it will be possible that document files could be vectors for viruses in the future. The Apple environment gives a good example of this in that there have already been viruses introduced via Hypertext stacks (previously thought of as an automated document file). One type of "document" which currently can cause problems is one containing control sequences which are interpretable by a device driver such as ANSI.SYS. It has been suggested that by merely TYPEing a file with such sequences, that they can be acted upon by the device driver which is capable of executing them. From personal experience, this seems to work with the PROMPT command when it is fed a sequence of control sequences while ANSI.SYS is loaded, but I have never been able to have the same results by merely typing a file containing control sequences. This is not to say that it can't happen, but suggests that at least this does not work for the version of ANSI.SYS that I have. Future trends in how documents and data files are defined may include making them yet another vector for computer viruses. Q: "o Is there any risk in copying data and document files from an infected DOS floppy disk to a clean PC's hard disk? (Assuming, of course, that one does *not* boot from the infected diskette.)" A: Given the above scenario, the answer is generally no. There are two caveats: 1) you should be somewhat concerned about checking the integrity of these data and document files as they may have been destroyed or altered by the virus and 2) if any of the "data" files are interpretable as executable by some other program (such as a Lotus macro) then these files should be treated as potentially malicious until the symptoms of the infection are known. The copying process itself is safe regardless (given your scenario) however, you should be concerned with what type of files are being copied to avoid introducing other problems. I thought all of these questions were very good and should spark further discussion. I would hope that once the discussion is concluded that the consensus could be added to the FAQ. I am sure that these questions have been asked before, so hopefully once the FAQ is updated, future requests for the same information can be referred to the FAQ. This points to another need regarding the FAQ, and that is organization. Some thought needs to be given to what keywords, or subjects should be used to allow the quick and easy navigation of what will prove to be a cumbersome document. Perhaps Patricia Hoffman might have some ideas on this since she has done a nice job with VSUM, or maybe Ben Schneiderman of UMCP could give us some Hypertext help :-). John R. Schutz writes: "A friend of mine's machine recently stopped booting from the HD, so we ran scan, and it reported that he was infected by Stoned. We cleaned that, ran scan again, and it reported that he was bitten by Mich. We tried cleaning that, and even though clean reported that it was successful, upon rescan it was still there. Even Norton Anti-virus Michaelangelo didn't clean it correctly. Any explanations and solutions?" I would like to respond to this by referring John to the FAQ, but although this topic has been covered several times both by me and others, it does not appear in the FAQ. The answer is obvious to most people who have kept up with the list (no slight intended to John) and that is that both Michelangelo and Stoned have the same infection engine. Both take a copy of whatever is in the MBR and move it to sector 7. Neither check to see whether what is in the MBR is valid before doing so. So, regardless of which of these viruses infect first, if both infect the same hard drive, the first virus will take the old MBR and move it to sector 7 and replace it with the virus code. If both viruses infect, this results in the old MBR which had been moved to sector 7 being overwritten by the infected MBR from the first virus infection. Therefore, there is no longer a valid clean MBR resulting in the machine becoming non- bootable. Thus, when McAfee's clean program, or any other cleaning program which takes advantage of the knowledge that the Stoned and Michelangelo viruses store the clean MBR at sector 7 are used, they will take whatever is stored at sector 7 and rewrite it to the first sector (where the MBR code should be) which will result in the virus code in sector 7 being restored to sector 1 instead of the clean MBR. This will happen again and again and again, no matter how many times one tries to disinfect the disk if the disinfection utility uses this mechanism. The better technique is to use FDISK/MBR since for either of these two viruses the partition table is left intact, and only the partition program is overwritten. For those boot sector viruses which do not preserve a copy of the partition table in a usable form, reconstruction of the partition table will be required (not a trivial task). Again, this is a good question, but unless the answer is included in the FAQ, we are doomed to see it again and again, ad infinitum. :-) Regards, Brian Seborg P.S. I would like to make a call to the readership and to the moderator to come up with a protocol for adding additional material to the FAQ so that it is both robust and current, what do you say! :-) ------------------------------ Date: Thu, 07 May 92 10:40:51 +0700 From: Vincent Tracey Subject: Request for assistance re workshop itinerary Hello Netters, I am requesting information on an organization that is claiming to be able to train personnel on 'Puter virus' :-). The itinerary (workshops?) includes: Phreaking, types of virus', worms, virus detection, simulations, and detection/investigation. The seminar is scheduled for three days and due to limited $$$s -:^( , I should like to hear of *any* comments on a Dr. Karl A. Seger or Corporate Consultants of Lenoir City, Tennessee. Any assistance in helping us decide if this course is *useful* is appreciated. Thanx, Vincent Tracey E-mail: traceyv@heidelberg-emh2.army.mil Security Investigator aeusg-hd-po-s@heidelberg-emh2.army.mil BSB-HD Security Office Phone: 06221-57-8054/6456 APO AE 09102 DDN 370-8054/6456 ------------------------------ Date: Tue, 12 May 92 23:27:52 +0000 From: rslade@sfu.ca (Robert Slade) Subject: Re: Lines of defense against viruses csp58@seq1.keele.ac.uk (S. Tripathi) writes: > What would be the best line(s) of defense agianst viruses? My >[limited] understanding is that at boot time a scanner and then a TSR >monitoring program. Most AV software seem to have the two functions >built in. Do the AV software also come with disinfectors or are they >separate packages ? Having reviewed these things all this time, I should best make some kind of a stand here, eh? Padgett, and others, have given detailed descriptions of the concept of multi-layered protection, and it should come as no surprise that this is what I suggest. To simplify, and to try to bring it into the "real world" of "real products": 1) some kind of "boot time" integrity checking. Padgett's DISKSECURE or FixMBR/SafeMBR are available in the MS-DOS world. I am not aware of comparable products in other OSs. 2) a "boot completion" memory and system check. At the present time I am not aware of any products which do this automatically. All I am thinking of here is a simple check of memory to ensure that nothing new is in memory which is not there at the normal boot time. This is intended to protect the further steps against stealth attacks. 3) "test before we start". This can be either a scanner or a change detector/integrity checker: I would suggest both. 4) scan all new disks and programs. Self explanatory. > Where do integrity checkers fit into the scheme of things ? Vesselin says there are three types of antiviral software; I make some minor subsetting and come up with five. They are: scanners, which search for "string" patterns which identify specific viral programs; change detectors, which look for any changes in files and systems areas (which may or may not be due to viri); activity monitors, which look for the types of activities likely to be due to viral action; operation restrictors, which attempt to prevent "dangerous" operations; and encryption systems, which attempt to make a non-standard environment to prevent successful viral spread. Some of these have to be TSRs, some may be. > Which are the "best" products for the different lines of >defense? From where may copies be obtained (preferably UK sites) ? Funny you should ask :-) You have probably seen the draft list by this time. Jim Wright puts out an excellent list of sites every month. ============= Vancouver | "The client interface Institute for Robert_Slade@sfu.ca | is the boundary of Research into rslade@cue.bc.ca | trustworthiness." User CyberStore Dpac 85301030 | - Tony Buckland, UBC Security Canada V7K 2G6 | ------------------------------ Date: 13 May 92 10:08:13 +0000 From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Lines of defense against viruses csp58@seq1.keele.ac.uk (S. Tripathi) writes: > What would be the best line(s) of defense agianst viruses? My > [limited] understanding is that at boot time a scanner and then a TSR > monitoring program. Hmm, no, I definitively wouldn't call this "the best line of defense against viruses"... Note that any new virus will not be detected by the scanner and that a tunneling virus will trivially bypass the TSR monitoring program. But you are correct by thinking that a range of anti-virus techniques must be used. A few posts ago Padgett Peterson published an excellent article about how one should combine several anti-virus techniques to stop viruses. I suggest that you review the messages from the last two weeks. > Most AV software seem to have the two functions > built in. Do the AV software also come with disinfectors or are they > separate packages ? It depends on the package, of course. Till not the only software I am aware of that has the scanner and the disinfector packaged separately, is McAfee's SCAN/CLEAN. > Where do integrity checkers fit into the scheme of things ? There are several kinds (about a dozen) of anti-virus programs, but they can be grouped into three main groups: scanners/removers, monitors, and integrity checkers. Therefore, the integrity checkers are just a kind of anti-virus programs - and currently the strongest (although not the most used) line of anti-virus defenses. > Which are the "best" products for the different lines of > defense? From where may copies be obtained (preferably UK sites) ? The following is only my oppinion and is based only on the anti-virus products I am experienced with. Sorry, if I forgot somebody's product. The two best scanners I know are Dr. Solomon's Atni-Virus ToolKit (from S & S International, UK) and Fridrik Skulason's F-Prot. It's difficult to say which is better, since they are good in different ways. The AVTK detects a little bit more viruses than F-Prot and performs exact virus identification, which is essential when disinfecting viruses. F-Prot is able to disinfect more viruses than the AVTK and better recognises new (unknown) variants of the old viruses. Considering the price of F-Prot ($1 per machine per year), it's probably better to use it together with any other scanner. The most secure TSR monitor I have seen is Mark Washburn's SECURE. It tries to provide discretionary access control to DOS. Of course, due to the lack of memory protection in DOS it can be bypassed, but this requires disassembling the program and understanding it, which is not trivial, since it uses some armouring tricks. Therefore, it provides security by obscurity. It is also not compatible with some environments (4DOS, Windows) and not very user-friendly. Another drawback is that the author is known to have written viruses (the V2Px serries) and some people cannot live with programs written by such people... :-) The package is shareware, available from Simtel20. The best integrity checkers I have seen are provided with V-Analyst III (the Untouchable in the USA) and the ASP Integrity Toolkit (available directly from ASP - Fred Cohen's company). A good alternative is also Integrity Master (shareware), but it is currently not so secure as the packages mentioned above. Of the hardware security features I am familiar with ThunderByte, produced by ESaSS in the Netherlands. Not virus-proof as their authors claim, but a pretty useful tool. Maybe one should also include Padgett Peterson's FIXUTILS (shareware); some program to backup the boot sectors and to restore them; and a few other tools. Of course, a good backup program is indispensable, but I don't have good experience with any of them, so I cannot recomend anything. I am trying to manage with ARJ (an archiver) and multi-volume archives on diskettes, but am not entirely satisfied... Hope the above helps. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN ** PGP public key available by finger. ** Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: Mon, 11 May 92 22:11:16 -0700 From: rslade@sfu.ca (Robert Slade) Subject: Review of Dr. Solomon's Anti-Virus Toolkit (PC) PCDSAVT.RVW 920505 Comparison Review Company and product: S&S International Ltd. Berkley Court, Mill Street Berkhamsted, Herts. HP2 4HB England Phone: +44 442 877 877 Fax: +44 442 877 882 BBS: +44 494 724 946 442 877 883 E-Mail: Dr. Alan Solomon sands@cix.compulink.co.uk Dr. Solomon's Anti-Virus Toolkit (AVT) 5.11 Vendor: perComp Verlag GmbH Holzmuhlenstrasse 84 2000 Hamburg 70 Germany Phone: +49 40 693 2033 Fax: +49 40 695 9991 E-Mail: Gunter Musstopf vendor: Ontrack Computer Systems 6321 Bury Drive Eden Prairie, MN 55346 USA (800) 752-1333 (612) 937-1107 fax: (612) 937-5815 Summary: Multilayered detection and disinfection system, strong scanning and disinfection components, intended for advanced use. Cost Rating (1-4, 1 = poor, 4 = very good) "Friendliness" Installation 2 Ease of use 3 Help systems 2 Compatibility 3 Company Stability 3 Support 3 Documentation 3 Hardware required 4 Performance 4 Availability 3 Local Support ? General Description: Menu driven (TOOLKIT) activity monitoring (GUARD, GUARDEMS), change detection (CHKVIRUS, QCV, RUN), scanning (FINDVIRU), disinfection (UNVIRUS, CLEANBOO, CLEANPAR), and operation restricting (NOFLOPPY, NOHARD) suite of programs. Also contains informational programs (CHECKMEM, PEEKA), network support (NETFV.BAT, FVMANY.BAT), as well as additional utilities (SHRED, TKBATCH, BROWSER). Comparison of features and specifications User Friendliness Installation The program is shipped on non-writable disks, two 360K or one 720K. There is an installation program: as it is a fairly simple copy program manual installation is also possible. The installation program will, at the user's discretion, also add the resident portion of the package to the AUTOEXEC.BAT file, however it does not affect the PATH statement, and therefore all virus checking must either start from within the \TOOLKIT directory (or whichever one the user creates), or be invoked with a full pathname. I have recommended the manual installation. The installation program provided is simple and quick, and I can see no problem with using it. However, the full advantage of this product is not, and probably cannot be, provided with an automated installation. Ease of use The TOOLKIT program provides a clear and uncluttered menuing system to access the various parts of the package. The screen messages and displays are intelligible and there is little chance for confusion. There are a number of command line options for use with the various programs when not using the TOOLKIT interface. The defaults are well chosen, and should be appropriate for most situations, and for novice users. For situations where client support is available, the message generated by VirusGuard on detection of a virus can be customized to direct the user to the local security support person. Help systems While help should not normally be required, in cases where it is needed it can best be obtained from the manual. Compatibility No conflicts were encountered in testing. Company Stability S&S International is an established presence in the antiviral software field, and has been so in Britain for some years. Company Support The package lists provisions for support through both the parent company and distributors. Documentation The documentation is an excellent study work for those just entering the computer virus field and wanting an introductory work. The explanation of how viral programs work is one of the best general treatments of the subject, even including suggestions for companies wishing to set up policies and procedures for inhouse data recovery teams. The list of viri in the manual is thorough and detailed: as it should be, taking up fully two-thirds of the manual's thickness. However, the organization of the manual could be a lot more helpful in terms of running the package itself. One must read through 12 pages before getting to a mention of suing the program at all (although it is helpful that the first mention is of how to run the program in an "emergency" situation where the user is suspecting that they are already infected), and 20 pages before mention is made of installing the program. Five of those early pages are devoted to a virus by virus listing of the virus information contained in chapter 4. From the perspective of the manual, this cannot be said to be a package for beginners. There *is* excellent information in the manual, but my recommendation would be that the package not be installed until the manual was read fully from cover to cover, particularly chapter 5. (Advanced users may skip chapter 4 :-) Provision is now made for the TOOLKIT program to run under Windows: that material is not covered in the printed manual but in a README.DOC file on the disk. In addition there are a number of possibly helpful batch files which are not mentioned or described anywhere. Advanced MS-DOS users should be able to modify these batch files to their own situation: again, it seems to be indicative that the package is not for naive users. There are other materials on the disk whose existence has less seeming reason: section 5.9 is reproduced in the file GUARD.DOC. Hardware Requirements The Toolkit can be run on dual floppy systems, although some functions require a hard drive. Performance Although the package provided for reviewing was sadly out of date, the scanner did a better job of detection of viral programs than a number of "current" commercial packages. A number of recent variant strains were identified as being related to their older "parents". Local Support None provided. Support Requirements The package is easy to use, particularly in the areas of scanning and disinfection, and should not require any additional assistance in detection of known viral programs. However, the package has very strong and sophisticated protection components which would give fullest advantage when installed by knowledgeable support personnel. The ongoing upgrade programs provided should be very strongly considered in the case of this package. General Notes AVT provides very strong antivirus protection to the advanced user. AVT provides very strong virus scanning capability for all users. There are a number of indications that this package is intended primarily for advanced users. Unassisted use of the program by novice users would likely result in some loss of potential protection. Therefore, this package is highly recommended for use by advanced users, who are willing to make the commitment to study the material provided. The package is recommended for novice users where local support is available. copyright Robert M. Slade, 1992 PCDSAVT.RVW 920505 ============== Vancouver | "Don't buy a Institute for Robert_Slade@sfu.ca | computer." Research into rslade@cue.bc.ca | Jeff Richards' User CyberStore Dpac 85301030 | First Law of Security Canada V7K 2G6 | Data Security ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 105] ******************************************