The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/zines/a_m/ciac.a2

Text File | 2003-06-11 | 11.2 KB | 482 lines

_____________________________________________________________________________

T H E  C O M P U T E R  I N C I D E N T  A D V I S O R Y  C A P A B I L I T Y



                                 C  I  A  C



                          A D V I S O R Y  N O T I C E

_____________________________________________________________________________



                  The W.COM Worm affecting VAX VMS Systems



October 16, 1989 18:37 PST                                 Number A-2





Summary



A worm is attacking NASA's SPAN network via Vax/VMS systems connected

to DECnet.  It is unclear if the spread of the worm has been checked.

It may spread to other systems such as DoE's HEPNET within a few days.

VMS system managers should prepare now. The worm targets VMS machines,

and can only be propagated via DECnet.  The worm exploits two features

of DECnet/VMS in order to propagate itself.  The first is the default

DECnet account, which is a facility for users who don't have a specific

login ID for a machine to have some degree of anonymous access. It uses

the default DECnet account to copy itself to a machine, and then uses

the "TASK 0" feature of DECnet to invoke the remote copy.  It has

several other features including a brute force attack on passwords.  An

analysis of the worm is provided below.  Included with the analysis is

a DCL program that will block the current version of the worm.  This

should give your system administrator enough time to close obvious

security holes.  This worm exploits poor security practices, so you

must take action now to assure that the worm will not propagate to your

system(s).



If your site may be affected, please contact us for further

information.  Information on how to contact CIAC appears at the end

of this notice.



________________________________________________________________________

     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.

                                                R. Kevin Oberman

________________________________________________________________________





Advisory Notice



A worm is attacking NASA's SPAN network via

Vax/VMS systems connected to DECnet.  It is unclear if the spread of the

worm has been checked.  It may spread to other systems such as DOE's

HEPNET within a few days. VMS system managers should prepare now. The

worm targets VMS machines, and can only be propagated via DECnet.  The

worm exploits two features of DECnet/VMS in order to propagate itself.

The first is the default DECnet account, which is a facility for users

who don't have a specific login ID for a machine to have some degree of

anonymous access. It uses the default DECnet account to copy itself to a

machine, and then uses the "TASK 0" feature of DECnet to invoke the

remote copy.  It has several other features including a brute force

attack.



Once the worm has successfully penetrated your system it will infect

.COM files and create new security vulnerabilities.  It then seems to

broadcast these vulnerabilities to the outside world.  It may also

damage files as well, either unintentionally or otherwise.



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. A

more thorough DCL program is being written.



If your site could be affected please call CIAC for more details...



_____________________________________________________________________



Date: Mon, 16 Oct 89 15:30 PDT

From: "Kevin Oberman, LLNL, [phone]" <[e-mail]>

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 analyis 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 progam 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 account's 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 withing 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

eleiminated, 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.)



Conclusion:



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 trap

door (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.



                                        R. Kevin Oberman

                                        Lawrence Livermore National Laboratory

                                        Internet: [e-mail]

                                        [phone]





________________________________________________________________________

If you have any questions please contact either of the following CIAC team

members:



Dave Brown, [phone] or FTS 543-9878

or

Gene Schultz, [phone] or FTS 532-8193

or send electronic mail to:

[e-mail]





CIAC FAX: [phone] FTS 543-0913