ron@hardees.rutgers.edu (12/24/88)
I got an anonymous tip about a DECNet virus. Milo Medin provided me with the details. The virus exploits a well known feature in DECnet which involves sites that leave TASK 0 running (this is the way DEC ships it). The virus sends a HI.COM file to your default decnet directory and then sends a command to task 0 to invoke it. To close the hole, you need to tell NCP to "CLEAR OBJECT TASK ALL" in your start up files as DECNET always starts this process. If you were infected you will find HI.COM in your default decnet directory and a process running called something like MAIL_178DZ. You should delete the com file and kill off the process if you find them. I don't vouch for the accuracy of the above, I am neither a DECNET nor a VMS lover. -Ron I apologize for all those who are sane enough to run TCP-IP rather than DECNET for having to see this, but it seemed like the most rapid distribution system I could find.
brian@ucsd.EDU (Brian Kantor) (12/26/88)
I received the following message last Friday; I mailed it off to the "phage" security list and it bounced because Purdue's mailer is broken, so I'll post it here. I hesitated to do this at first, since it's not directly relevant and I sure didn't want to panic people into wildly shutting down bridges and gateways again. SPAN (Space Physics Analysis Network??) is a DECNet network, so it lacks direct relevance to the TCP/IP list, but probably this is of at least passing interest. --- Date: Fri, 23 Dec 88 02:53:13 GMT From: gkn@Sds.Sdsc.Edu (Gerard K. Newman) Subject: SPAN WORM ALERT Ladies and gentleman, Someone has loosed a worm on SPAN at this very moment. Check your accounting files and NETSERVER.LOGs in your default DECnet accounts. You'll find evidence of someone creating a file (HI.COM, which I am in the process of fetching from the deleted blocks of one of them) which propagates itself around the network. It has hit all of the VMS machines here at SDSC today, and simply appears to crawl around and send mail to 25097::PHISOLIDE (node 25.79, for which I do not have a name in my DECnet database). It will take me a few more minutes to cobble together a program to dredge up the blocks of the command file (one of the first things it does is to delete itself ... it also sets it's process name to MAIL_178DC, so look around for those, too). When I have it I will forward the text. An adequate defense against the problem is: (from the SYSTEM or other suitably privileged account): $ Set Default your-default-decnet-area $ 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 information should receive the widest possible distribution. I will forward a copy of the command file in a few minutes. Please give me a call (# below) if you need more information. gkn ---------------------------------------- Internet: GKN@SDS.SDSC.EDU Bitnet: GKN@SDSC Span: SDSC::GKN (27.1) MFEnet: GKN@SDS USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138-5608 Phone: 619.534.5076
brian@ucsd.EDU (Brian Kantor) (12/26/88)
And here's the official bumf from DCA, which just arrived: --- ********************************************************************** DDN MGT Bulletin 50 DCA DDN Defense Communications System 23 Dec 88 Published by: DDN Network Info Center (NIC@SRI-NIC.ARPA) (800) 235-3155 DEFENSE DATA NETWORK MANAGEMENT BULLETIN The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network Information Center under DCA contract as a means of communicating official policy, procedures and other information of concern to management personnel at DDN facilities. Back issues may be read through the TACNEWS server ("@n" command at the TAC) or may be obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or 10.0.0.51] using login="anonymous" and password="guest". The pathname for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the bulletin number). ********************************************************************** SUBJECT: Worm (Benign) APPLICABLE OPERATING SYSTEM: DEC VMS PROPAGATION: Propagates via DECNET protocols, not TCP/IP protocols STATUS: Fix is enclosed VALIDATION: The fix has been forwarded to the CERT for validation, but validation has not been completed. But in order to provide timely information to our subcribers, this fix is being made available "as is". It was provided by a host administrator on the NASA SPAN/DOE HEPNET network. We recommend that you contact your vendor and refer to the vendor documentation listed below before attempting to implement the fix. PROBLEM: On Friday, 23 December, Gerard K. Newman of the San Diego Supercomputer Center reported a Christmas Eve computer worm (not a virus) called "HI.COM". This worm appears to be a benign Christmas greeting from "Father Christmas". ESSENTIAL CONSIDERATIONS: The recent Internet Virus has sensitized the telecommunications community to the potential threat of worms and viruses. However, "HI.COM" appears to be a prank and nothing more: (A) It only affects VMS machines connected to DECNET. (B) It does not use TCP/IP, thus it cannot "infect" the Internet (or MILNET/ARPANET). (C) It does no harm (all it does is send a "stop computing and go home" message after midnight on Christmas Eve). (D) It has safeguards against running multiple copies of itself on the same machine. (E) It will terminate itself after completing its mission (at 00:30 on the 24th). SYMPTOMS OF INFECTION: Some steps to take to determine if your system has been infected are: (A) Check your accounting files and NETSERVER.LOGs in your default DECnet accounts for a file called HI.COM. (B) Check your processes for one named MAIL_178DC. A FIX: 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". For general information about this patch call the CERT or the Network Information Center at (800) 235-3155. This represents the best information available at this time to fix this problem. -------