[comp.virus] VIRUSCAN test

Charles_M_Preston@Sun.COM (08/13/89)

    For the past couple weeks I have been testing the latest
versions of John McAfee's virus scanning program, Viruscan,
downloaded as SCANV29.ARC, SCANV33.ARC, etc., and very briefly
the resident version archived as SCANRES4.ARC.

    While I have not completed the testing protocol with each
virus, perhaps an interim report will be of interest.

    The testing protocol is:
      1. Scan a disk containing a copy of a virus in some form;
      2. Have the virus infect at least one other program (for
         .COM and .EXE infectors) or  disk (for boot infectors)
         so Viruscan must locate the virus signature as it would
         normally be found in an infected machine;
      3. Modify the virus in the most common ways people change
         them (cosmetic changes to ASCII text messages or small
         modifications to the code and try Viruscan again.

    Step 2 arises from testing another PC anti-virus product
which was supposed to scan for viruses.  When I found that it
would not detect a particular boot virus on an infected floppy,
I asked the software vendor about it.  I was told that it would
detect a .COM program which would produce an infected disk - not
useful to most people with infected disks, the common way this
virus is seen  Even though the viruses tested are not technically
self-mutating, my intent is to test Viruscan against later
generation infections, as they would be found in a normal
computing environment.

    Naturally, there is a problem knowing which virus is actually
being found, since they go under different names and are
frequently modified.  The viruses are currently identified by
their length, method of infection, symptoms of activity or
trigger, and any imbedded text strings, based on virus
descriptions from a variety of sources. These include Computers &
Security journal, and articles which have been on Virus-L, such
as Jim Goodwin's descriptions modified by Dave Ferbrache, and
reports by Joe Hirst from the British Computer Virus Research
Centre.

    There is  a proposal for  checksumming of viruses in the June
Computers & Security, which would allow confirmation that a found
virus is the identical one already disassembled and described by
someone.  In the meantime, identification has been made as
mentioned.

    So far, Viruscan has detected the following viruses:

    Boot infectors - Brain, Alameda/Yale, Ping-Pong, Den Zuk,
      Stoned, Israeli virus that causes characters to fall down
      the screen;

    .COM or .EXE infectors - Jerusalem -several versions
      including sURIV variants, 1701-1704-several versions,
      Lehigh, 1168, 1280, DOS62-Vienna, Saratoga, Icelandic,
      Icelandic 2, April First, and Fu Manchu.

    SCANV33 has a byte string to check for the 405.com virus, but
does not detect it.  SCANV34 has been modified to allow proper
detection.

    SCANRES 0.7V34, the resident version of Viruscan, correctly
detects the 405 virus when an infected program is run.

    I have not had any false positives on other commercial or
shareware programs that have been scanned.  Viruscan appears to
check for viruses only in reasonable locations for those
particular strains.  If there is a virus that infects only .COM
files, and an infected file has a .VOM or other extension, it
will not be reported.  Of course, it is not immediately
executable, either.

    On the other side of the coin, if a disk has been infected by
a boot infector, and still has a modified boot record, it will be
reported by Viruscan.  This is true even if the rest of the virus
code normally hidden in other sectors has been destroyed, thus
making the disk non-bootable and non infectious.  This is a
desirable warning, however, since the boot record is not
original, and since other disks may be still infected.

Disclaimer:  I am a computer security consultant and have been
working with PC and Macintosh microcomputer viruses and anti-
virus products for about 18 months. I have no obligation to John
McAfee except to report the outcome of the tests.  I am a member
of the Computer Virus Industry Association, which is operated by
John McAfee.

Charles M. Preston                       907-344-5164
Information Integrity                    MCI Mail  214-1369
Box 240027                               BIX  cpreston
Anchorage, AK  99524                     cpreston@cup.portal.com

cpreston@Sun.COM (10/24/89)

These results apply to versions through V38.  The current version at
this time is V45.  Changes are made at least once per week, it seems,
to keep up with new viruses, and I finished the work about the time
this digest went off for a couple weeks.

VIRUSCAN, for the IBM PC, from McAfee Associates, was tested using 23
actual viruses or strains of virus.  These included boot or partition
viruses such as Stoned, Ping Pong, and Brain, and .COM or .EXE viruses
such as Datacrime (1168, 1280, Datacrime II) Jerusalem, Icelandic
(several varieties) and Fu Manchu.

In each case, with two exceptions (noted below) VIRUSCAN correctly
identified the viruses after they had infected programs or disks, and
located all instances of infection in all subdirectories of the hard
disks.

One version of the program, before V35, failed to detect the 405
virus, but this was corrected in later versions.  Suriv 300, a
Jerusalem variant, was not detected in an .EXE file, but was caught in
a .COM file.

Based on the testing I did, VIRUSCAN appears to be a well-written and
effective program for locating specific known viruses, and is a very
useful part of an anti-virus program.

Next question:  How good are scanning programs?

There seems to be a perception, at least as written in several sources, that
scanning for known viruses is the weakest method of detecting viruses.  This
is probably based partly on the assumption that the slightest change in a
virus will defeat the effort to detect it using byte strings.  Experience
shows that minor changes are frequently made to microcomputer viruses.
Perhaps the most freqent change is to imbedded, non-encrypted, text strings.
Changes are also made to the infection trigger or activation conditions or
dates.

Obviously, changes can be made to any virus to defeat any particular scan
string.  This has already occurred in the Macintosh world, but most changes
made so far have been on the same level of difficulty as changing ASCII
strings.

Inspection of a search string in VIRUSCAN and/or its location in the virus
code can show that a particular search string is not based on imbedded text,
and that changing the text will not interfere with detection.  A number of
viruses were checked for this.

Also, it is easy to determine that text added to a boot sector in the
Yale/Alameda virus, for example, to make it look more like a normal boot
sector would not interfere with its detection.  If the search string used in
the scanning program is at a different location than the added text, it
won't interfere.

On other changes, I found that with a partial disassembly, or one that was
perhaps incorrectly interpreted by me, changes to what appeared to be an
infection trigger did not replicate with the virus, or did not cause the
anticipated change in virus behavior.

For this reason, it seemed more efficient, and probably more accurate, just to
make a common type of change to a virus, and test VIRUSCAN again.

Each virus was modified by patching it, making minor changes in the
executable code on the disk.  Each modified  virus was allowed to infect at
least one other program to produce a second generation virus.  The final
infected program was inspected and run to ascertain that the modification
was correctly transmitted  with the virus.  This established that there was
a viable new strain of virus.  VIRUSCAN was run to see if it still found the
modified virus.

- --------
Viruses modified and detected by VIRUSCAN version 0.5V34 or later versions
through V38.


 -Virus name-                        -Type of modification-



 Ping Pong boot Virus (Italian)         Activation window time was
                                        increased

 Jerusalem Virus - Version D            Activation date changed

 1280 Virus (Datacrime)                 Activation (destruction)
                                        date changed

 1168 Virus (Datacrime)                Activation (destruction)
                                        date changed

 Vienna (DOS 62) Virus - Version A    Manipulation task to move
                                        5 bytes to corrupt
                                        infected program was
                                        changed.

 405 virus                              Changed to seek and infect
                                        hidden files

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

Conclusion:

A well-chosen search string for a virus can survive at least some of the
common changes to viruses that are made as they pass through different
hands.  A good scanning program can provide better protection than it might
appear at first glance.

VIRUSCAN is available from BIX, CompuServe, and other sources, including the
Homebase BBS, at 408-988-4004.  On Homebase, the latest version is
SCANV45.ZIP.

Disclaimer:  I am a computer security consultant and have been
working with PC and Macintosh microcomputer viruses and anti-
virus products for about 18 months. I have no obligation to John
McAfee except to report the outcome of the tests.  Information Integrity is
a member of the Computer Virus Industry Association, which is operated by
John McAfee.

Charles M. Preston                             907-344-5164
Information Integrity                          MCI Mail  214-1369
Box 240027                                     BIX  cpreston
Anchorage, AK  99524                           cpreston@cup.portal.com

dmg@lid.mitre.org (David Gursky) (10/25/89)

In VIRUS-L Digest V2 #221, Charles Preston wrote a rather long message
about virus scanners vs. more automated virus detection applications.
I would like to point out to him that although there are some
excellent scanning applications on the market, for Macs, PCs, etc., I
prefer recommending that users do not rely on scanners simply because
you must remember to periodically scan the disk.  My experience has
been that users simple do not remember to do this, hence a strategy
that relied solely on a scanner application would not be a strong
defense against electronic vandalism.

David Gursky
Member of the Technical Staff
Special Projects Department, W-143
The MITRE Corporation