VIRUS-L Digest Wednesday, 18 Apr 1990 Volume 3 : Issue 77 Today's Topics: Computer Security/Virus Conference Announcement Re: WDEF A on Chessmaster 2100 and Cribgin (Mac) MACs for programs New files on MIBSRV (PC) HELP!!! Twelve tricks trojan popped up! (PC) PCs v. Mainframes Re: Jerusalem-B (PC) Mainframe virus activity Hardware protection and the spread of viruses (PC) Jerusalem B Virus found at Rutgers U (PC) Detecting "smart" viruses 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 yourreal nme. Send contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to LEHIIBM1.BITNET for 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: Mon, 16 Apr 90 08:25:22 -0500 From: tar@ksuvax1.cis.ksu.edu (Tim Ramsey) Subject: Computer Security/Virus Conference Announcement [ I'm posting this for a faculty member. Please direct all questions and comments to the address given below. ] Nobol Computer Servicers, Inc. is presenting a seminar on Computer and Information Security to be held at the Embassy Suites hotel at the Kansas City International Airport, Kansas City, Missouri July 11-13. The topics to be covered by experts from business, industry, government and academia are: database security, network security, data center security, risk management, contingency planning, EDP auditing, computer crime, malicious code (viruses, trojan horses, worms, etc.) and the security and integrity of data. The seminar sessions will be grouped into three tracks each day and participants are free to move from track to track. Panel sessions will occupy the third day; discussion time will be allotted in those sessions for attendees to raise questions requiring indepth answers. Seminar speakers include Jay Bloombecker, Director of the National Center for Computer Crime Data; Clay Hodson, Supervising investigator for the Economic Crime Unit in Riverside California; Ed Devlin, Executive Vice President of Harris, Devlin and Associates, consultants in disaster recovery and business resumption planning; Carol Brown, Vice President of Winthrop, Brown and Co., a former systems programming manager and author of books for senior management on computing; and Computer Associates will discuss security in the DB2 system. For more information contact: Nobol Computer Services, Inc. Attn: David Spore 414 NW 66th Terrace #204 Kansas City, MO 64118 ------------------------------ Date: Mon, 16 Apr 90 17:44:47 +0000 From: sukes@eng.umd.edu (Tasuki Hirata) Subject: Re: WDEF A on Chessmaster 2100 and Cribgin (Mac) jim@rand.org writes: >VIRUS-L V3 #72 (9 Apr) contained an unconfirmed report that Chessmaster >2100 (Macintosh version) from the Software Toolworks was infected with >WDEF A. The Toolworks was looking into it. > >I contacted them Tuesday, and they have confirmed that WDEF A was on >their master disks for both Chessmaster 2100 and another game program >called Cribgin, both for the Mac. They have started a recall on both >products, and expect to be able to ship replacements starting this Friday. > > Jim Gillogly > jim@rand.org To those of you that complain about the virus will recieve a complementary copy of Virex..... - -- / Tasuki Hirata (sukes@eng.umd.edu) | Intel 80386: / / UUCP: uunet!eng.umd.edu!sukes | Power Tool for the Power Fool / ------------------------------ Date: 16 Apr 90 11:03:39 -0400 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: MACs for programs >From V3 #76 (Bill Murray) >The real value is in an author not being held accountable for >something he did not write..... Authors, the use of a MAC serves >you even if no one ever reconciles it. It is cheap. You have a >choice of functions, security, and costs. The choice is yours. >Pick one, but do something. Use several; they are cheap. AMEN! I couldn't have said it better myself. Not that this is the ONLY good reason to use a sophisticated authentication algorithm, but it is one MORE good reason. Please add to the list of available algorithms ANSI X9.9 and ISO 8731-2. What may not be obvious is that the best of these MAC algorithms allow the author of a program to publish the selected algorithm, the signature of his program, AND the cryptographic key used to generate that signature. - -Bob Bosen- Enigma Logic Inc. INTERNET: 71435.1777@COMPUSERVE.COM ------------------------------ Date: Mon, 16 Apr 90 12:24:33 -0500 From: James Ford Subject: New files on MIBSRV (PC) I have found 2 files which I have placed on MIBSRV. These files are DEZIPINC.ZIP and UNZIP20.ZIP. They unZIP files and have the source (in C) included. Hopefully, someone can use them as a jumping-off platform for developing a CMS, VMS, UNIX (etc.) generic unZIPper. If someone takes the plunge (or challenge), I would appreciate a copy of their program, either by Email or FTPing to pub/ibm-antivirus/00uploads. If other OS versions of unZIP are available now, I would like to know where I can get a copy. If you don't have a PC, then let me know and I'll mail the C source to you directly. At MIBSRV.MIB.ENG.UA.EDU (130.160.20.80), located in pub/ibm-antivirus - ---------------------------- DEZIPINC.ZIP - 27619 bytes UNZIP20.ZIP - 46138 bytes - ---------- Buy in haste, repair at leisure. - ---------- James Ford - JFORD1@UA1VM.BITNET, JFORD@MIBSRV.MIB.ENG.UA.EDU THE University of Alabama (in Tuscaloosa, Alabama USA) ------------------------------ Date: Tue, 17 Apr 90 09:04:00 +0700 From: Jeroen Houtzager Subject: HELP!!! Twelve tricks trojan popped up! (PC) Hello, A friend discovered the "Twelve Tricks Trojan" on his 386 machine. What can he do to get rid of this thing? He knows which floppy imported it and he has a backup. But the damn thing seems to hide everywhere!!! Questions: - Does the TTT hide in CMOS RAM? - Does the TTT hide in EMS RAM? - Does the TTT infect OS/2 programs? - How can infected files be repaired? Please reply as quick as possible. My friend doesn't dare to use his machine and he has to do some project on it... Thanks in advance for the info!!! Jeroen ------------------------------ Date: Mon, 16 Apr 90 17:10:00 -0400 From: WHMurray@DOCKMASTER.NCSC.MIL Subject: PCs v. Mainframes >I think the reasons that we have seen microcomputer viruses, but no >large-system viruses are primarily "cultural" (writing viruses hasn't >become "the thing to do" in the mainframe underground, there simply >aren't as many mainframe programmers, large installations don't tend >to exchange software yet, and so on). I would like to think that Dave is right and that mainframes are simply more orderly. In fact, I think that they are simply less populous. Depending in part upon the latency and speed of propagation, viruses require large populations for success (being defined as the ability to continue to live and propogate). Think of a population of one, or even a hundred. Everyone gets sick, becomes immune, or dies. Herpes Simplex (chicken pox) will die of its own weight in populations of less than a hundred thousand. In larger populations the population refreshes itself at a rate sufficient to give the Herpes new places (children) to infect. > .................................., large installations don't tend >to exchange software yet, and so on). seems to suggest that software is the vector. That is, that it is the intent to share software that is causing the spread and success of the PC viruses. I do not believe that either. While this may contribute a a little, it is really the sharing of MACHINES that is causing the majority of the spread. Neither software nor media are being shared in a way that would cause this problem, but machines are. That is why the problem is so much more obvious in labs, centers, and retail outlets. People are downloading software, and that is risky behavior, but it is not accounting for much of the spread. There is even a little sharing of diskettes, but most people keep their own. While most machines are dedicated to a user and not being shared, a large number are being shared and they are at the nexus of the problem. Large installations do share software. They even have bulletin boards. They move data and programs back and forth. What they do not do is take ipl media from one system to another. They are also pretty good about managing "write protect" rings. We need to stop sharing PCs in such a way that nobody is primarily responsible for their content (the machine's). We must stop inserting our media in strange machines, and then taking it to other machines. When we must engage in these risky practices, we must employ write protection. If mainframe populations were as large as PC populations, and if we moved the media in a similar manner, then we might see the same problems there as we do in PCs. William Hugh Murray, Executive Consultant, Information System Security 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 203 966 4769, WHMurray at DOCKMASTER.NCSC.MIL ------------------------------ Date: Tue, 17 Apr 90 13:19:54 +0000 From: frisk@rhi.hi.is (Fridrik Skulason) Subject: Re: Jerusalem-B (PC) inesc!ajr@relay.EU.net (Julio Raposo) writes: > I have made last year a program to clean the Jerusalem-B virus from > the infected files without damaging them. Just one problem - it is not always possible to detect if the program has been damaged beyond repair by the virus. This may happen if the information on the length of the file which is stored in the header is incorrect. If it is more than 1808 bytes too low, the corruption can be detected, but the file should be restored from a backup. If it is incorrect, but by less than 1808 bytes, the corruption can not be detected. So be careful, when repairing Jerusalem-infected files - you cannot be sure they are restored to their original condition. This situation is very rare, however - I only know of two examples, one small utility and WordPerfect 4.x - -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 | ------------------------------ Date: Tue, 17 Apr 90 16:07:33 -0400 From: Arthur Gutowski Subject: Mainframe virus activity Dave Chess writes: >I think the reasons that we have seen microcomputer viruses, but no >large-system viruses are primarily "cultural" (writing viruses hasn't >become "the thing to do" in the mainframe underground, there simply >aren't as many mainframe programmers, large installations don't tend >to exchange software yet, and so on). I don't think this is entirely what's stopping people from taking an interest in mainframe virus writing. True, there aren't as many mainframe programmers, and true large installations don't trade software (this is mainly due to most mainframe software being *licensed, commercial* products--trading is against the rules; and even most in-house development becomes property of the installation). But even if there was a fair amount of trading going on and there were more people in the business... Writing mainframe viruses is not as simplistic a task is it is for the micro environment. Mainframe OS (such as MVS, VM, *nix, VMS) are extremely complex--they have been under development for more than 20 years. The knowledge required to program a virus into a system such as this would be equivalent to the qualifications needed for a System Programmer. Not to mention security systems (such as ACF2 or RACF for VM or MVS). To be able to romp over someone's programs would require that you either had write access to his libraries via rules or could program around the security system. And this still doesn't mean that you'll be able to cover your tracks. At least in MVS there are records kept of when files are opened, written to, etc. The possibility of getting caught far outweighs the novelty or bragging rights, I think. Trojans, however, are a different story. Unfortunately, exploitation of mail systems (the CHRISTMA EXEC is a prime example), and other system anomolies is a little easier to accomplish. I have the misfortune (and according reputation) for inadvertantly releasing a bomb on MVS simply (or so I thought) by making a copy of the system catalogs. It took two weeks to clean up the mess. Getting something like this to propogate and act like a virus is another thing. I don't think viruses are as much cultural as they are limited by the complexity of the system(s) involved. Disclaimer: These are only opinions. As such, they are subject to change. Any replies and further discussion is appreciated. /=====\ Arthur J. Gutowski, System Programmer : o o : MVS and Antiviral Group / Tech Support / WSU Univ. Computing Center : : 5925 Woodward; Detroit MI 48202; PH#: (313) 577-0718 : ----- : Bitnet: AGUTOWS@WAYNEST1 Internet: AGUTOWS@WAYNEST1.BITNET \=====/ Have a day. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Disclaimer: I think, therefore I am...(I think). ------------------------------ Date: Tue, 17 Apr 90 16:39:52 -0400 From: Arthur Gutowski Subject: Hardware protection and the spread of viruses (PC) With all the discussion of this going around lately, I had a thought. Doesn't the Amiga use EPROMs for its operating system? I'm told that under this type of system, when you order and receive a new version of the operating system, you flip the write-enable switch on for the EPROM, install the new operating system into the EPROM, flip the enable switch off, reboot, and you're off. Now I know this is an expensive adventure, but couldn't something like this be applied to PCs? Granted, it wouldn't eliminate viruses. As has been discussed, as long as there is an application development area and software trading, the possibility for viruses exist. But wouldn't this eliminate an entire class of viruses (namely boot-sector and partition-table infectors)? With the entire OS in ROM, there is no longer a need for executable code in the partition/boot record--it becomes merely a media/layout descriptor. This of course all operates under the assumption that you never receive an infected OS. Just a thought, Art ------------------------------ Date: Wed, 18 Apr 90 00:11:33 -0400 From: msmith@TOPAZ.RUTGERS.EDU Subject: Jerusalem B Virus found at Rutgers U (PC) This evening I found the Jerusalem B Virus on a friend's machine (read: not computing center). I think I got rid of it. The procedure I used was: 1) boot from clean floppy 2) run scanv39 (the newest I had - getting a newer one now) on it and write down the filenames infected. 3) delete all infected files and replace from backups after verifying that the backup is clean 4) re-run scanv39, if not clean repeat 2 and 3. Is that sufficient? We know where it came from, so we're contacting that person to let him know he's infected. Mark ------------------------------ Date: 18 Apr 90 10:16:00 +0000 From: sverrehu@ifi.uio.no (Sverre Holmsen Huseby) Subject: Detecting "smart" viruses About the viruses that desinfects (program-)files when they are opened, and reinfects them when they are closed: Would it be possible for a checksum-program to detect this by recording the time taken to check the file? I assume the des-/re-infection takes a couple of timer ticks! Sverre H. Huseby (sverrehu@ifi.uio.no) Student - University of Oslo, Norway ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253