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

Text File | 1995-01-03 | 22KB | 473 lines

VIRUS-L Digest   Monday, 30 Oct 1989    Volume 2 : Issue 226

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:

Virus scanning on PCs?
Re: Protection in Operating Systems
How to Become a Virus Expert (Mac)
Re: Lode [sic] Runner Virus (Apple)
Where are the Sophisticated Viruses?
2608- possible virus? (AMIGA)
BOOTCHEK (possible virus) (PC)
Defensive computing...
Re: Obj - anti-virus (PC)
MacDraw II 1.1/GateKeeper 1.1 problems (Mac)
Self-checking programs (PC anti-virus protection)

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

Date:    26 Oct 89 16:07:15 +0000
From:    [e-mail] (Wm E Davidsen Jr)
Subject: Virus scanning on PCs?

  Do scanning programs (in particular scanv45) check video memory for a
virus? I once developed a program which installed itself in the 2nd page
of video memory because there was nowhere else for it. Not a virus, just
a fix for some BIOS bugs, but someone else could hide a virus there if
they were so inclined. Very little software ever uses any page but the
first.

  Oh, if the video pages were swapped and then output to the serial port
was done, the display was really pretty!
- --
bill davidsen   ([e-mail] -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

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

Date:    26 Oct 89 16:03:14 +0000
From:    [e-mail] (Wm E Davidsen Jr)
Subject: Re: Protection in Operating Systems

In article <[e-mail]>, [e-mail] w
rites:

|  However, as it relates to viruses, the big difference between them
|  today is the number and nature of uses and users.  If UNIX were being
|  used for the same things and by the same number of users as DOS, it
|  would be just as vulnerable.

  I don't see how that relates to the technical issues. DOS allows any
program to write anywhere in memory, including over the o/s. UNIX does
not. DOS allows any program to write directly on the hard disk. UNIX
does not. DOS allows any program to write to a floppy disk. UNIX may
or may not, but in general UNIX seldom uses floppies at all, and when
it does the formats are usually not susceptable to changing one file
without changing others (ie. tar, cpio). DOS allows any program to
modify any file on any disk. UNIX does not.

  This is not a case of one being "better" than another, just a case of
inherent characteristics of the systems. Yes, if someone is running UNIX
on an 8088 machine many of the protections are bypassed.
- --
bill davidsen   ([e-mail] -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

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

Date:    Fri, 27 Oct 89 15:48:39 -0500
From:    Joe McMahon <[e-mail]>
Subject: How to Become a Virus Expert (Mac)

1) Read this digest. There are probably more contributors here than
   in any other spot around.
2) Study Inside Macintosh, particularly the sections on ROM patches,
   INITs, and VBL tasks. These are the principle attack vectors for
   Mac viruses.
3) Become adept at using TMON, Macsbug, or some other disassembler/
   debugger. This will help you track down what is happening during
   a given infection.

I don't know of anything equivalent to the "microscope and tweezers"
report on the Internet worm for any Mac virus, so I can't refer you
to any articles which talk about the mechanics of any virus in great
detail. The only one which might be of use to you is an article in
MacTutor magazine (last year? check the MacTutor anthologies) which
has a description of an nVIR infection and a primitive but useful
removal program.

 --- Joe M.

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

Date:    Fri, 27 Oct 89 14:59:56 -0700
From:    [e-mail]
Subject: Re: Lode [sic] Runner Virus (Apple)

In article <[e-mail]>,
[e-mail] posted an article about the Apple IIGS
LOAD RUNNER virus, and asked the following questions:
>                           [...]  (1) Does any reader of VIRUS-L
>know if the French expression "non-destructeur" means
>"non-destructive" or "indestructible?"  (2)Could anyone post a
>version of VIRUS.KILLER (source code follows the report) written
>in BASIC?  (It could be posted here or to [e-mail])
>(3)  Because the university does not import VIRUS ALERT I
>have not posted this report to it, for fear of replication.  Could
>someone post this message to VIRUS ALERT if it has not appeared there
>already?

Way back in July, I found this beasty lurking on some of my disks, and
did a fairly thorough analysis of it, which culminated in the writing
of the program which appeared at the end of the original article
(copies of the program are available from me at the addresses below).
I think I can provide some answers and information.

I speak no French, but I think I can say after looking at the virus
code that whatever "non-destructeur" really means, it OUGHT to mean
"non-destructive."  The damage done by this virus is minimal--it
destroys only the boot blocks of a 3.5" disk (5.25" disks and hard
disks seem to be immune), leaving all the files and directories intact
(it can, however, render some copy-protected games unusable).  My
impression is that the author of the virus was thinking something like
"I'm going to release this virus, which is a really bad thing to do,
but it will be all right if it doesn't do any real damage."  This
impression seems to be reinforced by the fact that LOAD RUNNER has a
finite life-span built in-- at the same time it starts damaging, it
also stops propagating, and being a boot block virus, it destroys
copies of itself when it destroys the boot blocks.

Posting a BASIC version of VIRUS.KILLER isn't really practical--the
steps that it takes to eliminate LOAD RUNNER are pretty much beyond
the capabilities of poor old Applesoft BASIC.  Any BASIC program would
probably be just a short menu routine wrapped around a
machine-language core which would be essentially the same as the
current program.

It's probably a bit late for a VIRUS ALERT message.  I first saw LOAD
RUNNER back in July (at which point it had probably already been
around for a while), and if memory serves, the article quoted in the
original posting was first posted sometime around August or September.
Besides, LOAD RUNNER's trigger dates are any time between Oct. 1 and
Dec. 31 inclusive, so any infected users have probably aready seen it
run its course, and an alert now would be somewhat akin to locking the
proverbial barn door after the horse has escaped.

- -------------------------
A summary of LOAD RUNNER:

Entry................: LOAD RUNNER
Alias(es)............: (none)
Virus detection when.: July, 1989
               where.: Various places in the US and Canada
Classifications......: Boot block virus
Length of virus......: 1024 bytes (all of blocks 0 and 1)
Operating system(s)..: ProDOS 8, ProDOS 16, GS/OS
Version/release......: all
Computer model(s)....: Apple IIGS
Identification.......: Boot blocks are changed.
                       System:  Virus copies itself to $E1/BC00 thru $E1/BFFF.
Type of infection....: Virus resides in the boot blocks of a 3.5" disk.  Copies
               itself to $E1/BC00 when disk is booted.  Copies itself
               to disk in slot 5, drive 1 when CONTROL-APPLE-RESET is
               pressed.  Propagation routine gains control by patching
               undocumented system vector in Memory Manager.  Original
               boot blocks are not saved--virus contains code to emulate
               standard boot process.
Infection trigger....: Infects disks in slot 5, drive 1 only.  Infection of
               disks occurs when CONTROL-APPLE-RESET is pressed.
               Infection of host machine occurs when an infected disk
               is booted.
Interrupts hooked....: n/a
Damage...............: Erases boot blocks of disk in slot 5, drive 1.  No files
               are damaged.
Damage trigger.......: Any date between Oct. 1 and Dec. 31 inclusive, of any
               year.  Damage occurs when an infected disk is booted.
               If damage occurs, further infection will not occur.
               (Note that the damage process wipes the virus off of the
               infected disk.)
Acknowledgment:
Location.............: University of Oregon
Documented by........: Neil Parker ([e-mail])
Date.................: 27-October-1989

Personal opinion: A rather wimpy virus.  Damage is minimal and easily
repaired.  The virus code uses no special tricks, except for the
method used to survive and gain control after RESET.  All in all, it's
not worth making much of a fuss about (except to the extent that ALL
viruses are worth making a fuss about).

(This is my first posting to comp.virus/VIRUS-L.  Did I get the report
format right?)

Neil Parker     [e-mail]     [e-mail]
DISCLAIMER:  Opinions are mine alone.

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

Date:    Sat, 28 Oct 89 01:46:00 -0400
From:    [e-mail]
Subject: Where are the Sophisticated Viruses?

For various reasons I have been behind in my reading of Virus-L, and
so I found myself skimming something like the last dozen issues of the
digest all at once.  I was struck by something: are we lucky and there
are no competent, sophisticated writers of viruses out there, or are
we just fooling ourselves?  Although the details of most of the virus
prevention programs (e.g., Gatekeeper for the Mac) haven't been
discussed at all or recently enough that I remember them, it seems to
me that any virus writer willing to get his hands dirty and write code
that directly uses the I/O hardware (rather than rely on the operating
system) should be able to write a virus that could not be detected by
any of the preventative defenses that are supposed to be watching for
suspicious writes and that would only be detected after-the-fact by
reactive defenses that did a lot of robust integrity checksumming.
(Looking for file modification dates would be useless since the virus
would of course not be polite enough to update any directories;
scanning programs would be useless on the assumption that the virus
remains undetected until it goes off so no-one would have included a
signature to scan for.)  Suppose some suitably motivated person wrote
such a virus and set the trigger for a year or two away (provided the
virus had been executed and/or propagated some number of times) -- how
far within the IBM-PC or Mac community would it likely spread before
the trigger fired?  How do we know one or more such beasts isn't
already out there, just biding its time?

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

Date:    29 Oct 89 00:16:58 +0000
From:    [e-mail] (Iain Davidson)
Subject: 2608- possible virus? (AMIGA)

In article <[e-mail]> [e-mail] (Okay S
 J) writes:
>I received this from Amiga-relay this morning....From all reports, it
>appears that Xeno, if it is a virus, is the 1st non-boot infector virus
>in the Amiga community. All the others I've seen so far live in the boot
>sector and most Amiga anti-virals seem to only worry about the boot sector
>and in RAM at the time.
>I'll cross-post anything I hear from either side to their respective
>lists.
>
>Stephen Okay    Technical Aide, The MITRE Corporation
>x6737        [e-mail]/[e-mail]

[Text deleted]

Well, while up in Vancouver, BC at an Amiga Users Group meeting, a interesting
  thing was demostrated.....

I call it the "2608" virus. (don't know the offical name).

It worked like the IRQ virus attaching itself to the first executable in
  the startup-sequence.  But with a slight twist.  It would copy the
  found executable to devs:"    " and copy itself into the old name in
  the "C" directory (size 2608 bytes).

The way that it was noticed was that the person had typed "echo blah blah"
  in his startup-sequence, but in "C" directory he had "echo" called
  "Echo" .  One day he had noticed that the command was in all lowercase
  and 2608 bytes long (not the usual 653? bytes long).  He also noticed
  that he had a extra file "   " in the devs: directory the same size
  as the echo command.

Evidently, the virus copyed itself to the command location, then
  copied the command to the devs: directory.  Everytime the command
  was executed it would call the virus-program which in turn would call
  the REAL command. Appearing as though all worked fine.

Another interesting thing....  about every 5 times he warm-boot, a
  message would come up saying something like "Virus Exterminator.. blah
  blah.... Virus by Blah Blah (i don't remember the specifics)" this
  only appeared for a brief second ... not long enough to read the whole
  thing.

Anybody else have any info on this ?

- -Iain Davidson
[e-mail]
[e-mail]
uw-beaver!wwu.edu!IAIN

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

Date:    Sun, 29 Oct 89 00:19:00 -0500
From:    [e-mail]
Subject: BOOTCHEK (possible virus) (PC)

HI!

        This list provides a service of great benefit to many many
   computer users! Congratulations.

        I recently downloaded BootChek 1.0 from Simtel20. With increasing
  frequency it has been saying my boot sector has been modified. I have
  allowed it to replace the "corrupt" boot sector on each of these occaisions.
  The complaint only happens on cold boots and not everytime the machine is
  cold booted. BootCHek lists the offset at which the sector starts to be
  different as 11 (on other occaisions 17, and most recently as 6.) The
  most recent time this symptom occured was after three reboots (each of
  which set off bootchek)

        Viruscanv42 shows no viruses on my 10 meg hard disk. I also run
  flushot plus ver 1.5 and UNVIRUS6 from Simtel20. These are running on
  my 4.77mhz IBM PC Clone with a DTK BIOS.

        I am concerned that BootChek has a bug, a virus, or both.

        Would someone please respond ASAP with any thoughts or info on
   my concerns!

                Jeffrey Perry
                Northeastern University PC Users Group

PS. I have the corrupt.hex file produced by each of the five times bootchek
    claimed my boot sector had been changed. If anyone wants to analyze them
    I would be glad to send them along.

PSS. I have backed up my Hard Disk so I am ready for just about anything
    BUT I hope it is merely a bug in bootchek!!!

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

Date:    Sun, 29 Oct 89 09:33:05 -0500
From:    [e-mail] (David Gursky)
Subject: Defensive computing...

Just a "friendly reminder" to the readers of Virus-L (and apologies to
those who get both RISKS and Virus-L, and saw this note in RISKS some
weeks ago).

There are several key dates that electronic vandals like to strike on:
Any Friday the 13th, April Fool's Day, and Halloween.  The latter is
Tuesday, and it would be exceedingly prudent (not to mention cheap
insurance) for people to back up their disks in the event they are
infected with a virus, or are unwittingly using a Trojan Horse,
equipped with a time-bomb set for Halloween.

A backup will not prevent the time-bomb from going off, nor will it
remove the virus or Trojan Horse from your system, but it will be
invaluable in recovering any data you may loose.


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

Date:    29 Oct 89 19:56:08 +0000
From:    [e-mail] (Paul Kerchen)
Subject: Re: Obj - anti-virus (PC)


In article <[e-mail]> [e-mail] (Pa
ul Bienvenue) writes:
>       [stuff about distributing OBJ files as anti-viral technique]
>
>    It's a nice idea, but it wouldn't really stop virus writers, just
>make life a little more difficult for them.

That's the whole point: to make life more difficult for virus writers.
The whole virus problem is NP complete, meaning that there is no way
to ever completely solve it.  For every protection scheme, there is a
way to break it; just look at the copy protection war that has been
going on for years now.  Anyone who's in the virus business (either
attacking or defending) had better know that they can never hope to
create a virus/vaccine which is completely bulletproof.  There will
always be someone on the other side who will figure out a scheme to
counter that virus/vaccine.  Therefore, no solution should ever be
ruled out simply on the basis that it cannot stop virus writers (I
know that this isn`t the only reason Paul gave, but I just wanted
to make this point). Stopping virus writers isn`t going to happen
in software or hardware, but in societal pressure.  (Perhaps some
future first lady will make that her project: viruses--just say no.
:-) )

Paul Kerchen                            | [e-mail]

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

Date:    Sun, 29 Oct 89 15:14:00 -0500
From:    [e-mail]
Subject: MacDraw II 1.1/GateKeeper 1.1 problems (Mac)

Question: Does GateKeeper 1.1 have problems with MacDraw 1.1? Our
installation has version 1.1 running on a machine protected with
GateKeeper. Whenever we try to save a previously opened document, we
get a dialog box saying "File not Found". SOMETHING is saved, because
the changes are there when we open the document; but MacDraw does not
recognize this. I've pretty much narrowed the trouble down to either
GateKeeper or a virus in MacDraw II, because when I use the override
feature on GateKeeper, MacDraw works fine. But even when I give
MacDraw II 1.1 full privliges, (Res/File on Other, System, and Self)
it still gives the File Not Found dialog box. Has anyone else had this
problem?
                      Travis Butler at [e-mail]

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

Date:    Sun, 29 Oct 89 21:13:00 -0500
From:    [e-mail]
Subject: Self-checking programs (PC anti-virus protection)

Bob McCabe of the University of Guelph wrote (27 Oct) "it struck me
that it should be possible to work out a scheme by which any program
could check itself at load time for infection..."

This is quite true, and in fact there is at least one commercial
anti-virus product out there which implements this idea.  (There may
well be others.)  The one I have noticed is VACCINATE PLUS, by Computer
Integrity Corp.  of Boulder Colorado.  Along with several other
anti-viral tools, this product includes an "INSTALL" utility which
"vaccinates" the boot track and all executables on the disk.
"Vaccination" consists of appending a cryptographic "seal" checking
module (smaller than a typical virus!)  and patching the load module
header so that this module executes first, then passes control to the
original application program if the program is "clean", otherwise
halting and issuing a warning message.

According to Larry Martin of Computer Integrity Corp., the resulting
protection is entirely transparent to the end user, i.e.  no keystrokes
are required, you just run a program in the normal way, and it runs
normally unless the file has been infected, in which case it issues the
warning and returns control to DOS.

Computer Integrity Corp.  can be reached by phone at [phone] (FAX
number is 449-7477).  Their address is PO Box 17721, Boulder CO 80308.
(I have no commercial connection with this company.)

Regarding the specific scheme Bob McCabe described, i.e.  computing a
CRC on a program and then encrypting it, it is fairly well known that
since the CRC process is linear over the binary field (commonly called
"GF(2)" by algebraists), it is little more than a high school algebra
exercise to make your desired changes to the program, then make a few
more bits' worth of additional changes (determined by simple linear
algebra over GF(2)) which restore the CRC bits to their former value so
that they will still perfectly match the bits recovered from the
encrypted CRC -- thus defeating the protection scheme.  The only trick,
in an executable program, is to set up the code so that the additional
bits you have to diddle to restore the CRC do not adversely affect
execution, e.g.  include a branch around them or whatever suits your
fancy.

The basic idea is OK, but you need to use a "one-way" hash function,
rather than something readily invertible like a linear CRC.  See Dorothy
Denning's book or any of a number of recent articles for ideas on better
hash functions, or use one of the "chained" modes of the DES which have
been proposed for detecting data alterations.

The key (so to speak) property that is needed is that it must be
difficult to construct a second message or in this case computer program
with the same value for the hashing function's output.

- -John Sangster SPHINX Technologies, Incorporated [phone] P.O.
Box 81287 Wellesley Hills, MA 02181

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

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