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 AA03432; Tue, 19 Jun 90 05:00:39 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA28348; Tue, 19 Jun 90 05:00:35 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA01292; Tue, 19 Jun 90 05:00:19 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa04657; 19 Jun 90 9:24 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Tue, 19 Jun 90 09:38:08 BST Message-Id: <$TGWFCWKBBCRZ at UMPA> Subject: Here is Virus-L vol 0 #0902 Virus-L Digest Fri, 2 Sep 88, Volume 0 : Issue #0902 Today's Topics MS-DOS: new strain of virus? A Modest Proposal Re: A Modest Proposal SCORES spread question Yale Virus Info Re: SCORES spread question ** no subject, date = Fri, 2 Sep 88 16:42:00 EDTT Re: Pc-Lock CRC vs. encryption schemes ------------------------------ Date: Fri, 2 Sep 88 10:20:13 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Otto Stolz +49 7531 88 2645 Subject: MS-DOS: new strain of virus? Hello experts, last night one of our staff members detected evidence of a virus that has infected every puplicly accessible AT or compatible at our department (computing center of an university), and more than 50% of the ATs used by staff persons only. Meanwhile, I think I know how this virus spreads. So far, it has not done any harm, but I do not know what it will do to the befallen in future. Please find details below. Has anybody seen this particular strain of virus before? If so, what do we have to expect, if we do not succeed in destroying all copies? Please answer privatly to me to avoid unnecessary network traffic; I'll summarize to The List. If this is a new strain, somebody (me?) will probably have to disassemble it to find out, what threat it contains. This will probably last for a couple of weeks, so do not expect quick results. For this task, I'll probably need a dis-assembler and a compare-program. Who can me tell, where to obtain such tools? Thanks for your time, and best regards, Otto - ------------ [Symptoms]: 1. Apparently, the virus makes itself core-resident and waits for some .COM or .EXE file to be started. 2. When a .COM or .EXE is started, the virus inserts itself into that very program, making it exactly 1704 Bytes longer, according to the DIR command. If the program resides on a write-protected disk, the virus will cause a write-protect error, instead. No program is infected twice. I tried it with a pseudo program of 4 bytes (my 1st name), and found that after the infection these 4 bytes had apparently been overwritten (visual inspection with TYPE only -- we'll use some suitable editor after disinfection). A .COM and an .EXE file with the same file name and the same 4 bytes content yielded apparently identical infected files (visual inspection with TYPE only -- no comparison pro- gram run, so far), while another test case with a different file name and different contents (5 Bytes) showed a slight difference in the infected file. Astonishingly, even these pseudo programs are termi- nated without any error message from DOS. 3. When you run the infected program on another computer, it will continue to infect every .COM or .EXE file started there. [Recovery]: We've begun to re-install software on the infected disks, proceeding thus (thanks to VIRUS-L for many hints during the last couple of months): 1. On dedicated computers, backup the important data files. Be sure not to backup any .COM or .EXE file. Skip this step on public computers. (BTW, an incredibly stupid notion, a "contradictio in adjecto": these "public Personal Computers", we were forced to install on account of decisions by our government! Now, we're experiencing the consequences of this oddity.) 2. Switch off the Computer. 3. Switch it on again, booting from a write-protected, original system disk. Install the software again from write-protected originally vendor-supplied disks. On one computer, test for presence of the virus after installation of every software component, to make sure the virus doesn't come from a software package (vendors aren't immune, are they?? :-) On the publicly accessible computers, this step involves removing the SafeGuard Cards, installed therein. We can't distribute the repaired software through the PC-Network, as this would require at least one .COM or .EXE file on the receiving side. All we can do to save some labour, is installing the DOS and networking component on every computer, install the other components only on the server and re-distribute them from it. (Again, you see the advantage of a host, where software is maintained only in 1 copy, over a pool of PCs!) 4. On dedicated computers, restore the backed-up files. Apparently, we are facing pretty much labour to re-install everything properly. 5. Try to develop some virus-recognizing program to avoid future infection from the same strain. Still unsolved problem: how can we force every user to apply this program to her disks, before starting any .COM or .EXE??? Suggestions welcome! -------------------- Date: Fri, 2 Sep 88 13:57:20 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: "M. Smith" Subject: A Modest Proposal With the mess that the nets are in right now, an idea that Info-Micro went to on the Arpa side is due. Info-Micro distributes unmoderated Digests at a once per day rate. The Digests may be sent twice on occasion, but as they are numbered and dated, it is easy to eliminate substitutes and trail down evil mailers in the net (not as much of a problem on ARPA/MILNET since the topology is point to point. *FAILED* mail is the big problem, as the mailer retries for three days and sends a copy of the failed mail to EVERY MEMBER OF THE LIST _E_A_C_H_ _D_A_Y_ !!!) Unattended operation might make many people happier, but semi-automatic operation is probably safer, although I would rather get digests regularly, than one behemoth when the digester has been away for two weeks. I will post any comments/flames I get, but you can send mail directly to Ken (see his monthly blurb for his address) if you like this idea. Send all disagreements to /dev/null ;-) Thank you for your attention, Mark L. Smith mlsmith@nadc.ARPA -------------------- Date: Fri, 2 Sep 88 14:38:53 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Ken van Wyk Subject: Re: A Modest Proposal In-Reply-To: Your message of Fri, 2 Sep 88 13:57:20 EDT > With the mess that the nets are in right now, an idea that Info-Micro > ... > idea. Send all disagreements to /dev/null ;-) That's a suggestion that I'd considered a while ago, and I put it up to a vote. The bottom line was that most people preferred running VIRUS-L undigested and unmoderated. You can, of course, unsubscribe and read just the weekly logs if you wish. That's a pseudo-digest list. That's what the majority wanted. Let's *please* not get into a debate about the pros and cons of digest/non-digest. I went with the majority vote. Enough said about digesting, ok? Thanks, Ken Kenneth R. van Wyk Calvin's mom running a bath for Calvin... User Services Senior Consultant Calvin: It's too cold! Lehigh University Computing Center Calvin: Now it's too hot! Internet: Calvin: Now it's too cold! BITNET: Calvin: Now it's too deep! -------------------- Date: Fri, 2 Sep 88 14:50:00 CST Reply-To: Virus Discussion List Sender: Virus Discussion List From: conni annable Subject: SCORES spread question Yesterday, we discovered that the MAC network in our Library was infected with the SCORES virus. This was identified by INTERFERON V3.0. This morning FERRET V1.1 was used to clean up the hard disks and the Library folks will now go through their application diskettes and clean them up as well. A major problem is that the network is publicly available (bring your own diskettes). FERRET reported the infection dates - the earliest one was May 23, 1988. We seem to see some evidence that the virus has been spread through data files. Does anyone know if this is possible? The other possibility is that these (not extremely computer literate) users are not remembering everything quite correctly, but we have at least one who clains to have taken a disk containing "just the data I wanted to print" to this network to use the laser printer, then contaminating a stand-alone MAC in another location later with that disk. Thoughts? Thanks, Conni Annable Network Manager and Virus Information Coordinator (whatever that means) University of Texas Health Science Center at San Antonio All opinions stated are entirely my own. -------------------- Date: Fri, 2 Sep 88 16:35:00 EST Reply-To: Virus Discussion List Sender: Virus Discussion List From: Chris Bracy Subject: Yale Virus Info I have now dissabled the Yale virus entirely. Here are some specifics... There is a format table set up to format the 40th track for 8 sectors /track. The final bios is call is missing however so the format is never done. The virus copies itself to high memory and reduces the MS-DOS memory count by 1K. It then reads the original boot sector which was kept on track 40, sector 8, which is then executed. This virus takes over two vectors: int 9 and Int 19. Int 19 is the reboot vector. Int 9 is the keyboard vector. The Virus only spreads on reboot. If an infected disk was booted and you do a warm boot (Ctrl-Alt-Del) it will infect the new disk. The keyboard handler has the logic to watch for this reboot. The keyboard handler also has a hook for Ctrl-Alt-i. If pressed the virus copies it generation count to 40:72. If I remember correctly, (I can't figure out where I saw this originally) this location is checked on reboot for 1234H. If found it does a quick boot. It is possible that the writer wanted to make this a key for dont infect, but on all machines I have access to, this isnt the case. The virus resets the screen by putting a byte in memory. This method doesn't work correctly on new machines. Instead of clearing the screen, it converts it to 40 column mode. (This is how it was noticed) This virus keeps a generation count. It doesnt appear to use this count for anything (except as mentioned above). The version I got had a generation number 14h. The virus will jump to ROM basic if it cannot load the original boot sector. I believe this is either and old virus or written by someone with an old machine. The format is 8 tracks instead of the current 9. The jump for ROM basic is in. The screen clear is done with a poke (this does clear the screen on an original PC but not on newer machines.) etc... The virus infects almost any diskette, but it must be in drive A: (eliminating hard drives). It will only boot PC(XT) compatibles. I could not get it to boot an AT (I tried Zenith 248 and 286). It will also infect almost any version of DOS. I have tried DOS 1.0 thru 3.3. The virus has no harmful effects except for writing onto track 40. Even on high density drives where this is in the middle of the disk. If track 40 is written to after it is infected, it will cause the disk to become unbootable. If anyone has seen this virus, or has any questions, please drop me a line. Chris. *==============================*======================================* | Chris A. Bracy | Student Consultant | | (215) 758-4141 | Lehigh University Computing Center | | Kcabrac@Vax1.cc.Lehigh.Edu | Fairchild Martindale Bldg. 8B | | Kcabrac@LehiCDC1.Bitnet | Lehigh University | | CAB4@Lehigh.Bitnet | Bethlehem, PA 18015 | *==============================*======================================* -------------------- Date: Fri, 2 Sep 88 16:32:12 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: Joe McMahon Subject: Re: SCORES spread question In-Reply-To: Message of Fri, 2 Sep 88 14:50:00 CST from >FERRET V1.1 was used to clean up the hard disks.... Uh, I'd REALLY want to check over those files again if I were you; Ferret 1.1 doesn't always clean up Scores completely...! Try KillScores instead (available from our LISTSERV). >We seem to see some evidence that the virus has been spread through data >files. Does anyone know if this is possible? No. Scores ONLY affects files which contain executable (CODE) resources; details notwithstanding, unless you have VERY peculiar data files (with CODE in them? Wow), you can't catch Scores from a data file. Just as a thought -- Lightspeed C project files have code added to them; this couldn't be the case here, could it? Also, get Vaccine on ALL of your public machines, and teach the users that the Vaccine dialog means biiiiiiiiig trouble. "Wanted" posters, e.g., "Has you seen this dialog?", are a good way to do this. Vaccine is also available from LISTSERV@SCFVM; please e-mail me directly if you'd like some help. - - Joe M. -------------------- Date: Fri, 2 Sep 88 16:42:00 EDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: WHMurray@DOCKMASTER.ARPA In-Reply-To: Message of 30 Aug 88 09:10 EDT from "Frank San Miguel" Frank San Miguel asks: >That brings me to another point, if a war should take place >(sensibilities forbiding), how prominently would viruses be used as a >means of attacking an enemy? This sounds like the plot of a cheesy >film. I certainly prefer them to hydrogen bombs. During the second world war, the US authorities used a different currency in Hawaii than they did on the continent. This was a defense against counterfeit currency attacks. Note that counterfeiting is difficult except with the resources of a sovereign power. There are both a cheesy film and a cheesy tv series based upon the premise that Nazi Germany had attempted to de-stabilize Great Britain by debasing its currency with counterfeit. (Both of these include a line about the conscription of felons to help carry out the attack.) To the best of my knowledge there was never such an attack, even against the notoriously easy to counterfeit US currency. While such attacks make great fantasy, they do not make very good warfare. Both the US and Great Britain were very busy debasing their own currency. They did not need any help from the Axis powers. While colorful, these attacks are not nearly so damaging as bombs or artillery, even though they may be cheaper. The use of criminals also suggests that, even in wartime, there are limits beyond which noble people do not go. Counterfeiting and forgery are the tactics of criminals. Even spying has a taint to it. Saboteurs are dealt with much more severely than soldiers. Viruses are the tools of the immature, the sneaks, and the cowards; not those of the hero. William Hugh Murray, Fellow, Information System Security, Ernst & Whinney 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 -------------------- Date: Fri, 2 Sep 88 09:57:00 MDT Reply-To: Virus Discussion List Sender: Virus Discussion List From: KEENAN@UNCAMULT Subject: Re: Pc-Lock In-Reply-To: Message of 31 Aug 88 13:52 MDT from "James Ford" I saw one case (a large government installation here in Calgary) in which the user changed his CONFIG.SYS file (which the Pc-lock documentation warns you not to do..who reads documentation? :-) and was then unable to access anything. The remedy involved pulling the power to the card I believe. Tom Keenan Associate Professor Dept. of Computer Science The University of Calgary -------------------- Date: Fri, 2 Sep 88 18:51:38 +0300 Reply-To: Virus Discussion List Sender: Virus Discussion List From: "Y. Radai" Subject: CRC vs. encryption schemes Jerry Leichter writes: > Suppose I know how your polynomial generator works, and have a copy >of ONE file with your checksum for it. I proceed to compute the checksum of >the file with all 70 million possible polynomials, comparing the results to >the known checksum. Even if it takes a second to compute, I can expect a >match in a little over a year. I have three replies to this: (1) Just where do you expect to get the checksum, relative to the generating polynomial which I use for detection of viral infection, of even ONE file of mine? I'm certainly not going to publish one. Are you going to get onto my computer and peek at the files on my hard disk, hoping to find my checksum base and hoping that the data isn't stored in encrypted form? (If you should by some chance succeed, you'll find my polynomial there too, without your even having to compute it!) Well, if my files were sufficiently important (or if I were sufficiently paranoid) to think that someone would be willing to devote a year of computer time for them, I would certainly keep my checksum base (and checksum program) offline, on a diskette which I would keep locked up and which I would insert into my computer only during the time I check my CRCs. (2) Assuming you have somehow managed to get ahold of one of my checksums, by the time you come up with my polynomial after a full year (!!), I will have changed my generator several times, and you will have spent an awful lot of computer time for nothing! Okay, for sake of argument let's suppose you pull our your checkbook and purchase a real fast computer with parallel processors, like the Cray 3 (*) if you can hold out another year until it's available. Then you could do it much faster, before I get a chance to change my generator. But again, if my files are sufficiently important, I will checksum each of them not once, but twice or more, each time using a different generator. So you got *one* of my polynomials; so what? (3) Let's suppose for sake of argument that (a) I'm important enough for you to devote all this computation time or power, (b) I use only one generator, (c) I hand you one of my checksums, and (d) I haven't had time to change my generator by the time you've computed it. When all is said and done, you've got a weapon only against *MY* files. Now if you're interested in attacking other people who use a personal/random CRC, you're going to have to go through all that again for each and every one of them. If, on the other hand, you're interested in attacking only me, you hardly need a virus; a simple immediate-acting Trojan will do. And in that case, *no* checksum program will help, no matter how sophisticated or secure! So tell me: Why bother calculating my polynomial at all?? >Today, it is extremely naive. The world is full of failed cryptosystems >which people relied on because "no one could demonstrate a method" of breaking >them. Given advances in the field, the burden of proof should be - and, among >people who work on these issues, IS - entirely on the PROPOSER of a system to >show that his system is secure, in some sense. In what *practical* sense have DES and RSA been shown to be appreciably more secure than a Rabin-type CRC? What I know is that RSA can be broken if someone should find a reasonably quick way of factoring very large numbers. I don't seem to recall that the proposers of RSA have shown that to be impossible. As for DES (here I am relying mainly on an article by Tom Athanasiou in the Risks Digest): (1) It was created essentially by modifying IBM's LUCIFER. However the modifications seem to have been all in the direction of *weakening* it. And the reason was evidently so that the code-breaking department of the NSA would be able to *break* it when used by others. Thus the key size was reduced from 128 to 56 bits. (2) Changes were also made in the S-boxes. It has been rumored that the NSA inserted a "trapdoor" into them in order to make the system vulnerable; in any case, mathematicians have demonstrated the possibility of weakening the cipher by introducing hidden regularities into the S-boxes. (3) In 1985, the NSA abandoned DES. At that time its deputy director for communications security was quoted as saying that he "wouldn't bet a plugged nickel on the Soviet Union not breaking [DES]". So whatever theoretical criteria DES may satisfy, its proposers have not only not shown the system to be secure in practice, but they have even abandoned it on grounds of its being *in*secure. Of course, you might reply, there's no *absolute* guarantee of security with *any* system. Well, it seems to me that the difference between our views lies in where to draw the line between the insufficiently secure and the (apparently) sufficiently secure. The brute force scheme which you describe may be worthwhile if you're trying to *break a cipher* of some important intelligence or military agency. (The fact that you refer me to Kahn's book strongly suggests that that's the application you have in mind.) But we here on the list are concerned only with virusbusting. Of course, cryptographic techniques are welcome for that purpose. But one has to keep a proper sense of proportion. It's straining the imagination to suppose that the ordinary type of virus creator would spend over a year of computer time to break a CRC checker used for viral detection purposes by ordinary individuals or institutions, and *that* is the community *I* am concerned with. These people need a *fast* algorithm with *reasonably* high degree of security, and (present-day) cryptosystems simply can't meet the first of these two requirements. Your standards concerning security are presumably much higher than mine, while the increased execution time demanded by cryptosystems doesn't seem to play the slightest part in your considerations. Hence you apparently draw the line I mentioned above somewhere between a 31-bit CRC and DES. But for the purposes I have described, it suffices to draw it between a fixed-generator CRC and a personal/random one. Besides, by emphasizing brute-force methods of breaking schemes, you miss the *real* danger; "real" because it's *MUCH* more likely to be employed by a virus creator than a brute-force method. As I said in my posting of Aug. 29, that comes from certain *loopholes* which must be blocked by the program utilizing the checksum algorithm. Without such blocking, *no* checksum algorithm, no matter how sophisticated, can provide dependable detection of viral detection. My program has them. Does yours....?? Y. Radai, Hebrew Univ. of Jerusalem (*) For those unfamiliar with the Cray 3, they say it's so fast, it can complete an infinite loop in six minutes. -------------------- *** end of Virus-L issue ***