VIRUS-L Digest Thursday, 29 Dec 1988 Volume 1 : Issue 59a Today's Topics: UUDECODE source available (PC?) debrain.uue Virus @ lockheed? More on the virus... nVIR 10 - A Correction (Mac) VIRUS WARNING: DECNET Worm (forwarded from VALERT-L) Formatting disks (PC) --------------------------------------------------------------------------- Date: Fri, 23 Dec 88 12:51:53 EDT From: Jean Subject: UUDECODE source available (PC?) To: VIRUS-L@LEHIIBM1 Well I finally have an answer for those who need UUDECODE to create the files they request in .UUE format. I just sent the files to Ken and hope he puts them up on the LISTSERV. I now have a BASIC program with PURE ASCII data statements that creates UUDECODE.EXE and guess what? It works fine. If you cant wait for Ken to get it on the LISTSERV, send me a short MAIL request saying you want the UUDECODE PACKAGE and I'll file send it to you. If you have BITRCV, let me know and I'll Bitsend them which is faster. If you want BITRCV, let me know as well. ------------------------------ Date: Fri, 23 Dec 88 14:03:09 EDT From: SSAT@PACEVM.BITNET Subject: debrain.uue To: VIRUS-L@LEHIIBM1 If anyone has debrain.uue could they please send it to me? We finally got uudecode working properly and now we need debrain.uue Thank you. ------------------------------ Date: Fri, 23 Dec 88 15:17:39 EST From: angelo@jvncf.csc.org (Michael F. Angelo) Subject: Virus @ lockheed? I just got a call from one of my friends, and he said that Lockheed has pulled itself from the internet, due to a virus / hacker. Does anyone out there know anything about this? ps. It supposedly affected there vms machine? ------------------------------ Date: Fri, 23 Dec 88 15:30:22 EST From: Joe McMahon Subject: nVIR 10 - A Correction (Mac) I just received a note from Matthias Urlichs, who tells me that nVIR 10 merely DEACTIVATES the nVIR virus, it does not kill it. I suppose it's like a DNA suppressor, rather than an antibody. Sorry if I have caused anyone inconvenience. The nVIR Vaccine program in the NVIRVACC SITHQX file should still be used to remove nVIR from applications, and the manual procedure mentioned in the ANTI-VIR SITHQX stack can be used to clean systems. I have been receiving a LOT of nVIR removal software lately; I haven't had time to review it yet. I will be doing so and adding the ones I find best address the problem to our LISTSERV after January 1. Happy holidays, all. - --- Joe M. ------------------------------ Date: Fri, 23 Dec 88 19:54:27 est Sender: Virus Alert List From: lecgwy!lyons%RUTGERS.EDU@IBM1.CC.Lehigh.Edu Subject: VIRUS WARNING: DECNET Worm (forwarded from VALERT-L) The following information relates to the DECNET worm which hit the HEPNET and infects DEC VMS systems. Note that in addition to the information presented here, the possibility exists that a non-HEPNET system may have been infected. You should check your system for a file by the name of HI.COM, and a process running with the name MAIL_178DC. If you find either of them, your system more than likely has been infected. Read on for further background, as well as a more thorough explanation. Thanks to Ed DeHart at CERT, Fred Ostapik at ARPA-NIC, and all others who helped assemble this information. - --- Marty Lyons, Lockheed Electronics Company, 1501 U.S. Highway 22, CS #1, M/S 147, Plainfield, N.J. 07061-1501 (201) 757-1600 x3156 LYONS@LECGWY.LEC.LOCKHEED.COM or LYONS%LECGWY.UUCP@AUSTIN.LOCKHEED.COM Worm-fix distribution list: CERT, CMU (cert@sei.cmu.edu) John Wagner, Princeton (wagner@pucc.bitnet, wagner@princeton.edu) Chris Tengi, Princeton (tengi@deepthought.princeton.edu) Nick Cardo, JVNC Supercompuer Center (cardo@jvncc.csc.org) Chuck Hedrick, Rutgers (hedrick@rutgers.edu) Steve Keeton, NJIT (syssfk@njitx.njit.edu) Seldon Ball, Cornell (system@crnlns.bitnet) Nick Gimbrone, Cornell (njg@cornella.bitnet) Sandi Ivano, Yale (???) Anio Khullar, CUNY Graduate Center (ank@cunyvms1.bitnet) Shakil Khan, CUNY Queens College (khan@qcvax.bitnet) Meredith Coombs, Stevens Tech (???) Ken Ng, NJIT (ken@orion.bitnet) Dave Capshaw, Lockheed-Austin (capshaw@austin.lockheed.com) Marty Lyons, Lockheed Electronics (lyons@lecgwy.lec.lockheed.com) Randi Robinson, CUNY (rlrcu@cunyvm.cuny.edu) BITNET Laison Distribution List (laison@bitnic.bitnet) BITNET Linkfail List (linkfail@bitnic.bitnet) BITNET Virus Alert List (valert-l@lehiibm1.bitnet) UUCP/Stargate Announcements (announce@stargate.com) > From rutgers!sei.cmu.edu!ecd Fri Dec 23 17:59:18 1988 > Received: from ED.SEI.CMU.EDU by rutgers.edu (5.59/RU-1.2/3.02) > id AA18876; Fri, 23 Dec 88 17:47:30 EST > Received: by ed.sei.cmu.edu (5.54/2.3) > id AA08030; Fri, 23 Dec 88 17:28:48 EST > Date: Fri, 23 Dec 88 17:28:48 EST > Message-Id: <8812232228.AA08030@ed.sei.cmu.edu> > To: lecgwy!lyons, steinauer@ecf.icst.nbs.go > Subject: Re: NASA Virus The following information has been provided by one of the VMS experts on the Internet. Due to the holidays, the CERT has not been able to verify the information. If you do verify the information please let us know. Thanks, Ed DeHart Software Engineering Institute / Computer Emergency Response Team cert@sei.cmu.edu 412-268-7090 ======================================================================= There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an international DECnet-based network. The worm targets VMS machines, and can only be propagated via DECnet. The worm itself appears to be benign, in that it does not destroy files or compromise the system. It's purpose appears to be to deliver a Christmas message to users starting at midnight on 24 Dec 1988. It does have a hook in it to monitor it's progress; it mails a message back to a specific node (20.117, user PHSOLIDE) containing an identifying string of the "infected" machine. The worm exploits two features of DECnet/VMS in order to propagate itself. The first is the default DECnet account, which is a facility for users who don't have a specific login ID for a machine to have some degree of anonymous access. It uses the default DECnet account to copy itself to a machine, and then uses the "TASK 0" feature of DECnet to invoke the remote copy. There are several steps which you can take to protect yourself from this kind of attack. The easiest (and most restrictive) is to disable the default DECnet account on your machine altogether. This can be done with the following commands from the SYSTEM or other suitably privileged account: $ Run SYS$SYSTEM:NCP Purge Executor Nonprivileged User Account Password Clear Executor Nonprivileged User Account Password ^Z This requires that everyone who accesses your resources via DECnet to have a legitimate login ID or proxy login account on your machine (proxy logins are discussed in detail in chapter 7 of the _Guide to VMS System Security_, see below). You can take less restrictive steps to protect your machine while still maintaining some degree of default access. If you wish to keep the ability for users to copy files to the default DECnet account but wish to prevent them from copying DCL command procedures there and then executing them you can issue the following commands (again from the SYSTEM or other suitably privileged account): $ Run SYS$SYSTEM:NCP Clear Object Task All ^Z You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line CLEAR OBJECT TASK ALL AFTER the line which says SET KNOWN OBJECTS ALL This has the side-effect of disabling users from executing any command procedure via DECnet that the system manager has not defined in the DECnet permanent database. These steps alone are not sufficient to prevent copies of the virus from being copied to your machine; but they will prevent it from being executed. To prevent copies of this specific virus from being copied to your machine you can issue the following commands (from the SYSTEM or other privileged account): $ Set Default your-default-decnet-directory $ Create HI.COM $ Stop/ID=0 ^Z $ Set File/Owner=[1,4]- /Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM This prevents anyone from copying a file called "HI.COM" into your default DECnet account; however, other files can be copied there unless you disable access to the DECnet object FAL (the File Access Listener) from your default DECnet account. This can be done by creating a specific account for FAL (using the AUTHORIZE utility) with a seperate UIC, default directory, and minimal privileges and forcing the FAL object to use that account. The following sequence of commands are an example (these commands also require that they be issued from the SYSTEM or other suitably privileged account): $ Set Default SYS$SYTEM $ Run AUTHORIZE Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"- /Password=randomstring/Device=disk-device/Directory=[some-directory]- /Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup- /NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)- /LGICMD=SYS$SYSTEM:FALLOG.COM ^Z $ Run NCP Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL - Password same-random-string Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL - Password same-random-string ^Z $ Create FALLOG.COM $ V := 'F$Verify(0) $ Write SYS$OUTPUT "" $ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'" $ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:" $ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'" $ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'" $ Write SYS$OUTPUT "" ^Z This sequence of commands separates the FAL account from the default DECnet account, and you can use file protections to enforce that the FAL account cannot access files in the default DECnet account and vice-versa. The command file FALLOG.COM above will log all remote file accesses in the file NETSERVER.LOG in the directory specified for the FAL account above. The FAL program can supply additional logging information; contact your DIGITAL software support person for further details. Further steps can be taken to restrict access to your system. These steps are discussed in detail in the _Guide to VMS System Security_, DEC order number AA-LA40A-TE, dated April 1988. See in particular chapter 7, entitled _Security for a DECnet Node_. ------------------------------ Date: SUN DEC 25, 1988 16.55.23 EST From: "Prof Arthur I. Larky" Subject: Formatting disks (PC) When you format a floppy, you do two things: (1) you create an empty FAT (File Allocation Table) which indicates that you have not assigned any portion of the disk to files, and (2) you create the data sectors on the disk by writing sector numbers, CRC's, etc on every track of the disk. Thus the disk is completely clean; unless, of course, your format program or DOS has been subverted. You also write a boot record. If you have asked for it, the two hidden DOS programs get put as the first two programs on the disk. When you use the same program (Format) to format a hard disk, all it does is create the empty FAT table, thus everything that was on the disk is still there, but you have one heck of a problem finding it unless you are a virus that knows where it is. Hard disk owners can get rid of everything by doing a low-level format (on my Zenith its a program called PREP). This does the entire job of putting the sector and track numbers, CRC's, etc. on the disk and also creates a map of bad sectors (truly bad ones, not virus-faked bad ones). Unfortunately, it takes hours (yes, hours) to do this low level format since the program does repeated checks on the read/write-ability of the disk. Some controllers have code in their ROM at c800:5 that does this low-level formatting; others do not. If you use Debug to look at the code, you may be able to figure out whether its there or not. Another way to find out is to try it; however, you better not have anything valuable on the disk in case it works. Art Larky CSEE Dept Lehigh University ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253