********************************************************************** 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.