Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA13816; Fri, 1 Jun 90 11:28:04 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA20539; Fri, 1 Jun 90 11:28:01 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA00504; Fri, 1 Jun 90 11:27:46 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23332; 1 Jun 90 16:05 BST From: Anthony Appleyard To: KRVW <@NSFnet-Relay.AC.UK:KRVW@sei.cmu.edu> Date: Fri, 01 Jun 90 16:06:24 BST Message-Id: <$TGTWCZCFFBQV at UMPA> Subject: Virus-L vol 0 issue #0509 Virus-L Digest Mon, 9 May 88, Volume 0 : Issue #0509 Today's Topics hunting up infected files CRC's for detecting viruses Preventing public domain software contamination file confusion Request FSP_12.ARC.1 (Newest Flushot-Plus Program) ** no subject, date = Mon, 9 May 88 17:30:34 EDT ** no subject, date = Mon, 9 May 88 18:25:27 edt Re: hunting up infected files ------------------------------ Date: Mon, 9 May 88 16:05:00 CET Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Karl-L. Noell" Subject: hunting up infected files Now we have come to the point where it's even possible to infect files without altering their size or their time date stamps. So I'd like to recall the well known, efficient and approved cyclic redundancy check (CRC). It should be good practice, to compute the CRC remainder every week for all files on harddisk drives. For this purpose I'm using the very helpful tool FILECRC written by Ted H. Emigh. It's in SIMTEL20 / RPICICGE FILECRC.ARC . Running FILECRC computes the individual checksums and leads over to compare them with the CRCs obtained from the previous run. This will uncover all files which have been altered since the last run, especially those modified in a 'non-DOS-manner'. And all *new* files are shown, revealing unwanted descendants born by trojanic creatures or hatched out of any cuckoo egg. Karl Noell fhw (Wiesbaden, W.Germany) -------------------- Date: Mon, 9 May 88 10:52:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)" Subject: CRC's for detecting viruses Unfortunately, it is very easy to modify a file so that any given CRC remains unaltered. The protection you get by using a CRC is thus quite limited - it stops those virus-writers who aren't clever enough to work around it. Stepping back a bit and looking at the bigger picture: Given a program P, viewed as a bitstring (or a very large number or a polynomial over Z mod 2 or whatever is convenient), we want to compute a signature S(P) which is (a) fairly small; (b) chosen so that it is "highly likely" that, if Q != P, S(Q) != S(P). An example of a simple signature function is "number of bits (bytes, blocks) in P" - the size of the file. This simple function also points out the weak- ness that a given S may have: "Highly likely" must refer to a given set of ways of chosing Q != P. Virus makers at first did not go out of their way to chose Q's the same size as P, so this S worked fine. Now they know better, and this S is useless. There are many other possible S functions: Sum of the bytes of P, XOR of P viewed as a vector of 16-bit words, various weighted sums (given by something like S[0] = 0; S[i+1] = k*S[i] + P[i], where P[i] is the i'th byte/word of P and S = S[size(P)]), and so on. CRC is yet another possibility. All these choices of S have uses given particular ways of chosing Q. CRC is good if Q is what comes out after sending P over a noisy telephone line - the kinds of changes that that process induces to form Q from P are "highly likely" (in a very precise sense) to change the CRC. However, when you are talking about a change due to an intelligent opponent, the story is very different. There exist "cryptographically strong" S functions, in the sense that, given P and S(P), it is "very difficult" - as hard as breaking some code - to find ANY Q != P with S(Q) = S(P). DES, the Data Encryption Standard, provides a mode of use, called CKS (checksum) mode, in which you chose a secret key K, then compute S(P) = DES_CKS(P,K). This is cryptographically strong - it is as hard to break as DES itself. Unfortunately, it requires that K be kept secret - given K, it is no more secure than, say, XOR. What this means is that an individual can chose a secret K and use this technique to checksum his own files - but there is no way to publish a list of (P,S(P)) values that would do anyone any good in determining whether a program they received was intact, since to test it they would need to know K - and then the bad guys would know K, too. DES requires fairly slow computation. It turns out that CRC CAN be used this way, if you chose a random, secret CRC polynomial. There's a paper by Michael Rabin called "Fingerprinting by Random Polynomials" - sorry, I don't have a handy reference - that shows how to do this, and proves that the result is cryptographically strong - as long as the polynomial is kept secret. It is also possible to construct cryptographically strong signatures that do NOT require that a secret be kept. These are essentially one-way functions that are thought, for good reason, to be hard to invert. It isn't hard to build one of these using DES, or any good encryption function. Unfortunately, they tend to require a LOT of slow computation - what happens is that pieces of P get fed in to the encryption function, not as data, but as keys. Encryption algorithms are designed for reasonable implementation for a FIXED key and VARIABLE data - changing the key all the time is hard, since fast implementa- tions usually rely on munging on the key for a while to set things up just right. (BTW, the security of such schemes comes from the difficulty, in a good encryption system, of learning the key, even given a lot of plaintext/ ciphertext pairs.) I would suggest a compromise: A mechanism that, while not completely secure, makes things very hard on a virus-maker while not requiring huge amounts of computation. When a program is published, a large number of random polynomials (say, 100 or 1000) are chosen, using the techniques of Rabin's paper. The CRC of the program with ALL the polynomials is published. To check a program, you chose any two of the polynomials - also published - compute the CRC's, and compare. (You must, of course, chose those two at random.) The virus maker must make his program have the same CRC with respect to ALL the 100 or 1000 polynomials - which is possible, but requires (I believe, this would need to be studied) a LOT of computation. (The length should probably be checked - it's going to be a lot easier on the virus maker if he can add extra stuff to the end of the program to make the CRC's come out right.) -- Jerry -------------------- Date: Mon, 9 May 88 12:50:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Atul Butte Subject: Preventing public domain software contamination With all the problems with virus infected public domain and shareware software, I propose the following solution (for the Macintosh): There exists a shareware program called StuffIt 1.4 which was designed to group multiple files into one file which can then be uploaded. StuffIt 1.4 is for the Macintosh, and is turning into a sort of standard for packing. StuffIt 1.4, in addition to grouping files can compress them and can encrypt them. The proposal: How about adding a new feature to StuffIt that encrypts files, but in such a way that they can only be decrypted and not encrypted again? This can be done with the following method. StuffIt could prompt the uploading user to enter an encrypting code which is used to encrypt the files. Along with the files, another code is included. This code is the decrypting code, which downloading users can use to decrypt the file. The decrypting code could be hashed by some secret function into the original encrypting code. This method is similar to the "trapdoor" functions used for Public-Key Cryptosystems with one-way functions. The advantage of this is that the original author of a program can encrypt his or her software and place it in the public domain without the fear of others downloading the file, contaminating it with a virus, and then uploading the file as the original. Atul Butte /----------\ /----------\ Brown University ! OK ! ! CANCEL ! ST602397@BROWNVM.BITNET \----------/ \----------/ -------------------- Date: Mon, 9 May 88 13:31:33 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Kenneth R. van Wyk" Subject: file confusion There appears to be quite some confusion as to how to get files from the VIRUS-L archives - I've gotten a *lot* of requests to better explain myself. Everyone on this list subscribed to the list by sending a message to LISTSERV@LEHIIBM1 stating SUB VIRUS-L your name. Well, retrieving files is very similar to this. Specifically, you will once again be sending a message to LISTSERV@LEHIIBM1, but instead of SUBscribing, you will be GETting a specific file. So, to get a particular file, like DIRTY DOZEN, send mail to LISTSERV@LEHIIBM1 containing: GET DIRTY DOZEN VIRUS-L That's all. You'll get the file DIRTY DOZEN in your mail shortly afterwards. If you want to *see* what files are available, send INDEX VIRUS-L Also to LISTSERV@LEHIIBM1. Care should be taken to *NOT* send the message to VIRUS-L@LEHIIBM1 since it will go out to the entire list and not reflect favorably upon yourself... :-) Hope this clears things up. Sorry for the repetition to those who already know all about this. Ken - ---------------------------------------------------------------------- = Kenneth R. van Wyk = _ /| = = User Services Senior Consultant = Ack Thippfft! \'o.O` = = Lehigh University Computing Center = =(___)= = = Internet: = U = = BITNET: = Bill 'n Opus in '88! = - ---------------------------------------------------------------------- -------------------- Date: Mon, 9 May 88 17:19:52 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Jim <15360JIM@MSU> Subject: Request FSP_12.ARC.1 (Newest Flushot-Plus Program) I tried to get a lastest copy of fsp_12.arc.1 I read a message that I can get a clear copy from simtel20.arpa. But I don't know how to access to simtel20.arpa directly. By the way, I checked listserv at rpicicge and couldn't find any fsp_12.arc.1 there. Please help me out! -------------------- Date: Mon, 9 May 88 17:30:34 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: OJA@NCCIBM1 In-Reply-To: Travis Lee Winfrey's message of 6 May 88 Regarding the inquiry of a list of known viruses, malicious, or otherwise.... first check the dirty dozen listing available as a file from VIRUS-L. In a few weeks or earlier, I can get a quick amalgam of couple of articles listing many of the viruses. In a month or so, I hope to make a "VIRLOG" patterned after the "dirty dozen" listings. It will be helpful but I can't gaurantee it will 100% comprehensive. But I will be seeking to compile whatever info I get here, from RISKS, and elsewhere that can be published. With that listing will be a list of anti-virus/bomb programs. BOMBSQAD and CHK4BOMB have been mentioned. On the files areas, there are several good programs. As for tampered programs, well... it is hard to keep up with that. However, I can warn you about FLUSHOT4. It is a tampered version; that is why Ross Greenberg calls his program FLUSHOT+ or (FSP). But the DOS REName command makes tracking these nasties impossible. Whatever the name of the FLUSHOT type program, watch for ones with executable text files (ie.; COM or EXE files to run so the documentation will be displayed.) Ross Greenberg uses ASCII files for the documentation. Other than that and the suspect NOTROJ program (another story in itself), I don't know of other tampered "cures". Regarding books, I have heard of a "Hacker's Manual" but I haven't seen it. There is no major book yet that I know of which deals specifically and in detail about malicious programs. J.D. Abolins -------------------- Date: Mon, 9 May 88 18:25:27 edt Reply-To: Virus Discussion List Sender: Virus Discussion List From: Travis Lee Winfrey In-Reply-To: OJA%NCCIBM1.BITNET@cuvma.columbia.edu's message of Mon, 9 May 88 17:30:34 EDT <8805092142.AA17475@columbia.edu> Regarding books, I have heard of a "Hacker's Manual" but I haven't seen it. There is no major book yet that I know of which deals specifically and in detail about malicious programs. yes, I've seen the hacker's manual at a bookstore nearby. it pre-dates viruses, and is more for breaking into computers over networks or dialup lines. it was surprisingly accurate, listing for each os: the login procedure, how to find out user ids, what the privileged ids are (root, system, operator). I didn't see any lists of security bugs, but I was just glancing through it. there was also a lot of phone-phreaking information in it. the techniques are mostly for game-seeking kids playing around with modems, but they do good job of stripping away any security-by-ignorance schemes. t -------------------- Date: Mon, 9 May 88 15:40:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Joseph M. Beckman" Subject: Re: hunting up infected files In-Reply-To: Message of 9 May 88 11:05 EDT from "Karl-L. Noell" As an employee of the National Computer Security Center, I must point out that we do *NOT* attempt to track perpetrators for prosecution or for *ANY* other reason! We are not a law enforcement Agency, and are prohibited by law to take any such action. We are interested in tracking the viruses (or ordinary Trojan Horses) as they infect different sites. As a matter of professional interest, I would be curious as to the motivations of perpetrators of malicious code, or whether they are members of "Hacker Clubs;" but that is information that may be conveyed without identifying the people/organizations involved. Joseph