VIRUS-L Digest Wednesday, 31 Jan 1990 Volume 3 : Issue 27 Today's Topics: re: Universal virus detectors WDEF A at Connecticut College (Mac) Re: Thermal Nuclear War ? 4096 and 1260 Viruses (PC) PC Magazine Free Utility: PCDATA (PC) re: 1260 virus (PC) Re: ADAPSO Virus Book Disinfectant 1.6 (Mac) Possible new virus?? Followup Gatekeeper veto: Normal behavior or virus attack? (Mac) WDEF A at Univ of Miami (PC) virus propogation in non-executable files The Checksum feature of FLU_SHOT+ (PC) VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: 30 Jan 90 00:00:00 +0000 From: "David.M..Chess" Subject: re: Universal virus detectors I don't entirely understand the proposal from Jerry Leichter. He describes a system which (if I'm reading it right) basically allows the user to get a known-correct "last written" timestamp for any executable object. It's not clear to me how this constitutes a universal virus detector, though. Don't we also need an algorithm that looks at timestamps and timestamp-change histories, and detects viruses on that basis? That strikes me as a Hard Problem. Does the user review his timestamps once a day, and try to figure out which changes are OK and which aren't? Can the user really be counted on to get this right, given that virus authors will shortly find out the detection methods that we're using, and make viruses that act so as to be less likely to be noticed in that environment (details left to the readers' own ingenuity...)? Having a known-reliable "last changed" stamp for executables would be very nice, and would help with the anti-virus effort. I don't think it quite makes it as a Universal Detector, though... DC ------------------------------ Date: Tue, 30 Jan 90 15:29:00 -0500 From: gateh@CONNCOLL.BITNET Subject: WDEF A at Connecticut College (Mac) WDEF A has reared its head in our public labs and one office AppleShare network. Boy, does this thing spread like wildfire. Gregg TeHennepe | Minicomputer Specialist gateh@conncoll.bitnet | Connecticut College, New London, CT ------------------------------ Date: 30 Jan 90 15:41:00 -0800 From: MGB@SLACVM.BITNET Subject: Re: Thermal Nuclear War ? A suggestion might be for your friend to boot from a floppy and take a look in his autoexec.bat file to insure that a batch file was not created to type the message to his terminal BEFORE he reformat his hard disk. It really sounds as if someone might have created a small "Welcome Home" batch file rather than a virus. If the batch file does not exist, then he/she can consider a total reformat. All strange messages are not necessarily viruses. ------------------------------ Date: Tue, 30 Jan 90 15:32:57 -0800 From: Alan_J_Roberts@cup.portal.com Subject: 4096 and 1260 Viruses (PC) This is a forward from John McAfee: A new breed of viruses has surfaced in the past two months. These viruses are very complex and use sophisticated techniques to avoid detection, identification and removal. Since they are new viruses, they are not yet widespread, but they are destined to become major problems within the next year. Among this new breed of viruses is the 4096, Alabama, Virus-101 and the 1260. Very little has been written or discussed about these viruses, so I thought it was about time to shed some light on a trend I'm sure we will see more of. The two most interesting of the new breed are the 4096 and the 1260 viruses. The 4096 has had few public reports as yet, but this is not surprising since it is virtually invisible - even if memory resident filters like Flu-Shot+ or Protec are in use. It is by far the most sophisticated virus we have seen. It is also the largest, as measured by the number of instructions. Numerous disassemblers have copies of this virus, including Dave Chess, Joe Hirst, Morgan Schweers and others, but we don't yet have a fully documented listing. We do know quite a bit however: The virus is memory resident and infects COMMAND.COM, EXE files and COM files. The virus initially places the machine in single-step mode and then issues an interrupt 21, sub-function 52 to determine the real address of the interrupt 21 code within DOS. Thereafter, it issues a long jump to that location to avoid any interrupt trapping antivirals that may be resident. Thus the infection process, after the virus becomes resident, is transparent. The strangest part of the virus is that it is also able to trap all other disk reads and writes, and whenever an infected file is accessed by any program, the virus performs a disinfection of the program on the fly. Thus checksumming techniques, file length checks, and other file modification detectors cannot perceive the infection on the disk. Even searching the disk for the specific virus code will fail, since the code is removed from the file during the read request. Doing a directory of the disk likewise shows no virus effects. The real increased length of infected files is subtracted during the directory listing. This characteristic has a surprising side effect: Whenever an infected file is copied to another file that does not have an executable extension, the new file turns out to be the original, uninfected program. Whenever this uninfected program is copied to any other file that does have an executable extension, the end result is an infected program again. We don't yet know the exact mechanisms used by this virus, but we do know it works. No memory resident virus filter, or system virus scanner that we are aware of is able to prevent infection from this virus, or detect an infection after it has occurred - providing that the virus is active. The only way, currently, that we know how to detect this virus is to look for its code in memory. The 1260 virus, unlike the 4096, does not do much while active in memory. It does, however, have the most sophisticated encryption technique yet used by a virus. Not only is the virus fully encrypted, but the code extractor is also garbled for each occurrence of the virus. This makes simple string matching useless for identification. There are eight working commands in the Code Extractor; the remainder are fluff to allow that portion of code to look somewhat different between implementations. They are: 1. B8 nnnn MOV AX,immediate 2. B9 nnnn MOV CX,immediate 3. BF nnnn MOV DI,immediate address = END+0028 4. 31 0D XOR W[DI],CX 5. 31 05 XOR W[DI],AX 6. 47 INC DI 7. 40 INC AX 8. E2 nn LOOP immediate address ------------------------------ Date: Tue, 30 Jan 90 18:45:00 -0700 From: Keith Petersen Subject: PC Magazine Free Utility: PCDATA (PC) All the programs in the PC Magazine PCDATA package are available via anonymous ftp from SIMTEL20: pd2: VOL9N03.ARC 188K 01-16-90 PCMag FASTRUN,MIRDIR,NOVIRUS,SCANSYS,XALL - --Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil, w8sdz@brl.arpa BITNET: w8sdz@NDSUVM1 Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz ------------------------------ Date: 30 Jan 90 21:17:00 +0100 From: Morton Swimmer Subject: re: 1260 virus (PC) As a comment to what frisk mentioned about the 1260 virus, I would like to add that, you likewise cannot tell the difference between the Syslock, Macho and Advent viruses (viri?) using classical scan methods. They all have identical startup code which will proceed to decrypt the actual virus body. On top of that, Macho and Syslock have identical lengths (and similar damage). Advent is however much shorter. I'm not a big fan of virus scanning anyway, but using checksums, as I do, can be cumbersome. Cheers, Morton ------------------------------ Date: 31 Jan 90 04:37:42 +0000 From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: ADAPSO Virus Book spaf@cs.purdue.edu (Gene Spafford) writes: >"Computer Viruses: Dealing with Electronic Vandalism and Programmed >Threats" by Eugene Spafford, Kathleen Heaphy, and David Ferbrache. >1989, 109 pages. Published by ADAPSO. [...] >state and Federal laws against computer crime, and detailed >descriptions of all IBM and Apple Macintosh viruses known as of 1 >October 1990. ^^^^ Geez, I'm still writing 1989 on my checks, and now I'm writing 1990 where I should be putting 1989! Make that "known as of 1 October 1989" and realize you'll be old and forgetful someday too! - -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf ------------------------------ Date: Wed, 31 Jan 90 00:03:21 -0500 From: jln@acns.nwu.edu Subject: Disinfectant 1.6 (Mac) Disinfectant 1.6 ================ January 30, 1990 Disinfectant 1.6 is a new release of our free Macintosh virus detection and repair utility. Version 1.6 automatically detects and repairs files infected by new clones of the nVIR A and nVIR B viruses. Several clones of nVIR B have appeared, and in the past we had to configure and release a new version of Disinfectant to properly recognize each new clone. This should not be necessary in the future. The new generic nVIR clone detection and repair algorithm is based on the one used by Steve Brecher in his Repair program. Thanks to Steve for sharing his code with us. The new nVIR clone detection and repair feature was intended for release as part of Disinfectant version 2.0, which is still being developed. Yet another clone of nVIR B was recently discovered at Stanford University, so we decided to release just this part of version 2.0 now. Disinfectant 1.6 is available now via anonymous FTP from site acns.nwu.edu [129.105.49.1]. It will also be available soon on sumex-aim, rascal, comp.binaries.mac, CompuServe, Genie, Delphi, BIX, MacNet, America Online, Calvacom, AppleLink, and other popular sources for free and shareware software. John Norstad Academic Computing and Network Services Northwestern University 2129 Sheridan Road Evanston, IL 60208 Bitnet: jln@nuacc Internet: jln@acns.nwu.edu CompuServe: 76666,573 AppleLink: A0173 ------------------------------ Date: 31 Jan 90 04:54:50 +0000 From: munnari!dbrmelb.oz.au!steveo@dbrmelb.dbrhi.OZ (Stephen Oakes) Subject: Possible new virus?? Followup Sincere apologies for the previous article I sent yesterday about a possible new virus. It turned out that it was a message installed as a hoax by another party who altered the autoexec.bat file, and was not in fact a virus. PLease ignore my previous posting. Thank you, Stephen Oakes, steveo@dbrmelb.dbrhi.oz ------------------------------ Date: 31 Jan 90 10:56:41 +0000 From: swenson@pythagoras.Stanford.EDU (Norman Swenson) Subject: Gatekeeper veto: Normal behavior or virus attack? (Mac) I have noticed something suspiciously virus-like on my Mac II. I was getting a "Serious disk error" message from Microsoft Word and garbage in my files when using the editor in TeXtures. Fearing an imminent disk crash, I backed up my hard disk to another. While the files were copying over. I got a veto message from Gatekeeper (ver 1.1.1, w Gatekeeper Aid). I decided to check my disk using Disinfectant 1.5 and found that Drawover (part of Adobe Illustrator) was infected with nVir B. I disinfected that file, and all my disks then scanned clean. However, whenever I try to open the Illustrator folder on the backup disk, I get the following veto message: 'Gatekeeper has vetoed an attempt by Finder to violate "Res(other)" privileges against Desktop. [AddResource(ADBS,0)]'. I have isolated the behavior to the Adobe Separator 2.0 program. When I remove it from that folder, I do not get the message. When I put it back, I don't get the message the first time I open the folder, but I do every time after that. I made a copy of the folder on another disk, and at first I got the same behavior, but after I rebooted it went away on the second disk. I looked at both desktop files using resedit; one had the ADBS resource in it, the other did not. Is this normal behavior, or could it be due to a virus that Disinfectant 1.5 is not catching? Why would opening a folder require adding a resource to the desktop file? And why did Gatekeeper veto it on one disk, but not the other? Any information is greatly appreciated. Norm swenson@isl.stanford.edu ------------------------------ Date: Tue, 30 Jan 90 23:12:51 -0500 From: GROSS@umiami.Miami.EDU Subject: WDEF A at Univ of Miami (PC) For tracking purposes, let me say that WDEF A has managed to reach the Deep South...and has struck our public labs here on campus. Yippee. - -- Jason Gross Comp Sci Ugrad University of Miami Class of '91 (?) =========================================================================== Hey, wanna save the world? | Got sumtin' to say? gross@umiami.bitnet Nuke a Godless, Communist, | Pick and choose! gross@umiami.miami.edu gay whale for Christ. | gross@miavax.ir.miami.edu - Anonymous | =========================================================================== Lie: The University of Miami is a non-profit institution. ------------------------------ Date: 31 Jan 90 09:42:00 -0500 From: "WARTHMAN" Subject: virus propogation in non-executable files In VIRUS-L Digest V3 #23, DGStewart@DOCKMASTER.ARPA writes: > On another matter, there is a simple procedure which can be used to > check for most viruses and other forms of corrupt code. It is this: > All viruses have to be in some executable file in order to act. > ... > Text files cannot > propagate a virus and should not be deleted unless they have already > been trashed by the corrupt code. Although this may be the case in the MS-DOS and UNIX worlds, it is not strictly the case in for the Macintosh. Certainly a virus must be executed in order to spread, but that doesn't always mean that it must attach to an "executable" file. In particular, the WDEF virus inserts an executable resource into the "desktop" file. This file would never ordinarily contain any executable code, just data which describes the visual appearance of the disk volume on the Mac screen. Due to a "feature" of the Mac operating system, however, an executable resource can be contained in ordinary" data files and, under certain circumstances, be executed. Thus, we have a situation in which data files are used to contain and to propogate a virus. This is an especially sneaky method, since the *program* that is running when WDEF does its thing (Finder) is not, itsself, infected. - -- Jim Warthman ------------------------------ Date: Wed, 31 Jan 90 16:37:20 +0200 From: Y. Radai Subject: The Checksum feature of FLU_SHOT+ (PC) As happens every once in a while, I've fallen several weeks behind in reading VIRUS-L (due to e-mail problems among other things), so forgive me if I only now get around to replying to Ross Greenberg's posting in Issue 5. Concerning his FSP (FLU_SHOT+) program Ross writes: > However, to date, it seems to be good enough: >no virus infection on a checksummed program has gotten through (to my >users knowledge, naturally) without detection. I can only assume that >lack of reporting can be equated to lack of infection I'm willing to accept the assumption that no program checksummed by FSP has ever been infected by an actual virus without FSP's detecting it. What I don't accept is that this shows that FSP is "good enough". The assumption could equally well be true because users of FSP simply don't bother using its checksum feature!! In my opinion, the latter explanation is far closer to the truth. Of the three people I know who use FSP, two checksum only the 3 files in the sample FLUSHOT.DAT file: COMMAND.COM and the 2 hidden system files, and the other user doesn't use the checksumming feature at all. Why? Because it's so extremely tedious to use. The user is forced to individually enter into his FLUSHOT.DAT file the name of each file which he wishes to be checksummed along with a dummy check- sum, to run the program, to copy down each checksum displayed by the program, and then to manually replace each dummy checksum in FLUSHOT.DAT by the correct value. Since it's difficult for me to ima- gine anyone going through all that bother on more than a few files, I think my 3-user sample is representative. I might understand if the probability of these three files getting infected were much greater than that of other files. But precisely the opposite is true. There are only a few viruses which can infect COMMAND.COM, and all of these (except possibly one) are relatively rare. And I haven't heard of a single virus which can infect either of the other two files. So the fact that no program checksummed by FSP has been infected by a virus without being detected doesn't prove very much about how good FSP's checker is. >>How many of its users have the slightest idea how its security com- >>pares with that of other programs? > >The users have to trust the program author of any security product. As >such, they have to trust that, if a virus were to infect files with a >"zero differential" on the checksumming method I use, that I'd change >the checksuming method. Yes, there has to be a trust in your vendor. My question had nothing to do with trust. One may be very trustworthy but still unknowingly distribute an inferior product. >> for any given file all users will get the same checksum, and >>that's a potential security hole .... But since this hole can >>be plugged very simply and at no cost in speed, why not do so, Ross? > > If they ask me: "Is my COMMAND.COM file infected?", I need >simply ask them what the checksum is. From that I know the answer. If >I used some method to generate unique checksums for each user, I'd still >have to have some means to get back to the "real" checksum. Sorry, but I don't understand why you have to get back to the "real" checksum. Suppose we improve the security by making the checksums different for each user. From the fact that some user's checksum has changed relative to *whatever* it was when that user set up his checksum base, we'd know precisely the same thing that you know by comparing with the "real" checksum, namely that his file had been altered (which *may* indicate infection). So what do you gain by use of the "real" checksum? But let's suppose you can show me that there's some purpose for using real checksums. Do I understand you correctly that you keep a list of the real checksums of the COMMAND.COM file of all versions of PC-DOS and MS-DOS which ever existed? Then what about all the tens of thousands of other files which might get infected and which your users might ask you about? >Please understand that I certainly can appreciate the limitations of using >a less sophisticated algorithm within my code as versus something wonderfully >complex. But, as with any security product, I had to weigh off security >versus convienience considerations. Adding a random key to a simple algorithm wouldn't make it "wonderful- ly complex" or less convenient in the slightest. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI1@HBUNOS.BITNET ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253