VIRUS-L Digest   Friday,  6 Dec 1991    Volume 4 : Issue 231

Today's Topics:

password program (PC)
Re: vaccine for STONED on boot disks? (PC)
Reports about Dir II (PC)
Serious problems with JOSHI (PC)
possible virus? (PC)
Re: What's special about LAN's? (PC)
Virex antivirus software (PC)
Fitting Curves to Virus-Spread Data
DIR II (PC)
Jerusalem Info (PC)
Re: What's special about LAN's? (PC)
Dave Chess's paper available on archives
new program from Padgett (PC)
Avoiding detection

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.  Please sign submissions with your real name.  Send
contributions to [email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: [email protected].

  Ken van Wyk

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

Date:    02 Dec 91 17:06:05 +0000
>From:    S D Law <[email protected]>
Subject: password program (PC)

Hello,

We have recently found on our public pc's some sort of password
program that I think has somehow been put into the cmos.  It seems to
be a "commercial type product" that has been put on for fun.  Does
anyone know of this and abviously more importantly, how do I get into
the pc to get it off.  Booting from floppy does not work as cmos is
run before this.

Any help appreciated.

Thanks,
Steve Law.

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

Date:    Wed, 04 Dec 91 13:09:00 +1300
>From:    "Mark Aitchison, U of Canty; Physics" <[email protected]>
Subject: Re: vaccine for STONED on boot disks? (PC)

[email protected] (Don Medal) writes:
> I am happily in possession of INNOC which says it will innoculate against
> STONED, but with one tiny unhappy exception: it won't protect DOS bootable
> disks.
>
> We are constantly being infected with Stoned from a pool of student disks
> and would very much like to find a way to vaccinate against STONED for
> bootable disks, ideally to include hard drives, but at LEAST floppies.
> Can this be done?  Is it theoretically impossible?

Yes, it is possible to have a bootable disk immunised against the
Stoned virus, in that it looks enough like it is already stoned to
avoid getting infected.  There are vaccination programs that rely on
this method to avoid other viruses as well, in which case it is hard
to make it bootable.  In fact, it is impossible to protect against all
boot sector viruses in this way.  What I suggest is using two
different methods, software like INNOC for non-bootable diskettes to
avoid them getting at least the main viruses, plus software like
IMMUNISE or the new DISKSECURE on the bootable disks (presumably hard
disks).  These programs rely on a different method to avoid viruses,
and need to be specific to certain signatures (and therefore are
fundamentally safer, although you could argue that they are "risky" in
the sense that they do let a virus gain control for a while; viruses
can be written with such programs in mind, but that comment applies to
all anti-viral products).

Mark Aitchison.

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

Date:    04 Dec 91 03:20:26 +0000
>From:    [email protected] (Vesselin Bontchev)
Subject: Reports about Dir II (PC)

According to the last reports that I received, the Dir II virus is
spread in Bulgaria, the Soviet Union, Poland, Hungary, the USA (one
report), the UK (one report), Norway (about 6 % of the reported
infections), Germany (one report), and Turkey (one report).

Unfortunately, just minutes ago I got a report that somebody has
posted the SOURCE (!) of the virus (not a disassembly, the original
source) on a public FidoNet conference, which is distributed around
the world... :-((( That's sure to cause a lot of infections. And
several variants/mutations...

The person who has done this has been obviously a Bulgarian, since he
has used the name 'Ahmed Dogan' - the name of the leader of the party
in Bulgaria, which represents the Turkish minority... Only a person
from Bulgaria, who knows the political situation there could use such
name...

Ahh, and just a few days ago I heard Dr. Solomon't excellent speach
about the future nightmares in virus-writing... One of them was
regular posting of virus source code to public non-moderated forums...
The nightmare has become a reality... :-((

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev         Virus Test Center, University of Hamburg
[email protected]   Fachbereich Informatik - AGN, rm. 107 C
Tel.:+49-40-54715-224, Fax: -246     Vogt-Koeln-Strasse 30, D-2000, Hamburg 54

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

Date:    Wed, 04 Dec 91 10:40:36 -0100
>From:    "Luiz Sergio B. Neves" <[email protected]>
Subject: Serious problems with JOSHI (PC)

HI ! all

      I'm having serious problems to remove JOSHI from my hardisk. I'm
using a recent Mcafee scan, but it seems to be unable to do it.
      Would you be so kind to send me a complete description of this
terrible garbage program (JOSHI), covering infection, protection,...
whatever.
      Thank you in advance !!

             Yours sincerelly

                  Luiz Sergio B. Neves

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

Date:    04 Dec 91 11:37:00 -0500
>From:    "SUSAN HUMPHREY" <[email protected]>
Subject: possible virus? (PC)

Folks -

We have a lab on campus with 25 Epson 286 PCs.  Hard disks are "dying"
left and right, and, although they do get alot of use, they don't get
alot of abuse.  So - I'm looking into virus possibilities.

The symptoms are these: "BAD SECTORS, ERROR READING DRIVE C:" messages
appear and, inconsistently, the machines won't boot from the hard disk.
I check for viruses with Central Point's Anti-Virus product and come up
"clean".  I run Norton DiskDoctor and\or Spinrite II and detect many bad
sectors.  The disk thinks it's fixed and runs fine for a few days; then
the error messages start again, I run the disk utility again, find more
bad sectors, the disk thinks it's fine for a few days, etc.

At first we thought the disks were just dying a natural death, but it
also seems too great a coincidence - and the behavior seems odd...

As a last ditch effort to save the disks, we ran WIPEDISK, re-formatted,
ran WIPEDISK again, re-formatted again, and the disks now operate beauti-
fully, and are holding steady with only one or two bad sectors each.

Is there a virus that can do this?  Or do I just need to learn more about
hard disks?

Susan Humphrey
Assistant Director of Academic Computing
Kenyon College
Gambier, OH
[email protected]

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

Date:    Wed, 04 Dec 91 15:31:25 -0500
>From:    padgett%[email protected] (A. Padgett Peterson)
Subject: Re: What's special about LAN's? (PC)

>From:    [email protected] (Vesselin Bontchev)

>However, if the server gets infected (which generally means that you
>haven't maintained your LAN well enough), the disinfection process is
>a real nightmare. Even if the virus does not do anything destructive
>on the LAN (not intentionally, just because of its author's
>ignorance), you usually have to shut down the entire network, in order
>to clean the virus. Otherwise as soon as you log to the server, it
>infects your workstation, and as soon as you disinfect a workstation,
>it gets reinfected from the server. Usually shutting down an average
>LAN means tens of protesting users and hundreds (if not thousands) of
>$$ lost due to lost worktime....

Vesselin raises some very good points on LAN usage and the horrors of
infection however, infection does not have to equate disaster if
active measures are being taken (and I do not mean periodic SCANs).

While I have seen a virus blast through a LAN at login time, in the last
year a couple of massive infections (Jerusalem & Sunday) have been thwarted
and the LANs involved were able to stay up safely following disinfection
despite a considerable number of infected clients.

The method: all of the things Vesselin suggests PLUS integrity checking
of each of the clients at login with login refusal/client lockup if the
client is infected PLUS a fresh copy for each client of "unruly"
applications that require excess rights to execute.

Note that while it is better if each client have resident software, this is
not a criteria.

While this is effective enough, an even better method is integrity management
software resident on each client, verified and (if neccessary) updated
from the server at login.

A full philosophical description is in a paper for Dick Lefkon's Ides of
March Virus & Security Conference in New York (plug) but it is a proven fact
that a properly managed LAN can stay up and uninfected in the face of
infected clients while reporting the infections to administration.

Right now the technology permits isolation of infection. By this time next
year on-the-fly disinfection/reporting from the LAN server should be
"old hat" and one person will be able to perform installations/updates of
validation/detection software on thousands of machines in a morning.

                                               Padgett

BTW in issue 229 it was reported that MBR and Boot Sector infectors cannot
propagate on a LAN. More properly and as the Telephonica demonstrates,
the statement should have been: " cannot propagate on a LAN without help."
                                                           ^^^^^^^ ^^^^
While on that subject, I have been working on a generic MBR disinfector
that uses the SafeMBR technology to not only protect/detect future attacks
but also will provide generic recovery from nearly all MBR infections. The
pilot works just fine but the .DOC still needs to be written and it might
get a bit more "smarts" before release. RSN.

kudos & komments to:    <padgett%[email protected]>

"Anti-virus software that works is MUCH more difficult to write than a virus"

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

Date:    Wed, 04 Dec 91 15:39:00 -0500
>From:    [email protected]
Subject: Virex antivirus software (PC)

I'm new to viri and vaccines.  We are beginning to get hit heavily
with Stoned, Dark Advenger and Alameda.  I would like to know your
impression of VIREX antivirus software.  Is it good?  Is there
something better?  Any help you can give me will be appreciated.

A. Paul Reynolds
Instructional Support Specialist
Buffalo State College
Buffalo, NY

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

Date:    05 Dec 91 12:27:10 -0500
>From:    "David.M.Chess" <[email protected]>
Subject: Fitting Curves to Virus-Spread Data

At the recent NCSA Anti-Virus Product Developers' conference, I
mentioned at one session that a given set of data on virus spread
(which contained only four datapoints) could have all sorts of curves
fit to it, polynomial as well as exponential.  The person chairing the
session objected that a t-squared curve (for instance) wouldn't work,
because it would have to "go up again" at negative times.  I assume
this was just a momentary confusion, and that he has since seen the
light.

If so distinguished a gentleman can fall into this error momentarily,
though, it seems likely that many others may have done the same, so I
thought I'd point out why it's wrong.  The general principle I want to
champion is:

  For an equation (or other model) to be useful in
  studying and predicting virus spread, it does *not*
  have to fit possible or observed data over *every*
  possible range of the time variable; fitting within
  the range of interest (typically the recent past to
  the not-terribly-distant future) is sufficient.

For instance, consider the simplest possible model of local spread;
nodes are arranged like a checkerboard, and at every time tick (every
month, say) every infected node infects its four nearest neighbors (if
they are not already infected).  No infected node ever becomes
uninfected again.  The first four time ticks look like this:
                                              *
                              *              ***
                 *           ***            *****
    *           ***         *****          *******
                 *           ***            *****
                              *              ***
                                              *

The number of infected nodes goes from one at time zero, through 5,
13, 25 at time three, and so on.  The correct equation for this growth
is of course

      2          2                           2
     t  + (t + 1)         which is         2t  + 2t + 1

This describes the growth of the model perfectly for all non-negative
t, and it tells us useful things in, for instance, its first two
derivatives.  The fact that it gives non-zero numbers for t<0 is
irrelevant.  (This model is of course too simple to be very useful in
any real-world situation; it just illustrates my point, and the
opposite end of the "locality" continuum from the exponential
"everyone randomly connected to everyone else" model.)

Even exponential curves cannot fit any real-world data perfectly.  For
instance, the typical exponential model is asymptotic to zero for low
t, which means that, strictly speaking, the model predicts a non-zero
probability of computer virus infection even in, say, 1921.  So it's
clear that no mathematical model of virus growth should be judged by
its predictions outside a reasonable range of times, and that the
behavior of t-squared models at negative values of t (for instance) is
not a reason to reject such models.

I hope I haven't spent more time on this question than it deserves!

DC

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

Date:    Thu, 05 Dec 91 20:10:34 +0700
>From:    Piotr Pikuta <[email protected]>
Subject: DIR II (PC)

If you want a program which clears DIR II virus, you can write to:

Miroslaw Startek
<[email protected]>

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

Date:    Fri, 06 Dec 91 11:44:49 -0100
>From:    CARLOS GOULART <[email protected]>
Subject: Jerusalem Info (PC)

As I am not getting to send a mail to Larry Mateo, who in one post of
VIRUS-L was looking forward some Jerusalem info, I'd like to ask him
(or to someone else) that same file. I'm needing it to write down a
vaccine and a anti-virus specific to this virus.

Thank you all,

Carlos.

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

Date:    Fri, 06 Dec 91 14:05:46 -0500
>From:    Otto Stolz <[email protected]>
Subject: Re: What's special about LAN's? (PC)

Hi everybody,

on 03 Dec 91 21:36:24 +0000 Vesselin Bontchev
<[email protected]> said:
..
>- - Any person with superuser (or whatever it is called) rights, must
>have also a regular account (with low privilege rights only) and must
>use only this account for his/her everyday work. S/he must log in with
>superuser rights only when s/he really has to do some job that
>requires these rights and must log out as soon as the job is done.

And, above all, while logged in as superuser, the person must only use
trusted (clean, as is hoped) software.

I.e. he/she must *not* link/connect/(whatever it is dubbed) into
his/her own data areas nor invoke his/her favourite tools from there.
Preferably, the super user should only use standard software that has
always been kept in protected data areas, and that originally came on
write-protected media from renowned vendors.

If the person wishes to use his/her own tools he/she has developed under
his/her regular account, then these tools must be transferred in source
form to the superuser account, checked for integrity (which should be
possible by visual inspection in this case), then compiled/linked/
whatever by the standard tools.

In a nutshell: you must limit the amount of information transferred
to the superuser account and to other protected areas (e.g. program
libraries), and you must particularly shield this account and these
data areas from binary executables.

Good luck,
                   Otto Stolz <[email protected]>
                              <[email protected]>

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

Date:    Thu, 05 Dec 91 15:37:01 -0500
>From:    Kenneth R. van Wyk <[email protected]>
Subject: Dave Chess's paper available on archives

Several days ago, I put Dave Chess's paper, "Virus Verification and
Removal -- Tools and Techniques", on the FTP archive on
cert.sei.cmu.edu.  At the time, we were having problems getting a
PostScript version of the file to print.  Well, the PostScript file is
now available, and I can verify that it prints fine on a LaserWriter.
The file is in pub/virus-l/docs under the filename:

verify.remove.chess.ps

Thanks for the contribution, Dave!

Ken

P.S. Keep those FAQ's coming, folks!  I've gotten a few submissions
already.  Hopefully, we can have a good working document by the
beginning of next month.

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

Date:    Fri, 06 Dec 91 05:56:00 -0500
>From:    [email protected]
Subject: new program from Padgett (PC)

Hi.
Padgett Petersen sent me his latest creation in the field of virus
protection programs, FixMBR.  It is now available from our site in the
[.msdos.antivirus] directory as FIXMBR.ZIP.

Following is an excerpt of the documentation:

FIXMBR  .ZIP    FixMBR v1.5 (beta).  By A. Padgett Peterson.  Sent by the
               author.  Copyright (C) 1991, all rights reserved.
               This program is designed to replace the standard MS-DOS master
               boot record program with code that does more than just find the
               active partition and jump to the O/S boot record, SAFEMBR first
               checks the disk access integrity, its own integrity, and
               validates the indicated partition.
               FixMBR will only work with the first hard disk if more than one
               unit is present on the system.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes     HAYES @ URVAX                 (Vanilla BITNET)
University of Richmond   [email protected]     (Bitnet or Internet)
Richmond, VA  23173

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

Date:    Mon, 02 Dec 91 20:55:50 -0800
>From:    [email protected] (Rob Slade)
Subject: Avoiding detection

FUNGENA.CVP   911202

                     Detection avoidance

Viral programs have almost no defence at all against
disinfection.  99% of viri are almost trivially simple to get
rid of, simply by replacing the "infected" file (or boot sector)
with an original copy.  (Some more recent boot sector and system
viri require slightly more knowledge in order to perform
effective disinfection: none require drastic measures.)  Far
from their image as the predators of the computer world, viral
programs behave much more like prey.  Their survival is
dependant upon two primary factors: reproductive ability and
avoidance of detection.

Using the standard system calls to modify a file leaves very
definite traces.  The change in a file "creation" or "last
modified" date is probably more noticeable than a growth in file
size.  File size is rather meaningless, whereas dates and times
do have significance for users.  Changing the date back to its
original value, however, is not a significant programming
challenge.

Adding code while avoiding a change in file size is more
difficult, but not impossible.  Overwriting existing code and
adding code to "unused" portions of the file or disk are some
possible means.  (The fictional rogue program P1, in Thomas
Ryan's "The Adolesence of P1", avoided problems of detection by
analyzing and rewriting existing code in such a manner that the
programs were more compact and ran more efficiently.  Such
activity has not yet, alas, been discovered in any existing
virus.)

Some viral programs, or rather, virus authors, rely on
psychological factors.  There are a number of examples of viri
which will not infect program files under a certain minimum
size, knowing that an additional 2K is much more noticeable on a
5K utility than on a 300K spreadsheet.

In a sense these are all "stealth" technologies, but this term
is most often used for programs which attempt to avoid detection
by trapping calls to read the disk and "lying" to the
interrogating program.  By so doing, they avoid any kind of
detection which relies upon perusal of the disk.  The disk gives
back only that information regarding file dates, sizes and
makeup which were appropriate to the original situation.  (This
also relies upon the virus being "active" at the time of
checking.)  Although this method avoids any kind of "disk"
detection, including checksumming and signature scanning, it
leaves traces in the computer's memory which can be detected.
(Some viral programs also try to "cover their tracks" by
watching for any analysis of the area they occupy in memory and
crashing the system, but this tends to be noticeable behaviour
.. )

copyright Robert M. Slade, 1991   FUNGENA.CVP   911202

=============
Vancouver        [email protected]   | "Metabolically
Institute for    [email protected] |  challenged"
Research into    CyberStore               |
User              (Datapac 3020 8530 1030)| politically correct
Security         Canada V7K 2G6           | term for "dead"

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

End of VIRUS-L Digest [Volume 4 Issue 231]
******************************************

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.