Hacker 2/HACKER2.mdf/virus/virusl3/virusl3.27

Text File | 1995-01-03 | 21KB | 458 lines

VIRUS-L Digest   Wednesday, 31 Jan 1990    Volume 3 : Issue 27

Today's Topics:

re: Universal virus detectors
WDEF A at Connecticut College (Mac)
Re: Thermal Nuclear War ?
4096 and 1260 Viruses (PC)
PC Magazine Free Utility: PCDATA (PC)
re: 1260 virus (PC)
Re: ADAPSO Virus Book
Disinfectant 1.6 (Mac)
Possible new virus?? Followup
Gatekeeper veto: Normal behavior or virus attack? (Mac)
WDEF A at Univ of Miami (PC)
virus propogation in non-executable files
The Checksum feature of FLU_SHOT+ (PC)

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

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

Date:    30 Jan 90 00:00:00 +0000
From:    "David.M..Chess" <[e-mail]>
Subject: re: Universal virus detectors

I don't entirely understand the proposal from Jerry Leichter.  He
describes a system which (if I'm reading it right) basically allows
the user to get a known-correct "last written" timestamp for any
executable object.  It's not clear to me how this constitutes a
universal virus detector, though.  Don't we also need an algorithm
that looks at timestamps and timestamp-change histories, and detects
viruses on that basis?  That strikes me as a Hard Problem.  Does the
user review his timestamps once a day, and try to figure out which
changes are OK and which aren't?

Can the user really be counted on to get this right, given that virus
authors will shortly find out the detection methods that we're using,
and make viruses that act so as to be less likely to be noticed in
that environment (details left to the readers' own ingenuity...)?

Having a known-reliable "last changed" stamp for executables would be
very nice, and would help with the anti-virus effort.  I don't think
it quite makes it as a Universal Detector, though...

DC

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

Date:    Tue, 30 Jan 90 15:29:00 -0500
From:    [e-mail]
Subject: WDEF A at Connecticut College (Mac)

WDEF A has reared its head in our public labs and one office
AppleShare network.  Boy, does this thing spread like wildfire.

Gregg TeHennepe                        | Minicomputer Specialist
[e-mail]                  | Connecticut College, New London, CT

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

Date:    30 Jan 90 15:41:00 -0800
From:    [e-mail]
Subject: Re: Thermal Nuclear War ?

A suggestion might be for your friend to boot from a floppy and take a
look in his autoexec.bat file to insure that a batch file was not
created to type the message to his terminal BEFORE he reformat his
hard disk.  It really sounds as if someone might have created a small
"Welcome Home" batch file rather than a virus.  If the batch file does
not exist, then he/she can consider a total reformat.  All strange
messages are not necessarily viruses.

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

Date:    Tue, 30 Jan 90 15:32:57 -0800
From:    [e-mail]
Subject: 4096 and 1260 Viruses (PC)

This is a forward from John McAfee:
          A new breed of viruses has surfaced in the past two months.
These viruses are very complex and use sophisticated techniques to
avoid detection, identification and removal.  Since they are new
viruses, they are not yet widespread, but they are destined to become
major problems within the next year.  Among this new breed of viruses
is the 4096, Alabama, Virus-101 and the 1260.  Very little has been
written or discussed about these viruses, so I thought it was about
time to shed some light on a trend I'm sure we will see more of.
          The two most interesting of the new breed are the 4096 and the
1260 viruses.  The 4096 has had few public reports as yet, but this is
not surprising since it is virtually invisible - even if memory
resident filters like Flu-Shot+ or Protec are in use.  It is by far
the most sophisticated virus we have seen.  It is also the largest, as
measured by the number of instructions.  Numerous disassemblers have
copies of this virus, including Dave Chess, Joe Hirst, Morgan Schweers
and others, but we don't yet have a fully documented listing.  We do
know quite a bit however:
          The virus is memory resident and infects COMMAND.COM, EXE
files and COM files.  The virus initially places the machine in
single-step mode and then issues an interrupt 21, sub-function 52 to
determine the real address of the interrupt 21 code within DOS.
Thereafter, it issues a long jump to that location to avoid any
interrupt trapping antivirals that may be resident.  Thus the
infection process, after the virus becomes resident, is transparent.
          The strangest part of the virus is that it is also able to
trap all other disk reads and writes, and whenever an infected file is
accessed by any program, the virus performs a disinfection of the
program on the fly.  Thus checksumming techniques, file length checks,
and other file modification detectors cannot perceive the infection on
the disk.  Even searching the disk for the specific virus code will
fail, since the code is removed from the file during the read request.
Doing a directory of the disk likewise shows no virus effects.  The
real increased length of infected files is subtracted during the
directory listing.
          This characteristic has a surprising side effect: Whenever an
infected file is copied to another file that does not have an
executable extension, the new file turns out to be the original,
uninfected program.  Whenever this uninfected program is copied to any
other file that does have an executable extension, the end result is
an infected program again.
          We don't yet know the exact mechanisms used by this virus, but
we do know it works.  No memory resident virus filter, or system virus
scanner that we are aware of is able to prevent infection from this
virus, or detect an infection after it has occurred - providing that
the virus is active.  The only way, currently, that we know how to
detect this virus is to look for its code in memory.
          The 1260 virus, unlike the 4096, does not do much while active
in memory.  It does, however, have the most sophisticated encryption
technique yet used by a virus.  Not only is the virus fully encrypted,
but the code extractor is also garbled for each occurrence of the
virus.  This makes simple string matching useless for identification.
          There are eight working commands in the Code Extractor; the
remainder are fluff to allow that portion of code to look somewhat
different between implementations.  They are:
  1.   B8 nnnn    MOV AX,immediate
  2.   B9 nnnn    MOV CX,immediate
  3.   BF nnnn    MOV DI,immediate address = END+0028
  4.   31 0D      XOR W[DI],CX
  5.   31 05      XOR W[DI],AX
  6.   47         INC DI
  7.   40         INC AX
  8.   E2 nn      LOOP immediate address

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

Date:    Tue, 30 Jan 90 18:45:00 -0700
From:    Keith Petersen <[e-mail]>
Subject: PC Magazine Free Utility: PCDATA (PC)

All the programs in the PC Magazine PCDATA package are available
via anonymous ftp from SIMTEL20:

pd2:<msdos2.pcmag>
VOL9N03.ARC      188K  01-16-90  PCMag FASTRUN,MIRDIR,NOVIRUS,SCANSYS,XALL

- --Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, & MISC archives [IP address 26.2.0.74]
Internet: [e-mail], [e-mail]  BITNET: w8sdz@NDSUVM1
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz

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

Date:    30 Jan 90 21:17:00 +0100
From:    Morton Swimmer <[e-mail]>
Subject: re: 1260 virus (PC)

As a comment to what frisk mentioned about the 1260 virus, I would
like to add that, you likewise cannot tell the difference between the
Syslock, Macho and Advent viruses (viri?) using classical scan
methods. They all have identical startup code which will proceed to
decrypt the actual virus body. On top of that, Macho and Syslock have
identical lengths (and similar damage). Advent is however much
shorter.

I'm not a big fan of virus scanning anyway, but using checksums, as
I do, can be cumbersome.

Cheers, Morton

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

Date:    31 Jan 90 04:37:42 +0000
From:    [e-mail] (Gene Spafford)
Subject: Re: ADAPSO Virus Book

[e-mail] (Gene Spafford) writes:
>"Computer Viruses: Dealing with Electronic Vandalism and Programmed
>Threats" by Eugene Spafford, Kathleen Heaphy, and David Ferbrache.
>1989, 109 pages.  Published by ADAPSO.
[...]
>state and Federal laws against computer crime, and detailed
>descriptions of all IBM and Apple Macintosh viruses known as of 1
>October 1990.
         ^^^^

Geez, I'm still writing 1989 on my checks, and now I'm writing 1990
where I should be putting 1989!   Make that "known as of 1 October
1989" and realize you'll be old and forgetful someday too!
- --
Gene Spafford
NSF/Purdue/U of Florida  Software Engineering Research Center,
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004
Internet:  [e-mail] uucp:     ...!{decwrl,gatech,ucbvax}!purdue!spaf

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

Date:    Wed, 31 Jan 90 00:03:21 -0500
From:    [e-mail]
Subject: Disinfectant 1.6 (Mac)

Disinfectant 1.6
================

January 30, 1990

Disinfectant 1.6 is a new release of our free Macintosh virus
detection and repair utility.

Version 1.6 automatically detects and repairs files infected by new
clones of the nVIR A and nVIR B viruses.  Several clones of nVIR B
have appeared, and in the past we had to configure and release a new
version of Disinfectant to properly recognize each new clone. This
should not be necessary in the future. The new generic nVIR clone
detection and repair algorithm is based on the one used by Steve
Brecher in his Repair program. Thanks to Steve for sharing his
code with us.

The new nVIR clone detection and repair feature was intended for
release as part of Disinfectant version 2.0, which is still being
developed.  Yet another clone of nVIR B was recently discovered at
Stanford University, so we decided to release just this part of
version 2.0 now.

Disinfectant 1.6 is available now via anonymous FTP from site
acns.nwu.edu [129.105.49.1].  It will also be available soon on
sumex-aim, rascal, comp.binaries.mac, CompuServe, Genie, Delphi, BIX,
MacNet, America Online, Calvacom, AppleLink, and other popular sources
for free and shareware software.

John Norstad
Academic Computing and Network Services
Northwestern University
2129 Sheridan Road
Evanston, IL 60208

Bitnet: jln@nuacc
Internet: [e-mail]
CompuServe: 76666,573
AppleLink: A0173

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

Date:    31 Jan 90 04:54:50 +0000
From:    munnari!dbrmelb.oz.au![e-mail] (Stephen Oakes)
Subject: Possible new virus?? Followup

Sincere apologies for the previous article I sent yesterday about a
possible new virus.  It turned out that it was a message installed as
a hoax by another party who altered the autoexec.bat file, and was not
in fact a virus.

PLease ignore my previous posting.

Thank you,
          Stephen Oakes,   [e-mail]

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

Date:    31 Jan 90 10:56:41 +0000
From:    [e-mail] (Norman Swenson)
Subject: Gatekeeper veto: Normal behavior or virus attack? (Mac)

I have noticed something suspiciously virus-like on my Mac II.  I was
getting a "Serious disk error" message from Microsoft Word and garbage
in my files when using the editor in TeXtures.  Fearing an imminent
disk crash, I backed up my hard disk to another.  While the files were
copying over. I got a veto message from Gatekeeper (ver 1.1.1, w
Gatekeeper Aid).  I decided to check my disk using Disinfectant 1.5
and found that Drawover (part of Adobe Illustrator) was infected with
nVir B.  I disinfected that file, and all my disks then scanned clean.
However, whenever I try to open the Illustrator folder on the backup
disk, I get the following veto message: 'Gatekeeper has vetoed an
attempt by Finder to violate "Res(other)" privileges against Desktop.
[AddResource(ADBS,0)]'.  I have isolated the behavior to the Adobe
Separator 2.0 program.  When I remove it from that folder, I do not
get the message.  When I put it back, I don't get the message the
first time I open the folder, but I do every time after that.  I made
a copy of the folder on another disk, and at first I got the same
behavior, but after I rebooted it went away on the second disk.  I
looked at both desktop files using resedit; one had the ADBS resource
in it, the other did not.  Is this normal behavior, or could it be due
to a virus that Disinfectant 1.5 is not catching?  Why would opening a
folder require adding a resource to the desktop file?  And why did
Gatekeeper veto it on one disk, but not the other?

Any information is greatly appreciated.

Norm
[e-mail]

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

Date:    Tue, 30 Jan 90 23:12:51 -0500
From:    [e-mail]
Subject: WDEF A at Univ of Miami (PC)

For tracking purposes, let me say that WDEF A has managed to reach the
Deep South...and has struck our public labs here on campus.

Yippee.

- --
Jason Gross     Comp Sci Ugrad     University of Miami     Class of '91 (?)
===========================================================================
Hey, wanna save the world? | Got sumtin' to say?        [e-mail]
Nuke a Godless, Communist, | Pick and choose!        [e-mail]
gay whale for Christ.      |                      [e-mail]
              - Anonymous  |
===========================================================================
          Lie: The University of Miami is a non-profit institution.

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

Date:    31 Jan 90 09:42:00 -0500
From:    "WARTHMAN" <[e-mail]>
Subject: virus propogation in non-executable files

In VIRUS-L Digest V3 #23,     [e-mail] writes:

> On another matter, there is a simple procedure which can be used to
> check for most viruses and other forms of corrupt code.  It is this:
> All viruses have to be in some executable file in order to act.
> ...
> Text files cannot
> propagate a virus and should not be deleted unless they have already
> been trashed by the corrupt code.

Although this may be the case in the MS-DOS and UNIX worlds, it is not
strictly the case in for the Macintosh. Certainly a virus must be
executed in order to spread, but that doesn't always mean that it must
attach to an "executable" file. In particular, the WDEF virus inserts
an executable resource into the "desktop" file. This file would never
ordinarily contain any executable code, just data which describes the
visual appearance of the disk volume on the Mac screen. Due to a
"feature" of the Mac operating system, however, an executable resource
can be contained in ordinary" data files and, under certain
circumstances, be executed. Thus, we have a situation in which data
files are used to contain and to propogate a virus. This is an
especially sneaky method, since the *program* that is running when
WDEF does its thing (Finder) is not, itsself, infected.

- -- Jim Warthman

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

Date:    Wed, 31 Jan 90 16:37:20 +0200
From:    Y. Radai <[e-mail]>
Subject: The Checksum feature of FLU_SHOT+ (PC)

  As happens every once in a while, I've fallen several weeks behind
in reading VIRUS-L (due to e-mail problems among other things), so
forgive me if I only now get around to replying to Ross Greenberg's
posting in Issue 5.

  Concerning his FSP (FLU_SHOT+) program Ross writes:
>                       However, to date, it seems to be good enough:
>no virus infection on a checksummed program has gotten through (to my
>users knowledge, naturally) without detection. I can only assume that
>lack of reporting can be equated to lack of infection

I'm willing to accept the assumption that no program checksummed by
FSP has ever been infected by an actual virus without FSP's detecting
it.  What I don't accept is that this shows that FSP is "good enough".
The assumption could equally well be true because users of FSP simply
don't bother using its checksum feature!!  In my opinion, the latter
explanation is far closer to the truth.
  Of the three people I know who use FSP, two checksum only the 3
files in the sample FLUSHOT.DAT file: COMMAND.COM and the 2 hidden
system files, and the other user doesn't use the checksumming feature
at all.  Why?  Because it's so extremely tedious to use.  The user is
forced to individually enter into his FLUSHOT.DAT file the name of
each file which he wishes to be checksummed along with a dummy check-
sum, to run the program, to copy down each checksum displayed by the
program, and then to manually replace each dummy checksum in
FLUSHOT.DAT by the correct value.  Since it's difficult for me to ima-
gine anyone going through all that bother on more than a few files, I
think my 3-user sample is representative.
  I might understand if the probability of these three files getting
infected were much greater than that of other files.  But precisely
the opposite is true.  There are only a few viruses which can infect
COMMAND.COM, and all of these (except possibly one) are relatively
rare.  And I haven't heard of a single virus which can infect either
of the other two files.  So the fact that no program checksummed by
FSP has been infected by a virus without being detected doesn't prove
very much about how good FSP's checker is.

>>How many of its users have the slightest idea how its security com-
>>pares with that of other programs?
>
>The users have to trust the program author of any security product.  As
>such, they have to trust that, if a virus were to infect files with a
>"zero differential" on the checksumming method I use, that I'd change
>the checksuming method.  Yes, there has to be a trust in your vendor.

My question had nothing to do with trust.  One may be very trustworthy
but still unknowingly distribute an inferior product.

>>     for any given file all users will get the same checksum, and
>>that's a potential security hole ....   But since this hole can
>>be plugged very simply and at no cost in speed, why not do so, Ross?
>
>             If they ask me: "Is my COMMAND.COM file infected?", I need
>simply ask them what the checksum is.  From that I know the answer.  If
>I used some method to generate unique checksums for each user, I'd still
>have to have some means to get back to the "real" checksum.

Sorry, but I don't understand why you have to get back to the "real"
checksum.  Suppose we improve the security by making the checksums
different for each user.  From the fact that some user's checksum has
changed relative to *whatever* it was when that user set up his
checksum base, we'd know precisely the same thing that you know by
comparing with the "real" checksum, namely that his file had been
altered (which *may* indicate infection).  So what do you gain by use
of the "real" checksum?
  But let's suppose you can show me that there's some purpose for
using real checksums.  Do I understand you correctly that you keep a
list of the real checksums of the COMMAND.COM file of all versions of
PC-DOS and MS-DOS which ever existed?  Then what about all the tens of
thousands of other files which might get infected and which your users
might ask you about?

>Please understand that I certainly can appreciate the limitations of using
>a less sophisticated algorithm within my code as versus something wonderfully
>complex.  But, as with any security product, I had to weigh off security
>versus convienience considerations.

Adding a random key to a simple algorithm wouldn't make it "wonderful-
ly complex" or less convenient in the slightest.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     [e-mail]

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

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