Hacker 2/HACKER2.mdf/virus/virusl2/virusl2.242

Text File | 1995-01-03 | 14KB | 296 lines

VIRUS-L Digest   Friday, 17 Nov 1989    Volume 2 : Issue 242

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to [e-mail] (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [e-mail].
 - Ken van Wyk

Today's Topics:

BITFTP confusion of yesterday
Virus or just hardware/software problem? (Mac)
Write protect tabs (was Re: CRC's)
Help needed on Mac virus attack (Mac)
possible bug in scanres46 (PC)
STONED Virus (PC)
Re: Signature Programs

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

Date:    Fri, 17 Nov 89 07:27:08 -0500
From:    Kenneth R. van Wyk <[e-mail]>
Subject: BITFTP confusion of yesterday

Hi folks,

Yes, I accidentally replied to a message yesterday, directly to the
entire list.  Again, I apologize for that.  I did learn that one of
the quickest ways to get help on something is to make a glaring
mistake like this.  :-)  Thanks to all those who sent in the HELP
information for BITFTP.  Allow me to explain...

FTP (File Transfer Protocol) is an Internet facility which, as the
name implies, allows users to transfer files between Internet hosts.
This facility is used frequently for making archives, programs, etc.,
available to the general public - the VIRUS-L/comp.virus archives are
available via anonymous FTP.  Traditionally, FTP was only available to
Internet subscribers since it relies directly on the TCP/IP network
protocol used on the Internet.

Enter BITFTP...  BITFTP is an email facility provided at PUCC
(Princeton University Computing Center) - perhaps other IBM VM/CMS
sites as well? - which allows users to invoke Internet FTP sessions
via email requests to [e-mail].  This gives BITNET and other
email networks (Usenet, etc.) access to much of the FTP facilities of
the Internet.  I say "much of" because the facility, in all its
usefulness, cannot currently transfer binary files, though real FTP
can.

Rather than include the lengthy HELP information for BITFTP here, I
refer readers who would like this information to obtain it on-line by
sending email to [e-mail] - in the email message, just enter
a line containing "HELP".  You will then receive the actual HELP file
provided by the service.

I hope this clears up the confusion.  BITFTP can provide a very useful
service to non-Internet sites.  As a disclaimer - BITFTP is not
provided by VIRUS-L/comp.virus, CERT, or any group that I'm associated
with; I know little more about it than what I've presented here, and
I'm merely pointing its availability out to users who might find it
useful.

Regards,

Ken

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

Date:    16 Nov 89 13:50:17 +0000
From:    [e-mail] (Mike McCann)
Subject: Virus or just hardware/software problem? (Mac)

I encountered a problem with a Mac Plus (Everex 20Mb HD, 6.0.3, 2.5Mb
RAM, QuickMail, Netway1000, SAM).  The system and finder were not
visible but the machine was still bootable (some software failed to
run or crashed).  When I used ResEdit from a locked disk I found two
DeskTops but no system or finder anywhere.  The person in charge of
Macintoshs for that area said he reinstalled all the software but the
problem reoccurs.  I immediately thought of a virus and scanned all
the disks and the Mac Plus with Disinfectant1.2 but found nothing (I
did find two file with damaged resource forks on the Mac Plus but
these were documents).

If anyone can offer any suggestions, I would greatly appreciate it.
(PS- I personally used Everex's HD formatter to erase the drive and
then installed new, known-clean system software on the Mac Plus with
his software (he didn't have known-clean copies of the software) and
I'm now waiting to see if strange things happen again).

Thanks
- --
Mike McCann       [phone]   Internet = [e-mail]
Poole Computer Center (Box P-21)       UUCP = gatech!hubcap!mmccann
Clemson University                   Bitnet = [e-mail]
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.

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

Date:    15 Nov 89 01:14:28 +0000
From:    munnari!stcns3.stc.oz.AU![e-mail] (Dave Horsfall)
Subject: Write protect tabs (was Re: CRC's)

In article <[e-mail]>,
    [e-mail] (Charles Kichler) writes:

| The advantage is hardware is difficult to modify via software.  As of yet,
| I haven't seen a program that can beat a write protect tab.

I have heard a story, perhaps apocryphal, of a disk controller whose
"write protect" mechanism merely set a bit in a register, which the
software was supposed to check.

Do you _know_ your write-protect tab really works?

[Ed. This question was discussed a few times on VIRUS-L/comp.virus;
the consensus was (after reviewing schematic diagrams) that the write
protect mechanism on PCs (and clones thereof) and Macs is implemented
in hardware and is thus not circumventable without hardware
modifications.  Unless someone can produce a definitive, reproducable
piece of code that can prove otherwise, lets all please consider this
to be the case.]

Dave Horsfall (VK2KFU),  Alcatel STC Australia,  [e-mail]
[e-mail],  ...munnari!stcns3.stc.oz.AU!dave

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

Date:    Thu, 16 Nov 89 09:19:27 -0500
From:    Tom Southall <[e-mail]>
Subject: Help needed on Mac virus attack (Mac)

Hello,

We are being hit by a Mac virus that is not recognized by our vaccine
programs (Disinfectant, etc.).  The symptoms we see, in order of
severity (age?) of the virus are:

1. System file date changes to current date
2. All printing services are degraded
3. File can not be opened - but is visible
4. Open files can not be saved
5. Machine freezes in the middle of doing work
6. Names of infected files are changed to *'s

The virus appears to be passed through data files and/or through our
Appletalk network.  We have reformatted all disks and fixed the
server, but the virus re-appears very quickly.

Any ideas as to what this might be, and how to get rid of it would be
greatly appreciated.  Thank you,

Tom Southall
Manager, User Services
The American University
Washington, DC  20016
[phone]

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

Date:    Thu, 16 Nov 89 15:55:20 -0600
From:    mitch cottrell <[e-mail]>
Subject: possible bug in scanres46 (PC)

To whom it may concern...

I do not wish to spread rumors....but??

Concerning the McAffee scanres and SCAN program, I am experiencing
unusual hardware problems at undetermined time lengths after
execution of these two programs (version 38 and 46) This problem
affects floppy disk drives only on base PC and XT systems.  The
faults appear to affect the disk drive motor and do not allow it to
run.  This problem does not appear in systems unless the programs a re
executed.  This problem is also cleared by a reboot or power cycle.

If anyone else has experienced similar problems please let me know...

PS.  I would hate to discover a new virus......

[Ed. Has anyone else had similar problems.  I'd suggest being *real*
hesitant to draw a conclusion on this without more similar
occurances.]

Reply [e-mail]
Acknowledge-To: <C2852@UMRVMB>

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

Date:    Thu, 16 Nov 89 17:31:32 -0500
From:    Mark Powers <[e-mail]>
Subject: STONED Virus (PC)

Two of our PC labs have been infected with the STONED virus.  Is there
anything out there that will fix these machines or are we looking at
rebuilding the infected disks?

                          Thanks for any assistance

                          Mark Powers
                          Academic Computer Service
                          Miami University
                          513-529-2020

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

Date:    Fri, 17 Nov 89 00:17:27 -0500
From:    Steve Woronick <[e-mail]>
Subject: Re: Signature Programs

   Bob Bosen <[e-mail]> brings up some interesting
points, asking why programmers writing authentification programs are
utilizing CRC and checksum algorithms rather than more sophisticated
algorithms like ANSI X9.9, ISO 8731-2, or DES.  I think it depends on
what you are trying to do.  If your plan is to encrypt your program and
rely on difficulties in decryption for protection against infection, then
it probably makes sense to use something very sophisticated, because you
want to make certain that no one but yourself can do the decryption.
If you are leaving the encrypted form on your disk (where it might be
compared with the unencrypted form which is surely to appear either on
your disk or in memory at some future date if you use it), you don't
want to be using something so simple that it might give your algorithm
away.

   On the other hand, if you are not encrypting your program but are
simply trying to generate a number (or maybe several numbers) for
authentification purposes, I don't see that it is necessary to use
anything more sophisticated than a polynomial.  If the virus doesn't
know your polynomial, then it's chances of guessing a sequence of
characters with which to "pad" your program file in order to generate
the same CRC value as the original unaltered program is quite
small.  Of course, everyone ought to be using a slightly different
algorithm (i.e. different polynomials) and ought to be hiding the
authentification algorithm.  Correct me if I'm wrong:  If the algorithm is
sophisticated enough that it is very hard for anyone to guess CRC values,
then there probably is no need to hide the values it calculates for each
of your program files; in principle, one might be able to deduce the
algorithm by comparing program files with the CRC values generated by the
algorithm, but this will work only if there is enough information
available for analysis (which will not be the case for sufficiently
high order polynomials).  The information in a CRC is small compared to
the information in an encrypted file, so CRC programs need not be
terribly sophisticated to foil discovery.

   It has been pointed out that doing a cold boot from a clean floppy
assures you that your system is running clean (i.e. there are no viruses
in memory --- there may be some on your hard disk, but these are dormant
until you run an infected program).  If you then run your
authentification program from the clean floppy disk on your clean system
to check your hard disk (or other), you can rest fully assured that no
virus etc. has had the opportunity to intercept your checking program
and fool you into thinking that an infected program is uninfected (unless
you were dumb and previously exposed the clean disk, though write-
protected, to the inquiring eyes of a virus).  And since there are no
viruses in memory, none can steal your checking algorithm or any of the
CRC values (which you probably are keeping on the clean disk; for that
matter you can keep your own personal polynomial coefficients on the
disk also).  You probably will wisely want to keep your clean disk
write-locked to prevent accidents, but infection is not the only threat
(so write protection does not fully protect one from accidents).  If one
runs the authentification program (or even accesses the disk it's on),
without first doing the cold clean boot, then one risks having the
authentification algorithm stolen by a virus.  And as has been stated
before, one cannot be certain of the authentification results if the
cold boot from the clean disk was not done.  Finally, you obviously have
to write to the clean disk once in a while to update the CRC-values list
for new programs/ whatever, but this is no problem because you're not
going access it without first doing the cold clean boot.  One of course
also assumes that your clean disk was really clean to start with.

   Any comments?  Here's a question:  What's a good reference for
finding out about ANSI X9.9 and ISO 8731-2?  I can give you one for DES
(Data Encryption Standard):  Numerical Recipes, The Art of Scientific
Computing, by W.H. Press, B.P. Flannery, S.A. Teukolsky, and W.T.
Vetterling, published by Cambridge University Press, (c)1986,
p. 214-220.  Two and one half pages of highly-inefficiently coded FORTRAN
is given which implements the DES algorithm (except that the standard
itself explicitly states that any implementation in software is not
secure and therefore not DES).
- -----------------------------------------------------------------------
Steven C. Woronick     | Disclaimer:  These are my own opinions.
Physics Dept.          |     Always check it out for yourself...
SUNY at Stony Brook    |
Stony Brook, NY  11794 |
Acknowledge-To: <XRAYSROK@SBCCVM>

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

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