TO: ALL SPAN SYSTEM MANAGERS
FROM: SPAN MANAGEMENT OFFICE
GODDARD SPACE FLIGHT CENTER CODE 630.2
GREENBELT, MD. 20771
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
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
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.
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:
UAF> mod DECNET /pass= !anything BUT "DECNET"
UAF> mod DECNET /flag=lockpwd/nobatch/prclm=0
Then, to match default access control information in the executor (so
MAIL and NML will still work):
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.
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.
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.
THE ACL APPROACH MAY REQUIRE A REBOOT TO PURGE THE OLD RIGHTSLIST.DAT
ON V4.7 SYSTEMS.
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.
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.
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.
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:
SET LGI_BRK_TERM 0
SET LGI_BRK_TMO 3600
SET LGI_HID_TIM 86400
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
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