VIRUS-L Digest Wednesday, 16 Mar 1994 Volume 7 : Issue 18 Today's Topics: Re: Good Vs. Bad Viruses Re: Computer Lab protections strategies Re: Have we lost track of the virus problem? Anti-Virus Area on ftp.demon.co.uk 'welcome datacomp' message Re: Have we lost track of the virus problem? File MADONA VMMEMO V (82 records, format V 74) (IBM VM/CMS) File ICM VMMEMO V (133 records, format V 76) (IBM VM/CMS) Re: vds comments (PC) Monkey (PC) Michaelangelo (PC) re: need help on mandela 2 virus! (PC) Re: vds comments (PC) Novell Anti-virus Software (PC) Michael Angelo Virus?? (PC) Re: vds comments (PC) Any info on "bombay" -- DOS machines (PC) Re: Clean 111 & Mich. (PC) Re: Clean 111 & Mich. (PC) LZR bootsector virus (PC) re: Quox virus? (PC) Tecnical Concepts of Viral Defense (MBR/DBR infectors) (PC) Re: Virus Info List By P.Hoffman? (PC) Re: Which ANTIVIRUS package to use????? (PC) Re: Need info on Halloween virus (PC) Invalid COMMAND.COM from A/V Prog. (PC) Re: Alternate infection method? (V-Sign) (PC) New viruses (PC) HEEEEEELP ME NOW!!!! : Filler Virus (PC) Research Project: Virus Survey VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a gatewayed and non-digested USENET counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. (The complete set of posting guidelines is available by FTP on CERT.org or upon request.) Please sign submissions with your real name; anonymous postings will not be accepted. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on CERT.org (192.88.209.5). Administrative mail (e.g., comments, suggestions, beer recipes) should be sent to me at: krvw@ASSIST.IMS.DISA.MIL. All submissions should be sent to: VIRUS-L@Lehigh.edu. Ken van Wyk ---------------------------------------------------------------------- Date: Mon, 07 Mar 94 19:49:30 -0500 From: olpopeye@aol.com Subject: Re: Good Vs. Bad Viruses date: Tuesday, 8 March 1994 This writer has followed the learned and not-so-learned discourse on "Good Viruses," "Bad Viruses," "Good vs. Bad Viruses" and all the surrounding rhetoric with emotions ranging from raucous laughter to gasps of disbelief. Hubris aside, I'm surprised that an audience of such a demonstrably high level of intelligence has yet to cut through the fog to the **CENTRAL QUESTION** of the debate, i.e.: *********************************************************************** WHAT IS THE **INTENT** INVOLVED IN EACH INSTANCE?? *********************************************************************** Some of my customers have lost data; some haven't. Some have screwed their hard disks completely; some haven't. The ignorant can cause as much damage to their business with FDISK.COM and/or FORMAT.COM as any virus writer. However, NONE of my customers have **INTENTIONALLY** trashed their data or their systems, nor filled up hard disk space with messages encouraging dope addiction or pornographic physical impossibilities. I say again, The central question remains: *********************************************************************** WHAT IS THE **INTENT** INVOLVED IN EACH INSTANCE?? *********************************************************************** No, I'm not a lawyer. Yes, I have a degree (several, in fact). But despite these obvious disqualifications, allow me to pose the following test: 1. Is the **INTENT** of the perpetrator to cause me harm? 2. Is the **INTENT** of the perpetrator to cause me inconvenience? 3. Is the **INTENT** of the perpetrator to cause me loss of disk storage space (thus reducing the utility of my computer(s))? 4. Is the **INTENT** of the perpetrator to destroy my data? 5. (Add in your own tests here...) Then, if the answer to ANY of the above is YES, then the perpetrator is a criminal and should be dealt with as such. And, there is no sophomoric quibble about whether a virus is harmful.¶ The answer then becomes obvious: IF YES THEN ----¶ and so forth..... And a note to any who write viruses for fun:¶ No, you're not smarter than we mere mortals; you're not better looking; youre not more sexually gifted;¶ you don't even smell better. You're no better than a graffiti "tagger," no better than a snotty-nosed brat disrupting school classes, no better than a shoplifter ransacking the local 7-11 or some thug stealing old ladies' Social Security Checks. And when you grow up, can you put any of your feats on your resume???? "Michaelangelo mentality" aside, viruses and their mentally deficient "intelligence-challenged" creators will be with us until the Constitution is changed to allow impaling, or hanging/drawing & quartering. Viruses DO cause harm, whether it's *gross* harm or "merely" inconvenience. My customers willingly pay for my consultants services on application programs when they can't slog through a monkey-written tech manual; they pay willingly for advice and labor on system upgrades, installations, disk crash data recovery, optimizing systems and suchlike, but almost universally virus infections are viewed as instances of *criminal trespass. I agree with them as I write up the bills. Incidentally, company practice here is termination of any employee who infects or allows infection of any computer system in our offices. This is not an idle threat. And, it works. Has the above clarified these muddy waters? - ----------------------------------------------------------------------------------------- - ------------- Walter E. Murdock OlPopeye@AOL.COM Murdock Associates, Palo Alto 75270.37@Compuserve.com "I sign the payroll, so my opinions count. HERE, anyway!" - ----------------------------------------------------------------------------------------- - -------------- ------------------------------ Date: Tue, 08 Mar 94 11:06:18 -0500 From: hstroem@ed.unit.no (Henrik Stroem) Subject: Re: Computer Lab protections strategies Otto Stolz writes: > An even better defence would be an integrity checker to compare the > boot sectors to a copy of their original contents; however this will > give a false positive when a user has given a new label to the disk. Not if you use a professional program, such as my own HS v3.58, available from oak.oakland.edu:/pub/msdos/virus/hs-v358.zip. It is a wellknown action of newer versions of DOS, that the bootsector is updated when you change the volume label, and it only makes sense that an integrity checker should be aware of this, and not yell VIRUS when it happens. > It is a good idea, to have a conspicuous banner displayed when a virus > is found, telling the startled user what to do next, particularly, > which staff member to contact. > > Thus, you will prevent further propagation of any boot sector virus > that managed to evade provision 1, above (e.g. a virus inserted by > a dropper program). When using an integrity checker to take care of bootinfectors, you also have the great advantage of automatic removal of the virus, so the machine can continue to be used without much more than seconds of delay. Sincerely, Henrik Stroem Stroem System Soft ------------------------------ Date: Tue, 08 Mar 94 13:32:15 -0500 From: hstroem@ed.unit.no (Henrik Stroem) Subject: Re: Have we lost track of the virus problem? Mitchell Cottrell writes: > As far as there being a harmless virus. I have to feel sorry for > anyone with that opinion because they obviously don't place any value > on their time. If an infection occurs on a machine I must allocate > time of either myself or another technician to solve the problem. In > today's marketplace time is money, and that virus has literally cost > me money to deal with. What if you never detect the infection? And there never is reported a problem with that particular PC, or computer lab? And the computer lab is the only lab running e.g., MS-DOS 5.0? And the virus only infects machines running MS-DOS 5.0? The virus may still not be harmless, but at least it is harmless to you. Only a thought, Henrik Stroem Stroem System Soft ------------------------------ Date: Tue, 08 Mar 94 19:24:25 -0500 From: amn@ubik.demon.co.uk (Anthony Naggs) Subject: Anti-Virus Area on ftp.demon.co.uk Anti-Virus Area on ftp.demon.co.uk readme.doc - 8 March 1994 Intro: ====== The space for this archive area has been kindly supplied by Demon Internet. My objective is to offer a comprehensive cross-platform site for antivirus utilities and information. Most files are culled from elsewhere on the net, though an increasing portion of the shareware is sent directly by the authors. Directories: ============ Below Current content /pub/antivirus amiga C= Amiga antivirus files archimedes Acorn Archimedes virus information atari Atari ST antivirus files books miscellaneous 'security' related books & associated files ibmpc/aids-disk 'fixes' & descriptions of the Aids Information Disk ibmpc/av-progs anti-virus programs ibmpc/av-utils 'support' utilities for a-v programs ibmpc/bbs-util tools to help BBS sysops check uploads for viruses ibmpc/info information files, eg texts, vsum ibmpc/lists 'in the wild' lists from Joe Wells ibmpc/misc - ibmpc/novell-av Novell antivirus programs ibmpc/os2-av OS/2 antivirus programs ibmpc/promo promotional text files ibmpc/simtel-av pointer to anti-virus files mirrored from SimTel ibmpc/tools miscellaneous tools ibmpc/updates updates for commercial a-v s/w (Norton & Central Point) ibmpc/vir-sim virus simulation visual aids incoming uploads here please! mac Mac antivirus files papers papers on viruses & antivirus ideas reports - virus-l archives of Virus-L (not quite complete - yet) vtc-catalog Hamburg University VTC catalog files Uploads: ======== Uploads to /pub/antivirus/incoming - with an announcement text I can post emailed to me. For programs I much prefer to have uploads directly by the author, or to copy files myself from a 'quality' ftp site - tell me where and I'll copy it across. I have started a mailing list for news about the site, and distributing upload announcements. Mail mxserver@ubik.demon.co.uk and ask for a subscription, (currently managed by hand). Notes: ====== My creation and maintenance of this area is entirely voluntary. The time and dialup costs involved come directly from my pocket - so if you find my work useful please mail me to say so. (If you really like it a *lot* I wouldn't say no to a modest donation of cookies, or pennies towards my phone bill! :-) - -- Anthony Naggs Paper mail: Hat 1: Software/Electronics Engineer PO Box 1080, Peacehaven, Hat 2: Computer Anti-Virus Researcher East Sussex BN10 8PZ PGP: public key available from keyservers Great Britain Email: amn@ubik.demon.co.uk Phone: +44 273 589701 ------------------------------ Date: Tue, 08 Mar 94 19:36:23 -0500 From: brauerjs@lamar.colostate.edu (brauerjs) Subject: 'welcome datacomp' message A question I am encountering a bug or virus and wonder if anybody has any experience. This 'thing' is inserting the text 'welcome datacomp' (all lower case and just like that) in anything. It happens with extensions off or on and does not matter what application is running. It happens repeadedly and is happening now on my Classic II (but not my Centris 660AV - but it has on my father's 660AV) the only common factor that we can find is a Tsounmi 270 w/ silverlining. His has quit doing it but my Classic II seems to be continuing. Does anybody have experience with this thing? Disenfectant does not see anything and Gatekeeper has not been posting warnings (although when infected if that is the way it goes Gatekeeper was not running). Sorry if this is in the wrong place - Please HELP. ------------------------------ Date: Wed, 09 Mar 94 03:43:58 -0500 From: jlundgr@eis.calstate.edu (John E. Lundgren) Subject: Re: Have we lost track of the virus problem? I think M. Cottrell is overreacting a bit. I, too, have had to stop everything, drag out all the floppies, and check each and every one for viruses. usually it was the Stoned, but I've had jerusalem infect the Wordperfect program until it was too big to fit in memory. I agree that the supposedly harmless stoned virus, for example, is not only harmful, but a big headache for those who become infected. It is a very big waste of time for people, especially teachers, where I work at a community college. We recently had the Datalock 1740 virus slip right by under the nose of Norton Anti Virus and most of the others. So I'm no stranger to the problems he is talking about. But I have to take issue with the statement that 'the virus is stealing $250,000....' Stealing is when the victim loses, and the thief gains. There is no $250,000 gain for the thief in this case. He is not a thief, he is a VANDAL. Vandals destroy others property, not gaining anything in return. So thief should really be Vandal. The only consolation the victims have is that those vandals out there don't know how much damage the viruses have caused. There are other things in life that could go wrong, especially hard disk crashes. If most people were prepared for this kind of damage, the virus infection would be a minor detail. But I see users who have no idea how to make a backup. So I see two sides to the story: malicious vandalism, and user incompetence. Enough of my $.02. No flames, pleez. - -- Fortune cookie/Tagline for the week: Funny -- only sensible people agree with me. Reality-ometer [\.....] Hmmph! Thought so... ------------------------------ Date: Wed, 09 Mar 94 04:00:54 -0500 From: Otto Stolz Subject: File MADONA VMMEMO V (82 records, format V 74) (IBM VM/CMS) ========================================================================= Entry...............: MADONA MODULE Alias(es)...........: --- Strain..............: --- Detected when.......: February 1994 where.: GONE-L mailing-list Classification......: Chain Letter (aka Rabbit) Length..............: 1. As NETDATA file (in the virtual reader): 34 Records 2. On disk: RECFM is V, LRECL is 2224, size is 3 records. - --------------------- Preconditions ------------------------------------ Operating System(s).: CMS (under VM/SP, VM/XA, or VM/ESA) Version/Release.....: presumably Rel. 3, and up; partially tested with VM/SP Release 6, Service Level 602 Computer model(s)...: IBM Mainframes, and Compatibles - --------------------- Attributes --------------------------------------- Easy Identification.: 1. Program comes in a file named MADONA MODULE. 2. Embedded REXX source code is found in record 3, positions 889-2217. Type of propagation.: Inspects the user's Standard Names File, and tries to send a copy of itself to every address found therein (for limitations, cf. sub Particularities, below). Propagation Trigger.: Running the MODULE, e.g. by entering MADONA at the "Ready;" prompt. Note that the MODULE must be received (e.g. by hitting the PF9 key, in the Rdrlist) prior to running it. Note also, that both receiving and running a MODULE file are basic operations that will be executed almost instantly by any moderately experienced CMS user. Storage media affected: Disk; RSCS Network (e.g. Bitnet/EARN/Netnorth) Damage..............: Permanent Damage: Any file named MADONA MODULE A will be erased, all RDR files will be purged, all files named PROFILE * on R/W disks will be erased. Transient Damage: A crude image (of an owl, or bat) will be displayed with the message: "SI FUDEU !" (Disregarding a typo ("si" for "se"), this is Brazilian Portuguese, meaning "You have fucked yourself"), followed by the message: "SURPRESA MOCADONA!! OS FANTASMAS ESTAO DE VOLTA CUIDADO!!" ("Surprise ...! The phantoms are back again -- beware!" The word "mocadona" is unknown to our informant, a native Brazilian speaker). Side effects: Network jams are possible due to processing multiple copies of MADONA MODULE Damage Trigger......: Permanent Damage: Running the MODULE (as above). Transient Damage: Running the MODULE (as above). Particularities.....: MADONA MODULE is coded rather awkwardly, and sloppyly, in particular: 1. When the program is renamed, it will still try to propagate a file named MADONA MODULE, and subsequently erase it. 2. The CMS Sendfile command MADONA exploits accepts only RSCS addresses (such as PGIFFORD@ALLEGVM); hence, a user located in Bitnet will propagate the file to Bitnet addresses, but not to Inter- net adresses -- not even to an Internet style Bitnet address (such as PGIFFORD@ALLEGVM.Bitnet). Similarities........: Propagation method resembles ZT MODULE; however, ZT uses the CMS Punch, rather than the Sendfile, command, quite similar to RAMA EXEC. - --------------------- Agents ------------------------------------------- Countermeasures.....: Sysadmins should include MADONA MODULE in their RSCS filters. List owners should set up their LISTSERV discussion groups with the "Files=No" option. Standard means......: Users should browse all incoming programs before running them. Particularly, they should discard MADONA MODULE rather than running it. - --------------------- Acknowledgement ---------------------------------- Location............: Allegheny College, Meadville, PA, USA Classification by...: Pete Gifford Documentation by....: Pete Gifford Date................: 1994-03-02 Information Source..: Analysis of MADONA MODULE, partial tests of embedded REXX code; description of RAMA EXEC. ===================== End of MADONA Chain Letter ========================= ------------------------------ Date: Wed, 09 Mar 94 04:00:47 -0500 From: Otto Stolz Subject: File ICM VMMEMO V (133 records, format V 76) (IBM VM/CMS) ======================================================================== 116 Entry...............: ICM EXEC Alias(es)...........: --- Strain..............: RAMA EXEC Detected when.......: 2 March 1994 where.: Israel Classification......: Chain Letter (aka Rabbit) Length..............: 1. As NETDATA file (in the virtual reader): 87 Records 2. On disk: RECFM is V, LRECL is 81, size is 190 records. (These figures may not be accurate, cf. Acknowledgments section, below). - --------------------- Preconditions ------------------------------------ Operating System(s).: CMS (under VM/SP, VM/XA, or VM/ESA) Version/Release.....: presumably Rel. 3, and up; tested with VM/SP Release 5, Service Level 526 Computer model(s)...: IBM Mainframes, and Compatibles - --------------------- Attributes --------------------------------------- Easy Identification.: 1. Program comes in a file named ICM EXEC; it is REXX language source code. 2. Source lines 35, 45, and 171, each contain a SAY instruction to display the highlighted words THE INTERNATIONAL CORESSPONDENCE MAGAZINE (note the typos). Type of propagation.: Inspects the user's Standard Names File, and tries to send a copy of itself to every address found therein (for limitations, cf. sub Particularities, below). Propagation Trigger.: Running the EXEC, e.g. by issuing the RUN prefix command against the pertinent line in the Filelist. Note that the EXEC must be received (e.g. by hitting the PF9 key, in the Rdrlist) prior to running it. Note also, that both receiving and running an EXEC file are basic operations that will be executed almost instantly by any moderately experienced CMS user. Storage media affected: Disk; RSCS Network (e.g. Bitnet/EARN/Netnorth) Damage..............: Permanent Damage: When the user agrees to subscribe to the alleged magazine (cf. Transient Damage, below), then he or she is asked for personal data which are appended to a file named ICM ICM (located on any disk); if no such file exists, ICM ICM A will be created. The file will sub- sequently be sent to STUCBC2@SAUPM00 (apparently a student account at King Fahd University of Petroleum and Minerals, Saudi Arabia). When the user agrees to contribute an article, then a file named ART ART (if any is accessible) will be sent to the same account and sub- sequently be erased (if it is located on a R/W disk, of course). Transient Damage: ICM performs a dialogue with the user to announce, in a horrible spelling, a new magazine, or perhaps a dicussion forum (I deem the wording rather muddled and not well thought out). Side effects: Network jams are possible due to processing multiple copies of ICM EXEC. Damage Trigger......: Permanent Damage: Running the EXEC (as above), and answering "Y", or "Yes", respectively. Transient Damage: Running the EXEC (as above). Particularities.....: Unlike most chain letters, the propagation code precedes the damage code. Propagation, and damage, code are apparently written by different people (e.g. the damage code is entirely in upper case, as if the programmer had not learned about XEDIT's SET CASE command; the damage code uses labels for flow control, whilst the propagation code exploits nested statements); cf. sub Similarities, below. The file is only propagated to RSCS addresses (such as RZOTTO@DKNKURZ1); hence, a user located in Bit- net will propagate the file to Bitnet addresses, but not to Internet adresses -- not even to an Internet style Bitnet address (such as RZOTTO @DKNKURZ1.Bitnet). Both parts of ICM EXEC are coded rather awkwardly, and sloppyly, in particular: - When the program is renamed, it will still try to propagate a file named ICM EXEC. - ICM EXEC contains code to supply the local node name to abbreviated RSCS addresses (such as RZOTTO); however, due to a bug, it will append the words VIA RSCS, and the current date, to the node name it inserts. Due to the resulting syntax error, no file will be sent to the abbreviated address. The pertinent error message is hidden by CMSTYPE HT. - ICM will consume any lines present in the Program Stack. - The words HI and LO are included in the output in one place where highlighting apparently was intended. - When the prospective subscriber of that magazine is asked for his or her personal data, every other input line is lost. - When the user has agreed to supply an article to the magazine, the command "S ART ART" is issued, which will normally result in a syntax error. Probably "X ART ART" was meant which would start an interactive edit session on the file which is subsequently sent to SAUPM00. Similarities........: The replication code is an exact copy of the replication code from RAMA EXEC (apart from the SENDFILE command in source line 23, of course); this has been verifyed by a COMPAREX run. Source line 23 is mixed case in RAMA, but upper case in ICM EXEC; this could be a result of the required modification having been made under XEDIT's default CASE setting (cf. Particularities, above). Most probably, the programmer of ICM, unaware of the SET CASE command, has copied, and modified, the propagation code from RAMA EXEC. - --------------------- Agents ------------------------------------------- Countermeasures.....: Sysadmins should include ICM EXEC in their RSCS filters. List owners should set up their LISTSERV discussion groups with the "Files=No" option. Standard means......: Users should browse all incoming programs before running them. Particularly, they should discard ICM EXEC rather than running it. - --------------------- Acknowledgement ---------------------------------- Location............: Rechenzentrum der Universit Classification by...: Otto Stolz Documentation by....: Otto Stolz Date................: 1994-03-09 Information Source..: Analysis, and test runs, of ICM EXEC, as reconstructed from a version partially distorted by E-mail transmission. ===================== End of ICM Chain Letter ========================= ------------------------------ Date: Mon, 07 Mar 94 09:25:44 -0500 From: frisk@complex.is (Fridrik Skulason) Subject: Re: vds comments (PC) hobbit@ftp.com (*Hobbit*) writes: >I gave it a whirl last night. >The default .ini file contains QUICK_VERIFY = yes, which makes VDS >fail to find fairly significant changes to a test .exe file, including >changing several bytes, changing the date, etc. Those changes "significant", but they are not virus-like - without having seen the program, I suspect it would catch all changes made my a virus infection - different entry points & changes to program size for example - -frisk ------------------------------ Date: Mon, 07 Mar 94 09:36:31 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Monkey (PC) >From: "Jeremy J. Blumenfeld" >Subject: Empire.Monkey.A variant of Stoned (PC) >Is there anyway to keep it off of the hard drive? Should /boot warn >against this type of infection? I wrote my FreeWare DiskSecure II to do just this. Normally it is sufficient to just set the CMOS to only boot from C: however if this is impossible then I would suggest DS II plus NoFBoot (also FreeWare) from FixUtil6. The combination of the two requires less than 600 bytes of RAM (that's right, Bytes) and is IMHO the best defense possible right now against MBR and Boot Sector infectors including Droppers. Also the FixUtil contains several other anti-viral programs. Both are available on several sites (Archie). DS241.ZIP and FixUtil6.ZIP are current or I can send uuencodes. Warmly, Padgett ------------------------------ Date: Mon, 07 Mar 94 11:23:12 -0500 From: corporon@wizard.cse.nd.edu (phillip corporon) Subject: Michaelangelo (PC) Is there a cure for a hard drive that has been infected with the Michaelangelo virus? Is the FDISK /MBR command a possible solution? Thanks...Phil. ******************************************************************** Phillip G. Corporon, Senior Computer/Electronic Specialist Department of Computer Science and Engineering University of Notre Dame, Notre Dame IN 46556-5637 internet..: phil@cse.nd.edu Voice.: 219/631-5893 applelink.: A0393 Fax...: 219/631-9260 bitnet....: f3pb88@irishmvs.bitnet ******************************************************************** ------------------------------ Date: Mon, 07 Mar 94 11:26:46 -0500 From: "David M. Chess" Subject: re: need help on mandela 2 virus! (PC) >From: amueller@sun1.ruf.uni-freiburg.de (Armin Mueller) >Hello, >How can I identify and fight the mandela 2 virus. >Now during work with Borland Pascal and the Debugger I saw >the following words as the contents of a new allocated >Variable: "Mandela 2 [Mnd-2] ..(rubbish).. Nice Day". That's just because, as you point out, that stuff was in memory at the time the variable was initialized. The reason it was in memory is almost certainly that the McAfee scanner that you ran left it there; this is particularly likely because it contains the virus name, the CLEAN code for the virus, and then the beginning of the name of another virus. You're almost certainly seeing some leftovers from the scan that you ran, rather than any evidence of a virus. - - -- - David M. Chess / Madonna Iguana High Integrity Computing Lab / Sine Theta IBM Watson Research ------------------------------ Date: Mon, 07 Mar 94 13:04:22 -0500 From: jaf@jaflrn.morse.net (Jon Freivald) Subject: Re: vds comments (PC) > Date: Tue, 22 Feb 94 21:24:13 -0500 > From: hobbit@ftp.com (*Hobbit*) > Subject: vds comments (PC) > > I gave it a whirl last night. > > The default .ini file contains QUICK_VERIFY = yes, which makes VDS > fail to find fairly significant changes to a test .exe file, including > changing several bytes, changing the date, etc. > > Could the documentation perhaps be written to stay within 80 columns? I'm in the unfortunate position of being required by higher headquarters to use this product. I have written a "talking paper" which has been submitted. If anyone is interested in getting a copy of it, it's available on my system (sorry, no ftp yet). You can dial-in to (516) 483-5841 (14.4 modems). I've got it posted in /pub/dos/anti-virus as VDS.dvi (for those of you who have TeX, ghostview, etc), VDS.lj (LaserJet ready output), and VDS.ps (postscript ready output). The paper is four pages long. If there's enough interest, I can e-mail it to someone to post on an ftp site. Any volunteers? Jon - -- Jon Freivald ( jaf@jaflrn.Morse.Net ) PGP V2 - 22A829/40 DA 9E 8E C0 A1 59 B2 46 3B 73 81 2B 7B 83 1F Nothing is impossible for the man who doesn't have to do it. ------------------------------ Date: Mon, 07 Mar 94 17:35:09 -0500 From: babak@be.ucla.edu (Babak) Subject: Novell Anti-virus Software (PC) Hi! I just found this forum and realized I can as this question here. I'm looking for a good server-based anti-virus software for our enterprise network at UCLA. Our department has about 20 Novell servers and about 450 workstations. I'm trying to see if I can find any comparisons of commercial anti-virus software for our network. Does anyone have any suggestions? Thanks in advance. Babak Saberi babak@be.ucla.edu ------------------------------ Date: Mon, 07 Mar 94 17:49:09 -0500 From: troyb@stat.ufl.edu (Troy Bleeker) Subject: Michael Angelo Virus?? (PC) Does anyone know how to recover from this virus?? Troy ------------------------------ Date: Mon, 07 Mar 94 18:51:11 -0500 From: tyetiser@umbc.edu (Mr. Tarkan Yetiser) Subject: Re: vds comments (PC) The "QUICK_VERIFY = Yes" option in VDSPRO30.INI will catch almost all virus-like modifications to executable files. If you randomly change files by hand, they may not be caught (unless the size changes as well). If you have a virus sample that infects EXE files in a way that the change is not caught by VDS in quick_verify mode, please forward me a sample. To use VDS for datta integrity, this option (QUICK_VERIFY) should be set to NO. Regards, Tarkan Yetiser VDS Advanced Research Group ------------------------------ Date: Mon, 07 Mar 94 19:14:49 -0500 From: kevin@eric.unl.edu (Kevin C. Clements) Subject: Any info on "bombay" -- DOS machines (PC) I hope this is an appropriate posting for this group. My request may be a bit premature -- I don't have all of the details on the behavior of "bombay," so I don't know if it's a true virus or some other form of nastiness (e.g. I don't know how it was transported). I've checked the pertinent directories (virus-l) and indexes at cert.org for information concerning "bombay," but I haven't found any reference to it so far. I'm hoping some readers of this group may have heard of it and have some insights. The problem concerns a PC (DOS machine). It seems harmless enough so far, but that may change. Here's what I know of the symptoms: 1) When exiting Windows 3.1 (using Norton's Desktop for Windows as the program manager) the computer produces a variable number of beeps. Sometimes (infrequently) a memory allocation error is reported and the system halts. 2) The \WINDOWS\WIN.INI file had been changed in the following ways (with date stamps within the past week): The [Windows Help] paragraph contained a bunch of gibberish The [Sounds] paragraph contained sound definitions that the PC's owner had not made. 3) The MAIN program group was missing from the desktop -- its group definition file had been deleted. This is the group that contains the windows "control panel" that one would use to control sounds (among other system functions). At this point, we thought that someone had simply "screwed around" with the PC when nobody was around. The PC's owner decided to restore from a backup tape he had recenly made. He found that a hidden directory named \bombay had been created in the past week -- and he hadn't done it. That's all I know right now -- the PC's owner isn't around so I can't get at it to do more checking (e.g. I don't know what was/is in the directory, or how it was created). If anyone has any pertinent information, or can suggest where I might find some, please respond via e-mail to kevin@eric.unl.edu. Your help is appreciated. Thanks, \o/ \o __| \ / |__ o _ \o/ _ o | /\ __\o \o | o/ o/__ /\ | /\ \__/ _/_\__|_\__/)_|____(_\__/o\__/_)____|__(\__/_|__/_\__|_\__/ /o Kevin C. Clements voice: 402-472-6643 \ / Biological Sciences fax: 402-472-2083 \| University of Nebraska o\ Lincoln, NE 68588-0118 kevin@eric.unl.edu _____________________________________________________________\_/__ ------------------------------ Date: Mon, 07 Mar 94 19:35:55 -0500 From: jhs@gall.rdt.monash.edu.au Subject: Re: Clean 111 & Mich. (PC) woody@knapper.cactus.org writes: >I just got hit with Michealangelo. My system is a dos 3.3 system be a bit more careful next time. [ stuff deleted ] >was acting up, adn would not boot off of any of the 6 backup copies >that I tried. Clean should have enough brains to be able to If you know how viruses work, you SHOULD have enough brains to realize, that there IS ONLY ONE WAY to do this, and I guess that 10 years of expierience in the area, they know what they are doing. >inactivate Mich in memory, or at least know that once it cleaned it >and you rebooted, that the active in memory portion would no longer be >a threat. But No, it can't do that. >The other and much more serious problem, is that after I cleaned the >disk heads, and managed to format a floppy with a system on it, and >rebooted off of that, it cleaned the hard disk. BUT it killed the dos >extended partion. Drives d - K had nothing on them. norton showed >only 1 partition (the primary one). THIS IS TOTALY UNACCEPTABLE >BEHAVIOR. CLEAN SHOULD BE ABLE TO DO THIS WITHOUT CLOBBERING THE >EXTENDED PARTITION TABLE. I spent an hour, working out what I thought That virus effects the boot partition and acts upon the FAT table. You can call yourself LUCKY that not more damage was done and you should call yourself LUCKY again that there is one utility which found out that there was a virus on your system and that there is another utility which could help you to remake your system and you had (in this case ) enough BRAINS to use them. DO NOT SCREAM ON UTILITIES WHICH HELP YOU IF YOU HAVE STUFFED UP! Consider: There is no scanning software. There is no ndd. Ypu would have to rebuild it ALL! >were the right paramters to rebuild the second partition, and used [ stuff deleted ] regards Jobst - -- jhs@gall.rdt.monash.edu.au .................................................. Jobst Schmalenbach 19 York Street, Sth Caulfield, 3162, Australia, 69-3-5237348 ....................................... Pain is temporary, Pride is forever! ------------------------------ Date: Mon, 07 Mar 94 22:46:22 +0000 From: c9219517@sage.newcastle.edu.au (Scott Howard) Subject: Re: Clean 111 & Mich. (PC) woody@knapper.cactus.org wrote: : I just got hit with Michealangelo. My system is a dos 3.3 system with : a 240 meg hard disk. I have a primary and a secondary partion. The : secondary partition is split into volumes d: e: f: g: h: i: j: k:. I : took clean111 and attempted to clean Mich off. There are two problems : with clean111 in this situation. One is a stupid procedural problem : to wit: When clean is scanning ram, and encounters Mich. active in : memory, it quits, requiring you to boot off a floppy. My floppy drive : was acting up, adn would not boot off of any of the 6 backup copies : that I tried. Clean should have enough brains to be able to : inactivate Mich in memory, or at least know that once it cleaned it Considering that there are often dozens of mutations of each virus, it would be almost impossible to write a program that could actually deactivate all of them from memory, and even if it could, it would still have no way of safely de-activating new strains. : and you rebooted, that the active in memory portion would no longer be : a threat. But No, it can't do that. The problem with this idea is that the moment clean actually removes the virus from the disk, the copy of Micheangelo in memory re-infects the disk again, leaving you right back where you started!! : The other and much more serious problem, is that after I cleaned the : disk heads, and managed to format a floppy with a system on it, and : rebooted off of that, it cleaned the hard disk. BUT it killed the dos : extended partion. Drives d - K had nothing on them. norton showed : only 1 partition (the primary one). THIS IS TOTALY UNACCEPTABLE : BEHAVIOR. CLEAN SHOULD BE ABLE TO DO THIS WITHOUT CLOBBERING THE : EXTENDED PARTITION TABLE. I spent an hour, working out what I thought Yes, it should be able to do it without wipeing the partition table, but at the same time if you had taken a bit of time to use the mirror/partn command (I presume you are using MS-DOS 5+), then you would have saved a lot of time fixing the problem!! : Cheers : Woody Scott. ------------------------------ Date: Tue, 08 Mar 94 09:31:47 -0500 From: clotscher@coh.fgg.eur.nl (Pim Clotscher @ COH) Subject: LZR bootsector virus (PC) L.S., Our helpdesk found the 'LZR' bootsector virus (F-Prot 2.11) on a 3.5" HD diskette. McAfee Scan 111 identifies it as [Genb], a 'new' generic bootsector type virus. F-Prot 2.11 cannot desinfect the diskette, nor can McAfee's CLEAN-UP. In F-Prot's new.211 file the virus is listed as detectable, but not removable. Question: is more detailed info available about the LZR virus, like desinfection method (SYS and/or FDISK/MBR, etc.), symptoms, payload, etc.? In this case we have copied all the data from the diskette, formatted it and copied back the data files (client happy). A copy of the infected disk will be sent to McAfee technical support in the Netherlands. Thanks for your attention, Pim Clotscher Erasmus University Rotterdam - NL E.R.C. - Computer Support Hoboken E-mail (Internet): clotscher@coh.fgg.eur.nl ------------------------------ Date: Tue, 08 Mar 94 09:37:10 -0500 From: "David M. Chess" Subject: re: Quox virus? (PC) >From: frahm@ucsu.colorado.edu (Joel A. Frahm) >I found the Quox virus on two PC's, using F-prot 2.10, >... What does it do? It appears to be a >boot sector virus. An extract from IBM AntiVirus's online help: Behavior Summary When you boot from an infected hard disk or diskette, the virus loads into memory and infects diskettes used in drive A or B later. It also infects the first physical hard disk in the system when it is used. If the virus is active in memory, attempts to read an infected boot record return a copy of the original uninfected boot record. The virus does no intentional damage; but, on some systems, it may overlay some existing data when it saves the original boot record elsewhere on the disk. In other words, your typical small stealthed does-nothing-but-spread boot infector... - - -- - David M. Chess | "Some look at the world as it is, and ask High Integrity Computing Lab | 'why?'. I look at the world as it is, IBM Watson Research | and say 'Hey, neat hack!'." - J. R. H. ------------------------------ Date: Tue, 08 Mar 94 10:24:08 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Tecnical Concepts of Viral Defense (MBR/DBR infectors) (PC) >From: Otto Stolz >Subject: Re: Computer Lab protections strategies (many good suggestions ommitted) The basic problem with the strategies suggested is that with the exception of write protecting floppies and setting the CMOS to boot from C:, they all take effect only after the O/S loads. For quite a few years, I have been saying that a proper defence needs to begin earlier, at the BIOS level and yet here, at least four years later, there are only two products that I know of that do so: My FreeWare stuff and Andy's Dr. Panda programs. The basic problem is that once the O/S loads, it becomes very difficult to detect low-level viruses that hide. In fact, most scanner must find the virus in memory (which creates an ongoing problem with false positives) and then require the user to re-boot from a clean floppy before attempting to disinfect. In addition I see continuing problems with lost partition tables, disks which when cleaned will not boot, and servers that will not serve. IMNSHO this occurs because the attempt is being made to late to be effective. True, I have focused on one area of work that seemed vacant (and still is) primarily because once the O/S loads there are pleanty of products to defend systems and not being a businessman I had no desire to compete - instead I preferred to use "technology demonstrators" to show what could be done. Originally I tried the ShareWare concept to see if I could at least make my hobby self-supporting but never received any income from inside my native country (USA) so gradually changed it all to FreeWare. Today, I have seen the problem slowly change from 1990 when the virus population was divided about half and half between low-level viruses and program infectors to 1994 when the overwhelming majority of the infections seen (STONED, MICHELANGELO, FORM, MONKEY, etc. etc. etc.) are low level infections - exactly the ones I have been trying to eradicate. Late last year I released DiskSecure II and the current version, 2.41, is about as close to a perfect low-level defense as software can get. (Hardware is better but no-one seems to have any money and hardware is expen$ive). When resident it needs only 300 bytes of RAM so there should be no objections there. It write-protects the low level mutables that viruses attack - if someone tries to change the fixed disk label an error message will occur. If the user manages to change the label anyway, on the next boot an error message will appear and it will be set back to the original *before* the DBR code executes again. DS II was designed to be forward looking. Before the MBR executes, DS II has become resident and will check/restore the original code if it has changed. The same is done for the DBR. Multiple redundancy is used so that even if the backup has been changed, restoration will occur. If you can set the CMOS to boot only from C: IMHO nothing more is needed, if not my (also FreeWare) NoFBoot will add safety from warm reboots from floppy for another 200 bytes of RAM. Taken together they use 500 bytes out of 655,360 (and NoFBoot can be loaded "high"). Further, my programs are designed to be compatable with other antivirals and their TSRs - even CPAV/MSAV. The only problem noted is that for some reason NAV 3.0 stated that it could not read the boot record (which is odd since DS II does nothing to impede READ, only WRITE and FORMAT). True, there are some multiple boot systems that DS II cannot be used with - COHERANT for one but I suspect that these are in the minority and DS II makes a *lot* of checks before installation. In fact it can even be used to protect a Novell server (at least 3.11, do not have any others - see "hobby" above). So I have done what I can in making an effective (have not found a virus that can defeat it even though it does not know what a virus is), cheap (free & only 300 bytes of RAM), global (works on everything from a Mk 1 IBM-PC with 4.77 mhz 8088 on up - could have saved a few bytes in the intercept by using 286+ only instructions but decided not to), fast (no noticable effect on performance), and easy to use (except for asking permission to do certain things, essentially the only decision the user needs to make is whether or not to require a password for the boot sequence/maintenance). But still low-level infections are obviously a major problem. Where did I go wrong ? Padgett ------------------------------ Date: Tue, 08 Mar 94 14:11:12 -0500 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Virus Info List By P.Hoffman? (PC) engpheng@solomon.technet.sg (MR Tan Eng Pheng) writes: >Does anybody know if Patricia M. Hoffman has released her latest Virus >Information Summary List? The latest one is vsumx401.zip (January '94) - it should be available on most decent FTP archives, but if everything else fails you can get a copy from our machine (complex.is) - -frisk ------------------------------ Date: Tue, 08 Mar 94 14:44:10 -0500 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Which ANTIVIRUS package to use????? (PC) >- - For the in-house Computer Emergency Responce Team, I recommend > at least two reliable Virus scanners/disinfectors, A good recommendation - however, there is one additional requirement - the scanners should not only be reliable, but also independent - that is, not use the same scan "engine". There are several virus scanners on the market that rely on a scan "engine" from a different manufacturer, and using two scanners that contain same "engine" is no better than just using one of them.... - -frisk ------------------------------ Date: Tue, 08 Mar 94 14:54:28 -0500 From: frisk@complex.is (Fridrik Skulason) Subject: Re: Need info on Halloween virus (PC) sgr4211@ggr.co.uk writes: >Does anyone have any information on the Helloween virus? It seems to be >a resident COM and EXE infector, but that's all I know. Well, Helloween is really a whole family of viruses...at least 14 different ones, with are 1063, 1182, 1227, 1228, 1288,1376, 1384, 1401, 1430, 1447, 1684, 1839,1888 and 2470 bytes long. There are some structural similarities, but the effects are different... - -frisk ------------------------------ Date: Wed, 09 Mar 94 04:12:42 -0500 From: jlundgr@eis.calstate.edu (John E. Lundgren) Subject: Invalid COMMAND.COM from A/V Prog. (PC) My boss made up a boot floppy disk using MS-DOS 6.0. It said that the COMMAND.COM was invalid when it booted, but it still gave the A: prompt. When I looked at the original master MS-DOS 6.0 disks, the command.com on the boot disk was about 800 bytes greater in size. I thought there might be a virus lurking there. So I renamed the original command.com to command.old, and put the one from the original master disk on the bootable floppy. It booted OK afterwards. So I ran F-PROT 211 on the bootable floppy, using the scan all files option. It said that the command.old (the one that gave me the problem) had been inoculated by Central Point Anti Virus, or maybe it was Vsafe. I'm guessing that CPAV is adding a checksum or something to the end of command.com when it is run. Apparently this changes the size of the file, but not the date or time. I'm also speculating that MS-DOS 6.0 is doing a self-check on the command.com, and possibly other program files, when they are first run. If it finds that the size has been changed, it complains. I thought that programs like CPAV created a file in the directory with checksum info, and didn't touch the program files. Has anyone had any experience like this? Any further info or clarifications? I would appreciate any email. Thanks. -- ------------------------------ Date: Wed, 09 Mar 94 05:53:26 -0500 From: A.APPLEYARD@fs1.mt.umist.ac.uk Subject: Re: Alternate infection method? (V-Sign) (PC) kenney@laser.nb.rockwell.com (Kevin Kenney) wrote in Virus-L vol7 #11 (Subject: Alternate infection method? (V-Sign) (PC)):- > Ran into a virus F-Prot 2.10(c?) calls V-Sign, and other programs call Cansu. Since it is a boot-sector infector and was on a non-bootable disk, it had partially corrupted a(n executable) file on that disk. By trying to run that program, I at least moved the virus into memory, and possibly activated it there. (VIRHUNT reported the virus active in memory.) ... Boot infectors work in non-booting floppies the same way as in boot floppies! Read the FAQ! Non-booting floppies have a boot sector, which contains a small dummy program that merely prints out "This floppy is not bootable", and can be infected same as any other boot sector. That is also why if you try to boot from a non-booting floppy that was formatted in Germany, the "can't boot" message comes up in German. ------------------------------ Date: Wed, 09 Mar 94 08:50:37 -0500 From: Greg Merideth Subject: New viruses (PC) Isn't it possible that it is going to get rather difficult in the near future to make a virus that cannot be detected? If a virus accesses the disk, theres a checksum, if it seaches for a com file, theres a checksum, overwrites a boot partition, theres a checksum, there's not much left to do. ------------------------------ Date: Wed, 09 Mar 94 09:22:52 -0500 From: ukjent (Ukjent person) Subject: HEEEEEELP ME NOW!!!! : Filler Virus (PC) Help!! My scan112 reports a Filler virus in upper memory. Then I boot from a clean, writeprotected disk and run clean112, but it doesn't remove the virus. I've read that it formats part/all of disk!! How do I remove it??? Bernt Rune Einarsen e-mail: bernt-rune.einarsen@slhk.no ------------------------------ Date: Tue, 08 Mar 94 08:19:00 -0500 From: omicron@genie.geis.com Subject: Research Project: Virus Survey To Fellow Board Users: I would like your assistance in a research study, the results of which will provide an understanding of computer virus damage and remedies by PC operators. You are requested to partake in this study by answering the questions listed below and e-mailing your responses to this researcher, via Internet, Omicron@genie.geis.com. Involvement should take no more than 15 minutes and there are no foreseeable risks involved. Specific information concerning yourself will remain strictly confidential. The results that are published publicly will not reference an individual since the study will analyze relationships among groups of data. Once received data has been been compiled and analyzed, a brief summary will be uploaded to this board. You may decide not to participate by not returning any information. This researcher certifies that the survey files are ASCII text and are virus free. If you have any questions regarding this study or desire a copy of the results, please contact this researcher at Omicron@genie.geis.com. Thank you very much. Omicron@genie.geis.com Virus Survey 1. On a scale of 1 to 5 (1 is very trivial and 5 is very serious), how serious do you feel the threat of computer viruses is today? 1. Very Trivial 2. Trivial 3. Moderate 4. Serious 5. Very Serious RESPONSE: 2. Has your computer ever been infected by a virus? If so, by which strain(s)? No, go to Item 3 Yes, please continue with the survey RESPONSE: Strain(s)? How did you detect it? What damage did it cause? 3. Do you know anyone else whose computer has been infected by a virus? If so, by what strain(s)? No, go to Item 5 Yes RESPONSE: Strain(s) 4. How do you suspect that your computer (or those of your friends or co-workers) contracted the virus? 1. BBS 2. Shareware 3. Network 4. Other (please specify) RESPONSE: 5. Do you or your company own anti-virus software? Which product(s)? 1. No, go to Item 8 2. Yes RESPONSE: Product(s) and cost 6. What persuaded you to invest in anti-virus software? 1. My computer became infected. 2. Friend or co-worker's computer became infected. 3. Company mandated it. 4. Other (please specify) RESPONSE: 7. How often do your run it? 1. Daily 2. Weekly 3. Monthly 4. Never 5. Other (please specify) RESPONSE: 8. What three features are most important to you in an anti-virus package? a. b. c. 9. Do you exchange files with co-workers? If so, on floppies or on a network? 1. No, go to Item 10 2. Yes a. Floppies b. Network RESPONSE: 10. How often do you back up your data? 1. Daily 2. Weekly 3. Monthly 4. Never 5. Other (please specify) RESPONSE: Please complete the following demographic information: 11. Age: 12. Occupation: 13. Number of months using a personal computer: Thank you very much for assisting in this survey. Please email it to Omicron@genie.geis.com ------------------------------ End of VIRUS-L Digest [Volume 7 Issue 18] *****************************************