REPORT #: SPAN-027 DATE : February 24, 1989 TO : Bill Olden/Code 205.1 SUBJECT : "Father Christmas" Worm Report 1) Attached is the official "Father Christmas" Worm Report. This report gives complete information about the worm that hit the DECnet INTERNET on December 23, 1988. Pat Sisson SPAN Security Manager Attachment: "Father Christmas" Worm Report "FATHER CHRISTMAS" WORM REPORT Prepared by: Pat Sisson SPAN Security Manager 6 February 1989 TABLE OF CONTENTS I. INTRODUCTION II. BACKGROUND III. DETAILS OF HOW THE "FATHER CHRISTMAS" WORM WORKED IV. TIMELINE OF THE "FATHER CHRISTMAS" WORM V. INFORMATION THAT WAS TURNED OVER TO THE SPAN SECURITY MANAGER VI. COMPLETE INFORMATION ABOUT THE NODE AND ACCOUNT THAT STARTED THE WORM VII. SPAN NODES SUCCESSFULLY SENT THEIR SYS$ANNOUNCE BANNER TO NEDCU2 VIII. FIXES THAT WERE BROADCASTED ON THE DECNET INTERNET IX. FINDINGS OF THE INVESTIGATION X. CLEANUP OF THE NODE NEDCU2:: XI. CONCLUSIONS APPENDICIES ------------------- A WARNING MESSAGE FROM RON TENCATI AT JPL (FOR SPAN) B MESSAGE SENT TO ALL REMOTE SITE MANAGERS ON XMAS WORM C LOGINS TO 20597::PHSOLIDE ACCOUNT D LISTING OF SPAN NODES THAT SUCCESSFULLY SENT THEIR BANNERS TO 20597::PHSOLIDE E LISTING OF SPAN NODES THAT DIDN'T SUCCESSFULLY SEND THEIR BANNERS TO 20597::PHSOLIDE - MAIL WAS FORWARDED TO STOP F FIXES BROADCASTED ON THE NEWORK I. INTRODUCTION A computer "worm" is a program that is self-contained and has the ability to propogate itself across a computer network. Unlike a virus, a worm does not modify another program. A "worm" will infect the computer to which it has gained access and, while executing, will try to infect other computers. The term "infect the computer" as used in this report will refer to computers who actually executed the worm program. A VAX/VMS worm will generally be in the form of a DCL command procedure or an executable (.exe) program. II. BACKGROUND On December 22, 1988 at 21:52 (swiss time) a decnet worm was released from a European HEPNET node NEDCU2:: (20.117; interger form 20597::) onto the DECnet Internet. This worm has been called the "Father Christmas" Worm, since it's ultimate goal was to send mail to users from Father Christmas. The worm performed several key functions: a) Send SYS$ANNOUNCE Banner to 20597::PHSOLIDE on NEDCU2 (node in Switzerland); b) Propogate a file called HI.COM to as many nodes as possible; c) Send a Christmas Mail greeting to all authorized users on a computer system The purpose of this report is to give details of the following aspects of the worm: a) Details of how the "Father Christmas" Worm worked b) Timeline of the worm c) Information that was turned over to the SPAN Security Manager d) Complete information about the Node and Account that started the worm e) SPAN nodes successfully sent their banner to 20597::PHSOLIDE (account where worm originated) f) Fixes that were broadcasted on the decnet network g) Clean-up of the node in NEDCU2 h) Findings of the investigation i) Conclusions III. DETAILS OF HOW THE "FATHER CHRISTMAS" WORM WORKED This section will cover HI.COM in complete detail. The steps HI.COM performed were as follows: a) Node "A" copies file (HI.COM) to target Node "B" . it tries to start HI.COM on the target node - via Task Object 0, or - via Username: DECNET, Password: DECNET combination . if it won't startup it deletes HI.COM off target Node "B" b) Node "B" loads HI.COM in memory and disguises it under the process name MAIL_178DC. It then deletes HI.COM file out of the DECnetdirectory c) Node "B" then sends it's SYS$ANNOUNCE banner to 20597::PHSOLIDE d) HI.COM checks System Clock Time . if the time is greater than 12/24/88 00:00, HI.COM - creates a listing of all the authorized users on that system - sends Christmas greeting to all users ********************** EXAMPLE OF MAIL MESSAGE *************** From: NODE::Father Christmas 24-DEC-1988 00:00 To: You... Subj: Christmas Card. Hi, How are ya ? I had a hard time preparing all the presents. It isn't quite an easy job. I'm getting more and more letters from the children every year and it's not so easy to get the terrible Rambo-Guns, Tanks and Space Ships up here at the Northpole. But now the good part is coming. Distributing all the presents with my sleigh and the deers is real fun. When I slide down the chimneys I often find a little present offered by the children, or even a little Brandy from the father. (Yeah!) Anyhow the chimneys are getting tighter and tighter every year. I think I'll have to put my diet on again. And after Christmas I've got my big holidays :-). Now stop computing and have a good time at home !!!! Merry Christmas and a happy New Year Your Father Christmas ***************************************************************************** - deletes the list it created - stops execution of HI.COM . if the time is greater than 12/24/88 00:30 - stops execution of HI.COM e) HI.COM randomly generates a node number (for target Node "C") . if node number = 0; HI.COM generates a new number . if node number > 63*1024; HI.COM generates a new number . copy HI.COM to target Node "C" . it tries to execute HI.COM on target Node "C" - via Task Object 0, or - via Username: DECNET, Password: DECNET combination - if it won't startup it deletes HI.COM off target Node "C" . continue this portion of HI.COM until the time is greater than 12/24/88 00:00 IV. TIMELINE OF THE "FATHER CHRISTMAS" WORM a) The worm was released on the DECNET Internet from the European HEPNET node NEDCU2 (20.117, interger form 20597) on: December 22, 1988 at 21:52 (swiss time); ~ December 22, 1988 at 16:52 (US east cost time) b) The worm was first noticed at the Goddard Space Flight Center by John McMahon, Systems Manager of node CSDR, December 22, 1988 at approximately 17:00. c) Ron Tencati at JPL sent out a warning message to 20597::SYSTEM on December 23, 1988 at 04:30 (swiss time). The warning stated that the running of an automated command procedure, like HI.COM, was not permitted on SPAN (see appendix A). d) The DECnet link between CERN and the 20597:: was disconnected on: December 23, 1988 at approx. 08:41 (swiss time) This link was scheduled to go down for an upgrade to the circuit. This action had nothing to do with the worm, but it did isolate the worm to the local campus network. e) On December 23rd messages were sent to all SPAN Routing Center Managers, for distribution to Remote Site Managers, warning them about the worm and what actions needed to be taken to stop it from running or from propogating itself across the network. This notice was also sent to HEPNET representatives, THENET representatives and AMES NSIPO for distribution (see Appendix A). The suggested means to stop the worm were as follows: Delete/Disable Task Object 0 Stop Process MAIL_178DC Delete copies of HI.COM on System f) "Father Christmas" worm stopped by December 23rd on SPAN. g) The PHSOLIDE account was logged into on December 23, 1988 from 06:58 until 07:23 (swiss time). During this time frame all the mail messages were deleted, along with the MAIL.MAI file. The user then invoked mail again and forwarded all mail to Username: STOP. This created error messages that could be viewed in the NETSERVER.log files. h) The worm continued to run on the Swiss local network until approximately December 23, 1988 18:20 (swiss time). V. INFORMATION THAT WAS TURNED OVER TO THE SPAN SECURITY MANAGER I received full cooperation from Claude Wacker, Systems Manager of the node NEDCU2. He supplied me with the following data: a) All logins to the account PHSOLIDE since December 2, 1988 b) All MAIL messages received with the SYS$ANNOUNCE as part of the mail message - starting December 23, 1988, 10:00am (swiss time) c) NETSERVER.LOG files starting December d) Accounting Records for the DECNET account starting December 22, 1988 at 22:00 (swiss time) e) Response from the Director of the University of Neuchatel stating that he has a signed non-involvement statement from all authorized users of the account PHSOLIDE VI. COMPLETE INFORMATION ABOUT THE NODE AND ACCOUNT THAT STARTED THE WORM The node that was responsible for starting the worm is located at: Univeristy of Neuchatel Institut of Physic Rue A.-L. Breguet 1 CH-200 Neuchatel Switzerland NODENAME: NEDCU2 NODENUM: 20.117 (20597::) USERNAME: PHSOLIDE SYS MGR: Claude C. Wacker Phone #: 41 38 252004 It is part of a local area network at the University of Neuchatel. It's outside DECnet connection is to European HEPNET through their routing center in CERN. The account PHSOLIDE is an account that is shared by approximately 15 scientists. This account had a trivial password associated with it and could have easily been known campus-wide. Appendix C shows all the logins to the PHSOLIDE account since December 2, 1988. All of the logins from other DECnet nodes and local access have been verified to be valid logins. The only questionable logins came in from the LAT terminal server. These accesses could have come from a particular building on campus or from their dial-in modems. The director of the University, Eric Jeannett, has had every authorized user of the account PHSOLIDE sign a non-involvement statement. This letter stated that they were not responsible for the creation of HI.COM, nor were they responsible for the propogation of the worm onto the network. VII. SPAN NODES THAT SUCCESSFULLY SENT THEIR SYS$ANNOUNCE BANNER TO 20597::PHSOLIDE All of the DECNET activity shown in Appendix D started after the release of the "Father Christmas" Worm on December 22, 1988 at 21:52 (swiss time). The nodes listed in Appendix D could have successfully sent their SYS$ANNOUNCE banner to 20597::PHSOLIDE. All mail evidence was deleted from 20597::PHSOLIDE. All of the systems listed in Appendix E tried to send their SYS$ANNOUNCE banner to 20597::PHSOLIDE. They were not successful because the user of the account PHSOLIDE had set their mail forwarding to Username: STOP. VIII. FIXES THAT WERE BROADCASTED ON THE DECNET INTERNET During the course of trying to stop the worm, several people sent out fixes. These fixes are from the following sources: Ron Tencati, SPAN (Appendix B) DCA DDN Defense Communications System (Appendix F) Phil Demar, HEPNET Manager at Fermilab (Appendix F) Gerard K. Newman, San Diego Supercomputer Center (Appendix F) These are by no means a complete list of all the fixes broadcassted on the network, but the appendices reflect a good sampling of the type of suggestions given. Some of these fixes went out on mailing distribution lists (such as: ARAPNET and VIRUS-L). IX. FINDINGS OF THE INVESTIGATION After carefully reviewing all of the logins to PHSOLIDE, I have determined the following: a) All interactive logins to 20597::PHSOLIDE from other DECnet nodes were valid logins; b) Only those coming in across the Terminal server were suspect . Accesses through the terminal server could have come from - a building on the campus or a - dial-in modems I have had numerous conversations with Claude Wacker, Systems Manager of the node NEDCU2, and he has also concluded that the suspect access to this account came in on the terminal server. The University of Neuchatel Administration is willing to prosecute the individual responsible for the creation and propogation of the worm, but have been unable to determine who that individual is. They have also written a report, that was distributed Campus-wide, talking about the Christmas Worm and what actions each node manager should do to secure their host. X. CLEAN-UP OF THE NODE NEDCU2: A report was written and distributed campus wide to alert the Systems Managers at the University of Neuchatel of the security problems they needed to address. Below is a list of the things the Claude Wacker, System Manager of node 20597::, did on his system: a) Eliminate multi-user accounts b) Passwords are required for dial-in access (through modems) c) Restricted user base for dial-in access d) Additional accounting information done for terminal server access e) Certain Username/Password combinations are not allowed XI. CONCLUSIONS During the last DSUWG meeting in October 1988, it was stressed in the Security presentation that we expected a VIRUS/WORM to hit the DECnet network. We could have easily guessed, at that time, that the virus/worm would probably propogate through the network through the use of the Task Object 0. All of the SPAN Security documents have stated that you should delete Task Object 0 from your permanent DECNET data base and replace its functionality with a dedicated task object. The next release of the "SPAN Security Guidelines and Procedures" manual will stress this point and will give full details on how to set-up these objects along with other solutions for retaining the Task Object functionality. The Father Christmas Worm has over 150 lines of non-trivial control language code demonstrating a reasonable understanding of VAX/VMS internals and the DECnet protocol implementation on DECnet networks. It is obvious from the analysis of this event that the individual who released the Father Christmas Worm realized what he/she was doing and carefully returnedagain to the compromised node to collect information (system banners) indicating the extend of the worm on the DECnet Internet. It is also obvious that he/she expected a large infection of computers by the worm across the network since the worm was released during the Christmas holiday season where there would have been the best chance of worm executing itself on unattended VAX machines. In addition, it is typically held by computer hacker groups who make a habit of compromising the integrity of computer systems that computer system manager, in general, do not implement appropriate security procedures and are therefore asking for unauthorized access to occur. It is estimated that half of the 12,000 DECnet Internet nodes received the worm but much less than 2% of those computers were infected (executing HI.COM) over the first 8 hours since the release of the worm. Within minutes after the worm was released a very quick user reaction across the whole network occurred and the situation was immediately taken seriously. Once the source program for the worm was captured, a procedural cure, using existing functionality of the computer operating systems, it was quickly devised and distributed by several organizations that use the network. A combination of existing computer security measures (to make systems immune to this type of worm), the quick and accurate procedures devised to stop the worm infection, and the network itself used to rapidly provide the cure were the main reasons why the worm infected such a small percentage of nodes. What disappointed me the most about the "Father Christmas" Worm was the amount of people willing to distribute HI.COM out onto distributed mailing lists. Copies of the souce code were seen floating around on VIRUS-L and on the DECNET Internet by the dozen. No one seemed concerned that this information might be given to the wrong individual to take the actual source code, massage it, and use it again. I hope that this won't happen the next time a virus/worm hits the DECNET Internet and that only authorized personnel will see the actual source code of the virus/worm. This will allow those individuals to write a vaccine (if needed) and to give out advice on how to stop the virus/worm. On Friday January 13, 1989 a worm, nearly identical to the Father Christmas Worm, entered the Digital Equipment Corporations (DEC) internal network called Easynet. The private Easynet network contains more nodes than the DECnet Internet. However, as discussed in a recent issue of Digital News (see Lawson, 1989) according to DEC the worm was spotted as it entered the network and the infected system was segregated before the worm could spread. Overall, the impact of the Father Christmas Worm was minimal in an operational sense but extensive in the area of strengthening computer system security (a never ending and ongoing activity) and has started a process to formalize procedures that will deal with these types of threats in the future. Whatever may be the intention of the authors of computer worms and viruses, if these threats are not met head on and delt with rapidly, the ultimate result may be that they destroy the productive working environment that an open network provides. APPENDIX A WARNING MESSAGE FROM RON TENCATI AT JPL (FOR SPAN) From: JPLGP::TENCATI 22-DEC-1988 22:12 To: NSSDCA::NETMGR,NSSDCA::SISSON,FNAL::DEMAR,NAIF::ZUS,NAIF::CHA,ISSAC::JDP,MARKAB::SYSTEM,TENCATI Subj: Notification of SPAN/HEPnet Network Worm Dear NEDCU2 System Manager, According to the attached NETSERVER.LOG file(s), your user PHSOLIDE copied a command procedure over the NASA Space Physics Analysis Network (SPAN) to JPL node NAIF. If the security measures of the local node had not prevented its execution, the uploaded procedure would have enabled remote DCL commands to be executed on our local node. This program also contains instructions that can cause it to propogate itself (in virus fashion) to another node if a copy of itself does not already exist there. It also tries to access a node using the default DECNET account by attempting to compromise the password. Let me explain the security policy for all JPL nodes. This is also true for for most of SPAN as well: The local system management will put files deemed informational or useful into the default DECNET account on their node. Network users may use the default file transfer capability of DECNET to exchange files with colleagues on this node. However, we do discourage the UPLOADING of files. Task-to-task communication (via object 0) has been disabled. This feature of DECNET has been abused by "hackers" in the past, and since alternative methods for bonafide SPAN users exist, this feature was removed. Command procedures that utilize this method of inter-node communication are strongly discouraged, and use of procedures such as HI.COM or other programs designed to execute DCL commands on a remote node are considered an attempt to penetrate the remote node, and have been prohibited by both NASA/SPAN and HEPNET management [Letter on file with SPAN mgmt at Goddard Space Flight Center]. For this reason, I am alerting you of violation of SPAN network security policies. Unauthorized probing of computer systems is also a violation of United States Federal laws, punishable by up to 10 years in prison and up to $10,000 in fines. California systems are further protected by Section 502 of the penal code, which addresses computer crimes. Please inform your user that it is NOT OK for them to arbitrarily upload (or cause to be uploaded) files into our DECNET directories. Especially those with no scientific value. This access of our node does not appear to be work-related. If your user desires assistance, electronic mail to a particular user on our node, or the system manager is always welcomed. We encourage any of your users to make use of this capability. You are hereby notified of the violations being performed by user PHSOLIDE on your node, you are asked to cause his activity to cease and desist IMMEDIATELY upon your receipt of this message. If violations continue to occur on our systems from your node, the matter may be referred to the NASA Office of the Inspector General or the FBI for follow-up as a computer crime under the relevant U.S. statutes and California laws. Your cooperation and understanding is appreciated in this matter. A copy of this message has been forwarded to the SPAN management at Goddard Space Flight Center as well as the HEPnet network management. If you have questions, you may wish to contact these agencies directly. The SPAN electronic mail address is: NSSDCA::NETMGR (for SPAN) and FNAL::DEMAR (for HEPnet). Thank you for your time and attention to this matter. Ron Tencati Network Security Manager Jet Propulsion Laboratory (818)354-8359 JPLGP::TENCATI APPENDIX B MESSAGE SENT TO ALL REMOTE SITE MANAGERS ON XMAS WORM From: NSSDCA::SISSON 23-DEC-1988 15:30 To: @RCMGR Subj: Information about SPAN/HEPNET virus attack Hello everyone! This is Pat Sisson, SPAN Security Manager located at the Goddard Space Flight Center. I'm sure the majority of you have heard about the VMS worm running around on the network - it's known at the "CHRISTMAS VIRUS/WORM". Ron Tencati, from JPL, has written a very nic explanation of how the virus/worm works and I have included a copy of his explanation for your perusal. A notice has been sent to the Systems Manager of the node 20.117 informing him that this type of activity on the network is not permissable. A detailed report will be written and submitted to NASA Headquarters on December 26, 1988. Please disable TASK OBJECT "0" or protect TASK OBJECT "0" on your host so that this virus can be stopped. Also look into your DEFAULT DECnet directory for the file called HI.COM. The one thing you need to look for is a process labeled MAIL_178DC running on your system. The virus/worm creates this process. Pat Sisson SPAN Security Manager **************************************************************************** **************************************************************************** From: JPLGP::TENCATI 22-DEC-1988 23:56 To: NSSDCA::SISSON Subj: Information about SPAN/HEPnet virus attack There is a new virus floating around the SPAN/HEPnet nodes. This is a "Christmas Virus/Worm". It is meant to (using TASK 0) replicate itself and start itself up on a remote node. Once started, it sends your system's startup banner (your system's identification) to user PHSOLIDE at node 20597:: (this is node 20.117, NEDCU2::, Believed to be in France). The attack takes the following form: 1) uploads itself and activates itself via TASK object 2) mails your sys$announce banner to user PHSOLIDE on HEPnet node 20.117 (20597/NEDCU2). 3) Ensures that only one copy of itself is running on your node. 4) Generates a random node address based on time, and tries to replicate itself onto that node. If it fails, this step is repeated. If a valid node is found, it tries both the default access method, and failing that, tries "DECNET DECNET" as a userid and password. 5) Runs AUTHORIZE to create a local list of all identifiers on your node, this consists of all your valid users. 6) Mails a message to every user on your system. This procedure is set to "stop" at midnight on December 24th. It will however continue to replicate itself perform step 2 above ad infinitum. This is a poor attempt to mimic the recent internet virus, it is also most definitely a probing attempt, since it mails your system startup banner back to the originator. It also tries to break into your DECNET account using password "DECNET" if default access does not work. On your nodes, you should disable the TASK 0 object so that you will not be affected should an infected node try to attach to your node. The SPAN and HEPnet management have been sent notification of this virus. Happy Holidays! Ron Tencati Network Security Manager Jet Propulsion Laboratory Pasadena, Ca. USA JPLGP::TENCATI (SPAN) APPENDIX C LOGINS TO 20597::PHSOLIDE ACCOUNT The following list shows the successful logins to the PHSOLIDE account starting December 2, 1988: Interactive Remote Sessions In Out Node Username or Access method =========== ===== ===== ====== ========================= 2-Dec-1988 10:38-10:40 NEIPH1 JANOS 7-Dec-1988 16:38-16:39 NEIPH1 JANOS 7-Dec-1988 16:37-16:43 NEIPH1 JANOS 7-Dec-1988 16:42-15:44 NEIPH1 NB 7-Dec-1988 16:37-16:45 NEIPH1 JANOS 7-Dec-1988 16:47-16:52 NEIPH1 NB 7-Dec-1988 17:25-17:32 NEIPH1 BITNET 7-Dec-1988 17:36-17:45 NEIPH1 BITNET 7-Dec-1988 17:58-18:00 NEIPH1 BITNET 8-Dec-1988 08:09-08:29 TTA4 hard wired port on VAX 8-Dec-1988 16:08-16:22 TTA4 hard wired port on VAX 19-Dec-1988 14:04-14:56 LTA59 LAT terminal port 20-Dec-1988 16:20-16:27 NEIPH1 BITNET 20-Dec-1988 16:30-16:39 NEIPH1 BITNET 22-Dec-1988 10:56-12:10 NEIPH1 IOP 22-Dec-1988 12:10-12:11 NEIPH1 IOP 22-Dec-1988 21:09-21:14 LTA93 LAT terminal port 22-Dec-1988 21:16-21:57 LTA95 LAT terminal port Batch process stated HI.COM =========================== 22-Dec-1988 21:52-23:16 submitted to CASTOR_BATCH Subprocesss stated by HI.COM ============================ 22-Dec-1988 21:53-21:53 Interactive Remote Sessions In Out Node Username or Access method =========== ===== ===== ====== ========================= 22-Dec-1988 22:46-23:24 LTA96 LAT terminal port 23-Dec-1988 06:58-07:23 LTA97 LAT terminal port APPENDIX D LISTING OF SPAN NODES THAT SUCCESSFULLY SENT THEIR SYS$ANNOUNCE BANNER TO 20597::PHSOLIDE All of the SPAN systems, listed below, could have sent their SYS$ANNOUNCE banner to 20597::PHSOLIDE. All mail evidence had been deleted. December 22, 1988 (late evening) and December 23, 1988 (early morning) ====================================================================== 22:43-02:28 1032 (1.8) 22:22-22:27 1066 (1.42) V2 23:59-00:02 1174 (1.150) P15MV1 23:02-23:18 3110 (3.38) FLYBOY 04:51-04:58 3161 (3.89) 04:46-05:02 3350 (3.278) 00:49-00:57 5144 (5.24) JPL35E 22:43-03:24 5980 (5.860) MARKAB 23:54-23:59 6148 (6.4) DFTNIC 02:31-02:46 6153 (6.9) SDCDCL 06:41-07:09 6168 (6.24) STARS 01:22-01:33 6202 (6.58) OCEAN1 01:10-01:20 6210 (6.66) OLEMAX 23:44-23:50 6240 (6.96) ROBOTS 00:40-00:46 6277 (6.133) NSSDCA 23:37-23:44 6338 (6.194) CHM2 05:41-06:05 6474 (6.330) HECTOR 01:01-01:09 7253 (7.88) 01:35-01:54 7258 (7.90) SPRLC 23:23-23:35 7523 (7.355) 03:02-03:24 7731 (7.563) SN01 06:09-06:15 7858 (7.690) SSCSTL 23:25-23:32 7935 (7.767) 22:50-00:06 9261 (9.45) PPD 02:59-03:20 9300 (9.84) CALOCK 05:13-05:38 10306 (10.66) 03:12-03:21 10315 (10.75) CMB 23:26-23:33 10585 (10.345) 23:25-23:33 11270 (11.6) NRL3 03:29-05:39 11330 (11.66) 01:36-01:46 11416 (11.152) PGSE 23:11-23:17 24610 (24.34) TOM 04:30-04:40 27649 (27.1) 02:39-02:47 27655 (27.7) M5 22:14-23:08 28571 (27.923) MMI23 APPENDIX E LISTING OF SPAN NODES THAT DID NOT SUCCESSFULLY SENT THEIR SYS$ANNOUNCE BANNER TO 20597::PHSOLIDE All of the systems listed below tried to send their SYS$ANNOUNCE banner to 20597::PHSOLIDE. The mail for the PHSOLIDE account had been forwarded to STOP, but the evidence remained in the NETSERVER.LOGS: 23-December-1988 - Switzerland Time ================ 08:06 1053 (1.29) guest acctg 08:08 6053 ( 5.933) @ CALTECH? 08:18 SDCD 6153 ( 6.9) 07:48 HRS 6172 ( 6.28) 07:54 SAL 6209 ( 6.65) @ GSFC 08:19 T2 6370 ( 6.226) @ Dartmouth 08:08 CFAIPO 6687 ( 6.543) @ SAO 07:46 CFANXT 6702 ( 6.558) @ SAO 08:17 UAHOAL 7198 ( 7.30) 08:14 VAX 7929 ( 7.761) @ MSFC 08:06/08:24 VAXINO 7489 ( 7.321) @ FL STATE UNIV 08:11 VCITRN 27859 (27.211) APPENDIX F FIXES BROADCASTED ON THE NETWORK 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. APPENDIX F (CON'T) FIXES BROADCASTED ON THE NETWORK HEPNET - FIX FOR FATHER CHRISTMAS WORM Phil DeMar, HEPNET Manager Fermilab Listed below (courtesy of Mark Kaletka of MIT) is a DDN Management bulletin sent out last Friday relative to our Christmas worm (and not a virus, as I've been chastized). It includes a "fix" for the worm. I would simply add the following comments: 1. The fix proposed below is one of several varients of the same general idea, namely disable the ability of the DECnet TASK object to be run from the default DECnet account. Perhaps the simplist method to disable the TASK object is to 'DEFINE(SET) OBJECT TASK USER fictious_username PASSWORD fictious_password'. This will cause any network access attempt of the TASK object that does not provide a valid username and password (either through proxy or explicit access control string) to fail. Note that structuring your network access in this way does not disable the DECnet TASK object, it only requires users to provide a valid access control string (proxy or explicit access control string) to utilize the TASK object. Another varient is to remove the EXECUTOR NONPRIVILEGED USER and EXECUTOR NONPRIVILEGED PASSWORD (as specified below). This causes your system to not have a default account to fall back on for any network access that does not provide an access control string (either by proxy or explicit access control string). However, this method differs from what is proposed below by defining a default account for those DECnet objects that warrant default network access. Those DECnet objects typically are: MAIL, FAL (file transfer), NML (NCP), PHONE, and FINGER (if its on your system and you want to open it to network access). In order to enable general network access to those specific DECnet objects, an NCP command 'DEFINE(SET) OBJECT objectname USER DECNET PASSWORD password' for the MAIL, FAL, NML, PHONE, and FINGER objects is executed. The effect of this is to create a default account for MAIL, FAL, etc., but not have a default account for the TASK object (or any other unspecified DECnet object, for that matter). In the instance of the worm or NETDCL.COM (which also uses the same back-door), the command procedure can be copied into your default DECnet account, but any attempt to run it via task-to-task communications fails, since the DECnet TASK object has no default account to run under. Again, network access is not completely disable the DECnet TASK object, it only requires users to provide a valid username and password (proxy or explicit access control string) to utilize the TASK object. 2. It would also be HIGHLY recommended that if you are using the default password for the DECNET account (DECNET), you should change it. One of the ways the worm operated was that if task-to-task failed after the command procedure was copied into the default account, a second attempt at task-to-task was tried with the explicit access control string "DECNET DECNET". So, even if you had no default account assigned to the TASK object, the worm could still use task-to-task communication via the DECNET account. In short, leaving DECNET as a password on the DECNET account is an open invitation for anyone to use the DECNET account to access your system. CHANGE IT! In order to change the default account password, you must RUN AUTHORIZE and MODIFY DECNET (or whatever you're default account is named)/PASS=xxxxxxxxx. Then you must make sure that whereever the default account is referenced in the DECnet object database (ie. NCP), the password is the same as the password just entered in AUTHORIZE. If the password in the DECnet object database does not correlate to the password in the SYSUAF, then an "invalid login information" error will be generated, and any network access requests for that DECnet object will fail. 3. This worm has been termed 'benign'; however, one would be foolish not to close off the back-door that it utilized. The next worm might well be malicious. By one varient or another, the DECNET TASK object should be effectively 'neutered' so that it can't be run out of the default network account. -- Phil DeMar Fermilab APPENDIX F (CON'T) FIXES BROADCASTED ON THE NETWORK GERARD K. NEWMAN - FIX FOR FATHER CHRISTMAS WORM USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138-5608 Phone: 619.534.5076 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.