VIRUS-L Digest Wednesday, 18 Sep 1991 Volume 4 : Issue 165 Today's Topics: Re: Scanning LZEXE and PKLITE files (PC) IDE drive infection. (PC) Yaunch virus? (PC) autocad non-virus (PC) Re: Scanning LZEXE and PKLITE files (PC) Re: Boot sectors Re: Mutant viruses (PC) Re: Viruses more common in Mac environment? Re: Virus Simulator Bibliography on computer viruses 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: Wed, 18 Sep 91 06:21:03 -0700 >From: Eric_Florack.Wbst311@xerox.com Subject: Re: Scanning LZEXE and PKLITE files (PC) >>You can employ programs like UNLZEXE and PKLITE's ability to decompress the file, then use your favorite virus scanner on them. You do *NOT* have to actually execute the programs in question<< Interesting, but.... >>A subsidiary question is that the decompression process may have distorted the signature of the virus. But if so, the virus is unlike to work in any case.<< Not altogether true, I fear. I'm hearing reports that some programs don't work any more afer tering de-compressed as such, particularly in the case of LZEXE. I have to assume then, that just because a scanner gives a clean bill of health to a such a file in it's recently-uncompressed-state, doesn't mean that it's compresed parent isn't dangerous. ------------------------------ Date: Wed, 18 Sep 91 08:27:00 -0700 >From: rogers@marlin.nosc.mil (Rollo D. Rogers) Subject: IDE drive infection. (PC) I was wondering how the following would be handled: 1. The Disk Killer virus infects and encrypts an IDE hard drive. 2. Apparently this type drive cannot be effectively/correctly low level formatted. 3. If a user cannot find the key to decrypt the drive after being infected by Disk Killer, what to do? Would a high level format be effective in this case? Inquiring minds wish to know? RollO~~ ------------------------------ Date: Wed, 18 Sep 91 13:10:32 -0400 >From: RICH BASILE Subject: Yaunch virus? (PC) We have a virus floating around called YAUNCH. I don't know what it does or how to get rid of it. It has attached itself to a DOS 4.01 file called IFSFUNC.EXE. I don't know what that file is, either. If anybody has any ideas, please reply directly. THANK YOU, RICHARD BASILE UNIVERSITY OF AKRON ------------------------------ Date: Wed, 18 Sep 91 12:28:54 -0600 >From: Bob Brown Subject: autocad non-virus (PC) I made a posting a little while ago about a suspected virus infecting autocad. We have since discovered that we did not have a virus. There was a program in the root directory that was called by the autoexec.bat. The program is a TSR that pops up the alien every 5 minutes or so. This was clearly an act of vandalism, but was not a virus. I apologize for the scare and appreciate your help and interest. Thank you - ---- Greg Kulosa uunet!harper!kulosa ------------------------------ Date: Wed, 18 Sep 91 17:28:59 +0000 >From: ts@uwasa.fi (Timo Salmi) Subject: Re: Scanning LZEXE and PKLITE files (PC) Eric_Florack.Wbst311@xerox.com writes: >I've recently gotten into a disussion, on another network, about LZEXE >and PKLITE'd files, and scanning inside of them. I take the stance >that there is no reliable way to scan inside them, with executing them >first, thereby infecting the system. As such, I have banned all such >treated files from my BBS's. Why do you need to execute them first. Some virus scanners can scan compressed executables, and besides you can first expand the executable with the proper expander, and then scan it. The dilemma really is that, for example, all PKLITE'd executables cannot be expanded. Perhaps it wasn't such a hot idea to sell the unexpandable compression version by PkWare. >Now, here's the question, or rather the challange: Someone convince me >I'm wrong; that such files /can/ in fact be scanned without risk, and >with accuracy, BY CURRENTLY EMPLOYED METHODS. If you get /pc/ts/tsbat27.arc batch collection from our archives, it contains among other things a batch to do this for you. Take a look, and judge for yourself. ................................................................... Prof. Timo Salmi Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1 School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun ------------------------------ Date: Wed, 18 Sep 91 13:52:02 +0300 >From: grdo@botik.yaroslavl.su (Gryaznov Dmitry O.) Subject: Re: Boot sectors bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >grdo@botik.yaroslavl.su writes: > >> In fact there is a way to overcome ANY boot sector infector on PC. To > >Not ANY... see below... OK. Any known by now. >> do this it is enough to restore the contents of interrupt vectors area >> just before booting DOS - virus will lost control. It is also desired >> to set a correct amount of RAM into an appropriate BIOS variable (loc. >> 0:413H). It is possible to place a necessary program code into a DOS >> BOOT sector (not MBR - such a code must be loaded AFTER all possible > >In general you're correct, but the described approach is a bit dirty. >It's better not to mess with the contents of the boot sector. A much >better approach is to implement this idea in a separate program. When Moreover - there is too liitle space in BOOT sector to place all the neccessary code and data there. Modified BOOT could load a special program from the root directory instead of IO.SYS/IBMBIO.COM. I didn't describe details since the main idea is just the same and is RATHER simple. >run in "installation mode", the program traces INT 13h to BIOS level >and using a CALL to that address reads the MBR and the boot secotrs of >all hard disk(s) and partition(s) and stores them (together with the >original INT 13h handler's address) in a file. Tracing has its own drawbacks - there are several nice methods to avoid tracing. >This will automatically disinfect all curent boot sector infectors >(including the stealth ones), but has some drawbacks: > > ..... > >2) It is possible (in theory) to design a virus which particularly >attacks this protection scheme - i.e., tries to find the file where >the original contents of the boot sector is, intercepts the program at >the point where the user is notified, prevents the system to be >rebooted, etc. All this could be made difficult enough but requires a >good amount of programming. Let this file be named by user or use just a random name during installation. >3) If a boot sector infector removes itself from the disk immediately >after it has installed itself in memory and then writes its code back >after, say, 5 minutes, chances are that the virus protection program >(if run from the AUTOEXEC.BAT file) will not notice it. But I wrote: >> ... restore the contents of interrupt vectors area >> just before booting DOS - virus will lost control. This is the main idea - drive control away from virus! >Such approach was implemented by at least one program in Bulgaria... >:-) The program is called ShrDog and is freeware, so if there is >enough interest, I'll e-mail it to Ken. The Bulgarian program has been >implemented independently of the USSR's one (i.e., it was the >implementor's own idea and he didn't know about similar approaches in >the past), however I admit that the idea was first published in the >Soviet Union. Yes. This person was A.Sessa from Dniepropetrovsk, Ukraine. He suggested this idea last November at All-Union Anti-Virus Conference in Kiev. You were there. Me too. >Since you are from the Soviet Union, could you please answer these two >quiestions: > >1) Is the Bulgarian virus Dir II already spread there? (It is a virus >that cross-links all COM and EXE files to the last disk cluster.) I >received a report that it is already spread in Poland, so I'm just >wondering... (To all the others: I'll publish soon a detailed >description of this virus.) Yes, it is. I didn't know this virus came from Bulgaria. Don't you know the author? This August a lot of PCs were infected at WDNH in Moscow (main Soviet exhibition) with this virus. So it is spread all over the USSR now. There are already several Soviet disinfectors available. Once again: is it meaningfull to PUBLISH a DETAILED description of a virus? Will it not encourage new virus-writers? Maybe it is worth to organize a special E-mail anti-virus conference not so opened as VIRUS-L/comp.virus for exchanging such an info and viruses among anti-virus specialists. >2) Can you (or whoever from the SU reads this) provide us with contact >with the Soviet anti-virus researcher Bezrukov, Nikolaj Nikolaevitch? >He lives in Kiev and has published a book on computer viruses. I know >his snail-mail address, but could anyone provide him with e-mail >contact? I have Bezrukov's E-mail address: bnn@softp.kiev.ua . I sent a message or two to him but got no response. Maybe something is wrong with this address. - -- Sincerely, Dmitry O. Gryaznov E-mail: grdo@botik.yaroslavl.su or grdo1@node.ias.msk.su Phones: office: (08535)-2-1731, (08535)-2-0715 home:(08535)-2-1465 ------------------------------ Date: Wed, 18 Sep 91 14:27:29 +0300 >From: grdo@botik.yaroslavl.su (Gryaznov Dmitry O.) Subject: Re: Mutant viruses (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >grdo@botik.yaroslavl.su writes: > >> At least two viruses wich can NOT be detected by scanning programs >> (SCAN etc.) have been reported in USSR. These are mutant viruses. > >Which ones? Can you send examples (encrypted please) to the VTC >Hamburg? We already got a Russian encrypted and mutating virus that is >currently unknown to the public. It was sent to us by two Russian >anti-virus researchers who claimed that they have created it in order >to show that virus scanners are inefective... The so-called Washburn >approach... :-(( Can you name these researches? One mutant virus is STARSHIP - it contains encrypted string ">STARSHIP_1<". It is both MBR and file infector. Uses 4th text video page - so it doesn't work on PCs with monochrome. When an infected program is being executed the virus just infects BOOT and doesn't remain resident. It stays resident when an infected disk is booted. Infects .EXE and .COM files being copied to floppy. Another one is TEQUILA. Also MBR/file infector. Contains encrypted strings "Welcome to T.TEQUILA's latest production", "Contact T.TEQUILA/P.o.Box 543/6312 St'hausen/Switzerland", "Loving thoughts to L.I.N.D.A.", "BEER and TEQUILA forever!", "Execute: mov ax, FE03 / int 21. Key to go on!". Infects .COM and .EXE when executed. Both use some stealth technique. Both mutate only in files, leaving MBR code the same. >> possible to implement scanning algorithms using powerful enough >> regular expressions. > >This means that the instructions that perform the decryption are >always in the same order? Well, this is not strictly nessecary; the >V2Px viruses mentioned above use different permutations of these >instructiuons, so they cannot be matched even by a regular >expression... I meant POWERFUL ENOUGH regular expressions. For example, including variant samples. - -- Sincerely, Dmitry O. Gryaznov E-mail: grdo@botik.yaroslavl.su or grdo1@node.ias.msk.su Phones: office: (08535)-2-1731, (08535)-2-0715 home:(08535)-2-1465 ------------------------------ Date: 18 Sep 91 20:31:17 +0000 >From: bdrake@oxy.edu (Barry T. Drake) Subject: Re: Viruses more common in Mac environment? Thanks to everyone who responded to my tale of viruses on campus, especially to the ones who responded politely. Thanks for the suggestion of Disinfectant; we do already have it, it's available on our AppleTalk server, and the main problem is educating people to use it wisely and often. I was not trying to claim that Mac viruses are more prevalent in general; I was relating our experiences here. We have had PCs since '85 and college- owned Macs since '88. - --Barry (bdrake@oxy.edu) ------------------------------ Date: 18 Sep 91 15:34:00 -0500 >From: "William Walker C60223 x4570" Subject: Re: Virus Simulator There was an interesting post to comp.risks discussing the statistics associated with false positives and false negatives of a medical test (MSFAP, which tests for some type of birth defects, but that part isn't relevant here). An analogy can be drawn between it and computer virus detection routines (I'll avoid the term "virus scanner"). >From: jgro@summit.lia.com (Jeremy Grodberg) [in RISKS 12.35] > In the realm of diagnostic and screening tests, there are 2 variables > and 4 possible outcomes. The test results can be positive or > negative, T+ or T-, and the "correct diagnosis" is either positive (has > the disease) or negative, D+ or D-. The "False Positive rate" is the > number of T+ given D-, divided by the number of D-. In other words, if > you tested only people without the disease, the False Positive rate is > the rate of positive test results you would get. Similarly, the "False > negative rate" is the T- given D+, divided by the number of D+. In the anti-virus field, T would refer to the output from a virus detection program, and D would refer to the diagnosis of a person experienced in virus detection and removal. > ... [The MSFAP] is not a yes/no test, but rather yields a > quantitative result. The medical literature recommends making it a > yes/no test by comparing the results to a threshold level, but there > are odds charts available for more specifically determining the > likelihood of having the disease based on the quantitative result. > There are two thresholds recommended in the literature, with false > positive rates of 3% and 1.4%. > The threshold which yields the higher false positive rate is the one > that was originally recommended, and continues to be used because it > greatly reduces the false negative rate, which can be as high as 44%. The first generation of virus detection programs were yes/no tests; that is, they looked for a particular sequence of bytes and indicated whether or not they found them. Because of the likelihood of a "clean" program having the same sequence, the false positive rate was high. Later generations of virus detection programs perform two or more tests (sequence-matching, algorithmic, or whatever) and generate (internally) a quantitative result, and if this result is high enough (above some threshold), it reports an infection. This reduces the false positive rate, but can, coupled with the increasing number and complexity of viri, increase the false negative rate. If the approriate tests are selected and an appropriate threshold is used, an acceptable balance between the false positive and false negative rates can be achieved (what is "appropriate" and what is "acceptable" is relative and not to be defined here). The very latest ones now give a somewhat quantitative result, such as "Possibly infected...," "Infected with new strain...," and so forth. This helps to decrease the false negative rate, while helping to control, or at least identify, false positives. (don't get me started on heuristics :-) ) As stated above, the false positive rate is the number of T+ given D-, divided by the number of D-. In other words, if you tested only people without the disease, the false positive rate is the rate of positive test results you would get. For this rate to be accurate, the people tested would have to be a suitable sample from the entire population. However, if you took a sample from a population which tested positive but diagnosed negative, the rate would be abnormally high. Also, for argument's sake, if you took whatever factor makes a person test positive and distributed it among the sample population, the rate would again be abnormally high. However, if you tested this same biased population with a second test, which was equally accurate but tested a different factor, the rate would remain accurate. Since none of the people are really positive, the false negative rates cannot be measured. Similarly, the false positive rate of a virus detection program is the number of T+ given D-, divided by the number of D-. If you tested only programs without a virus, the false positive rate is the rate of positive test results you would get. For this rate to be accurate, the programs tested would have to be a suitable sample from the entire set of programs (you can see it coming, can't you). Virus Simulator creates a population of programs including factors which make programs test positive to some tests. Using this biased population, the false positive rates for detection programs which use those factors will be abnormally high. The rates for detection programs which don't use those factors will be unchanged. Since none of the files contain genuine infections, the false negative rates cannot be measured. Therefore, Virus Simulator cannot possibly be used to test virus detection programs. I hope that this can help quantify some people's reservations about Virus Simulator. It has been pointed out in some other postings that the files created by Virus Simulator can be used to help train people in the use of anti- viral software. The rationale is that it is safer to use fake viri than real ones. I agree with this completely -- that's why I created a "defanged" version of "Stoned." However, this is only valid if the detection program selected gives false positives on the simulations (and yes, this applies to my creation too). It's pretty worthless if the selected detection program passes off the simulations as not real. Also, you cannot train users to remove viri with simulations (except by ERASE or FORMAT or the like, which is sometimes not desirable). That's the last I'm going to say about Virus Simulator (and there was much rejoicing :-) ). It would probably be best if we all put Virus Simulator with the other Bad Ideas with Good Intentions and forget it. As a certain unnamed person once said, "It is best to let sleepy dragons and Virus Simulators lie," and as Gene Roddenberry once said, "Let's move on to the next thing." Bill Walker ( WALKER@AEDC-VAX.AF.MIL ) | OAO Corporation | "... but as we say on Earth, Arnold Engineering Development Center | c'est la vie." M.S. 120 | - James T. Kirk Arnold Air Force Base, TN 37389-9998 | ------------------------------ Date: 18 Sep 91 18:05:10 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Bibliography on computer viruses Hello, everybody! A lot of people requested more exact bibliographic references of Cohen's papers and about scientific papers treating the computer virus problem. Well, here are some of them. To keep the list short, I listed only the scientiffic papers (I omitted even the excellent technical but not scientiffic papers published by Virus Bulletin), and only those of them I have a copy of handy right now. Sorry that I had no time to sort the list by author, title, publication, or date of publication. [Ed. Thank you, Vesselin! I will make this available by anonymous FTP on cert.sei.cmu.edu in pub/virus-l/docs/bibliography. If anyone has additions to this bibliography, I would be happy to add them.] Shoch J., Hupp J., "The Worm Programs - Early Experience woth a Distributed Computation", CACM, vol 25, 3, March 1982, pp. 172-180 Adleman L., "An Abstract Theory of Computer Viruses". Unfortunately, I have only a xerox copy of this one, and on the copy it is not written where the paper has been copied from. Cohen F., "Computer Viruses - Theory and Experiments", Computers & Security, vol 6. (1987), 1, pp. 22-35 Cohen F. "On the Implications of Computer Viruses and Methods of Defense", Computers & Security, vol. 7 (1988), 2, pp 167-184 Cohen F., "Models of Practical Defenses Against Computer Viruses", Computers & Security, vol. 8 (1989), 2, pp. 149-160 Cohen F., "Computational Aspects of Computer Viruses", Computers & Security, vol. 8 (1989), 4, pp. 325-344 Dowling W., "There Are No Safe Virus Tests", The American Mathematical Monthly, vol. 96, 9, Nov. 1989, pp. 835-836 Dowling W., "Computer Viruses: Diagonalization and Fixed Points", Notices of the American Mathematical Society, vol. 37 (1990), 7, pp. 858-861 Lai N., Gray T., "Strengthening Discretionary Access Controls to Inhibit Trojan Horses and Computer Viruses", proc. of USENIX'88, pp. 275-286 Joseph M., Avizienis A., "A Fault Tolerance Approach to Computer Viruses". Again, I cannot determine the exact source. Pozzo M., Gray T., "An Approach to Containing Computer Viruses", Computers & Security, vol. 6 (1987), pp. 321-331 Murray W., "The Application of Epidemiology to Computer Viruses", Computers & Security, vol. 7 (1988), 2, pp. 139-150 Wiseman S., "Preventing Viruses in Computer Systems", Computers & Security, vol. 8 (1989), 5, pp. 427-432 Jones S., White C., "The IPM Model of Computer Virus Management", Computers & Security, vol. 9 (1990), 5, pp. 411-418 Gleissner W., "A Mathematical Theory for the Spread of Computer Viruses", Computers & Security, vol. 8 (1989), 1, pp. 35-41 Ferbrache D., "Trojan Horse Techniques to Compromise Sensitive or Classified Data", Virus Bulletin, September 1990, pp. 11-14. An improved version of the paper can be found in the proceedings of the First International Virus Bulletin Conference on Computer Viruses, Jersey, September 1991. There you can find also an excellent paper form Yisrael Radai about authentification techniques and much more. Regards Vesselin - -- Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN Bontchev@Informatik.Uni-Hamburg.de Schlueterstrasse 70, D-2000 Hamburg 13 New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54 ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 165] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253