Copy Link
Add to Bookmark
Report
DDN Security Bulletin issue 03
**********************************************************************
DDN Security Bulletin 03 DCA DDN Defense Communications System
18 Oct 89 Published by: DDN Security Coordination Center
(SCC@NIC.DDN.MIL) (800) 235-3155
DEFENSE DATA NETWORK
SECURITY BULLETIN
The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DCA contract as a means of communicating
information on network and host security exposures, fixes, & concerns
to security & management personnel at DDN facilities. Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest". The bulletin
pathname is SCC:DDN-SECURITY-nn (where "nn" is the bulletin number).
**********************************************************************
W.COM ("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 (not TCP/IP) protocols.
At least two versions of this worm exist and more may be created.
Non-VMS systems are immune; TCP/IP networks are not at risk.
While this program is very similar to last year's HI.COM (or "Father
Christmas") worm (see DDN MGT Bulletin #50 23 Dec 88), THIS IS NOT A
PRANK. Instead of a "cute" Christmas greeting, W.COM appends code to
.com files and displays this banner:
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.
Initial reports described the worm as destructive, i.e. it would erase
files. Detailed analysis by the CERT, Lawrence Livermore National
Laboratory, and FermiLab has not found any code that would perform
file erasures. However, files are altered and new accounts created.
Serious security holes are left open by this worm.
It is very 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.
When the DDN PMO received these initial reports, the MailBridge
filters were activated to preclude any traffic from passing between
MILNET and the rest of the Internet. The filters will be turned off
(restoring full interoperability) Tuesday 17 October 1989 NLT 17:00
EDT. (NOTE: W.COM could traverse the MILNET only if encapsulated in
a TCP/IP "envelope", i.e. "assisted" by a human agent, and cannot
"infect" the MILNET.)
R. Kevin Oberman from Lawrence Livermore National Laboratory 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 also suggests checking every .com file on the system. The
worm appends code to .com files which will reopen a security hole
every time the program is executed.
An analysis of the worm (provided by R. Kevin Oberman and used with
his permission) appears below. Included with the analysis is a DCL
program that will block the current version of the worm. This program
should provide enough time to close up obvious security holes.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Date: Mon, 16 Oct 89 15:30 PDT
From: "Kevin Oberman, LLNL, (415)422-6955" <OBERMAN@icdc.llnl.gov>
Subject: Report on network worm ***URGENT***
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
GEMTOP 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 from 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
==============================================================================
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.)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
If you have any technical questions or have an infected system, please
call the CERT:
Computer Emergency Response Team
Email: cert@sei.cmu.edu
Telephone: 412-268-7090 (answers 24 hours a day)
If you have any general questions, please call the SCC:
Security Coordination Center
Email: scc@nic.ddn.mil
Telephone: 1-800-235-3155 or 415-859-3695 (7 a.m. to 5 p.m. Pacific time).
**********************************************************************
