textfiles/internet/span03.vir

============================================================================
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
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) 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.

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