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 #39 1989-11-03 (1 file, 6237 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/139.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Fri, 3 Nov 89 18:10:00 PST
Subject: Security Digest V1 #39

Security Digest Volume 1 Issue 39

subject(s):

            SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK
            More on the WANK worm (WORM VACCINE PLEASE DISTRIBUTE)
            request for security packages
            Net Hacker ...
            Hacker detail ctd.
            Suspect ID
            Re: Advisory by CERT about Sun 4.X systems
            [markw@gvl.unisys.com : NTT Challenges Hacker]

------------------------------------------------------------------------

Date: Tue, 31 Oct 89 01:02:34 EST
From: Gene Spafford <uunet!cs.purdue.edu!spaf>
Subject: SECURITY GUIDELINES TO BE FOLLOWED IN LATEST WORM ATTACK

An update on the NASA worm situation.  Please pass along as you see
fit.

--From:    TENCATI@NSSDCA.GSFC.NASA.GOV (SPAN SECURITY MGR. (301)286-5223)

The following message is being circulated within SPAN.  It has been
submit to the routing center managers for distribution. I thought you
might like a copy for your records.  Please pass this on to as many people
as you feel it appropriate.

It is applicable to all DECnet nodes world-wide.

============================================================================
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
further *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.

 b) Place an ACL on RIGHTSLIST.DAT to prevent network access of your user names

------------------------------------------------------------------------

Date: Fri, 03 Nov 89 13:40:18 EST
From: Gene Spafford <uunet!cs.purdue.edu!spaf>
Subject: More on the WANK worm (WORM VACCINE PLEASE DISTRIBUTE)

I don't use VMS, so I can't comment on this.  However, here it
is for you to see & use as appropriate.

------- Forwarded Message

--Date:    Fri, 03 Nov 89 13:10:39 -0500
--From:    TBUTLER@NSSDCA.GSFC.NASA.GOV

              *********** WANK WORM VACCINE  **************

A vaccine to combat the WANK worm has been developed by Bernard Perrot
of the Institut de Physique Nucleaire, Orsay, France.

The vaccine consists of creating a bogus file which you put in
SYS$SYSTEM:RIGHTSLIST.DAT.  When the worm tries to use the information in this
file, the worm-code generates errors and blows up causing the attacking worm to
die. The vaccine does NOT affect the remote system - it only kills the worm.

This vaccine will stop attacks from any attacking nodes, it should therefore
greatly reduce the "annoyance level" of attacks by reducing the volume of audit
trails.

  ******************* IMPORTANT IMPORTANT IMPORTANT ***********************
                                PLEASE READ!!!

THIS VACCINE WILL ONLY WORK AGAINST **CURRENT** STRAINS OF THE WORM.  WE
BELIEVE HOWEVER THAT TO ELIMINATE THIS WORM FROM THE NETWORK, THIS TECHNIQUE
WILL HAVE TO BE USED ON AS MANY SYSTEMS AS POSSIBLE.  IT IS THE ONLY WAY TO
ATTACK THE WORM AT IT'S SOURCE (short of system management action on the
infected node...and a lot of system managers are either asleep, ignorant, lazy
or??? and therefore the  worm has been running on some systems for days).

*******************************************************************************


This method has been tested on VMS 4.7 thru VMS 5.2 systems. In order to
correctly implement this fix, the following steps must be performed:

1)  If you have previously implemented any of our suggestions regarding
    file protection or ACL's on RIGHTSLIST.DAT, it is necessary to undo them
    restoring SYS$SYSTEM:RIGHTSLIST.DAT to its original configuration.

2)  RENAME the file SYS$SYSTEM:RIGHTSLIST.DAT to some other name of
    your choosing.

3)  To make VMS operate correctly with the rightslist file in a new
    location, issue the following command, and also add it to your
    system startup procedure:

       $DEFINE/SYSTEM/EXEC RIGHTSLIST <ddcu:[dir]new-file-name>

    The worm won't find the file because it can't translate the
    logical symbol.

4)  Take the 4-line file listed below, protect it W:R and do not
    put an ACL on it.  Name it SYS$SYSTEM:RIGHTSLIST.DAT.  You *WANT*
    the worm to access this file!  Users on your system will translate the
    system logical RIGHTSLIST and things will work correctly.

When an infected system attacks your node, the first thing it does is
copy your sys$system:rightslist.dat file and tries to get your local
usernames.  This dummy file will cause the attacking worm to abort with
a fatal error when it tries to use the information it finds in the
bogus file.

If you have followed each of the above steps, VMS will run normally, and
you will not be vulnerable to the CURRENT strains of the worm which are
running aroung the network.

The following file should be copied into SYS$SYSTEM:RIGHTSLIST.DAT exactly
as it appears below:

- -------------------------- CUT HERE - RIGHTSLIST.DAT -----------------
DUMMY MAINTENANCE RECORD
0123456789012345"'F$PID(ON)
0123456789012345'F$PID(ON)
0123456789012345BATCH
- --------------------------- CUT HERE ----------------------------------

John McMahon of NASA/GSFC Advanced Data Flow Technology Office has created a
command procedure that will have the same end-result as the above instructions.
It is available by copying WANK_SHOT.COM  from NSSDCA::WANK_SHOT.COM or
6277::WANK_SHOT.COM.  This command procedure uses a modification of the above
procedure using a SET FILE/ENTER command to set up an alias for RIGHTSLIST.DAT
rather than the RENAME command above. Knowledgable system managers may want to
decide for themselves which version they prefer.

------------------------------------------------------------------------

Date: Tue, 31 Oct 89 09:49:39 MST
From: uunet!stcvax!rlr (Roger Rose)
Subject: request for security packages

Our corporate security group is attempting to compile a list of
recommended security software for various systems, and it has fallen
upon me to evaluate packages for UNIX-based systems.

The environment consists of a wide variety of systems, running various
flavors of UNIX.  Not all systems have source code.  The systems are
connected via ethernet.  NFS and DECNET support is not unusual.  Some
systems support modems and uucp links.

What the corporate MIS-types are fantasizing is a single package that
will run on any UNIX system and make it secure.  (pretty funny... huh?)
What *I'm* looking for falls into two categories:

   1.  Audit software that checks for holes in normal UNIX system
       administration.

   2.  Embedded/extended software that adds additional features.
       (eg. audit trails, access lists, password aging)

It would be nice if the software ran on various flavors of UNIX and
various hardware platforms (such as Lachman's stuff), but this is not
necessarily essential.  It would also be nice if source code were
available, so we can make local extensions and program around
vendor-specific problems.

To summarize, I'm interested any information, good or bad, about any
generally available security package running on any UNIX-based system.

------------------------------------------------------------------------

Date: Tue, 31 Oct 89 18:24:15 EST
From: uunet!aplcen.apl.jhu.edu!johnj
Subject: Net Hacker ...

[ This and the next two messages came in from the sun-managers mail list.
  Thought they might be of interest - neil ]

We (at welch.jhu.edu, not apl) had a hacker attack. It came in on the
ftp account (bug? looking) and was on for 16 min total, we watched for
a bit.

In case any of you have an attack, one thing I wish I had done was to
follow the guy out. He came in via terminal servers at Rice and PSU.

I shut off our router when convinced it may be hostile/harmful, I
think it may have been better to follow him out ... I got terminal
server addresses ;he/she/it used & could have followed it out
using some server commands lik who or help or ? to keep me going.

Any advice? I called CERT to inform them. Some info follows:

in my next mail ...

------------------------------------------------------------------------

Date: Tue, 31 Oct 89 18:39:21 EST
From: uunet!aplcen.apl.jhu.edu!johnj
Subject: Hacker detail ctd.

Sorry, had to dial in to remember some names.

I have a 4/280 running OSv 4.0

The first break was on ftp account, anonymous was enabled. The proces
seems to have then ls -R /users directory captured a copy of my
passwd file & looked for no passwd * pwds same as uid. The next
break was then under an account with no passwd. A login  with
group 0 (sorry I will mail again with this id) appeared in
my etc/passwd file.

The /usr/tmp/foo* files had:
        foo121212 an ls -R of /users (user accounts)
        foo456456 directory listings of files with string passwd in them
        foo654654 a list of .rhosts files

Nothing else seems to be harmed. The addresses of the terminal servers
used is:
        128.241.0.81

        128.118.25.2
        128.118.25.2

The first I think is rice, the next two are psu ( I called).

I will mail with the strange userid passwd entry.

------------------------------------------------------------------------

Date: Tue, 31 Oct 89 18:49:13 EST
From: uunet!aplcen.apl.jhu.edu!johnj
Subject: Suspect ID

Last for now folks, the userid that appeared in /etc/passwd was
schevon uid 1871 (not the highest) with a 0 group id.

------------------------------------------------------------------------

Date: Thu, 2 Nov 89 10:21:45 PST
From: uunet!gumby.dsd.TRW.COM!mdm (Mike Marcinkevicz)
Subject: Re: Advisory by CERT about Sun 4.X systems

Just a note that system administrators need to also remake the yellow pages
passwd file if Yellow Pages is running, otherwise the change is not guaranteed
to take effect.

------------------------------------------------------------------------

Date: Thu, 2 Nov 1989 20:12:38 CST
From: Werner Uhrig <uunet!rascal.ics.UTEXAS.EDU!werner>
Subject: [markw@gvl.unisys.com : NTT Challenges Hacker]

        I had caught a part of this story on the car-radio some weeks
        back and had meant to bring this to your attention.  I am not
        in favor of such "dares", and consider NTT's action irresponsible.

--From: markw@gvl.unisys.com
--Newsgroups: comp.dcom.telecom
--Subject: NTT Challenges Hackers

[A copy of the following article appeared on one of our bulletin boards here
 at work. I have no idea when or where it was originally published - MHW]

NTT: Calling All Hackers

Tokyo - Nippon Telegraph and Telephone Corp. has issued a provocative
challenge: the Japanese communications giant will give 1 million yen
($6803) to any computer hacker anywhere in the world who can break its
FEAL-8 data communications security code by August 1991. Why the
unusual move? The company wants to debunk a rumor circulationg in
Europe that its security code has been cracked. The FEAL-8 code,
developed by NTT in 1986, is widely used in Japan and overseas to
protect datacom systems and integrated circuit cards from illegal
access.

------------------------------------------------------------------------

        End of Security Digest Volume 1 Issue 39
        **********************

END OF DOCUMENT