INTRANETWORK MEMORANDUM SPAN MANAGEMENT OFFICE
19-OCT-1989
TO: ALL SPAN ROUTING CENTER MANAGERS AND REMOTE-NODE MANAGERS
FROM: RON TENCATI - SPAN SECURITY MANAGER
GODDARD SPACE FLIGHT CENTER CODE 630.2 GREENBELT, MD. 20771 (301)286-5223
SUBJ: INFORMATION REGARDING THE DECNET WORM AND PROTECTION MEASURES
- ———
The following information covers several aspects of the "WANK" DECnet worm which was released into the "DECnet Internet" earlier in the week.
Information contained in prior reports written by John McMahon of GSFC and Kevin Oberman of LLNL was used in preparing report. The assistance of Digital Equipment Corporation is also gratefully acknowledged.
Previous messages regarding this worm appearing on various mailing lists have indicated that system managers with questions or infected nodes should call other organizations.
For clarification, any SPAN-connected system that believes itself to be infected, or attacked should contact ONLY the SPAN management at Goddard Space Flight Center, Greenbelt, MD. The security effort is being coordinated by this group and all reports should be directed there. The contact number is (301)286-7251 or (301)286-5223. Electronic mail should be sent to NSSDCA::TENCATI or NSSDCA::NETMGR only. Do not send infection reports to any other node on SPAN.
HEPnet sites should contact FNAL::DEMAR.
BACKGROUND
The worm's mission is to propagate itself randomly across the network, to seek out systems with poor security, and to establish itself in a priviliged account whereupon it will modify the system's SYS$ANNOUNCE banner to the following message:
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.
- ——–
We don't currently see that the WORM is destructive, BUT it wastes resources, and may result in denial of service by locking out priviliged users or causing non-infected nodes to consume disk space storing all the audit records from the failed access attempts.
The worm attempts to establish itself onto a system by exploiting various weaknesses in the DECnet environment. Some of these weaknesses have been addressed by previous SPAN directives and guidelines. Systems that have implemented these guidelines are not at risk.
A random number generator is used to pick the next node the worm will try to infect. The worm contains an internal list of 82 canned usernames that it will try against a system.
In addition, it attempts to copy the file RIGHTSLIST.DAT from the selected target node. This file is normally protected W:R. If this file is successfully copied, a list of usernames specific to the target system will be generated and some subset of those will be appended to the "canned" list. The candidate words the worm uses whether or not it was successful at accessing RIGHTSLIST.DAT are the following:
ACCOUNITING ACCOUNTS ALLIN1 APPLETALK ARCHIVE
BACKUP CADCAM COGNOS CRAYSTN CUSTOMER
DDSNET DEC DECNET DEFAULT DEMO
DFS$DEFAULT DIGITAL DNS$SERVER DQS$SERVER ETHERNIM
EXOS FIELD GAMES GUEST HASP
IBM INGRES INVENTORY ISSYS IVP
LIBRARY LN03_DLAND LPS$SERVER MAC MAIL
MAILER MANAGER MANUALS MASS11 MBMANAGER
MIS MRGATE MANAGER NETNONPRIV NETPRIV
NEWSMGR NOTES$SERVER OPER OPERATOR ORACLE
OSI PCAPP PCCOMMON PLUTO POSTMASTER
RDBVMS$REM RHM SECURITY SHUTDOWN SNACSV
SPEAR SPM SRS STUDENT SUPPLIES
SYSINF SYSTEM SYSTEST SYSTEST_CLIG TAPESYS
TCP TELEX TEMP TEST TRAINING
TRANSFER USER USER1 USERP VAXNET
VAXSIM VTX VXSYS
The PASSWORDS tried against the set of accounts MAY be the username ONLY, OR other passwords may be tried (such as DIGITAL, PSIPAD, MANAGER, etc) apparently depending on the version of the WORM. A bug in the worm prevents it from testing the null password as previously suspected.
- ————-
[The following section provides information relating to the behavior of the worm. This information was primarily supplied by Kevin Oberman of LLNL and John McMahon of GSFC]
- ————-
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
This check is done using the F$GETJPI system service. The results
vary depending on the amount of priviliges the account possesses.
Non-priviliged accounts which are penetrated will only be able to
return information about their own UIC, so multiple copies of the
worm could be running simultaneously under different usernames.
3. The program then changes the default DECNET account password to a random
string of at least 12 characters.
4. Information on the infected node and account/password used to access the
system is mailed to a central collection point on SPAN.
5. The process changes its name to "NETW_" followed by a random number.
6. It checks to see if it has SYSNAM priv. If so, it defines the system
announcement message to be the WANK banner.
7. If it has SYSPRV, it disables mail to the SYSTEM account.
8. Also if it has SYSPRV, it modifies the system login command procedure
(SYLOGIN.COM) to APPEAR to delete all of a user's files. (It really does nothing.)
9. The procedure then scans the accounts logical name table for symbols
which contain directory specifications. Each directory located is searched for command procedures within it protected (W:RWED). Any such procedures have code inserted at the top which tries to modify the FIELD account to a known password with login from any source and all privs. This is a primitive virus, but very effective IF the procedure should be executed by a priviliged 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 causing the PHONE object to send
them a one-line "fortune cookie" type message. The appearance of this
message does not indicate a penetration attempt on that node, more
appropriately, it indicates an "irritation attempt".
NOTE If your site receives these PHONE messages the source node information can be found in the NETSERVER.LOG files in your DECnet default account.
11. The program tries to access the RIGHTSLIST.DAT file as previously
described earlier.
12. It then steps through the list of usernames it has built and uses FAL
to validate the candidate userid/password combination. If a password is
guesses, the worm copies itself over to the target system and starts itself
via the SUBMIT/REMOTE feature of VMS.
13. When the worm finishes with a system, it picks another random system and
repeats (forever).
SECURITY GUIDELINES TO STOP THE SPREAD OF THIS WORM:
1. It is IMPERATIVE that all systems protect or remove the DECnet TASK 0
object to prevent reoccurrance of this worm, OR MORE SERIOUS ATTACKS OF THIS KIND IN THE FUTURE!
The TASK object can be secured by either of the following methods:
Method 1):
Issue the command:
NCP> CLEAR OBJECT TASK ALL
after the network is started up. This command can also be
inserted into the procedure SYSTARTUP.COM (SYSTARTUP_V5.COM on V5.x
systems) after the call to STARTNET.COM. In addition while the system
is running, this command must be executed EACH TIME the network is
restarted.
Method 2):
Issue the following commands ONCE:
NCP> SET OBJECT TASK USER DECNET PASSWORD <a bunch of garbage> NCP> DEFINE OBJECT TASK USER DECNET PASSWORD <a bunch of garbage>
This causes a login failure to be generated whenever the TASK object is accessed. Once done, this change will be permanent.
NOTE
We have received one report that TASK 0 is required
for DECwindows. Read your documentation!
2. Under NO circumstances it is acceptable for an account to have a
password the same as the username. Passwords (passPHRASES) should be
created so that they are difficult to guess, multi-word phrases are
preferable. As a precaution, we recommend that all passwords be changed.
Additionally, system managers may choose to revalidate ALL accounts.
If a system had the DECNET TASK 0 protected as above, the DECNET account
protected against SUBMIT/REMOTE (described below) and no user had their
userid as their password, it was immune to this WORM. As a result, the
number of nodes actually INFECTED by this attack is relatively small. The
number ATTACKED however, is large.
3. NETWORK ACCOUNTS
To protect against the SUBMIT/REMOTE attack, run AUTHORIZE and make sure that all network account flags are set to NOBATCH, NODIALUP, NOLOCAL, and NOREMOTE.
4. FIELD ACCOUNT
Make sure the FIELD ACCOUNT does not have the password FIELD. DISUSER the account. You must SEARCH all .COM files for a "field/remote/dialup". If the search shows it is in .COM files, They have a trojan horse appended to the files. When the .COM file is executed, This Trojan horse will try to reset account FIELD to /NODISUSER and password to FIELD. You should either delete the corrupted .COM file and obtain a good one elsewhere, or examine the file and remove the affected lines of the command procedure.
5. WORM FILES
The WORM source files are W.COM or a single alphabetic character (C or D)
followed by 4 or 5 numeric characters. (Cnnnnn.COM), ("nnnn" represents a
random number). The WORM will start a process or processes running.
These processes are named in format NETW_nnnn, and should be deleted.
PHONE_nnnn may also be running as the WORM utilizes the PHONE object in
an attempt to send a message to a user on another randomly selected node.
6. ALARMS
Some alarms generated by the WORM are related to PHONE.EXE and FAL.EXE. The majority of the alarms are login failures as the WORM attempts to log into specific accounts.
We recommend that alarms be set immediately for logins, logouts, breakin attempts, modifications to the system and net UAF's, and to changes to user and system passwords.
DISCOVERY AND CLEANUP
1. Log into a "privileged account"
$ SHOW SYSTEM
Look for NETW_dddd (dddd represents 4 or 5 random digits)
IF NETW_dddd is found, note the process ID and do:
$ STOP PROCESS/ID=NETW_dddd
The command procedure included below can be used by system
managers to perform this function in the background. It is
recommended that this procedure be run for the next week or
so until the worm is killed-off.
2. Check the protection on all command procedures. If any are (W:REWD), check for infection. There should be two versions. The
older one should be OK unless multiple infection has occurred.
Generally the oldest version is OK but this is not guaranteed.
An easy method is to execute the command on every disk:
$SEARCH dev:[000000...]*.COM;* PASS=FIELD Any infected files will contain the line:
$mcr authorize add field/remote/dialup/network/batch/defpriv=all /priv=all/flag=(nodisuser,nocaptive,nopwd_expire)/pass=field
3. Redefine or deassingn the SYS$ANNOUNCE logical name. Replace the correct SYS$ANNOUNCE messages. (Note the initial value of SYS$ANNOUNCE to identify the infected user account and location of the false announce message files (on infected systems only).
4. Clean up SYSLOGIN.COM. Remove the bogus file deletion routine.
5. Search all login directories for files named Cddddd.com or
Dddddd.com. Dddddd.COM is a dummy file which precedes the actual
infection. Cddddd.COM is the worm itself (normally both are
deleted by the worm).
6. If your node is attacked or penetrated, please contact the SPAN
Management immediately via MAIL or by phone. Send all messages
to either NSSDCA::TENCATI or NSSDCA::NETMGR. If you do not have
NSSDCA defined in your database, use the node number 6277::. We
need to know which nodes have the worm running on them so we can
coordinate cleanup measures with the appropriate personnel.
NOTE A tell-tale sign that your node was ATTACKED will be multiple login failure reports in your operator.log file.
7. DO NOT DELETE ANY OF YOUR LOG FILES OR AUDIT TRAILS. THIS INFORMATION MAY BE REQUESTED OF YOU LATER IF THIS MATTER IS GOING TO BE PROSECUTED.
PREVENTION MEASURES
1. Ensure all user accounts have good password management. (No
"user user" or null passwords.)
2. No world READ command procedures in user or priviliged
accounts.
3. No TASK objects.
4. Do not use the the account names as the password on network
accounts. (Use the V5.2 approach - separate object userid's)
5. Ensure all network accounts are set NOBATCH, NOLOCAL, NODIALUP,
and NOREMOTE and have a PRCLIM of 1.
6. Audit all changes by AUTHORIZE. Analyze audit trail for changes
to the FIELD account.
7. Place an ALARM ACE on SYS$MANAGER:SYLOGIN.COM;* for
WRITE+DELETE+SUCCESS access. Enable ACL auditing. Analyze the
audit trail for change to SYLOGIN.COM.
8. Make sure ACCOUNTING and OPCOM are running and proper alarms
are set.
9. Protect RIGHTSLIST.DAT against World access. Alternatively
move or rename it and define the logical symbol RIGHTSLIST
to the new file. ($DEF/SYS/EXEC RIGHTSLIST <renamed file>)
This will limit the ability of the worm to determine
actual valid usernames.
—————————————————————————-
The following command procedure was written by John McMahon at GSFC. It can be run as a batch job under a priviliged account. This procedure searches all processes on a running system to determine if the worm process is present. If detected, the worm is deleted.
—————————- ANTIWANK.COM ———————————-
$!
$! Antiwank.Com - This program performs two functions. It kills any
$! copy of the worm currently running (any process starting with NETW_
$! in it's name) and disguises itself as a copy of the worm to help
$! prevent new copies from being created.
$!
$! This program should be submitted to a batch queue under the username
$! SYSTEM. It requires WORLD priv to check the process names on your
$! CPU. It runs continuously, but uses little overhead.
$!
$! This program uses the process name "NETW_AntiWank". It should not be
$! confused as a copy of the worm program itself (which uses
$! NETW_randomnumber).
$!
$! The system manager should add additional userids to the line
$! beginning with SEND_MAIL_TO. If the program detects the worm,
$! it will send a detection message to the userids in SEND_MAIL_TO.
$!
$! John McMahon
$! NASA/GSFC CODE 630.4
$!
$! 18-OCT-1989 16:11:56.21
$!
$! SPAN: SDCDCL::FASTEDDY
$! Internet: Fasteddy@Dftnic.Gsfc.Nasa.Gov
$! Bitnet: Fasteddy@Dftbit
$!
$! Phone: 301-286-2045
$!
$ Set NoON
$ AntiWank_Name = "NETW_AntiWank"
$ Process_Name_Prefix = "NETW_"
$ Send_Mail_To = "SYSTEM"
$ Set Process/Priv=(World)
$ Set Process/Name="AntiWank_Name'"
$ Start:
$ Context = ""
$ Pid_Loop:
$ Check_Pid = F$Pid(Context)
$ If Check_Pid .Eqs. "" Then Goto End_Pid_Loop
$ Check_Prcnam = F$Edit(F$Getjpi(Check_Pid,"PRCNAM"),"TRIM")
$ Write Sys$Output "Process Name: ",Check_Prcnam
$ If Check_Prcnam .Eqs. AntiWank_Name Then Goto Pid_Loop
$ If F$Extract(0,5,Check_Prcnam) .Eqs. Process_Name_Prefix Then -
Gosub Action_Routine
$ Goto Pid_Loop
$!
$ End_Pid_Loop:
$ Write Sys$Output F$TIME()," ANTIWANK is still working for you"
$ Wait 00:10:00
$ Goto Start
$!
$ Action_Routine:
$ Write Sys$Output "Action Routine"
$ Username = F$Getjpi(Check_Pid,"Username")
$ Stop/Id='Check_Pid'
$ Mail NL: 'Send_Mail_To' -
/SUBJECT="Worm Terminated $Status' Check_Prcnam' Check_Pid' ''Username'"
YES
$ Return
—————————END OF ANTIWANK.COM————————-
Downloaded From P-80 International Information Systems 304-744-2253