VIRUS-L Digest Thursday, 27 Apr 1989 Volume 2 : Issue 101 Today's Topics: Forwarded Message From Jim Goodwin re: various VIRUS-L comments BRAIN infection (PC) More Using Checkfunctions For Virus Detection (General Interest) re: Yale and 1701/1704 virus, and Sentry (PC) re: Checkfunctions For Virus Detection (General Interest) --------------------------------------------------------------------------- Date: Thu 27 Apr 1989 06:00 CDT From: GREENY Subject: Forwarded Message From Jim Goodwin re: various VIRUS-L comments The following is a message that I am forwarding for Jim Goodwin on the HomeBase Virus BBS. Bye for now but not for long Greeny BITNET: MISS026@ECNCDC Internet: MISS026%ECNCDC.BITNET@CUNYVM.CUNY.EDU ------------------------- Message Test to Follow ------------------------- 04/25/89 08:26:59 (Read 18 Times) From: JIM GOODWIN Last weeks Virus-L messages brought up a number of good points and questions. I hope the following clarifies some of the issues: To David Chess: Mr. McAfee is correct when he states the POP CS instruction will not work on 286 machines - in real or protected mode. As Naama Zahavi-Ely of the Yale computer center verified, the Yale (Alameda) virus does not run on ATs or other 286 machines. In fact, the the only way this virus is discovered (usually) is when someone attempts to boot a 286 machine from an infected disk. There is, however, another version of the Yale (Version -C), that replaces the POP CS with another series of instructions used to relocate the virus in memory. This version will run on the 286. Perhaps this is the version that you mean. To Tom Sheriff: The virus you described is the Australian virus (or stoned virus). It is a boot sector infector and causes no damage. The message you described is on the boot sector but it is never displayed. If you like, you can obtain a disassembly of the virus from HomeBase. Leave me a message. BTW, to remove the virus, perform a SYS command on the affected disks. To David Bader: You are incorrect about Sentry. It does not modify any existing files, the documentation warns of the re-boot and it does display the names of all infected files. As to the interrupt vector modifications, Sentry installs first in the autoexec, so no other programs will have been loaded that modify the interrupt vectors. We have yet to find a virus that Sentry will not detect. To Jeff Scott: The virus that you describe is the Venezuelan virus. It is a boot sector infector and is a damaging virus. There is also a non-virus Trojan floating around that looks identical from a user standpoint. To determine whether you have the trojan or the virus, boot a system diskette on an infected machine and check the boot sector using Norton to see if it has been modified. If it has, then you have the viral version. To David Chess: You mentioned a bug in the 1704 virus that prevents it from recognizing true IBM machines. What you are describing is the 1701 virus. The 1701 is identical to 1704 with the exception that 1701 cannot recognize the IBM/Clone difference. IBM in Denmark was the first company to get hit by the 1701, and there is a joke going around that the 1701 went into IBM, and the 1704 came out. By the way, both the 1701 and the 1704 can recognize pre-existing infections, but they WILL re-infect each other. Just a note of interest. I have finished the disassembly of the Russian Black Hole virus, and find that it is merely the New Jerusalem with some non-referenced text additions. Anyone wishing to see the disassembly please contact me on Homebase. 408 988 4004. Jim Goodwin. ------------------------------ Date: Thu, 27 Apr 1989 01:02 IST From: Ilan Lamdan Subject: BRAIN infection (PC) It seems like I have a visitor... A (c) brain virus infected few of my diskets. I wonder if anybody can tell me : A. any harm done by this virus... (what to expect ?) B. any cure ? C. if so, how can I get it (no ftp, pure BITNET). I searched the on SIMTEL20 but found nothing. thanks in advance Ilan ------------------------------ Date: Thu, 27 Apr 89 08:38:52 EST From: dmg@mwunix.mitre.org Subject: More Using Checkfunctions For Virus Detection (General Interest) In Virus-L V2 #100, Joe Sieczkowski passed on the following comment regarding my suggestion of encrypting the input to a checkfunction algorithm in order to prevent a virus from masking itself by having no effect on the checkfunction: >His checksum might be harder to fake, but it is not necessary to be able >to reverse the encryption to fake a checksum. Only the algorithm for >the forward encryption is needed, and that can be pulled from the >program that does the checking. If f is the checksum and g is the >encryption, all he has done is create a new function s(x) = f(g(x)) >which is just another signature function. If f was more than just >a CRC polynomial, g might not really make any difference, and if >f is a CRC, then some choices of g could make the combination easier >to break. > WB Before I go on, let me note that I understand "WB"'s comment about faking the checksum to mean that the virus is somehow able to recalculate the checksum for the application after infection. My solution was meant to address the case of a virus that, once added to an application, would not affect the checkfunction value. To address WB's comments (does this person have a name? I dislike using initials for someone I've never met), you need more then just the encryption algorithm, you need the encryption key as well. While I did say the key should be dependent on the data to be encrypted, that does not preclude the use of an independent seed key left up to the user. This seed is then modified by the input data. Even if the virus has the clear input data, and the encryption algorithm, it would need to query the user to get original seed key to success- fully infect the application. David Gursky Member of the Technical Staff, W-143 Special Projects Department The MITRE Corporation ------------------------------ Date: 27 April 1989, 10:28:07 EDT From: David M. Chess Subject: re: Yale and 1701/1704 virus, and Sentry (PC) I stand corrected on "POP CS"; that's what I get for reading (and misinterpreting!) the manual, rather than trying it myself. "POP CS" is invalid on a '286, even in real (DOS) mode, and the version of the virus with POP CS in it shouldn't be able to function on '286 machines. My mistake! On the "vanilla IBM machine" issue, though, I stick to my guns. I have samples of both the 1701 and the 1704. The 1701 has *two* bugs in that section: he forgot the "ES" overrides, and the last compare is a word compare rather than a byte compare. He fixed the override bug in the 1704, but he still has the word-compare bug. Perhaps I'm missing something subtle here. It seems to me that the instructions . CMP WORD PTR ES:[DI+8],4DH . JZ KILLVIRUS Are testing for the value "004D" at that place in BIOS. Interpreted as bytes, that's an "M" followed by a byte of zeros. In all the vanilla IBM machines I've looked at, the "M" is in fact followed by a blank (020 hex). So the compare will fail, and the jump to KILLVIRUS will not be taken. Have I made a mistake there somewhere? I have tested the 1704 on a number of vanilla IBM machines, and it happily infects on all of them. Perhaps there are some clones on which the "M" in "IBM" is actually followed by 00? Doesn't seem too likely... In any case, unless you can point out some mistake in the above, I think we have to conclude that the virus author still has a bug, and that the 1704 does spread just as well on vanilla IBM machines as on anything else. DC ------------------------------ Date: 27 April 1989, 10:39:06 EDT From: David M. Chess Subject: re: Checkfunctions For Virus Detection (General Interest) I don't think the conclusion was that check functions are too easy to defeat! A simple-minded fixed CRC has definite problems, but there are at least two alternatives to that (I thought they both came up in the discussion, but they may not have): - Use a more complex algorithm, based on an encryption (as you suggest). CRCs were designed to detect accidental changes, and no one was worried about the computational complexity of inverting them. Now that we *are* worried about that, it makes sense to use what's been learned in the crypto area. As you say, that can be slow. If hardware-assists for crypto become common, that would help! - Use a CRC in which the polynomial is kept secret. If the CRC is long enough (30 bits seems a good lower bound), and the polynomial is actually kept secret, it becomes very very hard to invert the CRC. I don't think anyone shot down that idea in the previous discussions, except to note that keeping the polynomial away from the virus reliably requires care. DC ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253