VIRUS-L Digest Wednesday, 20 Nov 1991 Volume 4 : Issue 221 Today's Topics: PC Week's Skatt Column of Nov 11th: Word Perf. & Virus? (PC) Re: Generic scanning - a small test (PC) Re: DIR-2 found in USA (PC) Re: Computer virus report from Bulgaria Re: Disk Compression (PC for now) AIDS trial Re: two (2) excerpts from FIDO VIRUS echo conference Protection... Bug in VSHIELD? (PC) Disk Defender (was: Virusproof systems; hardware) (PC) NIST Naming Proposal Re: McAfee84 fails on Stone, Azusa and Joshi? (PC) Write-permit is not 100% reliable (reference articles) 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: Thu, 14 Nov 91 16:22:00 -0700 >From: "Rich Travsky" Subject: PC Week's Skatt Column of Nov 11th: Word Perf. & Virus? (PC) Interesting little tidbit in the Nov. 11th PC Week in Spencer Katt's column: Word Perfect, ..., was also hit by some network malevolance late last month. What started out as a bug in printer format functions turned into a persnickety nationwide virus. Seems the mysterious seizure affected only LANs with Data General PCs running WordPerfect 5.1 This certainly sounds goofy. Anyone have any idea what the Katt's talking about? Richard Travsky Division of Information Technology RTRAVSKY @ CORRAL.UWYO.EDU University of Wyoming (307) 766 - 3663 / 3668 ------------------------------ Date: Fri, 15 Nov 91 00:12:41 +0000 >From: wkt@rodos2.cs.adfa.oz.au (Warren Toomey) Subject: Re: Generic scanning - a small test (PC) >From article by frisk@complex.is (Fridrik Skulason): > I just did a small test and I hope the results are of general interest. Yes! [ much deleted ] > Generic analysis is not yet a substitute for virus scanning, but it > is improving.... I'm sorry, I don't often read through comp.virus. Can you tell me if a free/shareware generic anaysis tool like the one you used is available for IBM PCs at the moment. Thanks in advance, Warren Toomey Warren Toomey VK1XWT, cold but happy Deep in the bowels of ADFA Comp Science. `POSIX Job Control?! POXY job control more like!' ------------------------------ Date: 15 Nov 91 08:35:04 +0000 >From: medici@dorm.rutgers.edu (Mark Medici) Subject: Re: DIR-2 found in USA (PC) As a follow-up to Mike Martin's message, this may also be of interest: 1. Dir-2 (a.k.a. FAT) is a fast moving virus. In addition to the lab Mike reported, we had infections at two other labs at nearly 100%. All this happened in a matter of days from the time we suspect the first infection occurred. 2. Though we will probably never learn how the virus arrived, it was transported from PC to PC via key disks required for a copy- protected computer-based instruction program. Yet another good reason to avoid copy protection. 3. McAfee's SCAN and VSHIELD version 84 correctly identify the virus. Unfortunately, due to a large staff relocation, we did not update immediately when the new release was issued. 4. Microcom's VIRx version 1.8 and Fridrik Skulason's F-PROT version 2.01 also correctly identify the virus. I have not checked with Central Point or Symantec about updates. 5. McAfee's CLEAN version 84 successfully removes the virus with no after effects. I am not aware of any other programs that currently do the same, though a back-up and restore of the infect- ed disk may also be a means of recovery (read on). 6. The virus cannot infect NetWare volumes, as there is no DOS FAT available for them to modify. I don't know if this holds true for other networks, but would expect that they, too, would prohibit anything from attempting to modify the FAT on shared volumes. 7. Once a program infected with DIR-2 is run, the virus immediately installs itself on the hard disk and modifies the hard disk's FAT. It is not necessary to run a program on the hard disk for the virus to be transferred. 8. With the exception of some copy protection schemes failing (our first clue to the virus) and un-explained (though infrequent) system crashes, (especially in MS-Windows), the virus is invisible while active. 9. If the system is booted from a clean DOS diskette, a DOS CHKDSK will report cross-linked files. This is because the virus changes the FAT so that all entries for executables point to the virus, which then redirects to the actual file while after the virus itself executes. CHKDSK will report no problems if the virus is active. 10. Attempts to copy executables when the virus is not active will only copy the virus itself. If you later run the copied file, the virus will load into memory and you will return to the DOS prompt without the desired program every running. Attempts to copy executables while the virus is active will yield both the executables and the virus. 11. Though not fully tested, it seems that using a DOS BACKUP of the infected disk will yield the original, uninfected executables. At least this is what I found, and it makes sense when you under- stand how the Dir-2 virus works. This allows another method of recovery from the virus: Back-up the entire system while the virus is active, reboot from a clean DOS disk, reformat the infected disk, and restore the backup. This did work for me the 3 times I tried it. This is all I know about the virus at this time. Once detected, recovery is simple with McAfee's CLEAN v84. If you elect to use the backup/restore method of recovery, make certain to either low-level format your disk or use a utility that will overwrite all data in all clusters before the restore (e.g., Norton's WipeDisk or WipeInfo, or PC Tools Compress with the "Clear Unused Clusters" option turned on), and do another complete scan to make sure the virus hasn't somehow been restored as well. Standard Disclaimer: This information is provided as-is and without any warantees as to accuracy. Though everything I've described is accurate as far as I've determined, that's no guarantee that things will work the same for you. Use this information at your own risk. Any opinions are mine alone and don't necessary reflect those of my employers. - -- - ------------------------------------------------------------------------ Mark A. Medici / Systems Programmer III Rutgers University Computing Services ------------------------------ Date: Fri, 15 Nov 91 09:10:06 +0000 >From: Fridrik Skulason Subject: Re: Computer virus report from Bulgaria In Message 11 Nov 91 16:16:48 GMT, bontchev@fbihh.informatik.uni-hamburg.de (Vesselin writes: >have been discovered, all of them of Bulgarian origin. These are >Damage 1.1 and 1.3 (which, according to a string in them are made in >Plovdiv), I would rather suggest that they should be called "Plovdiv 1.1" and "Plovdiv 1.3", rather than "Bulgarian Damage". "Damage" is already in use - for a couple of Italian Diamond (V1024) derived viruses, and as "Diamond" is of Bulgarian origin, it might be somewhat misleading. > a new version of Murphy, a new version of Terror, Neither of which seems to work properly.... >a new virus, called Brainy Which appears related to a sample named "Warrier" (not "Warrior"). I have not been able to get "Warrier" to infect anything, but "Brainy works without problems. A quite interesting little virus, by the way - It may insert itself into the middle of a .COM program, without changing the beginning of the file - a trick which is only used by one other virus so far. - -frisk ------------------------------ Date: 15 Nov 91 10:07:52 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: Disk Compression (PC for now) PHYS169@csc.canterbury.ac.nz (Mark Aitchison, U of Canty; Physics) writes: > What I meant was the combination of compressed disks plus other > (simple) software protection. For example: >User programs --> DOS --> Compression system --> ReadOnly driver --> int 1 3 > (Or, perhaps, DRDOS password protection in there as well). Obviously > viruses that go via DOS get blocked by the "readonly" software > protection driver (say, DMDRVR.BIN or DISKGARD or DS II?), but (as > many have debated recently) it is easy to bypass software protection > and call interrupt 13 directly. But in this case it doesn't do the > virus any good, since they bypass the compression system when they > bypass DOS and the Readonly driver. This leaves them with junk which > the virus will either not be able to interpret, or will make a mess > of, or will require much more complexity in the virus to do the same > job as whichever compression system was used. While the combination proposed by you is a good idea and will stop most of the current viruses, it presents some difficulties to implement and could create a false sense of security, since it does not stop -all- viruses - not even all of the currently known ones, lest those that could be written by using only the currenty known ways of attack. First about the difficulties. Currently no compression system or readonly driver could be installed -beneath- DOS. However, you probably mean that they should be installed as a device driver, that is, -beneath- the DOS file managing level, but -above- the DOS sector managing level. Even such a solution presents problems, since (as I mentioned in a pervious posting), I currently don't know a way to install both compression, disk locking and a separate INT 13h handling program on the same volume. As to the security problems, note that a virus does not have to circumvent a protection in order to spread. The fact that most Messy-DOS viruses do is because there is virtually no protection on Messy-DOS and any tries to achive one are just doomed patches which can be circumvented easily - which tempts the virus writers to do so. Suppose that a virus does not try to circumvent the multi-layer protection scheme that you proposed above. Say, it just writes to files when the user does so, that is, when they are copied, compiled, deleted or whatever. Since the user really intends to modify the file, the protection scheme will either allow the operation without notice (if it is intelligent enough to guess what the user wants), or will ask for confirmation. Do you know a user (however experienced) who will say "No" if the protection asks him whether he really wants to write in the copy of the file which he is just creating? (In fact, do you know a user who will continue to use a protection scheme which asks such silly questions?) Agreed, if a virus adopts such an infection scheme, its spread will be much slowlier. However, it'll bypass the protection completely, which may pay off, causing it to spread much wider than if it only tried to bypass standard monitoring software. In general, implementation of disk/file protection (even if it is implemented correctly, which is quite difficult under Messy-DOS) has the effect of only slowing down the virus spread, not of stopping it completely. Next, consider a virus of the Dir II type (-not- the Dir II itself, since it won't infect volumes driven by device drivers), which infects the directory entries information. Since DOS often updates this information (when you copy, delete, rename, etc. a file), the modification of this information must be permitted, if you need something more useful than a write-protected disk. And since the virus does its I/O via calling the DOS device drivers directly, for any monitoring/compressing/etc. software, the write requests will seem to come from DOS itself... > Now, my worry is with viruses that do, in fact, try to manipulate the > disk behind a compression scheme. That's probably getting too far Indeed. The result of the work of such viruses is usually that the disk becomes highly corrupted... For instance, the random sector destruction that the Dark Avenger viruses perform could easily make a Stacked volume heavily crippled. > "naughty", I guess, since it tries to bypass too much. Programs like > Norton's DS are only slightly naught, and go in at the interrupt 26 > level (I think), which is still possible - I don't know what fraction > of viruses use interrupt 26 instead of interrupt 13 or interrupt 21 > (anyone with an approximate percentage?) but these are the ones that Currently none of the known viruses uses INT 26h for -spreading- (that is, for writing its body in the infected objects). However, quite a few of them use INT 26h for their payload, to cause damage. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: 15 Nov 91 11:39:59 +0000 >From: cc_s406@titan.kingston.ac.uk Subject: AIDS trial I understand that the trial of the person charged with making the AIDS Trojan was due to start at Southwark Crown Court, London, on 11th. November. Does anyone have any knowledge about the proceedings so far? Andrew. - ------------------------------------------------------------------------------- - - Andrew Smith Computing Services JANET: asmith@uk.ac.king Kingston Polytechnic Surrey, U.K. Tel. +44 81 547 2000 ext. 2077 "...its origin and purpose still a total mystery." - ------------------------------------------------------------------------------- - - ------------------------------ Date: 15 Nov 91 12:13:08 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: two (2) excerpts from FIDO VIRUS echo conference HAYES@urvax.urich.edu writes: > according to certain rules. My firmware has the option of > rejecting operations that it doesn't like, and the PC can't > get around it. So here's the plan: the user flips a switch It all depends on how his system determines what it does like... It must either stop dead any disk writing (i.e., write-protecting the hard disk), or try to make clever guesses whether the write is legal or not. If it does the latter, it's relatively easy to design a virus which will bypass it - its write requests will seem to come from DOS. > then turns off the "System Configure" switch. The SSPT then > goes out and makes a record of all .EXE, .COM and .OVL files, > the hidden files, and their corresponding FAT and directory > entries. This info is stored on the reserved disk area. On Even the FAT and the directory entries? This means that you cannot rename or delete a file on the protected volume or even add a new file to it while the protection is on. Therefore, it practically write-protects the disk. But, if this is the main goal, it doesn't need to remember all that stuff and use clever assumptions... Just denying the write functions of INT 13h will be enough and will have the same effect. > Obviously the SSPT's job is to make sure that disk writes do > not hit any of the protected files, nor delete their directory > entries, nor fiddle the appropriate FAT bits. There could be That is, nothing can be done with the protected disk except than reading from it. Then why not just forbid writing without messing with FATs and direntries? > be added to the protected list. The SSPT board as currently > produced has a microprocessor, eprom, ram, two scsi chips, two > scsi connectors, a serial port, a 2x20 char LCD display, > led's, switches, and a loud buzzer. It could be programmed to All of this just to perform the same task, which could be achieved by a switch on the write-enable wire of the hard disk cable... :-) > This board would sell for about $400, so it would be most No wonder, with all that hardware stuff... > the AT system, for little additional cost. The user would > have to insert an electronic key into a port on the board to > allow tampering with protected files. The only type of virus Even a smart card? Uh-uh... > that I can think of that this system couldn't guard against is > the one that adds a .COM file with the same name as a legit > .EXE file. But there are easy preventions for that trick, Oh, it does. If it protects the FAT and the dir entries, no virus can create a new COM file for an existing EXE one. In fact, no one can create a file (any file) at all... > Of course, a sloppy user could add add'l programs to his > system that are infected, but since the critical system boot > stuff is protected, the virus can't become memory resident > unless that program is executed after boot. Any comments? If an infected file can be added to the disk and the system only protects the system disk areas from tampering (although these two things are pretty incompatible with each other), I don't see how it will prevent the infected file from being executed. Whether the virus in it will be able to infect other objects is another story. > Any comments from our resident hardware gurus? Seems an interesting > concept, except for its price, which will deterr a lot of individual > users... I have already seen something similar (although better, simpler and cheaper) realized - the ThunderByte card. It's pretty good, but does not stop all possible viruses, of course. > trick on a hd, and not a floppy. The usal target of ansi-bombs, btw, are > BBS's, where bombs left inside an e-mail msg can do a lot of damage (e.g. > refformatting the hd, creating enough files to fill the hd, etc). Hmm none of the mailer programs for BBSes that I have used was able to interpret the keyboard redefinition codes in the ANSI bombs. This is not a danger. The danger is if somebody puts an ANSI bomb in an archive's comment or in a README file, so that if you view it later (in DOS mode, not using your communication software). Anyway, I always disable the keyboard reprogramming feature of my ANSI driver, there is no real need for it - at least for me. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Bontchev@Informatik.Uni-Hamburg.De Fachbereich Informatik - AGN Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54 ------------------------------ Date: Thu, 14 Nov 91 19:58:20 -0800 >From: turtle@darkside.com (Fred Waller) Subject: Protection... Writes JPINSON@csa.ucns.uga.edu (Jim Pinson): > I once made a simple modification to a floppy drive so I could > write to protected diskettes. Disabling the write-protect detection mechanism in floppy drives is a trivial task. It is, however, a task that software cannot perform! The OPERATOR did that. A hammer, or other similarly- persuasive device, will also defeat hardware protection. There's no question about it... > If I had malicious intent, I could have "borrowed" someone's > original protected application diskette, and infect them. Of course. > If that person assumed that no virus could possibly be on > that disk, and failed to scan them, they would find themselves > infected. Yes, but failing to scan is not the reason why he got infected. Scanning is not foolproof either; the person could have scanned and still gotten infected. Or, if the scanner was not too well designed (as some are not), then the act of scanning itself might have spread the virus further to other parts of the system. In fact, of all the antiviral software methods, scanning is the least foolproof. Useful, though, as a stopgap measure. > Granted, this is not simple virus infection, but a combination > of sabotage and virus attack. Precisely. > The point is that too much confidence that you have a "perfect" > defense can leave you vulnerable to other forms of attack. This is true in every case. Overconfidence makes bad security. The same effect could have been achieved by subverting the scanner, or whatever other defense system was in use. It says nothing about the desirability or undesirability of hardware protection. Fred Waller turtle@darkside.com ------------------------------ Date: Fri, 15 Nov 91 08:22:43 -0600 >From: Brian McGraw Subject: Bug in VSHIELD? (PC) Hi everyone. I was wondering if anyone else has found a bug with Vshield v.84. It seems that when installed, a regular Ctrl-Alt-Del which usually causes a warm reboot, doesn't work the same. Instead, it does a cold boot, causing my drives to spin atrociously, and a memory check at the startup. When I removed Vshield from my UMB's, everything worked fine. Anyone else had this happen? Thanks, Brian McGraw DMCGRAW1@UA1VM.BITNET ------------------------------ Date: Fri, 15 Nov 91 17:10:00 +0200 >From: Y. Radai Subject: Disk Defender (was: Virusproof systems; hardware) (PC) Brian Howard writes: >Not to be extolling the virtue of a dead horse instead of beating it >but, I use DD on older systems (at this point less than 10 of about >70 still in service) protecting the MBR against Stoned and other >similar ilk. It's interesting to hear that someone is (almost) satisfied with DD, but I do wish you'd relate to the specific problem that I mentioned: >> ... one could specify >>what cylinders one wanted to be write protected, but it had to be the >>trailing cylinders (i.e. from a given cylinder to the end of the >>disk). And since the Master Boot Record has to be on Cylinder 0, it >>couldn't be protected. .... This >>was apparently deliberate because there was an accompanying device >>driver which modified the MBR at boot time. But this left the MBR >>wide open to infections by Stoned, etc. It's possible that the (1988) version of DD which I was using differs from the version you use, but please answer the following question: Are you able to put Cylinder 0 in the protected zone? If the answer is Yes, doesn't your version use a device driver (ADDPART.SYS) to modify the MBR at boot time? If the answer to the first question is No, then how can DD protect the MBR against the Stoned and other MBR infectors? From your reply to Vesselin: >(Oh, it has a third problem I just remembered about. It fails open. >Yep, when it fails it usually renders the drive writable. Would you mind explaining what you mean by "failing open"? > The second [re- >latively minor problem] is the company is out of business. Hmm, if DD is such a great product, I wonder why the company went out of business .... Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Fri, 15 Nov 91 11:47:02 -0500 >From: Tim Polk Subject: NIST Naming Proposal The NIST virus naming proposal has been mentioned in passing a couple of times recently; this message is intended to provide a brief overview of that proposal. This is an ongoing project, with documents in *draft* status. The project was inspired by the difficulties we have experienced when attempting to cross-reference and verify virus information. The goals of the proposal are: 1) to reduce the confusion caused by multiple names for a single virus; and 2) to ensure "good" virus names. We believe that "good" names are ones are that are easy to remember, are not offensive, and describe the behaviour or contents of the virus. The proposal consists of two parts: naming guidelines and naming procedures. To make a long story short, the naming guidelines call for names of the form "FAMILY-STRAIN;Variant#" where STRAIN and Variant# are optional. Viruses which have minor differences with existing viruses use the name of the existing virus with a new variant number. Viruses which are derived from existing viruses, but have substantial modifications in technique or side effects, would use the existing family name but would recieve a new STRAIN. Entirely new viruses are assigned a new FAMILY name. The naming procedures assigns the laboratory which isolates and analyzes the virus responsibilty for assigning the virus' name. A central site would maintain the central naming database, arbitrate disputes between laboratories, and generally enforce the naming guidelines. This proposal has been presented to members of both EICAR (at the Sept. conference) and the AVPD. We will be discussing this project again at the AVPD conference later this month. We are hopeful that the proposal will be widely accepted, but a number of unanswered questions remain. For those who are interested, we have posted the latest drafts for anonymous ftp from csrc.ncsl.nist.gov (129.6.54.11). The files are in the directory /pub/viruslab. The documents are available in both ascii text and PostScript formats. The ascii text versions are nameconv.txt and nameproc.txt; the PostScript versions have the .ps extension. Any comments may be sent to virus-lab@csmes.ncsl.nist.gov Thanks, Tim Polk Larry Bassham NIST ------------------------------ Date: Fri, 15 Nov 91 17:27:13 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: McAfee84 fails on Stone, Azusa and Joshi? (PC) tanu@beach.csulb.edu (Tanu Kartawiria) writes: >We are in the process of evaluating McAfee program, specifically the >VSHIELD84. We have vshield installed on all machines's autoexec.bat >with parameters '/m /chkhi /lock', however our computers are still >infected by those 3 viruses. The Clean program was able to remove >Stone and Azusa, but it failed to remove Joshi even though it reported >that it was successful in removing Joshi. Can you be more specific about what happened with the Joshi virus? Was the virus found in the partition table of the hard disk afterwards? >Isn't Vshield supposed to block those viruses from getting to our >computer in the first place? Are we missing something? Or are we >doing something wrong? I'd appreciate your comments and expertise. VSHIELD will prevent you from performing a soft-boot (Ctrl Alt Del) with an infected floppy in the A: drive, however, if you actually boot up from an infected floppy, then VSHIELD (which I assume is on the hard disk) is not run and a virus will have a chance of transferring to the hard disk. VSHIELD will, however, detect the virus the next time it is run. >Or should I use different program? If you want to prevent your PC's from being booted from a floppy disk, you may want to consider a new BIOS that will allow you to "lock out" boots from the floppy drives, or a card that will do something similar. Regards, Aryeh Goretsky McAfee Associates Technical Support - -- - - - - McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 4423 Cheeney Street | FAX (408) 970-9727 | aryehg@darkside.com(personal) Santa Clara, California | BBS (408) 988-4004 | 95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM ------------------------------ Date: Thu, 14 Nov 91 09:40:08 +0000 >From: Anthony Appleyard Subject: Write-permit is not 100% reliable (reference articles) from: {A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Thu, 14 Nov 91 09:32:56 GMT Re reliability of write-protect tabs, ref these articles in Virus-L vol 4:- ...................................................................... [vol] [can we trust diskette write-protection? (PC)] My PC ignored it 071 [Re: can we trust diskette write-protection? (PC)] Light bouncing about past the write protect tab; use black tabs not silvery tabs 072 [Re: can we trust diskette write-protection? (PC)] if I leave cover off my PC, fluorescent lights confuse its write protection detecter 074 [Re: can we trust diskette write-protection? (PC)] color of tabs used 077 [re: Diskette write protection.] some drives will write to some 5.25inch floppies that I have that have no write permit slot; description 078 [Which format for Partition Table Viruses (PC)] reformatting tape is no use of virus stays in computer memory 087 [Re: Can such a virus be written .... (PC)] can write protect by covering the write protect notch be bypassed by software? 115 [IBM Write-Protection (was: Can such a virus be written ... ) (PC)] Software can't bypass it; but hardware often malfunctions 116 sometimes but not often ([Re: Can such a virus be written .... (PC)]) 119 ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 221] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253