GENWiki

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

1. ———

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

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=<something>     !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 <something> !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 <type an INCORRECT password>
         $ MCR NCP DEF OBJECT TASK PASSWORD <type an INCORRECT 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.

3b) Place an ACL on RIGHTSLIST.DAT to prevent network access of your user names.

 For V5.X:

 SET ACL SYS$SYSTEM:RIGHTSLIST.DAT /ACL=(IDENTIFIER=NETWORK,ACCESS=NONE)

 Version 4.X systems have a more difficult time of it since the file
 locked by other images.  The suggested way of protecting it is from
 the SYSTEM account to:

    SET DEFAULT SYS$SYSTEM:
    COPY RIGHTSLIST.DAT *.TEMP
    SET ACL RIGHTSLIST.TEMP /ACL=(IDENTIFIER=NETWORK, ACCESS=NONE)
    RENAME RIGHTSLIST.TEMP *.DAT

 On completion, make sure that the protection is correct (W:R).

 You should purge the file as soon as possible.  However, you may
 not be able to purge until the system has either been rebooted or
 OPCOM  has been stopped and restarted.

3c) The logical name approach relies on "hiding" RIGHTSLIST.DAT and defining

 a system wide logical name that points to it.  Network access does not
 translate this logical name.

 $RENAME SYS$SYSTEM:RIGHTSLIST.DAT any_old_file_you_want.dat

 $DEFINE/SYSTEM/EXEC        RIGHTSLIST any_old_file_you_want.dat        

       As long as the logical symbol RIGHTSLIST points to the *real*
       file, it doesn't matter what you name it, or where it is.
       The worm EXPECTS it to be in SYS$SYSTEM:RIGHTSLIST.DAT.

4) If possible, verify that none of your users are using their username for

 their password.  Chances are that if they were, you'd have a worm
 running on your node right now though. The SPAN office has a toolkit 
 available which contains a program that can be used for this purpose.
 Contact NCF::NETMGR for details.

5) Place an ACL on the DEFAULT BATCH Queue of Version 5.x systems.

 SET ACL SYS$BATCH/OBJECT=QUEUE  /ACL=(IDENTIFIER=NETWORK, ACCESS=NONE)

 ACLS  are not supported on batch queues in Version 4.  It is 
 suggested remote Batch be disable by inserting the following command as
 the first command in SYS$SYSTEM:NETSERVER.COM, after the label LOOP:

    $ DEFINE SYS$BATCH NO_SUCH_QUEUE

 This will prevent the command from ever getting the correct queue.

1. ———

DEC also recommends that certain SYSGEN parameters be modified in order to thwart an attack technique the worm utilizes. The SPAN management supports these suggested modifications:

      $MCR SYSGEN
      USE CURRENT
      SET LGI_BRK_TERM 0
      SET LGI_BRK_TMO 3600
      SET LGI_HID_TIM 86400
      WRITE ACTIVE
      WRITE CURRENT
      EXIT
      $

If you have been attacked by this worm, please send the node name/number that the attack came from and if possible, the username of the attacker.

Send this information your local Routing Center Manager and to NCF::NETMGR on SPAN, 6277::NETMGR on HEPnet/Other nodes on the DECnet Internet.

The SPAN Management office also has a new version of ANTI_WANK.COM which can be started in a node's batch queue to search-out and report/destroy worms which may be running on a node. For copies of this procedure, send mail to NCF::NETMGR.

REMINDER - The NSI Networking Users Group (Formerly SPAN Data System Users

          Working Group - DSUWG) is meeting at Goddard Space Flight Center
          on NOV 13-15. All members of the SPAN/HEPnet community are 
          invited to attend. For information, contact Valerie Thomas, SPAN
          Project Manager at (301) 286-4740, or send mail to NCF::THOMAS.

 Downloaded From P-80 International Information Systems 304-744-2253