Date: Fri, 3 Nov 89 18:10:00 PST Subject: Security Digest V1 #39 Security Digest Volume 1 Issue 39 subject(s): SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK More on the WANK worm (WORM VACCINE PLEASE DISTRIBUTE) request for security packages Net Hacker ... Hacker detail ctd. Suspect ID Re: Advisory by CERT about Sun 4.X systems [markw@gvl.unisys.com : NTT Challenges Hacker] ------------------------------------------------------------------------ Date: Tue, 31 Oct 89 01:02:34 EST From: Gene Spafford Subject: SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK An update on the NASA worm situation. Please pass along as you see fit. --From: TENCATI@NSSDCA.GSFC.NASA.GOV (SPAN SECURITY MGR. (301)286-5223) The following message is being circulated within SPAN. It has been submit to the routing center managers for distribution. I thought you might like a copy for your records. Please pass this on to as many people as you feel it appropriate. It is applicable to all DECnet nodes world-wide. ============================================================================ INTER-NETWORK MEMORANDUM SPAN MANAGEMENT OFFICE ============================================================================= 30-OCT-1989 TO: ALL SPAN SYSTEM MANAGERS FROM: SPAN MANAGEMENT OFFICE GODDARD SPACE FLIGHT CENTER CODE 630.2 GREENBELT, MD. 20771 (301)286-7251 SUBJ: SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK ---------- A variant of the 16-Oct worm has been restarted on the DECnet internet. This worm is a slightly modified copy of the original worm that infected the networks last week. The method of attack is identical to the last except that this version calls itself OILZ_nnnn instead of NETW_nnnn. This variant of the worm changes the password of the account it penetrates unlike its predecessor which only changed passwords if it penetrated a privileged account. The effect of this modification is that if the DECNET account is breached (Userid DECNET, Password DECNET), changing of the password will disable further *INBOUND* network connections to the node, effectively removing it from the network. THIS IS THE PRIMARY WAY IN WHICH THE CURRENT WORM IS ACHIEVING SUCCESS. The previous precautions and guidelines issued by this office are still applicable and valid. The following 5 procedures should be implemented on all DECnet nodes to ensure that the worm cannot gain access to your node. ---------- 1) The current worm has been modified to attack the default DECNET account first. It attempts to enter the default DECNET account with user=DECNET and password=DECNET. This is the default set up. IT MUST BE CHANGED. To change it, two things have to be done: $MCR AUTHORIZE UAF> mod DECNET /pass= !anything BUT "DECNET" UAF> mod DECNET /flag=lockpwd/nobatch/prclm=0 UAF> exit Then, to match default access control information in the executor (so MAIL and NML will still work): $MCR NCP NCP> set executor nonpriv pass !NOTE this MUST match what you set in AUTHORIZE! The above changes will not effect operation of your system, but will prevent the worm from entering via your default DECNET account. 2) DISABLE THE TASK OBJECT The TASK Object MUST be removed from your DECnet database. There are two methods by which you can accomplish this: 1. In SYSTARTUP.COM/SYSTARTUP_V5.COM, after the call to @SYS$MANAGER:STARTNET, insert the following line: $ MCR NCP CLEAR OBJECT TASK ALL THIS COMMAND MUST BE EXECUTED *EACH TIME* THE NETWORK IS STARTED OR RESTARTED. DOING IT AT BOOT-TIME ALONE IS NOT SUFFICIENT. 2. Instead of option 1, the following commands can be issued ONCE from a privileged account to permanently change the information in the DECnet database for the TASK object: $ MCR NCP SET OBJECT TASK PASSWORD $ MCR NCP DEF OBJECT TASK PASSWORD If for some reason you MUST have a TASK object, please call the SPAN network office at (301)286-7251. 3a) Protect SYS$SYSTEM:RIGHTSLIST.DAT so that it is has no protection bits set for the WORLD category of users. This is how the attacking worm determines who your valid users are. There is some discussion about this approach, it apparently works on 4.7 thru 5.1-1 systems, reports from systems testing this approach say it breaks under V5.2. So there are 2 other approaches, set an ACL on RIGHTSLIST.DAT disabling NETWORK access, or using a logical name to point to RIGHTSLIST. **NOTE** THE ACL APPROACH MAY REQUIRE A REBOOT TO PURGE THE OLD RIGHTSLIST.DAT ON V4.7 SYSTEMS. b) Place an ACL on RIGHTSLIST.DAT to prevent network access of your user names ------------------------------------------------------------------------ Date: Fri, 03 Nov 89 13:40:18 EST From: Gene Spafford Subject: More on the WANK worm (WORM VACCINE PLEASE DISTRIBUTE) I don't use VMS, so I can't comment on this. However, here it is for you to see & use as appropriate. ------- Forwarded Message --Date: Fri, 03 Nov 89 13:10:39 -0500 --From: TBUTLER@NSSDCA.GSFC.NASA.GOV *********** WANK WORM VACCINE ************** A vaccine to combat the WANK worm has been developed by Bernard Perrot of the Institut de Physique Nucleaire, Orsay, France. The vaccine consists of creating a bogus file which you put in SYS$SYSTEM:RIGHTSLIST.DAT. When the worm tries to use the information in this file, the worm-code generates errors and blows up causing the attacking worm to die. The vaccine does NOT affect the remote system - it only kills the worm. This vaccine will stop attacks from any attacking nodes, it should therefore greatly reduce the "annoyance level" of attacks by reducing the volume of audit trails. ******************* IMPORTANT IMPORTANT IMPORTANT *********************** PLEASE READ!!! THIS VACCINE WILL ONLY WORK AGAINST **CURRENT** STRAINS OF THE WORM. WE BELIEVE HOWEVER THAT TO ELIMINATE THIS WORM FROM THE NETWORK, THIS TECHNIQUE WILL HAVE TO BE USED ON AS MANY SYSTEMS AS POSSIBLE. IT IS THE ONLY WAY TO ATTACK THE WORM AT IT'S SOURCE (short of system management action on the infected node...and a lot of system managers are either asleep, ignorant, lazy or??? and therefore the worm has been running on some systems for days). ******************************************************************************* This method has been tested on VMS 4.7 thru VMS 5.2 systems. In order to correctly implement this fix, the following steps must be performed: 1) If you have previously implemented any of our suggestions regarding file protection or ACL's on RIGHTSLIST.DAT, it is necessary to undo them restoring SYS$SYSTEM:RIGHTSLIST.DAT to its original configuration. 2) RENAME the file SYS$SYSTEM:RIGHTSLIST.DAT to some other name of your choosing. 3) To make VMS operate correctly with the rightslist file in a new location, issue the following command, and also add it to your system startup procedure: $DEFINE/SYSTEM/EXEC RIGHTSLIST The worm won't find the file because it can't translate the logical symbol. 4) Take the 4-line file listed below, protect it W:R and do not put an ACL on it. Name it SYS$SYSTEM:RIGHTSLIST.DAT. You *WANT* the worm to access this file! Users on your system will translate the system logical RIGHTSLIST and things will work correctly. When an infected system attacks your node, the first thing it does is copy your sys$system:rightslist.dat file and tries to get your local usernames. This dummy file will cause the attacking worm to abort with a fatal error when it tries to use the information it finds in the bogus file. If you have followed each of the above steps, VMS will run normally, and you will not be vulnerable to the CURRENT strains of the worm which are running aroung the network. The following file should be copied into SYS$SYSTEM:RIGHTSLIST.DAT exactly as it appears below: - -------------------------- CUT HERE - RIGHTSLIST.DAT ----------------- DUMMY MAINTENANCE RECORD 0123456789012345"'F$PID(ON) 0123456789012345'F$PID(ON) 0123456789012345BATCH - --------------------------- CUT HERE ---------------------------------- John McMahon of NASA/GSFC Advanced Data Flow Technology Office has created a command procedure that will have the same end-result as the above instructions. It is available by copying WANK_SHOT.COM from NSSDCA::WANK_SHOT.COM or 6277::WANK_SHOT.COM. This command procedure uses a modification of the above procedure using a SET FILE/ENTER command to set up an alias for RIGHTSLIST.DAT rather than the RENAME command above. Knowledgable system managers may want to decide for themselves which version they prefer. ------------------------------------------------------------------------ Date: Tue, 31 Oct 89 09:49:39 MST From: uunet!stcvax!rlr (Roger Rose) Subject: request for security packages Our corporate security group is attempting to compile a list of recommended security software for various systems, and it has fallen upon me to evaluate packages for UNIX-based systems. The environment consists of a wide variety of systems, running various flavors of UNIX. Not all systems have source code. The systems are connected via ethernet. NFS and DECNET support is not unusual. Some systems support modems and uucp links. What the corporate MIS-types are fantasizing is a single package that will run on any UNIX system and make it secure. (pretty funny... huh?) What *I'm* looking for falls into two categories: 1. Audit software that checks for holes in normal UNIX system administration. 2. Embedded/extended software that adds additional features. (eg. audit trails, access lists, password aging) It would be nice if the software ran on various flavors of UNIX and various hardware platforms (such as Lachman's stuff), but this is not necessarily essential. It would also be nice if source code were available, so we can make local extensions and program around vendor-specific problems. To summarize, I'm interested any information, good or bad, about any generally available security package running on any UNIX-based system. ------------------------------------------------------------------------ Date: Tue, 31 Oct 89 18:24:15 EST From: uunet!aplcen.apl.jhu.edu!johnj Subject: Net Hacker ... [ This and the next two messages came in from the sun-managers mail list. Thought they might be of interest - neil ] We (at welch.jhu.edu, not apl) had a hacker attack. It came in on the ftp account (bug? looking) and was on for 16 min total, we watched for a bit. In case any of you have an attack, one thing I wish I had done was to follow the guy out. He came in via terminal servers at Rice and PSU. I shut off our router when convinced it may be hostile/harmful, I think it may have been better to follow him out ... I got terminal server addresses ;he/she/it used & could have followed it out using some server commands lik who or help or ? to keep me going. Any advice? I called CERT to inform them. Some info follows: in my next mail ... ------------------------------------------------------------------------ Date: Tue, 31 Oct 89 18:39:21 EST From: uunet!aplcen.apl.jhu.edu!johnj Subject: Hacker detail ctd. Sorry, had to dial in to remember some names. I have a 4/280 running OSv 4.0 The first break was on ftp account, anonymous was enabled. The proces seems to have then ls -R /users directory captured a copy of my passwd file & looked for no passwd * pwds same as uid. The next break was then under an account with no passwd. A login with group 0 (sorry I will mail again with this id) appeared in my etc/passwd file. The /usr/tmp/foo* files had: foo121212 an ls -R of /users (user accounts) foo456456 directory listings of files with string passwd in them foo654654 a list of .rhosts files Nothing else seems to be harmed. The addresses of the terminal servers used is: 128.241.0.81 128.118.25.2 128.118.25.2 The first I think is rice, the next two are psu ( I called). I will mail with the strange userid passwd entry. ------------------------------------------------------------------------ Date: Tue, 31 Oct 89 18:49:13 EST From: uunet!aplcen.apl.jhu.edu!johnj Subject: Suspect ID Last for now folks, the userid that appeared in /etc/passwd was schevon uid 1871 (not the highest) with a 0 group id. ------------------------------------------------------------------------ Date: Thu, 2 Nov 89 10:21:45 PST From: uunet!gumby.dsd.TRW.COM!mdm (Mike Marcinkevicz) Subject: Re: Advisory by CERT about Sun 4.X systems Just a note that system administrators need to also remake the yellow pages passwd file if Yellow Pages is running, otherwise the change is not guaranteed to take effect. ------------------------------------------------------------------------ Date: Thu, 2 Nov 1989 20:12:38 CST From: Werner Uhrig Subject: [markw@gvl.unisys.com : NTT Challenges Hacker] I had caught a part of this story on the car-radio some weeks back and had meant to bring this to your attention. I am not in favor of such "dares", and consider NTT's action irresponsible. --From: markw@gvl.unisys.com --Newsgroups: comp.dcom.telecom --Subject: NTT Challenges Hackers [A copy of the following article appeared on one of our bulletin boards here at work. I have no idea when or where it was originally published - MHW] NTT: Calling All Hackers Tokyo - Nippon Telegraph and Telephone Corp. has issued a provocative challenge: the Japanese communications giant will give 1 million yen ($6803) to any computer hacker anywhere in the world who can break its FEAL-8 data communications security code by August 1991. Why the unusual move? The company wants to debunk a rumor circulationg in Europe that its security code has been cracked. The FEAL-8 code, developed by NTT in 1986, is widely used in Japan and overseas to protect datacom systems and integrated circuit cards from illegal access. ------------------------------------------------------------------------ End of Security Digest Volume 1 Issue 39 **********************