RISKS-LIST: RISKS-FORUM Digest Tuesday 24 October 1989 Volume 9 : Issue 34 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Earthquake and Computers (Bill Murray) Black Friday was only grey in Boston (Pete Kaiser) Human chess supremacy at risk? (Bob Barger) CERT Ultrix 3.0 Advisory (Ed DeHart) [OLD STUFF TO SOME OF YOU] CERT DECnet Worm Advisory (Ed DeHart) [OLD STUFF TO SOME OF YOU] The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]get risks-i.j . Vol summaries now in risks-i.0 (j=0) ---------------------------------------------------------------------- Date: Mon, 23 Oct 89 13:03 EDT From: WHMurray.Catwalk@DOCKMASTER.NCSC.MIL Subject: Earthquake and Computers Today's ComputerWorld contained a number of articles on the impact of the 1989 San Francisco earthquake on computers. I thought the following note about the impact of computers on the earthquake was interesting. "It is a measure of the dependence of a bank's customers that even after crossing a foot-wide crack in the sidewalk in the city's Mission District, one customer complained bitterly that the teller machine would not work. When reminded that the system's cables had to span the quake-torn area, the customer replied, "You'd think they'd know how to do something about this." And, of course, they do. The answer is to have many ATMs. A nearby article reports that eighty percent of the cities ATMs were up and running. William Hugh Murray, Fellow, Information System Security, Ernst & Young 2000 National City Center Cleveland, Ohio 44114 21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840 ------------------------------ Date: Sun, 22 Oct 89 18:32:45 PDT From: kaiser%cheese.DEC@src.dec.com (Mgr, Systems Consulting; 296-4345) Subject: Black Friday was only grey in Boston While driving to work the Monday after the 190-point Friday-the-13th drop in the Dow Jones index, I heard on WBUR (public radio morning news in Boston) an interview with one of the managers of the Boston Stock Exchange, said in the program to be one of the fastest-growing in the United States. He remarked that the Boston Exchange had no difficulty keeping up with the volume of trading nationwide, because their computer system could be turned off gracefully so that trades could be done manually -- apparently the only way to keep up with high volumes. (Remember all those stories of computers unable to keep up with the volume of trading?) He remarked further that the Boston exchange was able to keep up with the business on the day of the 500-point drop because the computer system wasn't yet installed. Sounds very sensible to me, and though I'm tempted to editorial comment, I'll refrain. ---Pete kaiser@cheese.enet.dec.com DEC, 2 Mt. Royal Ave. (UPO1-3), Marlboro MA 01752-9108 508-480-4345 (machine: 617-641-3450) ------------------------------ Date: Mon, 23 Oct 89 11:01 CDT From: Bob Barger Subject: Human chess supremacy at risk? THE NEW YORK TIMES (National edition) for Monday, October 23, has a front-page story headlined "Kasparov Beats Chess Computer (for Now)." The story (written by Harold C. Schonberg) reports that Gary Kasparov, the highest-ranked player in the history of chess, beat a computer named "Deep Thought" in the first game of a two game match. Commenting on the prospect of a more powerful machine being developed in five years that could scan a billion chess poisitions a second, Mr. Kasparov was reported to have said: "That means I can be champion for five more years....But I can't visualize living with the knowledge that a computer is stronger than the human mind. I had to challenge Deep Thought for this match to protect the human race." In many respects, a computer already is "stronger" than the human mind. Perhaps what Mr. Kasparov fears is that a computer might become more "creative" or "original" than the human mind...that it might become something more than an "extension" or "tool" of the human mind. Clearly, a lot of terms will have to be defined before that fear can be addressed...terms like "stronger," "creative," "original," "tool," "extension," and, perhaps most in need of definition, "human" and "mind." Bob Barger, Eastern Illinois University ------------------------------ Date: Wed, 18 Oct 89 15:16:26 EDT From: ecd@SEI.CMU.EDU Subject: CERT Ultrix 3.0 Advisory CERT Advisory Update October 18, 1989 DEC/Ultrix 3.0 Systems This is a repost of the Ultrix 3.0 advisory. We have received the sum output for DECstations. ============================================================================= Recently, the CERT/CC has been working with several Unix sites that have experienced breakins. Running tftpd, accounts with guessable passwords or no passwords, and known security holes not being patched have been the bulk of the problems. The intruder, once in, gains root access and replaces key programs with ones that create log files which contain accounts and passwords in clear text. The intruder then returns and collects the file. By using accounts which are trusted on other systems the intruder then installs replacement programs which start logging. There have been many postings about the problem from several other net users. In addition to looking for setuid root programs in users' home directories, hidden directories '.. ' (dot dot space space), and a modified telnet program, we have received two reports from Ultrix 3.0 sites that the intruders are replacing the /usr/bin/login program. The Ultrix security hole being used in these attacks is only found in Ultrix 3.0. Suggested steps: 1) Check for a bogus /usr/bin/login. The sum program should report the following for the DEC supplied login program. 27379 67 for VAXstation Ultrix 3.0 35559 116 for DECstation Ultrix 3.0 2) Check for a bogus /usr/etc/telnetd. The sum program should report the following for the DEC supplied telnetd program. 23552 47 for VAXstation Ultrix 3.0 45355 84 for DECstation Ultrix 3.0 3) Look for .savacct in either /usr/etc or in users' directories. This may be the file that the new login program creates. It could have a different name on your system. 4) Upgrade to Ultrix 3.1 ASAP. 5) Monitor accounts for users having passwords that can be found in the /usr/dict/words file or have simple passwords like a persons name or their account name. 6) Search through the file system for programs that are setuid root. 7) Disable or modify the tftpd program so that anonymous access to the file system is prevented. If you find that a system that has been broken into, changing the password on the compromised account is not sufficient. The intruders do remove copies of the /etc/passwd file in order to break the remaining passwords. It is best to change all of the passwords at one time. This will prevent the intruders from using another account. Please alert CERT if you do find a problem. Thank you, Ed DeHart Computer Emergency Response Team Email: cert@sei.cmu.edu Telephone: 412-268-7090 (answers 24 hours a day) ------------------------------ Date: Wed, 18 Oct 89 15:16:54 EDT From: ecd@SEI.CMU.EDU Subject: CERT DECnet Worm Advisory CERT Advisory October 17, 1989 "WANK" Worm On SPAN Network On 16 October, the CERT received word from SPAN network control that a worm was attacking SPAN VAX/VMS systems. This worm affects only DEC VMS systems and is propagated via DECnet protocols, not TCP/IP protocols. If a VMS system had other network connections, the worm was not programmed to take advantage of those connections. The worm is very similar to last year's HI.COM (or Father Christmas) worm. This is NOT A PRANK. Serious security holes are left open by this worm. The worm takes advantage of poor password management, modifies .com files, and spreads to other systems via DECnet. It is also important to understand that someone in the future could launch this worm on any DECnet based network. Many copies of the virus have been mailed around. Anyone running a DECnet network should be warned. R. Kevin Oberman from Lawrence Livermore National Labs reports: "This is a mean bug to kill and could have done a lot of damage. Since it notifies (by mail) someone of each successful penetration and leaves a trapdoor (the FIELD account), just killing the bug is not adequate. You must go in an make sure all accounts have passwords and that the passwords are not the same as the account name." The CERT/CC also suggests checking every .com file on the system. The worm appends code to .com files which will reopen a security hole everytime the program is executed. An analysis of the worm appears below and is provided by R. Kevin Oberman of Lawrence Livermore National Laboratory. Included with the analysis is a DCL program that will block the current version of the worm. At least two versions of this worm exist and more may be created. This program should give you enough time to close up obvious security holes. If you have any technical questions or have an infected system, please call the CERT/CC: Computer Emergency Response Team Email: cert@sei.cmu.edu Telephone: 412-268-7090 (answers 24 hours a day) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Report on the W.COM worm. R. Kevin Oberman Engineering Department Lawrence Livermore National Laboratory October 16, 1989 The following describes the action of the W.COM worm (currently based on the examination of the first two incarnations). The replication technique causes the code to be modified slightly which indicates the source of the attack and learned information. All analysis was done with more haste than I care for, but I believe I have all of the basic facts correct. First a description of the program: 1. The program assures that it is working in a directory to which the owner (itself) has full access (Read, Write,Execute, and Delete). 2. The program checks to see if another copy is still running. It looks for a process with the first 5 characters of "NETW_". If such is found, it deletes itself (the file) and stops its process. NOTE A quick check for infection is to look for a process name starting with "NETW_". This may be done with a SHOW PROCESS command. 3. The program then changes the default DECNET account password to a random string of at least 12 characters. 4. Information on the password used to access the system is mailed to the user GEMPAK on SPAN node 6.59. Some versions may have a different address. 5. The process changes its name to "NETW_" followed by a random number. 6. It then checks to see if it has SYSNAM priv. If so, it defines the system announcement message to be the banner in the program: W O R M S A G A I N S T N U C L E A R K I L L E R S _______________________________________________________________ \__ ____________ _____ ________ ____ ____ __ _____/ \ \ \ /\ / / / /\ \ | \ \ | | | | / / / \ \ \ / \ / / / /__\ \ | |\ \ | | | |/ / / \ \ \/ /\ \/ / / ______ \ | | \ \| | | |\ \ / \_\ /__\ /____/ /______\ \____| |__\ | |____| |_\ \_/ \___________________________________________________/ \ / \ Your System Has Been Officically WANKed / \_____________________________________________/ You talk of times of peace for all, and then prepare for war. 7. If it has SYSPRV, it disables mail to the SYSTEM account. 8. If it has SYSPRV, it modifies the system login command procedure to APPEAR to delete all of a user's file. (It really does nothing.) 9. The program then scans the accounts logical name table for command procedures and tries to modify the FIELD account to a known password with login form any source and all privs. This is a primitive virus, but very effective IF it should get into a privileged account. 10. It proceeds to attempt to access other systems by picking node numbers at random. It then used PHONE to get a list of active users on the remote system. It proceeds to irritate them by using PHONE to ring them. 11. The program then tries to access the RIGHTSLIST file and attempts to access some remote system using the users found and a list of "standard" users included with the worm. It looks for passwords which are the same as that of the account or are blank. It records all such accounts. 12. It looks for an account that has access to SYSUAF.DAT. 13. If a priv. account is found, the program is copied to that account and started. If no priv account was found, it is copied to other accounts found on the random system. 14. As soon as it finishes with a system, it picks another random system and repeats (forever). Response: 1. The following program will block the worm. Extract the following code and execute it. It will use minimal resources. It create a process named NETW_BLOCK which will prevent the worm from running. ------- Editors note: This fix will work only with this version of the worm. Mutated worms will require modification of this code; however, this program should prevent the worm from running long enough to secure your system from the worms attacks. ------- ============================================================================== $ Set Default SYS$MANAGER $ Create BLOCK_WORM.COM $ DECK/DOLLAR=END_BLOCK $LOOP: $ Set Process/Name=NETW_BLOCK $ Wait 12:0 $ GoTo loop END_BLOCK $ Run/Input=SYS$MANAGER:BLOCK_WORM.COM/Error=NL:/Output=NL:/UIC=[1,4] - SYS$SYSTEM:LOGINOUT ============================================================================== ------- Editor's note: This fix might only work if the worm is running as SYSTEM. An earlier post made by the CERT/CC suggested the following: $ 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. --------- 2. Enable security auditing. The following command turns on the MINIMUM alarms. The log is very useful in detecting the effects of the virus left by the worm. It will catch the viruses modification of the UAF. $ Set Audit/Alarm/Enable=(ACL,Authorization,Breakin=All,Logfailure=All) 3. Check for any account with NETWORK access available for blank passwords or passwords that are the same as the username. Change them! 4. If you are running VMS V5.x, get a copy of SYS$UPDATE:NETCONFIG_UPDATE.COM from any V5.2 system and run it. If you are running V4.x, change the username and password for the network object "FAL". 5. If you have been infected, it will be VERY obvious. Start checking the system for modifications to the FIELD account. Also, start scanning the system for the virus. Any file modified will contain the following line: $ oldsyso=f$trnlnm("SYS$OUTPUT") It may be in LOTS of command procedures. Until all copies of the virus are eliminated, the FIELD account may be changed again. 6. Once you are sure all of the holes are plugged, you might kill off NETW_BLOCK. (And then again, maybe not.) ------------------------------ End of RISKS-FORUM Digest 9.34 ************************