VIRUS-L Digest Monday, 25 Nov 1991 Volume 4 : Issue 226 Today's Topics: re: Warning! SCAN 82 trojanized! (PC) Re: Hard disk problem (PC) Re: System 7 vs. viruses (Mac) PCVirus publication? (PC) re: NIST Naming Proposal Re: NIST Naming Proposal Re: Dir-II removal (PC) Virus Verification and Removal Radai re: Frisk, re: Washburn Taxonomy tool? Empire Virus Update (long) (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. 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: Fri, 22 Nov 91 14:56:16 -0500 >From: pshuang@Athena.MIT.EDU Subject: re: Warning! SCAN 82 trojanized! (PC) > I have received reports from several places that breaking PKZIP's > authentification code is relatively easy. Does anyone know if PAK 2.0's security envelope feature has also been compromised? There doesn't seem to be the need to come up with any sophisticated procedure or program from scratch if one already exists. Adopting one of the schemes whereby the file is CRC'd by two seperate algorithms should also be foolproof, right? - --- Above text where applicable is (c) Copyleft 1991, all rights deserved by: UNIX:/etc/ping instantiated (Ping Huang) [INTERNET: pshuang@athena.mit.edu] ------------------------------ Date: Fri, 22 Nov 91 23:53:46 +0000 >From: bdh@gsbsun.uchicago.edu (Brian D. Howard (CS)) Subject: Re: Hard disk problem (PC) d246@uni05.larc.nasa.gov (Glen Braden) writes: >Greetings, > I have a question, concerning my brother's PC. I installed a new >(40m) hard disk into his 286 PC UNLIMITED(?) after his original hard >disk got trashed... Make sure that he sets the DOS partition as 'active' using FDISK. - -- _______________________________________________________________________________ This space intentionally left what would otherwise be blank were this not here. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------ Date: Fri, 22 Nov 91 23:01:49 +0000 >From: plains!umn-cs!LOCAL!aslakson@uunet.uu.net (Brian Excarnate) Subject: Re: System 7 vs. viruses (Mac) lunde@casbah.acns.nwu.edu (Albert Lunde) writes: > 1 - Desktop file viruses do not spread easily under system 7, because > the Finder is more careful about how it opens the Desktop file. > (This may be related to the use of the Desktop database except on > floppies or to the Finder rewrite in C++, I don't know. This > *could* be Apple getting smart.) Desktop file viruses do not spread under System 7 because System 7 does not use the Desktop file. If you have one left over from an older System, you can delete it if you like. The best way of scanning is to boot from a floppy with Disinfectant on it. That way nothing is busy on the harddrive. If you want further details, e-mail me or ask on comp.sys.mac.system. Brian ------------------------------ Date: Sat, 23 Nov 91 02:16:19 -0800 >From: jprice@intel7.intel.com (Great GooglyMoogly!) Subject: PCVirus publication? (PC) I've noticed several times in the digest that a publication named PCVirus has been mentioned. I have never seen this magazine. Could someone please send me some information about this publication. I think that I'd like to subscribe. Thanks in advance. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: John Price, FB7-53, Intel, Rio Rancho, New Mexico 87124 :: :: eMail: JPrice@Intel7.Intel.Com :: :: standard disclaimer applies :: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: "Your brain may no longer be the boss." Firesign Theatre ------------------------------ Date: Sat, 23 Nov 91 11:24:37 +0000 >From: Fridrik Skulason Subject: re: NIST Naming Proposal >Does anyone know of, or use, a radically different naming convention >(other than the ones mentioned and decided against in the NIST >documents)? None of the current major products...all the "radically different methods", such as the old East-German method of just numbering the viruses (virus-1, virus-2 ....etc) have been abandoned - or at least I don't think one needs to worry about them..... However - many products refer to variants of the some family only under a separate name - for example "Fu Manchu", but not "Jerusalem-Fu Manchu" or "Israeli-Fu Manchu". - -frisk ------------------------------ Date: Sat, 23 Nov 91 14:09:02 +0700 >From: KADLOF@PLEARN.BITNET Subject: Re: NIST Naming Proposal In VIRUS-L 4/224 "David.M.Chess" ask: >Does anyone know of, or use, a radically different naming convention >(other than the ones mentioned and decided against in the NIST >documents)? I know that the soviet researches are using radically different naming convention. It is based on classification method proposed by Nikolay Bezrukov from Kiev Institute of Civil Aviation Engineers. I am sure that Vesselin Bontchev has english description of soviet convention (he posted it in the FIDONET about one year ago). If you have in your sample collection any file with name like RCE-1834 then it is from Soviet Union archives. I do believe Vesselin will be able to provide better english description what I am talking about. Andrzej Kadlof Department of Mathematics, University of Warsaw Editor-in-chief of PCvirus Bulletin ------------------------------ Date: Sat, 23 Nov 91 14:09:01 +0700 >From: KADLOF@PLEARN.BITNET Subject: Re: Dir-II removal (PC) In VIRUS-L 4/224 bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: > The only three >methods for removing this virus which are currently availble, are >CLEAN 84, my program DIR2CLR, and using the REN method, described by >Andrzej Kadlof (similar to your backup method, but much easier and >faster). In Poland there is known the fourth method and as far as I known the best one. This is DIR2CURE.COM - program written by Marek Sell. This program hes been published in PCvirus 5(6)91. The problem with the first three method is that they work only when wirus is present in the system. Not necessary active (first two methods) but present. About two week ago I have had to clean Compaq Portable III with Compaq version of DOS 3.31. The problem is that Dir-II is able to install itself in memory of that system but is not able to write itself to disk. (I do not know why.) So my problem was to restore disk to its original state without live virus in the system. CLEAN v84 simply reported that there is no virus in the system. That was true. Vesselin's DIR2CLR was better as it reported new variant of Dir-II (due to the garbage in the last two sectors of HD). Method with renaming files is not applicable without Dir-II active in memory. Marek program is the only one I known, which can restore disk without detecting virus on the disk. I understand, that today, when we have two new variants of Dir-II (which I do not know yet), such a program may be as dangerous as CHKDSK is. (Restoring is possible only if the user decide to take the risk.) But it falls into general question how to restore disk encrypted in some way by virus, which deleted itself after final attack and there is no way to exactly decided which particular variant is responsible for all the mess. Andrzej Kadlof Department of Mathematics, University of Warsaw Editor-in-chief of PCvirus Bulletin ------------------------------ Date: Sat, 23 Nov 91 14:09:03 +0700 >From: KADLOF@PLEARN.BITNET Subject: Virus Verification and Removal In VIRUS-L 4/224 "David.M.Chess" writes: >The November 1991 issue of Virus Bulletin has a paper by me on the >above subject. It talks in general about verifying the identity of a >virus (why and how), and attempting to remove viruses from infected >objects (why, why not, and how); and it talks about the prototype >program that we have to do these things. The program is basically a >little interpreter for a high-level language that describes viruses >for verification and removal purposes. I know various other folks >have done similar things, and we hope that this paper will stimulate >discussion (and/or bragging!) on the subject. I am very happy that this subject is at last raised. I have never been able to understand how people can discuss about viruses (even about very specific technical details) without certainty that they are talking about the same. I think that the question of unique virus recognition is very important and should be solved as soon as possible. Some job in this direction has been done in Poland. One year ago we have started to publish PCvirus bulletin. One of the main idea of PCvirus is to give people so exact virus description, that they could be able to write safe cure. The major problem is of course unique virus identification. We use so called Virus Identyfication Card, which contains many general information and the most important, Virus Map. Virus Map is the main tool for virus identification. It consist of a series of numbers and is build in the following way: After the detailed analyze of virus, its body is divided into disjoint blocks. Each block is classified into one of the four categories: V - virus code, W - working area, C - constants and G - garbage. Working blocks we are ignoring. For blocks of type V, C and G we publish they offsets in virus body and set of control sums. Additionally, if given block is longer than 256 bytes, we divide it into smaller parts (of at most 256 bytes each). We olso sometimes publish dumps of blocks of type C or G if they can help during visual inspection of the suspicious file. For example the map of the virus Stoned is: offset block type length control sums - ------------------------------------------------------------------------ 0000 ( 0) virus code 8 AE0C 0008 ( 8) working area 13 0015 ( 21) virus code 373 907F 82ED 018A ( 394) constants 46 E34B dump: 59 6F 75 72 20 50 43 20 69 73 20 6E 6F 77 20 53 Your PC is now S 74 6F 6E 65 64 21 07 0D 0A 0A 00 4C 45 47 41 4C toned!.....LEGAL 49 53 45 20 4D 41 52 49 4A 55 41 4E 41 21 ISE MARIJUANA! - -------------------------------------------------- 0001C178:0002A4C3 --- Control sums are computed with the algorithm used by the Polish Section of Virus Information Bank. Of course the algorithm for computing control sums is published. I know that above method is not perfect. It is possible to write virus for which such a map could not be constructed. I call such a virus 'second generation virus'. However, after one year of experience, all viruses found in Poland in wild (about 100) falls into the class 'first generation virus'. Even selfencrypted viruse like Tequilla or 1260 (this one is not reported in Poland yet) has its map. Map for such a virus is build after decryption of its code. I know that similar concept has been developed by Vesselin Bontchev. Any comments are kindly welcome. Andrzej Kadlof Department of Mathematics, University of Warsaw Editor-in-chief of PCvirus Bulletin ------------------------------ Date: Sat, 23 Nov 91 10:29:00 -0500 >From: WHMurray@DOCKMASTER.NCSC.MIL Subject: Radai re: Frisk, re: Washburn Y. Radai: > I suppose, however, that you meant people who have released viruses >publicly, not just for test purposes. Well, perhaps. However, the important word is "released." >True, Washburn released a virus >publicly, but many of us distinguish between writers of deliberately >destructive viruses and those of non-destructive ones. I believe that you do but that such a distinction is not as significant as you believe. >And Mark's viruses are not destructive. Patently false. >True, someone else used his virus to create >a destructive one, and mainly because of the possibility that this >would happen, Washburn's decision was a mistake. It was indeed a mistake, but not only for the reason that you cite. >But perhaps he has realized his mistake? Perhaps. However, we must, in our own collective interest, punish the behavior, without regard to its perpetrator, his intent, or subsequentot his me aning. I believe that he intended exactly what he said. We should ignore, indeed we should ostracise, any and all who intentionally or knowingly release a virus. The only thing about the intent of such an author is the intent to release. That is at least reprehensible. I think that Mr. Skulason would agree with me that it should be punishable, at least within the cognoscenti, if not under the law. Between getting Mr. Washburn's virus on my computer and getting one of its progeny, I would prefer Mr. Washburn's. But that is not the issue. The author of this posting clearly believes that the intent of the author is important; it is not. Between having Mr. Washburn's program, it's progeny, or any other virus in the population, there is little to choose. ALL VIRUSES ARE DESTRUCTIVE OF TRUST. The persistent belief that there is something significant to choose among viruses, based upon their behavior in the execution environment, as opposed to their behavior in the population, is used by the ignorant, the reckless, or the irresponsible as justification for releasing viruses which they believe or assert to be benign in their intent. We have known for a long time that achieving the intent of the author of a program in a known execution environment is extremely difficult. Achieving that intent when the environment is not known is rare. It is, at best, accidental. That is, it is independent of his intent. While the author of a virus can be expected to know a little bit about the machine in which some copies of his creation will execute, he cannot know about all of them. While he may may be able to predict how it will behave in a particular machine, he can only speculate as to how it will behave in a population, all the salient characteristics of which he cannot possibly know. To assert otherwise is hubris. We would do well to remember how the god's punished Pandora. I responded to this posting without noting its source. Only when I was through did I check on its source. Imagine my chagrin to when I noted the name of its author. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL ------------------------------ Date: Fri, 22 Nov 91 13:39:37 +0000 >From: Technician Subject: Taxonomy tool? After look at the posting relating to taxonomy, I've a suggestion using the same approach that is used by some genetisists to analyes DNA relationship. The method is simply based on the op codes, and gives a visual comparison of two virus code sections. The method is dot matrix analysis, and works as show below. Each op code (see foot note) of Virus A is compared against all the op codes in Virus B, and a dot is placed where a match is found. This gives a visual representation of how well the two code segments compare. It will also show re-arrangment of the code ie moving a routine within code, insertion ie extra code and deletion ( it will also show data being reversed - text perhaps to fool scanners?). eg: A B D E F K L W L T Y P W S C H F S Q E T S Y U Y U S < - Virus A A * B * D * E * * F * * H * J Y * * * U * * S * * * * W * * G I O P * W * * S * * * C * F * S * * * * ^ \ Virus B As you can see, the two stings of letters have areas of similarity, denoted by the lines of *'s going down left to right, on a real DNA string, the lines are much more pronounced, and the background has the look of a star field, but for the purposes of a simple ASCII representation, I hope you can see what I mean (I don't have any virus strains to test this out on - and no I don't want any, just an observer, not a virlogist). Please note, I suggest this as a visual method of getting a good idea of how related viruses are, producing a true taxonomy is something else, in which this method might help, but exactly how or if, I'll leave upto the real experts. Jim Cottrell - Software Technician and former biologist, Computer Science, University of Durham [Foot Note - you can compare more than one opcode at a time, ie put a dot only if two adject op-codes match, or 4 out of a window of 5, them move on one.....] ------------------------------ Date: Sat, 23 Nov 91 12:39:53 -0700 >From: martin@cs.ualberta.ca (Tim Martin; FSO; Soil Sciences) Subject: Empire Virus Update (long) (PC) I came across another variant of "Empire" yesterday, and realized I haven't been keeping the news groups up to date on what we know about this virus "family". (Yesterday's variant isn't new, chronologically, it is simply the first time we have captured this particular variant.) Empire Virus Update - ------------------- The "Empire" viruses are boot sector viruses, derived from "Stoned". Evidence suggests that the virus writer started modifying Stoned in the fall of 1990, at the University of Alberta. At least the U of A computer labs were where the virus was released to the world. The last known variant was released on July 10, 1991. A total of 18 variants have been identified to date. These 18 variants are variants only in the strict sense: they have differences in the code -- sometimes only one or two bytes -- which virus scanner writers should know about, and which indicate separate programming efforts on the part of the virus writer. The rest of us can think of them all as one "species". Fred Waller, you can think whatever you wish, of course! :) All of these variants (but the one I found yesterday) are already in the collections of MacAfee, Frisk, Dave Chess, and other virus protection software writers. If you are using their latest scanners, you should be ok, though only FPROT seems to recognize all the variants. Some of the Empire family are really only very slightly different from the Stoned virus. These are probably from last fall. The only variants that we are sure were written since April 1991 are what I call Empire C and Empire D. These variants are designed as responses to virus detection schemes we put into place in response to the earlier variants. Empire C gets around the simple "chkdsk" test for boot sector viruses. Since most boot sector viruses have to reduce the number of "Total bytes of memory" of a computer, to hide at the top of memory, the virus can be detected by seeing whether "chkdsk" returns 1k or 2k less than it is supposed to return. Empire C simply didn't bother telling DOS that the virus was present in memory, when it installed itself. It put itself at 9000:0000 or 8000:0000 and functioned until something else used that memory location, then the system crashed. This virus shouldn't get far beyond U of A, but it has some virus-illiterate PC technicians in Edmonton scratching their heads. Empire D was a response to our installation of "Disk Secure" (from Padgett Peterson) in our computer labs. Empire D recognizes the presense of Disk Secure on a computer and removes it before infecting the computer. Of course we told Padgett about this within minutes of our discovering it, and he reached back into his collection of backup Disk Secure variants, developed and held in reserve just for such a contingency. Does Padgett ever miss anything? Seems at this point the virus writer gave up. :) Unfortunately the Empire virus variants are now the most common viruses at U of A and in the Edmonton area. The difficult challenge now is to teach the campus community how to recognize the virus, how to stop it, how to remove it. From Nick Fitzgerald's experience with the original Stoned, in New Zealand, I'm not too hopeful. Some characteristics of Empire variants: 1. Three have an algorithm for "data diddling", and thus are "intentionally" malicious. 2. Almost all will cause 3.5" disks to be confused about their format, thus APPARENTLY causing data loss. In fact the data can be recovered, by copying a proper 3.5" boot sector from the same format back into place, so the system can figure out what kind of diskette it is reading. 3. On hard disks, the virus infects the first sector (where the main boot record should be), and copies the MBR to sector 3, 6, or 7, depending on the variant. 4. On a floppy disk, the proper boot sector is moved into the directory. Most variants move it to side 1, sector 2 or sector 3. On a 360k diskette this is near or at the bottom of the root directory, so it rarely causes data loss. But on higher densities, it is near or at the beginning of the directory, and is much more likely to wipe out directory entries. Of course the FAT, and the files themselves, are not altered: "chkdsk /f" should permit recovery of the files. Unfortunately current virus detection software cannot always remove the Empire virus from floppy disks. The best method I have found is to do the job manually using Norton Utilities -- I still use version 4.5, I'm not sure why. I simply find the boot sector manually and copy it back into place, thereby clobbering the virus. Or else I copy the boot sector from a "like" floppy. To finish the job, the sector where the boot sector was hidden (somewhere in the directory) should be zeroed out, so the system doesn't get confused when reading the directory. 5. The name "Empire" is appropriate only for the first recognized variant, the one with the "Evil empire" message. The common textual theme throughout the others, usually contained in non-displayed, sometimes encoded strings, is "PC loves AT". ("Love" is often represented by a 03h, the heart character in IBM ascii.) Several variants have references to U of A as well; one has the encoded string "Canadian". Only a few of the variants ever display messages to the screen, some only when the hard disk first becomes infected. 6. Most variants are 1 sector long. A few take up part of sector 2 on a hard disk, to make room for the partition table data, but use only the one sector on a floppy, where the table isn't required. The "Empire A" variant needs a second sector for its encoded message. 7. Most variants begin with the command string EA 9F 01 C0 07. Other initial jump command strings are EA A1 00 C0 07 and EA A7 01 C0 07. 8. Most use self-encoding, so that only these first 5 bytes, and the decoding algorithm jumped to (about 24 bytes) stay recognizable. Actually this makes it possible for scanners like F-PROT to find variants that haven't yet been isolated: most of the Empire variants are identical in their non-encrypted bytes. 9. Most of the Empire variants use stealth. They simply reroute all INT 13 "reads" from hard disk side 0 cylinder 0 sector 1 to sector 3, 6, or 7, where the real MBR was put. They cancel any INT 13 request to write to 0,0,1. This technique is simple, but relatively effective. If I think an Empire virus might currently be in memory, controlling the computer, I find the easiest test is to use debug to look at the memory locations 9FC0:0, 9F80:0, 9000:0 and 8000:0. For example, this helps ensure that a "clean reboot" really was clean. A second way to help insure that the diskette you rebooted from really is clean is to use debug to look at the boot sector of that diskette: the Empire stealth applies only to the hard disk partition table. 10. Currently my naming scheme for Empire variants is not very logical. I hope the people working on naming conventions will simply come up with a numbering scheme for variants, that we will then standardize on. They may decide that at least three of the Empire variants should simply be called variants of Stoned: only the later ones really deviate significantly from their stoned roots. 11. An interesting task I haven't had time to get at is to try to figure out the chronological sequence of the earlier variants, from the code. Some of them are obvious, others are not. Vesselin, Fred: A new field of Science: Computer-Virological Archeology! :) Here's hoping this ends the saga of the Empire Virus. A Thank You Note: If anyone deserves credit for stopping the Empire viruses in the U of A labs, it is Padgett Peterson. A public, formal thank you, Padgett. While I am at it, Frisk should be thanked for his prompt response and his excellent software: we swear by FPROT here: it is the only thing I have that recognizes ALL the Empire variants. (Protection writers note: complementary test software can be sent to the address below! :) Tim. ------------------------------------------------------------- Tim Martin * Soil Science * These opinions are my own: University of Alberta * My employer has none! martin@cs.ualberta.ca * ------------------------------------------------------------- ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 226] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253