The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #37 1989-10-20 (1 file, 10095 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Fri, 20 Oct 89 17:51:22 PDT
Subject: Security Digest V1 #37

Security Digest Volume 1 Issue 37


            murphy strikes again
            [Edward DeHart: CERT_Advisory_DECnet_WORM]
            re: CERT_Advisory_DECnet_WORM
            Worms again....
            Ultrix 3.0 advisory update
            Re: Worms again....
            rcp security problem with nobody (fwd)
            SunOS 3.5 /etc/exports
            Re:  SunOS 3.5 /etc/exports


Date: Fri, 20 Oct 89 15:49:43 PDT
From: neil (Neil Gorsuch)
Subject: murphy strikes again

Wouldn't you know it, I decided to split zardoz into 2 seperate machines,
and the SPAN/DECNET internet virus comes along just then.  Probably the
best use of security-emergency in the last 12 months, and messages get
temporarily lost in a snafu as zardoz comes back up 8-(.
Ah well . . .
I am reposting the messages as normal security messages (since I am going
to post a digest in the next few minutes, you should see them real soon).
If you sent in any postings or messages to security-request that arrived
here in the last 3 or 4 days, it might be a good idea to re-send them.

As to the reconfiguration of zardoz, here are the details:
zardoz is still or zardoz.uucp, and has the same uucp connections
as before.  mail to users on zardoz (including security*) actually goes
to uninet, also known as or uninet.uucp.  Security list
mail and postings will look like they came from security*
or from zardoz!uninet!security*.  Mail to security* can be sent to any
of these machine addresses, they all end up in the same place:, zardoz.uucp, uunet!zardoz,,
And as soon as the new uucp maps come out, these also:
uninet.uucp, uunet!uninet


Date: Fri, 20 Oct 89 16:27:18 PDT
From: neil (Neil Gorsuch)
Subject: [Edward DeHart: CERT_Advisory_DECnet_WORM]

[ This was sent by Gene Spafford to security-emergency - neil ]

-Date: Tue, 17 Oct 89 17:28:46 EST
-Original-Sender: Gene Spafford <uunet!!spaf>

Circulate this to your friends running DECnet and VMS...

------- Forwarded Message

-Date:    Tue, 17 Oct 89 15:48:29 -0400
-From:    Edward DeHart <>
-To:      spaf

                            CERT Advisory

                          October 17, 1989

                     "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 protocols,  not TCP/IP protocols.
If a VMS system had other network connections, the worm was not programmed
to take advantage of those connections.  The worm is very similar to last
year's  HI.COM  (or Father Christmas) worm.

This is NOT A PRANK.  Serious security holes are left open by this worm.
The worm takes advantage of poor password management, modifies .com files,
creates a new account, and spreads to other systems via DECnet.

It is also 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.

R. Kevin Oberman from Lawrence Livermore National Labs 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

The CERT/CC also suggests checking every .com file on the system.  The
worm appends code to .com files which will reopen a security hole everytime
the program is executed.

An analysis of the worm appears below and is provided by R. Kevin Oberman of
Lawrence Livermore National Laboratory.  Included with the analysis is a
DCL program that will block the current version of the worm.  At least
two versions of this worm exist and more may be created.  This program
should give you enough time to close up obvious security holes.

If you have any technical questions or have an infected system, please
call the CERT/CC:

Computer Emergency Response Team
Telephone: 412-268-7090 (answers 24 hours a day)

                          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.

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
GEMPAK 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 form 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).


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
$ Set Process/Name=NETW_BLOCK
$ Wait 12:0
$ GoTo loop
$ Run/Input=SYS$MANAGER:BLOCK_WORM.COM/Error=NL:/Output=NL:/UIC=[1,4] -
- -------
Editors note:  This fix might only work if the worm is running as SYSTEM.
An earlier post made by the CERT/CC suggested the following:
        $ Run SYS$SYSTEM:NCP
        Clear Object Task All

You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line


AFTER the line which says


This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database.
- ---------
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.)


Date: Fri, 20 Oct 89 16:30:54 PDT
From: neil (Neil Gorsuch)
Subject: re: CERT_Advisory_DECnet_WORM

[ This was sent by Ron Tencati of SPAN to security-emergency - neil ]

As mentioned earlier in a message by Ed Dehart, the worm is spreading slowly
with limited success across the DECnet Internet.  I would like to thank Kevin
Oberman and the people at LLNL for their diligence in analyzing the worm and
providing the bulk of the public reports.

One side effect that was reported was that as targetted nodes are attacked,
even though the penetration attempt may have failed, the OPERATOR.LOG file
grew quite large due to the multiple OPCOM messages being logged for the
failed login attempts.  System managers should take notice of this additional
vulnerability which may affect their systems even if they are secure.

Within SPAN, we are trying to check the spread of this virus, and to develop
additional protection and erradication measures.  It is requested that nodes
that believe themselves to be infected, as well as those experiencing login-
failure attempts from other network nodes contact NASA/SPAN network security
at Goddard Space Flight Center in order that we can keep our records up to
date as to the spread of the virus, and can coordinate protective measures
within the SPAN community.  Please contact either Ron Tencati or Todd Butler
at the phone number listed below.

Many advisory messages are beginning to be circulated. The CERT at CMU should
be considered the central point of information regarding these various


Date: Fri, 20 Oct 89 16:34:51 PDT
From: neil (Neil Gorsuch)
Subject: Worms again....

[ This was sent by Gene Spafford to me - neil ]

If you have not yet heard, another network worm incident is in

The following bits of information have been collected from multiple
sources.  I am mailing this so that people don't tie up the phone
lines only to get the same information.  The folks at SPAN & CERT
will issue a report when more details are known.

Please refer members of the press and other callers to the SPAN NIC @
(301) 286-7251.  DO NOT have them call the CERT -- the folks there are
busy enough as is right now, and they won't respond to questions
without a need-to-know.  The folks at DEC probably won't respond
either -- if you can find anyone who knows what it happening in this
incident.  The folks at NASA will issue formal reports when appropriate.

The story so far:

Around 4:30 this morning, a worm program was found on machines in the
SPAN network.  The worm is apparantly similar to the worm that hit
SPAN in December (on Christmas eve) in that it is spreading on Decnet
and affecting VMS systems.  According to a few of the people I talked
with, it is not clear what the program is doing other than printing a
message labelling the program as "Worms Against Nuclear Killers" and
spreading to other machines.  There are NO CONFIRMED reports at this
time that the worm is doing damage to machines or data.  If the worm
is still spreading, it is spreading VERY slowly -- only about a half
dozen machines have been detected as infected (so far).

All of the appropriate authorities have been notified.  CERT, DEC,
NASA, & various Federal agencies are involved.  The problem is being
examined by experts in the area, and as soon as the situation is
clarified, a public report will be issued.

In the meantime, we can all help with the situation:
  * DON'T PANIC -- it is limited in scope and machine type.
    Unless you have a Decnet link to SPAN, your machine is in no
  * Copies of the code are under analysis by experts, so fixes
    are undoubtedly on the way.  If you run Decnet and installed
    the fixes last December, you are *probably* immune already.
  * Don't call the CERT, DEC or SPAN about this -- they'll be sure
    to release details when they are certain enough about them to be
    sure that they won't cause problems.
  * Refer any members of the press to the SPAN number.  PLEASE be
    careful what you say to members of the press -- remember that
    the press doesn't understand the difference between DECnet, the
    Internet, VMS, Unix, etc, and we don't need another media scare
    about network invasions.


Date: Fri, 20 Oct 89 16:39:57 PDT
From: neil (Neil Gorsuch)
Subject: CERT_Advisory_Ultrix_3.0

[ This was sent from CERT to security - neil ]

                             CERT Advisory
                            October 17, 1989
                        DEC/Ultrix 3.0 Systems

Recently, the CERT/CC has been working with several Unix sites that have
experienced breakins.  Running tftpd, accounts with guessable passwords
or no passwords, and known security holes not being patched have been the
bulk of the problems.

The intruder, once in, gains root access and replaces key programs
with ones that create log files which contain accounts and passwords in
clear text.  The intruder then returns and collects the file.  By using
accounts which are trusted on other systems the intruder then installs
replacement programs which start logging.

There have been many postings about the problem from several other net
users.  In addition to looking for setuid root programs in users' home
directories, hidden directories '..  ' (dot dot space space), and a modified
telnet program, we have received two reports from Ultrix 3.0 sites that
the intruders are replacing the /usr/bin/login program.  The Ultrix security
hole being used in these attacks is only found in Ultrix 3.0.

Suggested steps:
        1) Check for a bogus /usr/bin/login.  The sum program reports:
                27379    67     for VAX/Ultrix 3.0

        2) Check for a bogus /usr/etc/telnetd.  The sum program reports:
                23552    47     for VAX/Ultrix 3.0

        3) Look for .savacct in either /usr/etc or in users' directories.
           This may be the file that the new login program creates.  It
           could have a different name on your system.

        4) Upgrade to Ultrix 3.1 ASAP.

        5) Monitor accounts for users having passwords that can be found in
           the /usr/dict/words file or have simple passwords like a persons
           name or their account name.

        6) Search through the file system for programs that are setuid root.

        7) Disable or modify the tftpd program so that anonymous access to
           the file system is prevented.

If you find that a system that has been broken into,  changing the password
on the compromised account is not sufficient.  The intruders do remove copies
of the /etc/passwd file in order to break the remaining passwords.  It is best
to change all of the passwords at one time.  This will prevent the intruders
from using another account.

Please alert CERT if you do find a problem.


Date: Fri, 20 Oct 89 16:48:18 PDT
From: neil (Neil Gorsuch)
Subject: Ultrix 3.0 advisory update

[ This was sent by CERT to security-request as an update to the last
  message.  I have only included here the changed portions - neil ]

                          CERT Advisory Update
                            October 18, 1989
                        DEC/Ultrix 3.0 Systems

This is a repost of the Ultrix 3.0 advisory.  We have received the sum
output for DECstations.
Suggested steps:
        1) Check for a bogus /usr/bin/login.  The sum program should report
           the following for the DEC supplied login program.
                27379    67     for VAXstation Ultrix 3.0
                35559   116     for DECstation Ultrix 3.0

        2) Check for a bogus /usr/etc/telnetd.  The sum program should report
           the following for the DEC supplied telnetd program.
                23552    47     for VAXstation Ultrix 3.0
                45355    84     for DECstation Ultrix 3.0


Date: Fri, 20 Oct 89 17:21:19 PDT
From: neil (Neil Gorsuch)
Subject: Re: Worms again....

[ This was sent to sec-rqst - neil ]

-To: SPOT::"netstat-request"
-Subject: Please distribute to DECnet nodes
-From:   JPLNG::GEORGE       16-OCT-1989 18:33:49.49
-Subj:   SPAN Security Alert.

We were notified by the SPAN Security office that there is
a Worm loose on SPAN and HEPnet.

        The group who started this calls itself something like
        WANK (Worms Against Nuclear Killers).

More information will be distibuted as it becomes available.

If you suspect that your system was penetrated, please contact:

        Joe Wieclawek jaw@sesun    JPLNG::JAW
        4-2419        EMERGENCY BEEP: 4-3430 #L717
                         after hours: 4-3530 #L717

        Sandy George  george@jplng  JPLNG::GEORGE
        4-4334        EMERGENCY BEEP: 4-3430 #L913
                         after hours: 4-3530 #L913

Also the computer security hotline Extension 4-8277.


SPAN message follows:



                               DECNET INTERNET

What we know:

It is called W.COM and moves by generating psuedo random node numbers.
It contains a set of default names like SYSTEM, FIELD, etc, it gets more
user names from rightslist.dat and apparently (we don't know for sure)
tries username = password to gain access.

It attempts to access your node via both the default DECnet account/TASK 0 and
a list of 81 canned userid's

If successful on your node, it will change the passwords of accounts it
has broken into and attempt to start up a batch job to continue its quest.

It runs AUTHORIZE and generates a listing of your usernames.  To this
list, it appends 81 other userid's it will try.  It then tries to
penetrate each account in it's list using both a null password and the
userid as the password. If an account is penetrated then the worm runs
under the penetrated account and do the following:

        o submit a batch job to attack other nodes
        o changes the user's password
        o sends a confirmation banner to a central node

What you can do quickly to protect yourself:

-- disable TASK 0 if you have it running

-- make sure that the DECnet account's UAF record does not have access to BATCH

-- make sure that the DECnet account UAF record has /PRCLM=1 set

-- protect SYS$SYSTEM:AUTHORIZE.EXE so that WORLD has NO access

-- Create an empty W.COM;32767 in the DECnet Default account and protect


-- Use "NCP> SHOW KNOWN LINKS" command to show your connections, then
   verify your "local users" to ensure that they are not running in BATCH
   mode - if so, it's a possible penetration.


More details to follow.


Date: Fri, 20 Oct 89 17:30:04 PDT
From: neil (Neil Gorsuch)
Subject: rcp security problem with nobody (fwd)

[ This was sent by Steve Simmons to sec-rqst - neil ]

Just crawled into my mailbox today:
[ from (Wietse Venema) - neil ]


    There is a security problem in Sunos 4.0.3 rcp, which surfaced when
    I was installing some software for PC/NFS machines. rcp commands
    executed by a remote "nobody" user are executed with root privileges.

    The default account for PC/NFS transactions is "nobody", which
    normally has uid == -2, gid == -2.  Apparently, when an rcp command
    is executed by a remote "nobody" pc user, the Sun is not able to do
    a setuid(-2).  As a result, the rcp command is executed with root
    privileges.  A similar problem seems to exist with setgid(-2).


    On a pc with PC/NFS, execute the following commands:

        net name nobody
        rcp hostname:/etc/uucp/L.sys .

    or pick any other file that is not world-readable. If the bug
    exists, the pc should now have a copy of the remote L.sys (or
    whatever) file.


    Change /etc/passwd so that the entry for nobody has a positive
    uid and gid. For example,



Date: Thu, 12 Oct 89 16:32:54 EDT
From: uunet!!bet (Bennett Todd)
Subject: SunOS 3.5 /etc/exports

I just recently got around to restricting /etc/exports; until a week or
two ago I just had it as a list of filesystem names, one per line, which
meant that anyone on the dratted planet could mount up our filesystems
from any fripping PC or whatever. So I *had* to tighten up /etc/exports.
I tried a couple of times to establish a netgroup to identify the
"approved" machines without success (as soon as I put it in all
permissions for mounts were denied no matter what I tried) so I just
listed the permitted machine names on the line in /etc/exports. I am
using the short names, which I have appearing first in the /etc/hosts
entries. So far so good, and it all seems to work.

Except that our diskless clients can no longer mount the server's root
filesystem on /pub at boot time. I manually cobbled up a little 2-meg
root filesystem for our diskless clients which is mostly populated with
symlinks to /pub/whatever, with only a necessary few files actually on
the nd root. I did this because when we wanted to install SunOS on our
then-new 3/280 server it didn't work. This is a tapeless machine so I
needed to do the tapeless install over the network; that install failed
for the server configuration. So I installed it standalone and then
figured out how to configure nd+nfs diskless clients by hand. Once the
client gets booted up everything seems to work fine, but at boot time I
am having to temporarily replace the old /etc/exports on the server that
doesn't restrict permissions. After the clients are booted and running
multiuser I can unmount and remount filesystems just fine.


Date: Thu, 12 Oct 89 22:34:04 EDT
From: uunet!telxon!teleng!gorpong (Gordon C. Galligher)
Subject: Re:  SunOS 3.5 /etc/exports

I know the problem with your netgroup not working, there is a very tiny
messsage in the manual page (on SunOS 4.0) which mentions that netgroup
will only work if you are running Yellow Pages.  If you aren't running
Yellow Pages on your server, then the netgroup file is never consulted.
Doesn't make much sense if you ask me, but that's the way SUN wanted it.
I'm afraid that I cannot help you with the other problem about booting
diskless and problems mounting.  Maybe someone else out there has run
into the same problem.


        End of Security Digest Volume 1 Issue 37