VIRUS-L Digest             Thursday, 29 Dec 1988        Volume 1 : Issue 59a

Today's Topics:
UUDECODE source available (PC?)
debrain.uue
Virus @ lockheed?
More on the virus...
nVIR 10 - A Correction (Mac)
VIRUS WARNING: DECNET Worm (forwarded from VALERT-L)
Formatting disks (PC)

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

Date:         Fri, 23 Dec 88 12:51:53 EDT
From:         Jean <[email protected]>
Subject:      UUDECODE source available (PC?)
To:           VIRUS-L@LEHIIBM1

Well I finally have an answer for those who need UUDECODE to create
the files they request in .UUE format. I just sent the files to Ken and
hope he puts them up on the LISTSERV.

I now have a BASIC program with PURE ASCII data statements that creates
UUDECODE.EXE and guess what? It works fine.

If you cant wait for Ken to get it on the LISTSERV, send me a short
MAIL request saying you want the UUDECODE PACKAGE and I'll file send it
to you.

If you have BITRCV, let me know and I'll Bitsend them which is faster.
If you want BITRCV, let me know as well.

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

Date:         Fri, 23 Dec 88 14:03:09 EDT
From:         [email protected]
Subject:      debrain.uue
To:           VIRUS-L@LEHIIBM1

If anyone has debrain.uue could they please send it to me?

We finally got uudecode working properly and now we need debrain.uue

Thank you.

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


Date: Fri, 23 Dec 88 15:17:39 EST
From: [email protected] (Michael F. Angelo)
Subject: Virus @ lockheed?

I just got a call from one of my friends, and he said that Lockheed
has pulled itself from the internet, due to a virus / hacker.  Does
anyone out there know anything about this?

ps.  It supposedly affected there vms machine?

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

Date:         Fri, 23 Dec 88 15:30:22 EST
From:         Joe McMahon <[email protected]>
Subject:      nVIR 10 - A Correction (Mac)

I just received a note from Matthias Urlichs, who tells me that nVIR 10
merely DEACTIVATES the nVIR virus, it does not kill it.

I suppose it's like a DNA suppressor, rather than an antibody.

Sorry if I have caused anyone inconvenience. The nVIR Vaccine program
in the NVIRVACC SITHQX file should still be used to remove nVIR from
applications, and the manual procedure mentioned in the ANTI-VIR
SITHQX stack can be used to clean systems.

I have been receiving a LOT of nVIR removal software lately; I haven't
had time to review it yet. I will be doing so and adding the ones I find
best address the problem to our LISTSERV after January 1.

Happy holidays, all.

- --- Joe M.

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

Date:         Fri, 23 Dec 88 19:54:27 est
Sender: Virus Alert List <[email protected]>
From: lecgwy!lyons%[email protected]
Subject:      VIRUS WARNING: DECNET Worm (forwarded from VALERT-L)

The following information relates to the DECNET worm which
hit the HEPNET and infects DEC VMS systems.

Note that in addition to the information presented here, the possibility
exists that a non-HEPNET system may have been infected.  You should
check your system for a file by the name of HI.COM, and a process
running with the name MAIL_178DC.  If you find either of them, your
system more than likely has been infected.  Read on for further
background, as well as a more thorough explanation.

Thanks to Ed DeHart at CERT, Fred Ostapik at ARPA-NIC, and all others
who helped assemble this information.

- ---
Marty Lyons, Lockheed Electronics Company, 1501 U.S. Highway 22,
CS #1, M/S 147, Plainfield, N.J. 07061-1501 (201) 757-1600 x3156
[email protected] or LYONS%[email protected]

Worm-fix distribution list:
 CERT, CMU ([email protected])
 John Wagner, Princeton ([email protected], [email protected])
 Chris Tengi, Princeton ([email protected])
 Nick Cardo, JVNC Supercompuer Center ([email protected])
 Chuck Hedrick, Rutgers ([email protected])
 Steve Keeton, NJIT ([email protected])
 Seldon Ball, Cornell ([email protected])
 Nick Gimbrone, Cornell ([email protected])
 Sandi Ivano, Yale (???)
 Anio Khullar, CUNY Graduate Center ([email protected])
 Shakil Khan, CUNY Queens College ([email protected])
 Meredith Coombs, Stevens Tech (???)
 Ken Ng, NJIT ([email protected])
 Dave Capshaw, Lockheed-Austin ([email protected])
 Marty Lyons, Lockheed Electronics ([email protected])
 Randi Robinson, CUNY ([email protected])
 BITNET Laison Distribution List ([email protected])
 BITNET Linkfail List ([email protected])
 BITNET Virus Alert List ([email protected])
 UUCP/Stargate Announcements ([email protected])

> From rutgers!sei.cmu.edu!ecd Fri Dec 23 17:59:18 1988
> Received: from ED.SEI.CMU.EDU by rutgers.edu (5.59/RU-1.2/3.02)
> id AA18876; Fri, 23 Dec 88 17:47:30 EST
> Received: by ed.sei.cmu.edu (5.54/2.3)
> id AA08030; Fri, 23 Dec 88 17:28:48 EST
> Date: Fri, 23 Dec 88 17:28:48 EST
> Message-Id: <[email protected]>
> To: lecgwy!lyons, [email protected]
> Subject: Re:  NASA Virus

The following information has been provided by one of the VMS experts
on the Internet.  Due to the holidays,  the CERT has not been able to
verify the information.  If you do verify the information please let
us know.

Thanks,
Ed DeHart
Software Engineering Institute / Computer Emergency Response Team
[email protected]
412-268-7090
=======================================================================

There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network.  The worm targets VMS machines, and
can only be propagated via DECnet.

The worm itself appears to be benign, in that it does not destroy files
or compromise the system.  It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988.  It
does have a hook in it to monitor it's progress;  it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.

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.

There are several steps which you can take to protect yourself from this
kind of attack.  The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether.  This can be done with
the following commands from the SYSTEM or other suitably privileged account:

       $ Run SYS$SYSTEM:NCP
       Purge Executor Nonprivileged User Account Password
       Clear Executor Nonprivileged User Account Password
       ^Z

This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the _Guide to VMS System Security_,
see below).

You can take less restrictive steps to protect your machine while still
maintaining some degree of default access.  If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):

       $ Run SYS$SYSTEM:NCP
       Clear Object Task All
       ^Z

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

       CLEAR OBJECT TASK ALL

AFTER the line which says

       SET KNOWN OBJECTS ALL

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.  These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine;  but they
will prevent it from being executed.  To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):

       $ Set Default your-default-decnet-directory
       $ Create HI.COM
       $ Stop/ID=0
       ^Z
       $ Set File/Owner=[1,4]-
       /Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM

This prevents anyone from copying a file called "HI.COM" into your default
DECnet account;  however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account.  This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account.  The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):


       $ Set Default SYS$SYTEM
       $ Run AUTHORIZE
       Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
       /Password=randomstring/Device=disk-device/Directory=[some-directory]-
       /Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
       /NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
       /LGICMD=SYS$SYSTEM:FALLOG.COM
       ^Z
       $ Run NCP
       Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
       Password same-random-string
       Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
       Password same-random-string
       ^Z
       $ Create FALLOG.COM
       $ V := 'F$Verify(0)
       $ Write SYS$OUTPUT ""
       $ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
       $ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
       $ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
       $ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
       $ Write SYS$OUTPUT ""
       ^Z

This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa.  The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.

The FAL program can supply additional logging information;  contact your
DIGITAL software support person for further details.

Further steps can be taken to restrict access to your system.  These
steps are discussed in detail in the _Guide to VMS System Security_, DEC
order number AA-LA40A-TE, dated April 1988.  See in particular chapter 7,
entitled _Security for a DECnet Node_.


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

Date:     SUN DEC 25, 1988 16.55.23 EST
From:     "Prof Arthur I. Larky" <[email protected]>
Subject:  Formatting disks (PC)

When you format a floppy, you do two things: (1) you create an empty FAT
(File Allocation Table) which indicates that you have not assigned any
portion of the disk to files, and (2) you create the data sectors on
the disk by writing sector numbers, CRC's, etc on every track of the
disk.  Thus the disk is completely clean; unless, of course, your
format program or DOS has been subverted.  You also write a boot
record.  If you have asked for it, the two hidden DOS programs get put
as the first two programs on the disk.
 When you use the same program (Format) to format a hard disk, all
it does is create the empty FAT table, thus everything that was on the
disk is still there, but you have one heck of a problem finding it
unless you are a virus that knows where it is.
 Hard disk owners can get rid of everything by doing a low-level
format (on my Zenith its a program called PREP).  This does the
entire job of putting the sector and track numbers, CRC's, etc. on
the disk and also creates a map of bad sectors (truly bad ones, not
virus-faked bad ones).  Unfortunately, it takes hours (yes, hours) to
do this low level format since the program does repeated checks on
the read/write-ability of the disk.  Some controllers have code in
their ROM at c800:5 that does this low-level formatting; others do
not.  If you use Debug to look at the code, you may be able to figure
out whether its there or not.  Another way to find out is to try it;
however, you better not have anything valuable on the disk in case
it works.
Art Larky
CSEE Dept
Lehigh University

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

End of VIRUS-L Digest
*********************
Downloaded From P-80 International Information Systems 304-744-2253

You are viewing proxied material from infinitelyremote.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.