VIRUS-L Digest Monday, 26 Feb 1990 Volume 3 : Issue 49 Today's Topics: Request for anti-virus sw (Mac) NYT Bestseller! Virus signatures & IBM virus scanner (PC) Book - Computer Virus Handbook Scan 3.0V58 uploaded (PC) Re: anti-virus procedures (Mac) The 1554 (NOT 1559!) virus (PC) $1000 for breaking this Manipulation Detection Code (MDC) Viruses and Copyrights Virus Conference Info How the 1554 virus recognizes infected files (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. Please sign submissions with your real name. 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@SEI.CMU.EDU. Ken van Wyk --------------------------------------------------------------------------- Date: Fri, 23 Feb 90 02:49:36 +0000 From: craig@sli.com (Craig Woods) Subject: Request for anti-virus sw (Mac) Situation: Our site has WDEF (I think): our Mac is virtually useless - font's are messed up, the machine crashes regularly when {leaving applications | copying files | using scrapbook}, and the printer and modem regularly disconnect from Fleetwood (the Mac). We do not have ResEdit or other tools to analyze the System/desktop file/resources so we have no way of knowing whether this is WDEF or not. (I sure hope this IS WDEF, otherwise our system is REALLY messed up :-) I've seen some questions/references to re-building the desktop as a way of (temporarily?) combating the virus, but this has no effect on the Mac's reliability. We have sent for a Virex upgrade to combat the virus; Unfortunately, we sent for it via U.S. Snail mail, so it may take weeks to get here. As an emergency shortcut, I am submitting the following... Plea: 1) Are the products Gatekeeper 1.1.1, Gatekeeper Aid 1.0.1, Disinfectant 1.6 public domain software? 2) If so, would someone please mail them to me? (We are not on the Internet, so I can't FTP from anywhere (can I?)) 3) If someone does mail this software, could you include some instructions for unpacking software from the Net? Our UUguru recently left the company, so no-one here knows anything about unpack, unshar, unhex, and all those other un-holy sciences. This task is complicated by the fact that the mail will be received on a Vax, FTP'ed to a Sun, and converted to Mac format via TOPS. I am hoping to be able to get the Mac up over the weekend so that we can publish our software manual next week. Mail explaining the impossibility of any of the above steps will be appreciated, if anyone can stop laughing long enough to reply (You want to do WHAT!?!?). :-) Many thanks in advance. Craig Woods Systems Manager Software Leverage,Inc. ...uunet!sli!craig craig%sli@uunet.uu.net ------------------------------ Date: Thu, 22 Feb 90 15:01:31 -0500 From: cliff@cfa253.harvard.edu (Cliff Stoll) Subject: NYT Bestseller! Greetings to the Virus-L gang... The Cuckoo's Egg has made it onto the NY Times bestseller list. I'm amazed that so many people would be interested in our computer networks, viruses, and nasty animals in our systems. Many people on Virus-L directly helped with the book - each of you knows who you are. At least as important: throughout writing it, I read Virus-L to keep up to date. And so, to all who have contributed to this lively forum, my thanks to you for spreading the good word. Especially, thanks to Ken van Wyk, who's put long hours into creating a fast moving, well moderated conference. -- Cliff Stoll Cliff@cfa.harvard.edu ------------------------------ Date: Fri, 23 Feb 90 10:51:11 -0500 From: Kevin_Haney@NIHDCRT.BITNET Subject: Virus signatures & IBM virus scanner (PC) With regard to Gerry Santoro's question about the IBM virus scanning program, the author, Bill Arnold, is constantly updating the program, improving its performance and including new viral signatures. The current version is 1.37 which scans for 58 different signatures and I assume that if you have an older one you can get an update from IBM. There is a facility in the program that gives you the ability to add new viruses to be scanned for by constructing a text file (ADDENDA.LST) containing the signatures of new viruses. However, I do not know of any central place where these signatures can be obtained. While it is a valid concern that posting signatures may cause virus authors to change them to create undetectable mutant viruses, I think this is offset by the need to be able to update a scanning program rapidly when a new virus is found. (It is also possible to choose signatures that cannot be changed without rewriting the whole virus program.) Is there in fact a publicly accessible system where new virus signatures can be found? If not, it seems that this digest would be a good place to post such signatures as long as they come form a reputable and verifiable source. What do others think? [Ed. There are a few problems with posting virus signatures. First, many developers choose, and indeed prefer, to use in-house developed signatures. Second, some viruses cannot be detected by "traditional" signature scans. There are more problems, I'm sure. Still, I'm not at all opposed to people posting virus signatures, just as long as everyone realizes the limitations of these signatures.] _________________________________________________________ | | | Kevin Haney, Computer Specialist | | Division of Computer Research and Technology | | National Institutes of Health | | BITNET - Kevin_Haney@NIHDCRT.BITNET | |_________________________________________________________| ------------------------------ Date: Fri, 23 Feb 90 11:55:45 -0500 From: hoffman@seas.gwu.edu (lance hoffman) Subject: Book - Computer Virus Handbook I just obtained COMPUTER VIRUS HANDBOOK, by Harold Highland, published by Elsevier Advanced Technology, Mayfield House, 256 Banbury Road, Oxford OX2 7DH, United Kingdom. It has approximately 370 pages (8 1/2 x 11) of material in a hard binding, ISBN 0-946395-46-2. It boasts a foreword by Bill Caelli, Director of the Information Security Research Center, Queensland University of Technoloby, Brisbane, Queensland, Australia, and ten chapters: 1. Basic Definitions and Other Fundamentals 2. The Application of Epidemiology to Computer Viruses (by William H. Murray) 3. A History of Computer Viruses Introduction The Famous Trio (Brain, Lehigh, Israeli) Another Trio (Alameda, Ping Pong, Marijuana) Three Special Viruses (Macro, Vienna, Batch) Other Known and Reported Viruses (Datacrime, Icelandic, Autumn Leaves, Fu Manchu, Traceback, others) 4. Reports from the Virus Hunters U. of Delaware and the Pakistani Computer Virus (by Anne E. Webster) Lehigh Virus (by Ken van Wyk) Israel PC Virus (by Yisrael Radai) 5. Evaluation Protocol and Test Methodology Virus Test Centers, Evaluation Sites, Anti-virus products ... 6. Testing an Anti-Virus Product (by Jon David) 7. Product Evaluations (includes reports on Antidote, Data Physician, Disk Defender, Disk Watcher, Dr. Panda Utilities, Flu Shot +, Immunize, Mace Vaccine, Ntivirus, Softsafe, Vaccinate, Vaccine [Certus], Vaccine (Sophos Ltd.), Vaccine (Worldwide Software), VirAlarm 2000 PC, Virus-Free, Virusafe, Vir-X, V*Screen, XFICheck) [addresses of manufactures are in back of book] 8. Viruses - A Management Issue (by Harry B. de Maio) 9. Procedures to Reduce the Computer Virus Threat 10. Conceptual Foundations of Computer Viruses includes five reprinted papers from Computers & Security Quite a bit of the material has appeared before in Computers & Security (the journal published by Elsevier) but a good deal is new. Especially interesting are the test results of anti-viral products. Lance J. Hoffman The George Washington University ------------------------------ Date: Fri, 23 Feb 90 12:15:08 -0600 From: James Ford Subject: Scan 3.0V58 uploaded (PC) Sorry, the files were: SCANV58.ZIP - SCAN 3.0V58 (not 1.4V58) SCANRS58.ZIP - SCAN 3.0V58 (not 1.4V58) (tsr) Sorry for any inconvience the error may have caused. - ---------- James Ford - JFORD1@UA1VM.BITNET, JFORD@MIBSRV.MIB.ENG.UA.EDU ------------------------------ Date: Fri, 23 Feb 90 11:47:00 -0800 From: SAM@POMONA.CLAREMONT.EDU Subject: Re: anti-virus procedures (Mac) We are currently investigating possible proposals for PREVENTING virus infections in our Mac/PC labs. If anyone has a procedure they are using or have seen (including necessary hard/software), I would appreciate a brief description of policies as well as procedures. I am working with a colleague on this and if you could send any replies to me directly and CC: my colleague (JKNOWLES@POMONA.CLAREMONT.EDU) we would be forever grateful... Thanks. Sam Cropsey, Microsystems Manager Pomona College Internet: SAM@POMONA.CLAREMONT.EDU Bitnet: SAM@POMONA ------------------------------ Date: 23 Feb 90 20:53:00 +0700 From: T762102@DM0LRZ01.BITNET Subject: The 1554 (NOT 1559!) virus (PC) Gonzalo M. Rojas Costa writes: > This virus only copies itself to the address 9800h:0000. It don't >installs resident with INT 27 or the function 31H. If I execute a big >program (that ocupies the segment 9800h), this program erase the virus >from memory and a crash will occurr. Sorry, this is a misunderstanding, due to my poor English. What I did mean was not that the virus is a TSR program, but that once you run an infected application, it will stay in memory permanently (until the next reboot, of course :-) ). I call such a virus memory resident, since it's resident in the memory all the time. What I do *not* call a memory resident virus is a virus which gets its code executed only when one executes an infected application. >For that reason I don't find appropriate the name 1559 for this >virus. Besides, the size of the virus is 1554 bytes. Then I don't >find the reason for that name. Agreed. So let's call it the 1554 virus. (John McAfee?) >The 32 bytes overwritten can be found at offset (14,15)*16+1271 on >the infected program that I disassembled. (It seems that the offset >where the bytes overwritten are located is (14,15)*16+number, and >number depends of the size of the program being infected). Nope. The number is hard coded in the virus body. Here is the relevant portion of the code: org xxx push ds push cs pop ds lea si,[4F7h] mov di,100h mov cx,20h rep movsb This code restores the original bytes into their place. It is executed just after the virus has performed a jump at cs+[0Eh]:0. Therefore the full address of xxx is (cs+[0Eh])*10h. The instruction lea si,[4F7h] actually loads SI with the number 4F7h (1271 decimal). rep movsb moves 20h (32 decimal) bytes from DS:SI to ES:DI. And we have DS == CS (push cs; pop ds). Therefore, the bytes are got from (full address) (CS+[0Eh])*10h+4F7h. To eliminate the value of the CS register, just remember that the file was loaded at address CS:100h (i.e., the full address is CS*10h+100h). I speak here only for the .COM files. Now, if we subtract the two values, we'll get (CS+[0Eh])*10h+4F7h-CS*10h+100h = [0Eh]*10h+3F7h from the beginning of the file. And 3F7h is just 1015 decimal --- the number I stated in my previous posting. I repeat, this is true only for the .COM files. BTW, has someone of the other antivirus researchers produced a program which is able to disinfect the files from this virus? And even to restore their original size? I spoke with David Chess and he told me that he prefers the "delete the infected file and restore them from backups" method. But have in mind, that guy from Taiwan (was he from there?) is in trouble --- and may not have the appropriate backups. (We all miss them just when we need them :-).) Vesselin ------------------------------ Date: Fri, 23 Feb 90 15:28:00 -0600 From: Pete Klammer 303/556-3915 Subject: $1000 for breaking this Manipulation Detection Code (MDC) [Ed. From the CERT-Tools mailing list.] "Re-posting of this announcement to appropriate groups is encouraged." >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: smb@ulysses.att.com Subject: Snefru algorithm for checksumming Date: Wed, 21 Feb 90 13:39:59 EST A few days ago, I wrote a message suggesting that CRCs were inappropriate for security uses, and that Snefru or MD4 might be better. Several people wrote back asking where they could obtain them. Ralph Merkle -- the author of Snefru -- has posted the following note; as per the permissions at the end of the note, I am resending it to this list. --Steve Bellovin smb@ulysses.att.com - ------- Forwarded Message Date: Tue, 20 Feb 90 14:06:50 PST From: Ralph Merkle Subject: $1,000 reward for breaking Snefru 2.0 The following was posted to sci.crypt: - - -------------------------------------- The one-way hash function, Snefru 2.0, is available by anonymous FTP from arisia.xerox.com in directory /pub/hash. It is available for use by anyone interested. A $1,000 reward is offered to the first person to break it. General: Snefru 2.0 is a one-way hash function. One-way hash functions have also been called manipulation detection codes (MDC's), message digests, cryptographically secure checksums, cryptographically secure hash totals, and sometimes fingerprints. One way hash functions do not involve use of a secret key or any secret information. They are used to authenticate information, and to verify that the information has not been tampered with. One-way hash functions have the following properties: 1.) Given any input of any size (a file, for example) it is easy to compute the output of the one-way hash function. If the one-way hash function is designated H, then output = H(input) is easy to compute (takes time linear in the size of the input). 2.) Although the input might be very large, the output is relatively small and of fixed size. In Snefru 2.0, the output can be either 128 or 256 bits (selectable by the user). 3.) It is computationally infeasible to find two inputs x and x' that produce the same output. That is, finding x and x' such that: H(x) = H(x') is infeasible. Finding such a pair of inputs is known as "cracking" or "breaking" the one-way hash function. 4.) Given an output, it is computationally infeasible to find an input that produces that output. (This property is not always used). One-way hash functions are not the same as Message Authentication Codes, or MAC's, which involve the use of a secret key. History of Snefru: Snefru version 1.0 was designed and made public over a year ago. No significant security flaws were found then or since in Snefru 1.0, but several improvements were suggested. Most significantly, the tables used in Snefru 1.0 were not generated in a publicly verifiable fashion. Snefru version 2.0 uses a set of tables generated from publicly known random information: "A Million Random Digits with 100,000 Normal Deviates" by the RAND Corporation, published by the Free Press in 1955. In addition, the algorithm used to derive the tables is also publicly known (and available for anonymous FTP along with Snefru 2.0). During the redesign, the basic algorithm was made simpler and some features of modest utility which increased the complexity of the design were eliminated. The revisions for Snefru 2.0 were completed in July. The C source for Snefru 2.0 was made available by anonymous FTP in November of 1989. Security of Snefru: The security of one-way hash functions can (at present) only be assessed by making them widely available for review and attack. At the present time, Snefru has undergone some internal review at Xerox and has been subjected to two separate and independent reviews by two outside consultants hired for the purpose. No security problems have been uncovered. During the past decade, however, many one-way hash functions have been proposed and then broken. The security of any particular one-way hash function should therefore be viewed with caution. And, of course, Xerox Corporation makes no representations concerning either the merchantability of Snefru or the suitability of Snefru for any particular purpose. It is provided "as is" without express or implied warranty of any kind. Various groups not connected with Xerox have begun to examine the security of Snefru since it was made publicly available. It will probably be a while before these groups develop an opinion about its security. To encourage examination of Snefru, a reward of $1,000 is offered to the first person who shows they have broken it. A "break" is defined as providing two different inputs that produce the same output. The output size will be 128 bits, and the "security level" parameter will be set at 2 (these are the default settings). (Note that a more secure setting for the security level parameter (4) and a larger output size (256 bits) are available in Snefru 2.0 as options). Fine print: Xerox employees cannot enter. The winner must send his name, address, and social security number (if available) along with the inputs x and x' that produce the same output. It is expected that other relevant information (the nature of the algorithm used, the hardware, etc) will also be sent, though this is not required. Any taxes are the responsibility of the winner. We reserve the right to decide ties (multiple entries on or about the same date) and our decision will be final. Implementations: Snefru 2.0 is a C version. Snefru 2.1 is identical algorithmically, but is partially implemented in assembly language to improve performance. The two implementations produce the same result, which increases the belief that both are correct. Snefru 2.1 is now also available for anonymous FTP. The assembly language version hashes slightly over 8 megabits per second (slightly over 1 megabyte per second) on a SUN SPARC station 1 when I/O time is not included (the actual execution time of the hash algorithm by itself is measured). The same version hashes at slightly over 6 megabits per second when the I/O time is included. The C version of Snefru 2.1 hashes at 4 megabits per second (including I/O time). Free Availability: Anyone who wishes to use Snefru can do so without charge. The following notices appear in the source, and are the only restrictions on the use of Snefru: Copyright (c) Xerox Corporation 1989. All rights reserved. License to copy and use this software is granted provided that it is identified as the "Xerox Secure Hash Function" in all material mentioning or referencing this software or this hash function. License is also granted to make and use derivative works provided that such works are identified as "derived from the Xerox Secure Hash Function" in all material mentioning or referencing the derived work. Xerox Corporation makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind. Re-posting of this announcement to appropriate groups is encouraged. Ralph C. Merkle merkle@xerox.com Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304 - ------- End of Forwarded Message **CERT-Tools Information:**************************************************** * Submissions : cert-tools@cert.sei.cmu.edu * * Address additions/deletions/changes : cert-tools-request@cert.sei.cmu.edu * * Moderator : tools@cert.sei.cmu.edu * ***************************************************************************** >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /** --poko " I'm half Estonian, which makes up for the other half. " Pete Klammer /(303)556-3915 FAX:(303)556-4822 PKLAMMER@PIKES.COLORADO.EDU CU-Denver Computing Services / Campus Box 169 BITNET: PKLAMMER@CUDENVER 1200 Larimer St NC2506 / Denver CO 80204-5300 UU:!boulder!pikes!pklammer **/ ------------------------------ Date: Fri, 23 Feb 90 21:40:50 -0500 From: davidbrierley@lynx.northeastern.edu Subject: Viruses and Copyrights [Ed. A number (!) of people sent in other contributions to the ongoing discussion debating whether or not the AIDS Trojan was a copy protection scheme. While each and every one of these raised valid concerns, in the interest of reducing net volume, I've not included them all in this digest (bulk posting for you Usenet readers...). If anyone feels strongly against this, just let me know. I'll gladly continue posting related messages if it is felt that there are further points to be raised.] I have read (and heartily recommend) the third edition of _How to Copyright Software_ by attorney M.J. Salone and would like to post a few points from it: 1) The United States is a member of the Berne Convention as of March 1, 1989; which means that works published on or after that date do not need a copyight notice (Copyright 1990 John Doe) in order to be entitled to copyright protection. A notice is required to be included in works published before that date or else they will lose protection unless: a) Only a relatively small number of copies of the work exist without the notice. This, of course, will not be the case with viruses since they are designed specifically to replicate themselves. OR b) The copyright is registered with a copyright office within five years of publication AND the notice is included in copies that are not yet in the hands of the public. A virus author isn't likely to register, even if a pseudonym is listed in the copyright notice, since the author's real name is needed in order to actually sue in court for damages. Admitting in court that he/she wrote a virus and waiving a copy of the registration around will be all the evidence needed to convict the author of breaking the law. (Since the confession was made during a civil suit filed by the author I don't think "self-incrimination" regulations would protect the author.) OR c) The author licensed or authorized another party to handle the work and the notice was not included due to the negligence of that party, unless the author did not specifically require the party to include the copyright notice. This probably wouldn't apply to virus writers since other parties could later become witnesses against the author. Most virus writers get pleasure of creating a virus on their own. Because of the length involved I will break up my contribution into a few smaller postings. Next time I'll mention how derivative works come into play; this relates to cases where a person copyrights a disassembly of a virus written by someone else. DISCLAIMER: The above interpretations are mine - I'm not a lawyer! Please do not take this posting to be complete truth! ------------------------------ Date: Fri, 23 Feb 90 21:07:00 -0500 From: David@DOCKMASTER.NCSC.MIL Subject: Virus Conference Info Verified lack of info at 800 number, reported same to conference sponsor, was told that as of next Monday (2/26) full info would be available to callers, and those with FAX numbers could get immediate detailed hard copy. (Those of us still relying on mail for hard copy would immediately be sent appropriate materials, complete with many pictures!!!) The sessions are $275 for one day, $375 for both. Two decent hotels will be providing rooms at $89 per nigtht, but there are no special airline setups. (I got this info when they returned my call.) Sessions go for the full day both days. I'm too feeble to type in a full list of speakers, so call the 800 number (800/835-2246) if you want additional info. (If you want to sign up, they take MC/VISA/AMEX.) The 800 number is provided by some 800 general service - I expect that the conference will be run much more professionally. Jon David ------------------------------ Date: 25 Feb 90 19:37:00 +0700 From: T762102@DM0LRZ01.BITNET Subject: How the 1554 virus recognizes infected files (PC) Hi! Since this was not mentioned yet (I hope, I receive the digests with some delay), I would like to point out how the 1554 virus recognizes which files are infected by him. For .COM files: If the contents of the word at offset 02 in the file is 12Eh, then the file is infected. This means that the contents of the bytes at offset 02 and 03 are 2Eh and 01h respectively. Offsets are counted from 0, i.e. the first byte of the file is at offset 0. For .EXE files: If the contents of the word at offset 02 in the file is equal to the negated contents of the word at offset 12h, then the file is infected. Unfortunately, this does not give us a method for file vaccination, since the contents of the bytes mentioned above is used. For .COM files, the byte at offset 02 is usually (not always!) the third byte of a JMP instruction. For .EXE files the situation is easier --- the word at offset 12h contains the so-called checksum, which is never used and can be modified. Vesselin Bontchev ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253