VIRUS-L Digest Thursday, 1 Mar 1990 Volume 3 : Issue 51 Today's Topics: Possible Virus (PC) Virus spread (PC) Memory Scans for Viruses (PC) Memory Scanning Addendum (PC) Disinfecting vs. backups & virus signatures (PC) Virus Catalog February 1990 Edition RE: Israeli virus strains vs. Novell? (PC) Re: How the 1554 virus recognizes infected files (PC) Viruses and Copyrights (Part 2) 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. Please sign submissions with your real name. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to LEHIIBM1.BITNET for 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@SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: 27 Feb 90 20:20:16 +0000 From: wb@cbnewsj.ATT.COM (werner.baumgartner) Subject: Possible Virus (PC) I recently down-loaded a file from a local BBS called MEGASPUP.ZIP which is flagged by SCAN58 as containing 2 viruses, 1701/1704 Ver B and Vacsina. This program is supposed to decrease disk access time, according to the documentation. Does anyone have any information about this file, such as its origin etc. Also, now what do I do with it, should I send it somewhere to be analysed ? ------------------------------ Date: Tue, 27 Feb 90 20:05:00 -0500 From: Preston@DOCKMASTER.NCSC.MIL Subject: Virus spread (PC) Is Jerusalem-B spread an indicator of the future? Jerusalem-B (Israeli variant) was apparently shipped about 1 week ago in a PC AT clone from one of the smaller companies. It was on a formatted hard drive with MS-DOS 4.01 installed. The company confirmed that they had been having a problem with that virus when contacted by the upset owner. An earlier contact with the company had resulted in a denial of a virus problem, and a claim of shipping 300 systems per day. The new owner, being innocent in the ways of viruses, had, within an hour, infected his master copies of Microsoft Works and an income tax program, and now has ordered replacements. This is the same virus shipped by the Census Bureau several weeks ago to about 300 users, according to published reports. There have been detection tools for this virus for months, rather than weeks, as in the case of some of the newer and "better" viruses. So far, indications from my experience and surveys are that most companies and users wait to learn from personal experience about viruses, rather than learning from others. Are these infections (with an old virus) an indication of what will happen when the large number of new viruses have had time to spread far enough? Or will the increasing availability of virus scanning tools and self-checking programs (like MS Works) intersect the "infected systems curve" soon? I don't recall seeing an "average rate of adoption" study for techniques to counter new classes of threats to information systems, but it appears that it may be in the 10%/year range or lower, at least initially. Charles M. Preston 907-344-5164 Information Integrity MCI Mail 214-1369 Box 240027 BIX cpreston cup.portal.com ------------------------------ Date: Tue, 27 Feb 90 17:47:32 -0800 From: Alan_J_Roberts@cup.portal.com Subject: Memory Scans for Viruses (PC) This is a forward from John McAfee ================================================================= Nino Margetic raised a good point yesterday that I have not seen discussed yet. His question was - "why would a virus be detected in memory when there is no indication of the virus in any of the system's files?". A very good question. To begin with, as Nino pointed out, the system was infected and then disinfected. Herein lies the mystery. In the disinfection process files are read in through the DOS internal buffers, disinfected and written back out -- again passing through the DOS internal buffers. DOS has a very peculiar habit of insisting that all file creations occupy a full cluster, whether you need it or not, and rather than zeroing out the remainder of the cluster, DOS further insists on padding the remainder with whatever is currently hanging out unused in the buffer area. Why it does the I do not know -- perhaps a sense of nostalgia for what was once useful code -- who knows, but in any case this is what it does. When a file is disinfected then, and written back as a clean file, everything beyond the end of file mark is residual from whatever has passed through the DOS buffers. Inevitably, pieces of the original virus will end up in the buffer area, located just at the end of the disinfected program. These virus pieces are then written to the disk as filler for the remainder of the cluster. This process is not unique to disinfecting. Any file creations performed while a system is infected may have this end result. Now, whenever the file is scanned, DOS reads to the end of the file mark and passes the information to the scan routine. SCAN sees a clean file, as indeed it is. However, in the process of scanning the file, DOS had to read the entire cluster into the internal buffers (God knows why -- perhaps, again, from some sense of nostalgia for lost data) and in the process it may bring pieces of the virus into its buffers. A memory scan will then detect this. The virus is of course not functional or harmful at this point. It is possible, of course, to design a memory scan that could differentiate between a live and a dead virus. But this would cause weaknesses in the memory scan function due to possible modifications of the virus by unknown hackers that would fool the scan. It's easy to relocate code. Not so easy to re-code the segments that being scanned for (assuming the hacker does not know the segments being used as the I.D.). In any case, that's neither here nor there. The causes of Nino's observations are hopefully exposed. .... ------------------------------ Date: Tue, 27 Feb 90 17:57:50 -0800 From: Alan_J_Roberts@cup.portal.com Subject: Memory Scanning Addendum (PC) Another forward from John McAfee: ======================================================================== I think that I forgot to answer the implied question in Nino Margetic's posting -- "If, after a disinfection, t file scan says I'm clean but the memory scan flags the virus, what do I believe?" Believe the file scan. Except for the following viruses - 4096, 512 and EDV. If it happens with any of these three then give us a call. 408 988 3832. John MKcAfee ------------------------------ Date: 28 Feb 90 21:10:00 +0700 From: T762102@DM0LRZ01.BITNET Subject: Disinfecting vs. backups & virus signatures (PC) Hi! John McAfee (in vol. 3, issue 50) writes: > the process of disinfecting a >file always leaves an element of uncertainty in the system. > For example, the Jerusalem virus uses information in the EXE >header record to determine how to infect. Often this header record >is inaccurate, causing the virus to overlay part of the EXE file, >and also causing the virus to update the header record incorrectly. Often? How often? I know about a version of WordPerfect and that's all. >The virus has, in effect, destroyed part of the EXE file, and this >destruction is often not noticed immediately by the user. The >corrupted area might be seldom referenced, or in a program function >area that is bypassed in normal processing. If this is the case, >removal will leave a program that will at some point cause >inconsistencies, data corruption, or system crashes when the erased >area is referenced. There is simply no way to recover the file >because there is no way (short of using the original uninfected >program) to determine what was in the file before it was >overwritten. Well, the file was *already* destroyed when it was infected. If you disinfect it you won't cause more damage (besides the false sense of security). If you don't have the appropriate backups (or the originals, of course), you have only two possibilities --- to leave the file destroyed but infected and to leave it destroyed but *not* infected. I prefer the second solution, since the first will continue to spread the infection. Of course, you can also completely delete the file. > The Jerusalem is not alone in causing these problems. There >are numerous EXE infectors and some COM infectors (405, Vienna) >that cannot be successfully recovered in all cases. Ooops! Files, which are *infected* by the Vienna virus can *always* be recovered. In all cases. You cannot recover the files *destroyed* by this virus (with their first 5 bytes overwritten), but this is the case with all files destroyed by a virus. (They know well how to destroy our data, these nasty things :-).) > To get back to my point, I would strongly suggest that >infected files be overwritten in their entirety and then deleted >if at all possible. Only as a last resort, where backups or >original diskettes are unavailable, should disinfection be used. OK, OK! I agree that it is better to have backups. But it is *best* to have *both* backups and a disinfector. If this was not true all the work done by the antivirus researchers would be useless. This forum would be useless too. It is relatively easy (if you have non-infected backups, of course) to recover from any virus attack --- even if it was performed by the most sophisticated virus. You have only to follow a set of computer hygiene rules, which fin on a half page. Even that dumb fool --- the so-called average user can be teach to follow them.... Hmmm, can he? :-) - -------------- John Sangster (JHSangster@DOCKMASTER.NCSC.MIL) writes: >Possibly a useful approach to posting virus scan patterns would be >for virologists to extract one or more segments of the virus code of, >say, 1K bytes (that's a fairly reasonable 12 lines at 80 bytes per >line). >Of course, viruses can be constructed which alter themselves at each >replication, making any search with a fixed string futile, or at >best, "challenging" to design. CAN BE?! Whey *were* constructed. The 1701/1704 virus contains only a small piece of code which can be scanned for --- all the rest is encrypted. The virus uses the file length as an encryption key --- therefore the encrypted part is always (well, almost always) different. And there exist much more clever viruses like the 4096 and the 1260 viruses, in which even the (small) part which is not encrypted and which is used to decrypt the rest of the virus, even this small part is somewhat different for every infected file. (Well, I think so, I have no examples of these viruses.) And it is also possible to design a virus (hey, catch that virus writer who is reading this behind your back :-)), which will be impossible to be recognized --- in the file. The virus itself will not be able to say if a file is already infected. Eventually, there will be two (or more) copies of the virus in the file. But when the file is run, the virus will figure out that there is something after it and will strip it off the file. It is hard to implement such a thing, but once someone gets the idea, it will be much easier --- remember the problem "write a program which outputs its own source". Vesselin ------------------------------ Date: 28 Feb 90 17:16:00 +0100 From: Klaus Brunnstein Subject: Virus Catalog February 1990 Edition ======================================================================= == Computer Virus Catalog Index == ======================================================================= == Status: February 15, 1990 (Format 1.2) == == Classified: 15 MSDOS-Viruses (MSDOSVIR.A89): Nov.15,1989 == == +17 MSDOS-Viruses (MSDOSVIR.290): Feb.15,1990 == == 24 AMIGA-Viruses (AMIGAVIR.A89): Nov.15,1989 == == 6 Atari-Viruses (ATARIVIR.A89): Nov.15,1989 == == Next edition planned: April 1990 == ======================================================================= == To minimize problems with network restrictions (some of which == == limit e-mail to packages of less than 100 kBytes), the list of == == totally 30 MS-DOS viruses is partitioned, due to the first pub- == == lication, in 2 partitions (indicated at each entry): == == October 1989: Document MSDOSVIR.A89: 1.138 Lines, 62 kBytes == == + February 1990: Document MSDOSVIR.290: 1.163 Lines, 67 kBytes == ======================================================================= == List of classified MS-DOS Viruses: =Doc= == ---------------------------------- = = == + 1) Advent Virus =290= == 2) Autumn Leaves=Herbst="1704"=Cascade A Virus =A89= == 3) "1701" = Cascade B = Autumn Leaves B = Herbst B Virus =A89= == 4) Bouncing Ball = Italian = Ping Pong= Turin Virus =A89= == + 5) Dark Avenger =290= == + 6) DATACRIME Ia = "1168" Virus =290= == + 7) DATACRIME Ib = "1280" Virus =290= == + 8) dBase Virus =290= == + 9) Denzuk = "Search" = Venezuellan Virus =290= == + 10) Do Nothing = Stupid = 640k Virus =290= == 11) "Friday 13th" = South African Virus =A89= == + 12) Fu Manchu Virus =290= == 13) GhostBalls Virus =A89= == + 14) Hello (1A) Virus =290= == 15) Icelandic#1 = Disk Crunching = One-in-Ten Virus =A89= == 16) Icelandic#2 Virus =A89= == 17) Israeli = Jerusalem A Virus =A89= == + 18) Lehigh Virus =290= == 19) MachoSoft Virus =A89= == + 20) Marijuana = Stoned = New Zealand Virus =290= == 21) Merritt = Alameda A = Yale Virus =A89= == + 22) MIX1 = Mixer1 Virus =290= == + 23) Ogre = Disk Killer 1.00 Virus =290= == 24) Oropax = Music Virus =A89= == 25) Saratoga Virus =A89= == 26) SHOE-B v9.0 Virus =A89= == + 27) sURIV 1.01 Virus =290= == + 28) Swap = Israeli Boot Virus =290= == + 29) SYSLOCK Virus =290= == 30) VACSINA Virus =A89= == 31) Vienna = Austrian = "648" Virus =A89= == + 32) Zero Bug = ZBug = Palette Virus =290= == == == Remark: The following 25 MSDOS-Viruses are presently examined, == == classification will be published in next edition (April,1989): == == == == .) AIDS Virus == == .) Amstrad Virus == == .) Ashar Virus (Pakistani Virus Strain)== == .) Brain A = Pakistani A-Virus (Pakistani Virus Strain)== == .) April 1st Virus (Jerusalem Virus Strain)== == .) DATACRIME II = Columbus Day Virus (DATACRIME Virus Strain)== == .) Devils Dance Virus == == .) Ghost Boot Virus == == .) Lisbon Virus (Vienna Virus Strain)== == .) Pentagon Virus == == .) Perfume Virus == == .) Silvia Virus == == .) SURIV 2.01, 3.00 Viruses (Jerusalem Virus Strain)== == .) Traceback = "3066" Virus == == .) Typo (Link) = Fumble Virus == == .) Vcomm Virus == == .) W13 (Variants A,B) = Polish Viruses == == .) Yankee Doodle Virus == == .) Yankee Bulgarian Virus == == .) "405" Virus == == .) "1260" Virus == == .) "1702" Variant (Autumn Leaves Virus Strain)== == .) "4096" Virus == ======================================================================= == The list of 24 AMIGA viruses is divided into 2 partitions (as == == indicated at each entry): == == October 1989: Document AMIGAVIR.A89: == == November 1989: Document AMIGAVIR.B89: == ======================================================================= == List of AMIGA Viruses: == == ---------------------- == == 1) AEK-Virus = Micro-Master Virus (SCA Virus Strain) =A89= == 2) BGS 9-Virus =A89= == 3) Byte Bandit Virus =A89= == 4) Byte Bandit Plus Virus (Byte Bandit Virus Strain) =A89= == 5) Byte Warrior#1 Virus = DASA-Virus (Byte Warrior Strain) =A89= == 6) Disk Doctors Virus =A89= == 7) Gaddafi-Virus =A89= == 8) Gyros Virus =A89= == 9) IRQ-Virus =A89= == 10) LAMER (Exterminator) Virus =A89= == 11) LSD Virus (SCA Virus Strain) =A89= == 12) NORTH STAR I Antivirus-Virus (NORTH STAR Virus Strain) =A89= == 13) NORTH STAR II Antivirus-Virus (NORTH STAR Virus Strain) =A89= == 14) Obelisk Virus =A89= == 15) Paramount Virus=Byte Warrior#2 Virus (Byte Warrior Strain)=A89= == 16) Pentagon Antivirus-Virus =B89= == 17) Revenge 1.2G Virus =B89= == 18) SCA-Virus =B89= == 19) System Z 3.0 Antivirus-Virus (System Z Virus Strain) =B89= == 20) System Z 4.0 Antivirus-Virus (System Z Virus Strain) =B89= == 21) System Z 5.0 Antivirus-Virus (System Z Virus Strain) =B89= == 22) Timebomb 1.0 Virus =B89= == 23) VKill 1.0 Virus = Camouflage Virus =B89= == 24) WAFT-Virus =B89= == == == Remark: the following 8 AMIGA-viruses are presently analysed,clas-= == sified and will be published in the next edition (April,1990): == == .) BUTONIC 1.1 Virus == == .) JOSHUA Virus == == .) LAMER EXTERMINATOR Virus 1.0, 2.0, 3.0 == == .) SYSTEM Z 5.1, 5.3 Virus == == .) WARHAWK Virus == ======================================================================= == Document ATARIVIR.A89 contains the classifications of the == == following 6 viruses (375 Lines, 21 kBytes): == ======================================================================= == List of Atari Viruses: == == ---------------------- == == 1) ANTHRAX = Milzbrand Virus =A89= == 2) c't Virus =A89= == 3) Emil 1A Virus = "Virus 1A" =A89= == 4) Emil 2A Virus = "Virus 2A" = mad Virus =A89= == 5) Mouse (Inverter) Virus =A89= == 6) Zimmermann-Virus =A89= == == == Remark: the following 2 Atari-viruses are presently analysed,clas-= == sified and will be published in the next edition (April,1990): == == .) BPC Virus == == .) Ghost Virus == == == We have problems to get Atari viruses, as many users wish to ex- == == change their viruses (like stamps) against our's, which we gene- == == rally refuse: the Virus Test Center's ethical standard says, that == == we do not help to spread viruses! Please send infected programs == == without preconditions; we may only then continue our work. == ======================================================================= ======================================================================= == For their outstanding support and continued help, we wish to == == David Ferbrache (Edinburgh), Christoph Fischer (Karlsruhe), == == Yisrael Radai (Jerusalem) and Fridrik Skulason (Rejkjavik). == == Critical and constructive comments as well as additions are == == appreciated. Especially, descriptions of new viruses will be of == == general interest. To receive the Virus Catalog Format, containing== == entry descriptions, please contact the above address. == ======================================================================= == The Computer Virus Catalog may be copied free of charges provided == == that the source is properly mentioned at any time and location == == of reference. == ======================================================================= == Editor: Virus Test Center, Faculty for Informatics == == University of Hamburg == == Schlueterstr. 70, D2000 Hamburg 13, FR Germany == == Prof. Dr. Klaus Brunnstein, Simone Fischer-Huebner == == Tel: (040) 4123-4158 (KB), -4715 (SFH), -4162(Secr.) == == Email (EAN/BITNET): brunnstein@rz.informatik.uni-hamburg.dbp.de == ======================================================================= == This document = INDEX.290: 164 Lines, 12 kBytes == ======================================================================= ------------------------------ Date: Wed, 28 Feb 00 19:90:25 +0000 From: Gonzalo M. Rojas Costa Subject: RE: Israeli virus strains vs. Novell? (PC) Hi... Otto Stolz (RZOTTO%DKNKURZ1.BITNET@CUNYVM.CUNY.EDU) writes: >> ** the "Friday 13th" will cause Novell Networks to hang every time an >> infected program is invoked; Yes. Novell Networks use function E0 of int 21h for the print spooler. For that reason, if I execute an infected program, the server and the stations hangs. (On the server, before it hangs, the LAN manager prints a message that an interrupt vector was try to changed). >> ** so will probably other Israeli strains do. I tested versions B and B-2 of the Jerusalem virus and the two versions produce the same efect (hangs the stations and server). >> IMMUNE and similar virus-watchers will probably suspect Novell of >> being a virus, and alert the user about it; >> VIRCHECK and similar virus-checkers will cause Novell to hang, >> as well. I didn't tested IMMUNE on a Novell Network. But any program that try to detect the Jerusalem Virus through function E0 int 21h, hangs the computers on a Novell Network. In a Novell Network or other LAN you can use John Mcaffe's NETSCAN to search infected programs. (This program is on SIMTEL20 in the directory PD:). Disclaimer: The views expressed are my own! I do not speak for, nor do I represent any other person or company. Gonzalo M. Rojas Costa BITNET: LISTVIR@USACHVM1 ARPA: LISTVIR%USACHVM1.BITNET@CUNYVM.CUNY.EDU Owner of ASSMPC-L Antiviral Research Group Technical Support Unit Universidad de Santiago de Chile ------------------------------ Date: Wed, 28 Feb 00 19:90:57 +0000 From: Gonzalo M. Rojas Costa Subject: Re: How the 1554 virus recognizes infected files (PC) Hi... Vesselin Bontchev (T762102@DM0LRZ01.BITNET) writes: >> For .COM files: >> If the contents of the word at offset 02 in the file is 12Eh, >> then the file is infected. No. The file isn't infected if the contents of the word at offset 02 in the file is 12Eh. (i.e. If I have an infected program, this always have the word 12Eh at offset 02, because this word is part of an instruction of the virus). >> For .EXE files: >> If the contents of the word at offset 02 in the file is equal >> to the negated contents of the word at offset 12h, then the file is >> infected. No. If the contents of the word at offset 02 (Number of bytes contained in last page) is equal to the negated contents of the word at offset 12h (negative sum of all the words in the file), then the program ISN'T INFECTED. (In the process of infection, the virus negates the number of bytes contained in the last page of the EXE program, and this value it puts at offset 12h of the header (i.e. as the negative sum of all the words in the file). >> Unfortunately, this does not give us a method for file vaccination, >> since the contents of the bytes mentioned above is used. For .COM >> files, the byte at offset 02 is usually (not always!) the third >> byte of a JMP instruction. For .EXE files the situation is >> easier --- the word at offset 12h contains the so-called checksum, >> which is never used and can be modified. I completely agree with you. Disclaimer: The views expressed are my own! I do not speak for, nor do I represent any other person or company. Gonzalo M. Rojas Costa BITNET: LISTVIR@USACHVM1 ARPA: LISTVIR%USACHVM1.BITNET@CUNYVM.CUNY.EDU Owner of ASSMPC-L ("Assembly for the IBM-PC") Antiviral Research Group Technical Support Unit Universidad de Santiago de Chile ------------------------------ Date: Wed, 28 Feb 90 21:08:43 -0500 From: davidbrierley@lynx.northeastern.edu Subject: Viruses and Copyrights (Part 2) This is to continue my earlier posting on copyrights and viruses, based upon _How to Copyright Software_ by M.J. Salone. This posting is in regards to derivative works; for example, a disassembly of a virus made by someone other than the virus author. Congress defines the term 'derivative work'as "a work based upon one or more pre-existing works." [17 USC Sec. 101] A virus disassembly would probably fall under this definition because the opcodes are presumably from the actual virus even though the descriptive comments are the creative input of the person disassembling it. The above definition is likely to apply if a disassembly is considered to be a translation of the virus. The question then becomes "Is the disassembly author required to get the permission of the person who holds the copyright (usually the author) before publishing the disassembly?" The answer is, technically, yes. However, the absence of a copyright notice could be a legitimate excuse for assuming that the virus is public domain; this is backed up by the fact that viruses are designed to replicate themselves without consent of the user. Items within the public domain are free to be used and distributed in any way. Derivative works of public domain items can be copyrighted as long as the new material is substantial enough to be considered original. As far as disassemblies are concerned, the aforementioned descriptive comments are original material and can thus be copyrighted (i.e. the whole disassembly). Of course there is the question of whether-or-not a virus is considered to be properly copyrightable anyway, as other contributors to Virus-L have noted. Viruses install themselves into other programs, thus creating aunauthorized derivative works in the process! Please note that, if the above is untrue, then the disassembly can not be published without the consent of the virus' copyright holder. The copyright holder of a work solely has the right to publish derivative works based upon his/her original publication during the duration of the copyright. In my opinion the disassembly is copyrightable because the virus is in the public domain (since copyright notices are not normally found in viruses; not to mention that viruses may themselves be somewhat illegal). I I doubt that a virus author would sue for infringement because, as I said in my previous posting, that the virus author is likely to incrimminate himself by doing so. [Ed. For what it's worth, I believe that some versions of the Brain virus included a copyright notice in the ASCII header.] My next posting will contain a discussion on what rights are protected by a copyright. DISCLAIMER: The above are my opinions. I'm not a lawyer :-) Please do not take this material to be the law. ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253