Hacker Chronicles 2 (Alt)/The_Hacker_Chronicles_Volume_II-CD2.iso/virusl2/virusl2.243

Text File | 1995-01-03 | 8.9 KB | 221 lines

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

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:

eagle update (PC)
Help...Virus Attack (Mac)
Re: New Virus (PC) / Reported Possible Virus
Re: Virus or just hardware/software problem? (Mac)
Write protect tabs (was Re: CRC's)
RE: on CRCs

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

Date:    Thu, 16 Nov 89 19:06:00 -0500
From:    IA96000 <[e-mail]>
Subject: eagle update (PC)

Update on the virus contained in the file EAGLE.EXE.

1) It IS NOT new! It is Jerusalem B.
2) It IS infectious and will spread.
3) Scan WILL NOT detect the virus UNTIL EAGLE.EXE is run, at
   which time the /M command line switch for Scan picks up
   the virus during the memory check.
4) IF COMMAND.COM IS FOUND in the root directory of the drive
   EAGLE.EXE is executed from, the BOOT and FAT sectors are
   completely destroyed with the Hex 246 character! Several other
   sectors get destroyed at the same time. Jerusalem B is loaded
   into memory and waits silently.

5) If COMMAND.COM is notfound in the root directory, Jerusalem
   B loads into memory. No damage is done to the disk.

6) KISS AN EAGLE TODAY! is then printed to the screen.

   Not only is   the program EAGLE.EXE contain a live virus, it
is also a trojan in disguise, waiting to wipe the BOOT & FAT areas
clean.

   We are now checking to see if the trojan part of the program
is passed along when Jerusalem B is loaded into memory. In any
event, the file is DANGEROUS and care should be taken.

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

Date:    Fri, 17 Nov 89 10:37:00 -0500
From:    <[e-mail]>
Subject: Help...Virus Attack (Mac)

Please help!!

I work in an Apple computer lab at Central Connecticut State
University, and lately we've been having an outbreak of viruses (nVir
A).  I figured it out by using Disinfectant Ver. 1.1.

What should I do??  It is a public lab, so people are in and out all
the time some with their own disks.  We have all Mac SE's with 20 meg
HD hooked up through appletalk.  I tried using gatekeeper, but
programs such as Excel would not work.  I tried initializing all the
hard drives, and replacing them with the original software, but the
viruses keep coming back.  Also some of the people come in with their
own software that could be infected.

Any information on how I can control this problem would be greatly
appreciated.  You can contact me at: FELDMAN_GAL@CTSTATEU

Thanks,

Garry Feldman
Supervisor, CCSU Apple Computer Lab

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

Date:    16 Nov 89 10:13:00 -0500
From:    [e-mail]
Subject: Re: New Virus (PC) / Reported Possible Virus

Comment: About that "virus" reported to John McAfee [Virus-L Digest V2
#239] by Fred Hankel of Fargo, North Dakota, that

>> ... promply melted his power supply and mother board ... [and]
>> ... blasted a perfectly circular
>> hole in the front panel of his AT clone and left a three foot oval scorch
>> mark on the back wall of his den.

Er, doesn't anyone recognize a *L*I*G*H*T*N*I*N*G* strike?  The effects
Mr. Hankel reported are classic, only the assumption of a computer
virus is paranoia.

Maybe McAfee should submit this to the RISKS forum.
/s/:
Tom Zmudzinski             |      "The above does not constitute a policy
DCS Data Systems           |       statement from DCS Data Systems or its
McLean, Virginia           |       parent organization" - Zmudzinski
- ---------------------------+---------------------------------------------
[phone]             |      "But it does from Me!" - GOD


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

Date:    Fri, 17 Nov 89 13:05:43 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Virus or just hardware/software problem? (Mac)

I've seen this problem before, and it is not a symptom of any of the
known Mac viruses.  While I never found what the specific problem was,
my speculation was that it was some defect in the media.  I suggest
you backup the data files on your disk, reformat it, and reinstall the
software.

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

Date:    Fri, 17 Nov 89 09:51:38 -0600
From:    "Craig Finseth" <[e-mail]>
Subject: Write protect tabs (was Re: CRC's)

   [e-mail] (Charles Kichler) writes:

   ...

   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.]

I would like to confirm the "Ed." tack-on for IBM PCs, clones, and
Macs.  However, early Apple ][s *did* implement this feature in
software.

I don't know for sure, but believe that later (=current) Apple ][s,
Ataris, and Amigas perform this function in hardware.

Craig A. Finseth            [e-mail] [CAF13]
Minnesota Supercomputer Center, Inc.    [phone]

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

Date:    Fri, 17 Nov 89 10:40:00 -0600
From:    david paul hoyt <[e-mail]>
Subject: RE: on CRCs

  This is really in response to the CRC auto-diagnosis letters
recently, but it was prompted by Bob Bosen's November 16th article.

 Mr. Bosen points to very good documents that will point the serious
anti-viral minded software developers to an excellent method of
defending their software (and customers) from viruses.  I would
suggest that software developers should at least review these
documents.

  However, I would like to add a comment.  Any of these auto-check
schemes rely on a small number (1 to n) of programmed checks to see if
the software has been corrupted.  While this will defend against a
general purpose or unsophisticated virus, it has little value against
a malicious attack against your product.

  About ten years ago, there was a game called dungeon, that ran under
VMS and perhaps other machines as well.  Dungeon had something called
'game master mode.' You could rearrange things (cheat) to your heart's
content.  Figuring out how to use 'game master mode', figuring out its
data structures, parsers and whatnot was much more interesting and
educational than the game it self.  But I digress.

  You entered it by saying something (incant?) and it would issue you
a challenge. It gave you a word, and you had to decrypt it.  Knowing
nothing about cryptanalysis, I might of been out of luck.  But rather
than figuring out the cipher, I merely found the routine that checked
to see if your response was correct and patched it to always return
true.

  If I could figure this out as a complete novice (that was the first
year I had seen a computer) think what a disgruntled employee might be
able to do.

  The solution is, of course, to put part of the check someplace other
than in the computer.  The user can, even without his knowledge, be an
integral part of the check.  In the Mac world, and probably other
worlds as well, when you first open an application, it asks you your
name and your company. It then stores that data someplace, and each
subsequent time you open the program it proclaims "This program is
licensed to My Favorite Person."  Or what ever else you happened to
answer.

  The long and the short of it, is this: that name can be used as the
key, along with the checksum, signature or whatever else you use, to
encrypt itself. The CRC, exclusive or'ed with the odd bytes of the
name can be used to create a key to to decode the even bytes of the
name.  Or any other like method.  The individual's name will then be
part of the correct 'signature' for the program.  And the best part of
it is that it will be the user, not the program, that performs the
final authentication.  If the user see's

   "This program is licensed to M# Fpv9r`ta.eas*n"

Then she will know something's afoot.  And there is nothing the
vandals can do about it.  The virus will be detected.

david hoyt | [e-mail] | [e-mail]

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

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