VIRUS-L Digest Wednesday, 1 Nov 1989 Volume 2 : Issue 229 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., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, 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 Today's Topics: re: Virus scanning on PCs? Re: Protection in Operating Systems re: Where are the Sophisticated Viruses? re: Self-checking programs (PC) Re: Virus source available in Toronto Re: Self-checking programs (PC) Supplemental Security Info on DECnet Worm (VAX/DECnet) Re: Checksum programs Re: Imbedded virus detection Re: Checksum programs --------------------------------------------------------------------------- Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: re: Virus scanning on PCs? > Do scanning programs (in particular scanv45) check video memory > for a virus? Once again, it's important to remember that a virus has to get itself -executed- somehow. That means altering some object that gets executed (typically EXE and COM files and boot sectors so far). Nothing that I know of will execute code found in video memory. So a virus, even if it did hide most of itself in the video memory, would have to change some executable object (COM or EXE file, boot record, etc) in order to get executed. So, if you can check your executable objects thoroughly enough, it's not necessary to check video memory as well. All the known viruses hide in EXE or COM files, or boot records, so those are the only things any scanner for known viruses has to check. (This is about the same answer I gave last week to the question about viruses "hiding" in sectors marked as bad.) DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: Re: Protection in Operating Systems Bill Davidsen's point that DOS allows all sorts of things that UNIX(tm) doesn't is quite true. Remember, though, that viruses don't *have* to do any of those things (write over the o/s in memory, write directly to the hardware, etc) in order to spread. See Cohen's "Computer Viruses - Theory and Experiments" paper for some quite convincing numbers about viruses and UNIX. *Any* operating system that allows users to write programs and share information will be vulnerable to viruses. DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: re: Where are the Sophisticated Viruses? You're forgetting one important kind of virus detector: a general modification-detector that does a check-code of some kind (CRC, MDC, or whatever), and alerts the user when a file's *contents* (not the date) change. There are enough people using such things (at least in the PC world; I don't know much about that Mac world) that I think even a virus that talked straight to the hardware to avoid "suspicious activity" detectors wouldn't get far before it was detected. DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: re: Self-checking programs (PC anti-virus protection) > The basic idea is OK, but you need to use a "one-way" hash function, > rather than something readily invertible like a linear CRC. John Sangster is basically correct, but I'd like to suggest that it's possible to get the advantages of a CRC (faster and more exportable than the DES), and still avoid invertibility. The key (hehe) is that a CRC is easily invertible only if you know the polynomial used. If a modification-detector were to use a different CRC polynomial for each user (based, for instance, on a key phrase elicited from the user at each run), and the database of CRCs were kept from the virus (to avoid the virus being able to calculate the polynomial from file-CRC pairs), the theoretical invertibility of the CRC wouldn't matter, because a virus would not have all the information needed to make an undetected change. DC ------------------------------ Date: 31 Oct 89 00:00:00 +0000 From: "David.M..Chess" Subject: Re: Virus source available in Toronto > however "Viruses , A high Tech disease" published only > overwriting viruses!! Hm, maybe there are two versions of the book? The one I have contains an almost-complete disassembly of the 648 (aka Vienna, DOS-62, etc) virus on pages 156-164. This virus is a standard (very small) non-overwriting virus, that spreads between COM files, and leaves the function of the infected program intact. DC ------------------------------ Date: 31 Oct 89 12:54:19 +0000 From: leif@ambra.dk (Leif Andrew Rump) Subject: Re: Self-checking programs (PC anti-virus protection) JHSangster@DOCKMASTER.ARPA writes: > ... this product includes an "INSTALL" utility which >"vaccinates" the boot track and all executables on the disk. >"Vaccination" consists of appending a cryptographic "seal" checking >module (smaller than a typical virus!) and patching the load module ^^^^^^^^ >header so that this module executes first, then passes control to the >original application program if the program is "clean", otherwise >halting and issuing a warning message. If a virus killer can patch a program so can a virus! Exactly as virus detectors is able to find a virus by looking at the code so is the virus able to detect the virus killer and disable it! That's life!! Leif Andrew Rump, AmbraSoft A/S, Roejelskaer 15, DK-2840 Holte, Denmark UUCP: leif@ambra.dk, phone: +45 42424 111, touch phone: +45 42422 817+313 > > > Why are tall Irish girls with red hair so wonderful ? ? ? < < < ------------------------------ Date: Tue, 31 Oct 89 16:38:58 -0500 From: TENCATI@NSSDCA.GSFC.NASA.GOV (SPAN SECURITY MGR. (301)286-5223) Subject: Supplemental Security Info on DECnet Worm (VAX/DECnet) NETWORK SECURITY SUPPLEMENTAL INFORMATION - PROTECTING THE DECNET ACCOUNT The most important thing that needs to be done to protect a system against the current WORM attacks is to modify accounts where USERNAME=PASSWORD. This is the default configuration for the DECNET account. This can be changed easily, but there appears to be some confusion about the effect that this has on a network. Changing the DECnet default password DOES NOT IMPACT the normal operation of DECnet in any way. -------- The following section provides some background material to illustrate this point: On your system, issue the following commands from a priviliged (CMKRNL,BYPASS,SYSPRV) account: $MCR NCP (or $RUN SYS$SYSTEM:NCP) NCP> show executor characteristics This will produce a list that resembles the following: Node Volatile Characteristics as of 31-OCT-1989 11:02:23 Executor node = 6.133 (NSSDCA) Identification = DECnet-VAX V4.7, VMS V4.7 . . . Nonprivileged user id = DECNET Nonprivileged password = DECNET . . . This is your DECnet executor database. The information listed is the default configuration for your node. The information contained in this list includes "Nonprivileged user id" and "Nonpriviliged Password". This information is what DECnet uses for userid/password when the connecting process a)does not have a proxy, b)does not specify a username/password as part of the access string, and c)does not have a different userid/password defined for the network object being invoked. The access information contained in the executor database is used for reference only. The candidate userid and password (in this case DECNET and DECNET respectively) are then passed to LOGINOUT to validate them against the *REAL* information contained in SYSUAF.DAT. If the information matches, the access is allowed. If the information does not match, the connecting user gets the following error messages: Unable to connect to listner Login Information Invalid at Remote Node -------- In order to correctly change your default network password so that your system cannot be easily exploited by the current DECnet WORM, the following 2 steps must be followed: 1) Change the password for user DECNET in SYSUAF.DAT: UAF> modify DECNET/Password=NEW_DECNET_PASSWORD *NOTE* It is advisable at this time to check that certain other attributes of the DECNET user are properly set: The ONLY access method for this account should be NETWORK. The BATCH, REMOTE, INTERACTIVE, and DIALUP fields should all read "--no access--" The value of PRCLM should be set to ZERO. This is the number of (SPAWNed) sub-processes allowed. The flag LOCKPWD should be set. This prevents anyone but a priviliged user from changing the password. The following command can be used: UAF> MOD DECNET/FLAGS=LOCKPWD/PRCLM=0/NOBATCH/NODIAL/NOINTER/NOREM/NETW 2) Change the password for DECNET in your network executor database: NCP> set exec nonpriviliged password NEW_DECNET_PASSWORD NCP> define exec nonpriviliged password NEW_DECNET_PASSWORD The important thing to remember is that the password must be changed in BOTH places, otherwise your network WILL break. The worm is breaking nodes by penetrating the DECNET account, and changing only the UAF password with the $SET PASSWORD command. By not changing the NCP password, the network no longer accepts INBOUND connections. For more information, consult the VAX/VMS manuals: VMS V4.X - Volume 6 "Networking Manual" VMS V5.x - Volume 5A&5B "Guide to DECnet-VAX Networking" - --------------------------------------------------------------------------- Ron Tencati | NCF::TENCATI /6277::TENCATI SPAN Security Manager | Tencati@Nssdca.gsfc.nasa.gov NASA/Goddard Space Flight Center | (301)286-5223 Greenbelt, MD. USA | - --------------------------------------------------------------------------- ------------------------------ Date: 31 Oct 89 20:54:37 +0000 From: kerchen@iris.ucdavis.edu (Paul Kerchen) Subject: Re: Checksum programs RADAI1@HBUNOS.BITNET (Y. Radai) writes: > In my opinion, the most important requirements on a checksum program >are: >(5) It must be convenient to specify and update the list of files to > be checksummed. This point brings up a problem which is common to most checksumming solutions: where does one store these checksums and their keys? If they are stored on disk, they are vulnerable to attack just like programs. That is, a virus could infect the program and then update its checksum, since the key must be somewhere on disk as well (unless the user enters it every time they compute a checksum--yecch!) and one must assume that the checksum algorithm is known. Or, more simply, a virus could simply wipe out all the checksums, leaving the user to decide which files were infected. Storing the 'sums off line would insure security, but at what cost? Checking and updating the 'sums with any frequency would become tedious at best. I don't mean to rain on this parade, but this issue is one which must be considered by anyone writing a checksum-based anti-viral program. Paul Kerchen | kerchen@iris.ucdavis.edu ------------------------------ Date: Wed, 01 Nov 89 09:32:37 -0500 From: ZLCBEOWEN@csvax.qut.oz Subject: Re: Imbedded virus detection Bob McCabe writes: > While working out the algorithm for this check it struck me >that it should be possible to work out a scheme by which any >program could check itself at load time for infection. Have a look at PC Magazine Aug. 1989, 8(14), p411. There is some code there which does exactly this. - -- Chris Owen | zlcbeowen@csvax.qut.edu.au Library | phone: +61 7 223 2406 Queensland University of Technology | fax: +61 7 229 0874 Brisbane, AUSTRALIA | ------------------------------ Date: 1 Nov 89 13:47:43 GMT From: comcon!roy@uunet.UU.NET (Roy M. Silvernail) Subject: Re: Checksum programs RADAI1@HBUNOS.BITNET (Y. Radai) writes: > In my opinion, the most important requirements on a checksum program > are: > (2) Even if the checksum algorithm and checksum length are known, > without knowledge of the key (the generating polynomial in the > case of a CRC algorithm), it should be impossible to modify a file > in such a way that the checksum remains unchanged. What about doing both an 8-bit and a 16-bit CRC on the file, along with a record of the file length? It seems to me that an altered file might be able to duplicate one of the checksum, but not both, and certainly not both sums *and* the length record. (This might also reduce the need for each machine generating a unique checksum... something I have no clue about. How would this be done?) Roy M. Silvernail | UUCP: uunet!comcon!roy | "No, I don't live in an igloo!" [ah, but it's my account... of course I opine!] -Sourdough's riposte SnailMail: P.O. Box 210856, Anchorage, Alaska, 99521-0856, U.S.A., Earth, etc. ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253