VIRUS-L Digest Friday, 6 Dec 1991 Volume 4 : Issue 231 Today's Topics: password program (PC) Re: vaccine for STONED on boot disks? (PC) Reports about Dir II (PC) Serious problems with JOSHI (PC) possible virus? (PC) Re: What's special about LAN's? (PC) Virex antivirus software (PC) Fitting Curves to Virus-Spread Data DIR II (PC) Jerusalem Info (PC) Re: What's special about LAN's? (PC) Dave Chess's paper available on archives new program from Padgett (PC) Avoiding detection 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: 02 Dec 91 17:06:05 +0000 >From: S D Law Subject: password program (PC) Hello, We have recently found on our public pc's some sort of password program that I think has somehow been put into the cmos. It seems to be a "commercial type product" that has been put on for fun. Does anyone know of this and abviously more importantly, how do I get into the pc to get it off. Booting from floppy does not work as cmos is run before this. Any help appreciated. Thanks, Steve Law. ------------------------------ Date: Wed, 04 Dec 91 13:09:00 +1300 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: vaccine for STONED on boot disks? (PC) MEDAL@mail.crk.umn.edu (Don Medal) writes: > I am happily in possession of INNOC which says it will innoculate against > STONED, but with one tiny unhappy exception: it won't protect DOS bootable > disks. > > We are constantly being infected with Stoned from a pool of student disks > and would very much like to find a way to vaccinate against STONED for > bootable disks, ideally to include hard drives, but at LEAST floppies. > Can this be done? Is it theoretically impossible? Yes, it is possible to have a bootable disk immunised against the Stoned virus, in that it looks enough like it is already stoned to avoid getting infected. There are vaccination programs that rely on this method to avoid other viruses as well, in which case it is hard to make it bootable. In fact, it is impossible to protect against all boot sector viruses in this way. What I suggest is using two different methods, software like INNOC for non-bootable diskettes to avoid them getting at least the main viruses, plus software like IMMUNISE or the new DISKSECURE on the bootable disks (presumably hard disks). These programs rely on a different method to avoid viruses, and need to be specific to certain signatures (and therefore are fundamentally safer, although you could argue that they are "risky" in the sense that they do let a virus gain control for a while; viruses can be written with such programs in mind, but that comment applies to all anti-viral products). Mark Aitchison. ------------------------------ Date: 04 Dec 91 03:20:26 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Reports about Dir II (PC) According to the last reports that I received, the Dir II virus is spread in Bulgaria, the Soviet Union, Poland, Hungary, the USA (one report), the UK (one report), Norway (about 6 % of the reported infections), Germany (one report), and Turkey (one report). Unfortunately, just minutes ago I got a report that somebody has posted the SOURCE (!) of the virus (not a disassembly, the original source) on a public FidoNet conference, which is distributed around the world... :-((( That's sure to cause a lot of infections. And several variants/mutations... The person who has done this has been obviously a Bulgarian, since he has used the name 'Ahmed Dogan' - the name of the leader of the party in Bulgaria, which represents the Turkish minority... Only a person from Bulgaria, who knows the political situation there could use such name... Ahh, and just a few days ago I heard Dr. Solomon't excellent speach about the future nightmares in virus-writing... One of them was regular posting of virus source code to public non-moderated forums... The nightmare has become a reality... :-(( Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN, rm. 107 C Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Wed, 04 Dec 91 10:40:36 -0100 >From: "Luiz Sergio B. Neves" Subject: Serious problems with JOSHI (PC) HI ! all I'm having serious problems to remove JOSHI from my hardisk. I'm using a recent Mcafee scan, but it seems to be unable to do it. Would you be so kind to send me a complete description of this terrible garbage program (JOSHI), covering infection, protection,... whatever. Thank you in advance !! Yours sincerelly Luiz Sergio B. Neves ------------------------------ Date: 04 Dec 91 11:37:00 -0500 >From: "SUSAN HUMPHREY" Subject: possible virus? (PC) Folks - We have a lab on campus with 25 Epson 286 PCs. Hard disks are "dying" left and right, and, although they do get alot of use, they don't get alot of abuse. So - I'm looking into virus possibilities. The symptoms are these: "BAD SECTORS, ERROR READING DRIVE C:" messages appear and, inconsistently, the machines won't boot from the hard disk. I check for viruses with Central Point's Anti-Virus product and come up "clean". I run Norton DiskDoctor and\or Spinrite II and detect many bad sectors. The disk thinks it's fixed and runs fine for a few days; then the error messages start again, I run the disk utility again, find more bad sectors, the disk thinks it's fine for a few days, etc. At first we thought the disks were just dying a natural death, but it also seems too great a coincidence - and the behavior seems odd... As a last ditch effort to save the disks, we ran WIPEDISK, re-formatted, ran WIPEDISK again, re-formatted again, and the disks now operate beauti- fully, and are holding steady with only one or two bad sectors each. Is there a virus that can do this? Or do I just need to learn more about hard disks? Susan Humphrey Assistant Director of Academic Computing Kenyon College Gambier, OH HUMPHREY@VAX001.KENYON.EDU ------------------------------ Date: Wed, 04 Dec 91 15:31:25 -0500 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Re: What's special about LAN's? (PC) >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >However, if the server gets infected (which generally means that you >haven't maintained your LAN well enough), the disinfection process is >a real nightmare. Even if the virus does not do anything destructive >on the LAN (not intentionally, just because of its author's >ignorance), you usually have to shut down the entire network, in order >to clean the virus. Otherwise as soon as you log to the server, it >infects your workstation, and as soon as you disinfect a workstation, >it gets reinfected from the server. Usually shutting down an average >LAN means tens of protesting users and hundreds (if not thousands) of >$$ lost due to lost worktime.... Vesselin raises some very good points on LAN usage and the horrors of infection however, infection does not have to equate disaster if active measures are being taken (and I do not mean periodic SCANs). While I have seen a virus blast through a LAN at login time, in the last year a couple of massive infections (Jerusalem & Sunday) have been thwarted and the LANs involved were able to stay up safely following disinfection despite a considerable number of infected clients. The method: all of the things Vesselin suggests PLUS integrity checking of each of the clients at login with login refusal/client lockup if the client is infected PLUS a fresh copy for each client of "unruly" applications that require excess rights to execute. Note that while it is better if each client have resident software, this is not a criteria. While this is effective enough, an even better method is integrity management software resident on each client, verified and (if neccessary) updated from the server at login. A full philosophical description is in a paper for Dick Lefkon's Ides of March Virus & Security Conference in New York (plug) but it is a proven fact that a properly managed LAN can stay up and uninfected in the face of infected clients while reporting the infections to administration. Right now the technology permits isolation of infection. By this time next year on-the-fly disinfection/reporting from the LAN server should be "old hat" and one person will be able to perform installations/updates of validation/detection software on thousands of machines in a morning. Padgett BTW in issue 229 it was reported that MBR and Boot Sector infectors cannot propagate on a LAN. More properly and as the Telephonica demonstrates, the statement should have been: " cannot propagate on a LAN without help." ^^^^^^^ ^^^^ While on that subject, I have been working on a generic MBR disinfector that uses the SafeMBR technology to not only protect/detect future attacks but also will provide generic recovery from nearly all MBR infections. The pilot works just fine but the .DOC still needs to be written and it might get a bit more "smarts" before release. RSN. kudos & komments to: "Anti-virus software that works is MUCH more difficult to write than a virus" ------------------------------ Date: Wed, 04 Dec 91 15:39:00 -0500 >From: REYNOLAP@SNYBUFVA.BITNET Subject: Virex antivirus software (PC) I'm new to viri and vaccines. We are beginning to get hit heavily with Stoned, Dark Advenger and Alameda. I would like to know your impression of VIREX antivirus software. Is it good? Is there something better? Any help you can give me will be appreciated. A. Paul Reynolds Instructional Support Specialist Buffalo State College Buffalo, NY ------------------------------ Date: 05 Dec 91 12:27:10 -0500 >From: "David.M.Chess" Subject: Fitting Curves to Virus-Spread Data At the recent NCSA Anti-Virus Product Developers' conference, I mentioned at one session that a given set of data on virus spread (which contained only four datapoints) could have all sorts of curves fit to it, polynomial as well as exponential. The person chairing the session objected that a t-squared curve (for instance) wouldn't work, because it would have to "go up again" at negative times. I assume this was just a momentary confusion, and that he has since seen the light. If so distinguished a gentleman can fall into this error momentarily, though, it seems likely that many others may have done the same, so I thought I'd point out why it's wrong. The general principle I want to champion is: For an equation (or other model) to be useful in studying and predicting virus spread, it does *not* have to fit possible or observed data over *every* possible range of the time variable; fitting within the range of interest (typically the recent past to the not-terribly-distant future) is sufficient. For instance, consider the simplest possible model of local spread; nodes are arranged like a checkerboard, and at every time tick (every month, say) every infected node infects its four nearest neighbors (if they are not already infected). No infected node ever becomes uninfected again. The first four time ticks look like this: * * *** * *** ***** * *** ***** ******* * *** ***** * *** * The number of infected nodes goes from one at time zero, through 5, 13, 25 at time three, and so on. The correct equation for this growth is of course 2 2 2 t + (t + 1) which is 2t + 2t + 1 This describes the growth of the model perfectly for all non-negative t, and it tells us useful things in, for instance, its first two derivatives. The fact that it gives non-zero numbers for t<0 is irrelevant. (This model is of course too simple to be very useful in any real-world situation; it just illustrates my point, and the opposite end of the "locality" continuum from the exponential "everyone randomly connected to everyone else" model.) Even exponential curves cannot fit any real-world data perfectly. For instance, the typical exponential model is asymptotic to zero for low t, which means that, strictly speaking, the model predicts a non-zero probability of computer virus infection even in, say, 1921. So it's clear that no mathematical model of virus growth should be judged by its predictions outside a reasonable range of times, and that the behavior of t-squared models at negative values of t (for instance) is not a reason to reject such models. I hope I haven't spent more time on this question than it deserves! DC ------------------------------ Date: Thu, 05 Dec 91 20:10:34 +0700 >From: Piotr Pikuta Subject: DIR II (PC) If you want a program which clears DIR II virus, you can write to: Miroslaw Startek ------------------------------ Date: Fri, 06 Dec 91 11:44:49 -0100 >From: CARLOS GOULART Subject: Jerusalem Info (PC) As I am not getting to send a mail to Larry Mateo, who in one post of VIRUS-L was looking forward some Jerusalem info, I'd like to ask him (or to someone else) that same file. I'm needing it to write down a vaccine and a anti-virus specific to this virus. Thank you all, Carlos. ------------------------------ Date: Fri, 06 Dec 91 14:05:46 -0500 >From: Otto Stolz Subject: Re: What's special about LAN's? (PC) Hi everybody, on 03 Dec 91 21:36:24 +0000 Vesselin Bontchev said: ... >- - Any person with superuser (or whatever it is called) rights, must >have also a regular account (with low privilege rights only) and must >use only this account for his/her everyday work. S/he must log in with >superuser rights only when s/he really has to do some job that >requires these rights and must log out as soon as the job is done. And, above all, while logged in as superuser, the person must only use trusted (clean, as is hoped) software. I.e. he/she must *not* link/connect/(whatever it is dubbed) into his/her own data areas nor invoke his/her favourite tools from there. Preferably, the super user should only use standard software that has always been kept in protected data areas, and that originally came on write-protected media from renowned vendors. If the person wishes to use his/her own tools he/she has developed under his/her regular account, then these tools must be transferred in source form to the superuser account, checked for integrity (which should be possible by visual inspection in this case), then compiled/linked/ whatever by the standard tools. In a nutshell: you must limit the amount of information transferred to the superuser account and to other protected areas (e.g. program libraries), and you must particularly shield this account and these data areas from binary executables. Good luck, Otto Stolz ------------------------------ Date: Thu, 05 Dec 91 15:37:01 -0500 >From: Kenneth R. van Wyk Subject: Dave Chess's paper available on archives Several days ago, I put Dave Chess's paper, "Virus Verification and Removal -- Tools and Techniques", on the FTP archive on cert.sei.cmu.edu. At the time, we were having problems getting a PostScript version of the file to print. Well, the PostScript file is now available, and I can verify that it prints fine on a LaserWriter. The file is in pub/virus-l/docs under the filename: verify.remove.chess.ps Thanks for the contribution, Dave! Ken P.S. Keep those FAQ's coming, folks! I've gotten a few submissions already. Hopefully, we can have a good working document by the beginning of next month. ------------------------------ Date: Fri, 06 Dec 91 05:56:00 -0500 >From: HAYES@urvax.urich.edu Subject: new program from Padgett (PC) Hi. Padgett Petersen sent me his latest creation in the field of virus protection programs, FixMBR. It is now available from our site in the [.msdos.antivirus] directory as FIXMBR.ZIP. Following is an excerpt of the documentation: FIXMBR .ZIP FixMBR v1.5 (beta). By A. Padgett Peterson. Sent by the author. Copyright (C) 1991, all rights reserved. This program is designed to replace the standard MS-DOS master boot record program with code that does more than just find the active partition and jump to the O/S boot record, SAFEMBR first checks the disk access integrity, its own integrity, and validates the indicated partition. FixMBR will only work with the first hard disk if more than one unit is present on the system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET) University of Richmond hayes@urvax.urich.edu (Bitnet or Internet) Richmond, VA 23173 ------------------------------ Date: Mon, 02 Dec 91 20:55:50 -0800 >From: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Avoiding detection FUNGENA.CVP 911202 Detection avoidance Viral programs have almost no defence at all against disinfection. 99% of viri are almost trivially simple to get rid of, simply by replacing the "infected" file (or boot sector) with an original copy. (Some more recent boot sector and system viri require slightly more knowledge in order to perform effective disinfection: none require drastic measures.) Far from their image as the predators of the computer world, viral programs behave much more like prey. Their survival is dependant upon two primary factors: reproductive ability and avoidance of detection. Using the standard system calls to modify a file leaves very definite traces. The change in a file "creation" or "last modified" date is probably more noticeable than a growth in file size. File size is rather meaningless, whereas dates and times do have significance for users. Changing the date back to its original value, however, is not a significant programming challenge. Adding code while avoiding a change in file size is more difficult, but not impossible. Overwriting existing code and adding code to "unused" portions of the file or disk are some possible means. (The fictional rogue program P1, in Thomas Ryan's "The Adolesence of P1", avoided problems of detection by analyzing and rewriting existing code in such a manner that the programs were more compact and ran more efficiently. Such activity has not yet, alas, been discovered in any existing virus.) Some viral programs, or rather, virus authors, rely on psychological factors. There are a number of examples of viri which will not infect program files under a certain minimum size, knowing that an additional 2K is much more noticeable on a 5K utility than on a 300K spreadsheet. In a sense these are all "stealth" technologies, but this term is most often used for programs which attempt to avoid detection by trapping calls to read the disk and "lying" to the interrogating program. By so doing, they avoid any kind of detection which relies upon perusal of the disk. The disk gives back only that information regarding file dates, sizes and makeup which were appropriate to the original situation. (This also relies upon the virus being "active" at the time of checking.) Although this method avoids any kind of "disk" detection, including checksumming and signature scanning, it leaves traces in the computer's memory which can be detected. (Some viral programs also try to "cover their tracks" by watching for any analysis of the area they occupy in memory and crashing the system, but this tends to be noticeable behaviour ... ) copyright Robert M. Slade, 1991 FUNGENA.CVP 911202 ============= Vancouver p1@arkham.wimsey.bc.ca | "Metabolically Institute for Robert_Slade@mtsg.sfu.ca | challenged" Research into CyberStore | User (Datapac 3020 8530 1030)| politically correct Security Canada V7K 2G6 | term for "dead" ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 231] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253