VIRUS-L Digest Wednesday, 25 Oct 1989 Volume 2 : Issue 222 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 Today's Topics: VIRUSCAN/VIRSCAN Issues (PC) Free Catalog Disk Infected (PC) Protecting Your User's Disks (Mac) New virus in Israel (PC) You're not alone; DataCrime infection report (PC) possible virus infection (PC) Re: 0 bytes in 1 hidden file, virus? (PC) The not-so-new virus (Mac) Re: VIRUSCAN test (IBM PC) Jerusalem Virus Version B detected (PC) --------------------------------------------------------------------------- Date: Tue, 24 Oct 89 11:12:03 -0700 From: portal!cup.portal.com!Alan_J_Roberts@Sun.COM Subject: VIRUSCAN/VIRSCAN Issues (PC) The following is a forwarded message from John McAfee: ============================================================================= A number of people have commented on the "closed" architecture of VIRUSCAN and the encryption of the individual search strings used for virus identification. Some users feel that this is done in order to maintain a "monopoly" in the scanning industry and to keep competitors from using the same strings. I would like to put that concern to rest, if possible. First, as many users will have noticed, the earlier versions of SCAN had all strings available for anyone who cared to look at them. The users who wished merely to scan for viruses merely noticed them, shrugged (really - what value is it to the average user?), and went on. The folks who seemed to take notice of the strings were those few crackers who used the strings to change the virus segments referenced by the strings. This has happened seven times in three months, the most recent being the New Jerusalem virus discovered by Jan Terpstra and Ernst Baedecker in the Netherlands. The virus is identical to the Jerusalem-B, with the exception of the string changes that SCAN originally referenced. What this does is invalidate all of the work done to date on identification of the Jerusalem-B. To make it more difficult for crackers to get around the scanning process, I've done two things: 1. encrypt the strings (I know that this merely slows down the determined cracker, but it does deter the casual cracker - of which there are many). and 2. I use multiple strings for the more mutable viruses. In addition, I have taken to randomly changing strings for different versions of scan. None of this was done to deter competition. In fact, as Art Gilbert and Bill Vance at IBM should agree, I co-operate fully with competitors in providing virus samples, infection trends, market information and (possibly unwelcome) suggestions for improvements and points to watch out for in the more troublesome viruses. I even provide my string lists to any legitimate competitor who asks for them. I just don't provide them to the public, and I'm not sure the public really would be served by knowing the binary string sequences I use to identify a given virus. I response to the comments that IBM's open string list will make it easier for users to update the files themselves - I absolutely agree. There's a lot to be said for the flexibility and control that such an approach brings. But, ignoring the problem crackers for the moment, we will have to ask - who is going to update the string files? Is it each user? If so then chaos will ensue. I can categorically say that the average user is incapable of taking a live virus sample and creating a valid search string for that virus. The problems are immense. First, many viruses are written in C, PASCAL or other higher level language. Unless you are familiar with the actual code generated by the compiler runtime library and the canned compiler output sequences, you will have dificulty separating the origin virus code from the same code that you will find in hundreds or maybe thousands of other similarly compiled programs. Second, the string segments must have a unique "style" that will avoid false alarms with similar styled programs. For example, choosing a long string of register saves as an identifier will guarantee false alarms with other programs. The user will also have to know something about the infective characteristics of the virus as well. Does it only infect the partition record, or the boot sector? Does it infect overly files? Which ones? etc. All in all it is a task that most user shouldn't have to face. So we can agree, I think, that the strings will havee to be done by competent programmers with a fair amount of virus experience if it is to work. The question then is - which programmers? Who will set the standard. If there is no standard, then again, chaos results and which version of the strings swhould we use? My feeling is that the IBM approach works well for researchers, but that the general public should use only the strings that IBM produces (or someone that IBM should designate). So much for my soap-box for the day. We survived the earthquake out here. We were 6 miles from the epicenter, but we must have been on a standing wave since we suffered only moderate damage. My cat slept through the entire event (though, admittedly, he only normally wakes for 15 minutes at breakfast and 20 minutes at dinnertime). Have a good day. John McAfee ------------------------------ Date: Mon, 23 Oct 89 19:21:00 -0500 From: IA96000 Subject: Free Catalog Disk Infected (PC) My friend just received, and I now have in my posession a free disk from a Shareware copying company, which he received after he sent in a "bingo" card from a popular computer magazine. The disk has three infected files on it: 1) GETKEY.COM 3074 bytes 01-01-80 12:35a 2) CL.COM 3457 bytes 08-01-86 02:39p 3) LIST.COM 7871 bytes 06-17-86 02:37p SCAN version 0.7V42 reports as follows: GETKEY.COM - 3066/2930 TRACEBACK VIRUS CL.COM - 3066/2930 TRACEBACK VIRUS LIST.COM - FU MANCHU VERSION A GETKEY.COM and CL.COM are in the disks ROOT directory. CL.COM appears to a hidden file, as it is not seen when you do a DIR from the DOS prompt. LIST.COM is in the subdirectory \ORD. To be fair to the company which sent the disk, I will mention their name here, as in all probability, they do not know the disk is infected. No sense creating another major problem... The disk label is designed as follows: 1989 COMPANY NAME CATALOG *************************** P.O. xxxx HESPERIA, CA 92345 MAY VIEW OR PRINT CATALOG & ORDERFORM TO START CATALOG . . . A>START The disk has one subdirectory on it named \ORD which contains 8 files. The ROOT directory contains 25 files. My friend spotted the fact that LIST.COM is in both the ROOT and the sub-directory and the file sizes differ. Also, since he did not know the company, he ran SCAN as a precaution. If Dave Chess at IBM or Mr. McAfee wants a copy of this disk, please let me know...by EMAIL. I have gone to great lengths to not identify the company to avoid any problems. Also..please note this disk WAS NOT sent to the university, nor was any damage done to any of the university equipment. I hope I have given you all enough information to identify the disk, if you happen to receive one. The disk was not unsolicited, in other words, the disk was requested by my friend and the magazine has nothing to do with this issue, at this point in time. ------------------------------ Date: Tue, 24 Oct 89 15:32:00 -0500 From: "Thomas R. Blake" Subject: Protecting Your User's Disks (Mac) >(Prior to INIT29, I had been advising my users that if they go >to Kinko's they would be safe if they took only their data diskette. >But if a data infection can spread to their application disks, >this would not be good advice.) > >Anyone got the REAL answer? Well, I assume they're going to Kinko's to print. (Yes/No?) I'd say if they write-protect their diskettes they have no need to worry. Macintosh viruses will not spread to write-protected diskettes. Thomas R. Blake SUNY-Binghamton ------------------------------ Date: Tue, 24 Oct 89 19:32:37 +0200 From: "Yuval Tal (972)-8-474592" Subject: New virus in Israel (PC) A new virus was found here in Israel. I didn't know whether to call it: The Do Nothing Virus or The Stupid Virus. The author (which is as usually known) put an infected program on one of the BBSs in Israel. The program was an infected program which my friend wrote BUT it claimed to be a new version (eg. my friend's latest version was 3.4 and the one on the BBS was 4.0). He quickly downloaded this file and he found out that it is infected with a virus. After checking this virus he and I got to one big conclusion. The author of this virus probably doesn't know assembly so good. You can see this quite clear: -The virus tries to push only one byte into the stack. -The virus is copied always to location 9800:100h this means that it will work only on computers 640KB. The virus doesn't reduce the amount of memory (like other viruses such as Denzuk, Ping-Pong etc'). The virus is copied and that's it! Turbo Pascal, for instance, may use this location as heap and the virus may be erased from memory. Another thing, this virus infects only the first .COM file on the directory. It doesn't check if the file is already infected or not, it just infects it. This virus does nothing besides infecting the file, no damage at all! This is why I called it The Do Nothing Virus. Here is a report I made. I may change it a bit here and there.. - -------------------------------------------------------------------------- Entry................: The Do Nothing Virus Alias(es)............: The Stupid Virus Virus detection when.: 22-October-1989 where.: Israel Classifications......:.COM file infecting virus/extending. Length of virus......: 583 bytes add to file. Operating system(s)..: MS-DOS Version/release......: 2.0 or higher Computer model(s)....: IBM PC,XT,AT and compatibles Identification.......: .COM files: The first 3 bytes of the infected files are changed. System: The virus copies itself to 9800h:100h. Type of infection....: Extends .COM files. Adds 583 bytes to the end of the file. The virus copies itself to 9800:100h. This means that only computers with 640KB may be infected, hooks int 21 and infects other programs by scanning the directory until it finds a .COM file. It is infected upon function Fh and 3Dh. .EXE files are not infected. Infection trigger....: The first .COM file of the current directory is infected whether the file is infected or not. Interrupts hooked....: Int 21 Damage...............: None. Damage trigger.......: Whenever a file is opened. Standard means.......: Lots of programs such as Turbo Pascal use this area And the virus may be erased... Acknowledgment: Location.............: The Weizmann Institute Of Science, Rehovot, Israel Documented by........: Yuval Tal (NYYUVAL@WEIZMANN.BITNET). Date.................: 25-October-1989 - ------------------------------------------------------------------------------- - -Yvual Tal ------------------------------ Date: Tue, 24 Oct 89 17:45:48 -0400 From: Arthur Gutowski Subject: You're not alone; DataCrime infection report (PC) >From Virus-L Digest v2.220, frisk writes: > Well - now I know of one victim of the Datacrime-II virus ..... > myself. :-( Well, you shouldn't feel alone. A friend of mine who works for ERIM (Environmental Research Institute of Michigan) got hit too. His quotes sounded something like this (before being hit): "Oh, I'm not worried, I don't do much software trading, and what I do is straight from BBSs and buying from vendors." That was until he turned on a computer at work on Saturday 10/14. He had recently DLed a copy of PKZ102.EXE (PKZIP v1.02, self-extracting) from CompuServe and decided to try it out. Although I can't be sure that this was the source of the infection, eh told me it was the first time he had had a chance to run the program (hence, strong implication). Then it was showtime. Bye bye hard drive, low level format (F6) to cylinder 0. Effectively wiped out all access to the hard drive. Even a large chunk of the 2d copy of the FAT was duly destroyed because of this. He admitted to me that rebuilding a FAT, even with Mr. Norton's help, is not much fun. Needless to say, he has grudgingly accepted from me a disk containing several acrhives of antiviral tools to help him along in the battle. This disk is soon to be out in our Consulting center and student labs. Hopefully we can make enough people aware of things like this before more have to pay the awful price. Thankfully, it's already happening... One final note, I'm not POSITIVE it was DC that hit him, it may have been some variant. He is currently trying to see if he can get the infected program to me so I can look at it using info I've gained from watching here. Two strane things that made me question my assumption: 1) No "DATACRIME" message was thrown up on the screen that he remembers; 2) A name, Siegmar Schmidt, was written to the partition record. Now again, it DID format cyl0 and only cyl0...can anyone say for sure? Please e-mail me to the bitnet address above, 'twould be much appreciated. It CAN happen to anyone! Art +------------------------------------------------------------------+ | Arthur J. Gutowski, Student Assistant | | Antiviral Group / Tech Support / WSU University Computing Center | | 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 | | Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET | +==================================================================+ | "OOPS, what OOPS?!?...No, I diSTINCTly heard you say 'OOPS'!" | +------------------------------------------------------------------+ ------------------------------ Date: Tue, 24 Oct 89 19:34:21 -0400 From: flanders@grebyn.com (Dennis Flanders) Subject: possible virus infection (PC) I am a new user on VIRUS-L. I am a communication engineer on the FTS2000 project at Boeing Computer Services and we run a large client/server data network. It now serves over 800 PC's, Sun Workstations and is served by several host machines from mainframes to micros. I said all that to say this: In the process of "de lousing" our network for Columbus day and Friday the 13th, using a program called VScan, we discovered seven programs that showed as possible infected programs or carrier programs. In disassembling them only one proved to be dangerous. The others contained code sequences to totally lock the keyboard and triggered warnings. It may have had the infection passed on by another virus as the first three bytes in the .com file were 909090h. The following bytes (I believe 19) simply blitzed track 0. The infected file was a brief program (217 bytes) called KEYLOCK.COM which comes with a set of utilities distributed by PC Magazine. We could find no infected distribution disks. Only versions found on two PCs were found to contain this bomb. Curiously enough a couple of programs (ie NORTON.COM) popped a warning due to 1Fh found in the Seconds field of the directory. We also found several programs with a value >60 (ie 62) in the same location. All but one turned out to be harmless, we are still looking at the one. +-------------------------------------------------+----------------------+ |Dennis M. Flanders | | |AT&T Mail: !DFLANDERS | If at first you | |MCI Mail: DFLANDERS | don't succeed get | |INTERNET: flanders@grebyn.com | a bigger hammer! | |CompuServe: 73507,1771 | | +-------------------------------------------------+----------------------+ ------------------------------ Date: Tue, 24 Oct 89 14:56:02 -0400 From: rjs@moss.ATT.COM (Robert Snyder) Subject: Re: 0 bytes in 1 hidden file, virus? (PC) In volume 2 issue 217 of the virus list, Tasos notes that CHKDSK report "0 bytes in 1 hidden files" and wonders if he has a virus. This seems to come up fairly often when new people join the list so maybe an automatic answer is needed. In any case, Tasos probably ran CHKDSK on a disk with a volume label as that will exhibit his symptoms. I.e. it's not likely that Tasos has a virus. Robert Snyder {att|clyde}!moss!rjs rjs@moss.ATT.COM (201) 386-4467 The above statements are my own thoughts and observations and are not intended to represent my employer's position on the subject(s). ------------------------------ Date: 25 Oct 89 03:02:34 +0000 From: jap2_ss@uhura.cc.rochester.edu (The Mad Mathematician) Subject: The not-so-new virus (Mac) I am the one who first posted about the possibly new virus. I will give all the information I have here. I believe I hae finally gotten some infected software. There was a great deal of confusion at first as what exactly was happening. I was a consultant once, and as such am called upon to assist the present consultants with tasks they are new at. We had been having a problem with disks crashing at an alarming rate, all showing identical symptoms. They are these: The Chooser becomes unable to find any printer resources. The System and most system software gets writeen to, in an as yet unknown manner. Their sizes may or may not change. Other applications are written to, and documents created with them become unreadable. The Desktop gets damaged, causing the message "This disk needs minor repairs. Do you want to fix it?" to come up on bootup. By this stage the only recourse is to copy documents off with something like Deskzap and reformat the disk, replacing all the software. If the disk is repaired, it actually may seem that way, but ususally is ruined, even to the point of unusability. No virus detection programs identify a virus, except perhaps SAM Anti Virus Clinic, and even that doesn't always work. It _may_ be a NVIR variant that is self-modifying, but it does not create the nVIR resource. It does go through Vaccine, but Gatekeeper stops it cold. The reported STR 801 resource was an error by me. Please ignore this. There appeared to be a second virus also running around for a while. The sysmptoms were: Macwrite had its name changed to Macwite or Macwight. The ICN resource for the application was changed to show Macwite instead of the parallel lines. That's all we could find. We have found no other examples since the first three or four disks. I am of the opinion that someone modified one copy using something like Resedit, then shared it. That is all the information I can recall at this time. As I said, I believe I have found an infected disk, and will be sending copies of an infected application at the earliest opportunity, hopefully tommorrow. Thank you for your patience. Joseph Poutre (The Mad Mathematician) jap2_ss@uhura.cc.rochester.edu Understand the power of a single action. (R.E.M.) ------------------------------ Date: Tue, 24 Oct 89 23:28:15 -0400 From: dmg@lid.mitre.org (David Gursky) Subject: Re: VIRUSCAN test (IBM PC) In VIRUS-L Digest V2 #221, Charles Preston wrote a rather long message about virus scanners vs. more automated virus detection applications. I would like to point out to him that although there are some excellent scanning applications on the market, for Macs, PCs, etc., I prefer recommending that users do not rely on scanners simply because you must remember to periodically scan the disk. My experience has been that users simple do not remember to do this, hence a strategy that relied solely on a scanner application would not be a strong defense against electronic vandalism. David Gursky Member of the Technical Staff Special Projects Department, W-143 The MITRE Corporation ------------------------------ Date: Tue, 24 Oct 89 23:48:11 -0500 From: shaynes@lynx.northeastern.edu Subject: Jerusalem Virus Version B detected (PC) After running Scan 1.1V45 on my hard drive I detected the Jerusalem Virus Version B on one of my files. The file that I detected the virus on had not appeared in earlier runs of Scan. The infected file is UNVIRUS.EXE. The archive I got it out of was UNVIRUS.ARC. I downloaded this file from the SIMTEL20 PD archives. I immediately deleted the file. I have never had a reason to the program (and I would think that running the program on itself would have adverse affects). [Ed. Could someone at SIMTEL20 please check into this and confirm or deny it? Thanks!] +-----------------------------------------------------------------------------+ | PA_HAYNES@VAXE.COE.NORTHEASTERN.EDU | Sean A. Haynes |Student Northeastern | | SHAYNES@LYNX.NORTHEASTERN.EDU | 46 Udine St. |University, Boston | | PA_HAYNES@NUHUB.BITNET | Arlington, MA |MA 02115 | | | (617) 648-8390 |(617) 437-5422 | +-----------------------------------------------------------------------------+ ----------------------------- End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253