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

Text File | 1995-01-03 | 14KB | 327 lines

VIRUS-L Digest   Thursday,  2 Aug 1990    Volume 3 : Issue 137

Today's Topics:

Does 4096 attack boot sectors ? (Was: We have been hit !!!) (PC)
"Slow" virus (PC)
4096 Running Rampant At Wharton! (PC)
Antivirus-viruses
Military Viruses - Update
PC Virus Frequency List FYI (PC)
Possible Problems with VSHIELD and NK.EXE?? (PC)
Virusafe
Re: LaserWriter virus?

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 [e-mail] (that's equivalent to
LEHIIBM1.BITNET for 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: [e-mail].

   Ken van Wyk

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

Date:    Wed, 01 Aug 90 16:33:03 +0700
From:    David de Leeuw <[e-mail]>
Subject: Does 4096 attack boot sectors ? (Was: We have been hit !!!) (PC)

I wrote that 4096 does attack the boot sector.

David M. Chess and Y. Radai doubt this.

I should state that my observation was based on circumstantial
evidence only: four computers here refused to boot after massive
attacks by 4096. Also Michael Greve's original letter states that his
computers would not boot anymore. After antiviral cleaning and SYS the
systems boot again. I will try to isolate the virus to have it
compared by Y. Radai with the "original" 4096.

Are mutations also known in computer viruses ?

David de Leeuw
Ben Gurion Univ of the Negev

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

Date:    01 Aug 90 10:02:04 -0400
From:    "David.M.Chess" <[e-mail]>
Subject: "Slow" virus (PC)

> First sighting of Slow (PC) virus reported in Australia.

Coincidentally, we just got a report from Australia as well.
Does anyone know offhand why the virus is called "slow"?
I don't see any code that slows the machine down all that
much.   I probably just missed it...

Some findings about "Slow"; based on code analysis, not
on any testing:
  - Self-garbling, like the 17xx family et all, but with a
    reasonably large invariant part.  Data areas are stored
    under a second level of XOR-garble, for some reason.
  - Much of the code is taken from the 1813 (Jerusalem) virus,
    but Slow is better at telling EXE-format from COM-format
    files, and doesn't have the EXE-reinfecting bug.
  - Like the 1813, it goes resident when the first infected
    program is run, and infects anything executed thereafter.
  - Only "damage" seems to be that, on some Fridays after 1990,
    something like every other file-close will cause the file's
    timestamp to be set to zero.   Sort of odd!
  - The virus has a five-byte self-id string that infected files
    will end with.   It will rarely -change- this self-id; it
    stores both the current one, and one previous one, to avoid
    too much re-infection.   This is no doubt to avoid
    "innoculators" (which were never very interesting to start with).
  - Like the 1813, it sets the CRC in the header of infected EXE
    files to 1984; but it never uses the fact.   Either the author
    wanted to make Slow-infected files immune to the 1813, or
    (more likely) he just didn't understand the 1813's code
    well enough to know that the setting-to-1984 wasn't needed.

Any information about the "Slow" that adds to, or contradicts,
the above would be appreciated!

DC

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

Date:    Wed, 01 Aug 90 10:11:00 -0400
From:    Michael Greve <[e-mail]>
Subject: 4096 Running Rampant At Wharton! (PC)

    We thought we had rid ourselves of the 4096 virus.  Since I last wrote
   to this list the 4096 virus has re-infected the orginal 5 machines in
   our lab plus 4 more.  We seem to be losing the battle of 4096.  What
   I feel is wrong is that we probably have some students with infected
   com and exe files on their floppies (programs, games etc.).  They are
   using their programs and re-infecting our machines (unknowingly).  We
   are currently using Diskmanager as our hard disk protection software.
   Diskmanager isn't protecting the machine against 4096.  Is there a
   program, either shareware or by purchase, that will work with Diskmanager
   and protect the machine from 4096?  At this point we don't have the
   virus under control.  We don't have the capabilities to check students
   disks.  We are closing the lab and re-formatting all the machines. Another
   lab will be closed tomorrow for a entire lab check.  If this virus is on
   student diskettes then any machine could be infected and it could spread
   throughout Penn.  I don't mean to sound so negative, but I am concerned.

                                        Thanks again for any assistance.

                                                  Michael Greve
                                                  greve@wharton,upenn.edu
                                                  The Wharton School
                                                  University of Pa.

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

Date:    Wed, 01 Aug 90 15:41:48 +0100
From:    Anthony Appleyard <[e-mail]>
Subject: Antivirus-viruses

There has been several bouts of discussion on Virus-L  on  the  subject  of
antivirals that spread like viruses. As far as I can tell from reading back
issues of Virus-L, a few antivirus viruses have been released, with varying
results:-

(1) Mac: The original nVIR deleted  a  system  file,  so  a  new  nVIR  was
released which killed the old one.

(2) PC: Den Zuk was  released  to  kill  Brain;  it  also  killed  obsolete
versions  of  itself. But Den Zuk had a bug, which made it delete data when
infecting small disks.

(3) Amiga: North Star (I & II), supposed to kill other viruses and  nothing
else.  It works like a normal bootblock virus, with two good exceptions. If
it finds a unknown bootblock (normally an auto-loading  game),  it  DOESN'T
replace that bootblock, so the game keeps working. If it finds a virus on a
write-protected disk, it asks you to remove the write-protection.

(4) Amiga: System Z (3.0 & 4.0 & 5.0): boot sector virus, asks  the  user's
permission before infecting anything.

The arguments put against them are:-

(1) Ethics: System Z handles this point by  asking  the  user's  permission
before infecting.

(2) Risk of them malfunctioning and becoming ordinary harmful viruses: E.g.
Den Zuk. This point should be handled by thorough  testing  and  debugging.

(3) Risk of them being  hacked  into  harmful  viruses:  There  are  enough
ordinary  harmful  viruses  about  for  virus-writers to hack at. Antivirus
viruses can be protected by  some  sort  of  internal  checksum  tested  by
well-encrypted code, to test for unauthorized alteration.

The  main  inaccessible  reservoir  of  virus   infection   is   the   many
microcomputers  in  private  ownership,  often  used mainly by children and
teenagers, who are often ignorant of viruses, imagining that  virus  damage
is  hardware  malfunction  or software bug or the way of the world, with no
hope of access to email or the usual channels of  getting  virus  news  and
antivirals. There are far too many of these micros for any sort of national
register  to  be  kept of where each is kept, for a tester to go round them
like in a firm or a university. The only way that I can see of getting some
sort of antiviral well distributed among this widely scattered  chronically
infested  population, would be for the antiviral to distribute itself, i.e.
to spread like a virus. It is a choice of evils. For example,  if  Den  Zuk
hadn't  got  the bug of malfunctioning on small disks, it would likely have
spread largely ignored, and flushed out the harmful Brain from most of  the
places  where  it breeds in children's bedrooms among unsupervised IBM PC's
and casually-exchanged game floppies, until a Brain-infected videogame gets
run on a university or official or school computer and endangers  important
programs and data.

{A.Appleyard} (email: [e-mail]), Wed, 01 Aug 90  14:50:32  BST

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

Date:    Wed, 01 Aug 90 10:31:53 -0400
From:    Nick DiGiovanni <[e-mail]>
Subject: Military Viruses - Update

Business Week, July 23, p.30 ('Killer' Computer Viruses: An Idea Whose
Time Shouldn't Come, Mark Lewyn) reports the DOD's Center for Signals
Warfare (CSW) has received 19 proposals from software companies and
developers to create computer viruses that infiltrate and destroy
enemy communications systems.  Seems things are moving along nicely
towards development of a software version of the Andromeda Strain.

Nick Di Giovanni
EDP Audit Manager
Rutgers University

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

Date:    1 August, 1990
From:    Padgett Peterson <[e-mail]>
Subject: PC Virus Frequency List FYI (PC)

Virus Frequency List - extracted from Patricia Hoffman's VSUM9007,
July 1990 These are the viruses flagged as COMMON & NEW only. Those
flagged as Extinct, Endangered, Rare, or Mythical have been omitted.
For those interested in the complete listing, it is available from
HOMEBASE [phone] or EXCALIBUR! [phone] & I believe it is
now on SIMTEL20. From what I am seeing, the 4096 and JOSHI are going
to be much more difficult to detect and deal with than the other
rather crude strains we are used to.

  4096                  Common
  Ashar                 Common
  Brain                 Common
  Cascade               Common
  Cascade-B             Common
  Dark Avenger          Common
  Den Zuk               Common
  Disk Killer           Common
  Jerusalem             Common
  Jerusalem B           Common
  Joshi                 Common
  Korea                 Common - Korea
  Microbes              Common - India
  Murphy                Common - Bulgaria
  Ohio                  Common
  Ping Pong-B           Common
  Stoned                Common
  Sunday                Common
  Yankee Doodle         Common - Europe

  1008                  New
  1381 Virus            New
  Flash                 New

[Ed. The VSUM document is also available on cert.sei.cmu.edu, in the
pub/virus-l/docs directory, for anonymous FTP.]

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

Date:    27 Jul 90 21:04:00 -0500
From:    "6SWSCX" <[e-mail]>
Subject: Possible Problems with VSHIELD and NK.EXE?? (PC)

I have a Zenithe Z-184 Laptop system with the NUMERIKEYS external
keypad installed. SCANRES ver 61 did not have any problems with
the NK.EXE file that is the software driver for the keypad. When
I loaded VSHIELD ver 64, it indicates that NK.EXE is infected with t
with the [1381] Virus. I double checked the master disks, which
had previously ben used only to make backup copies, and the
NK.EXE is shown to be infected on them. I have had no probelms with
the computer or any of the files today,so I'm wondering if
this is really an infected file or just a misidentification by
VSHIELD?

Has anyone else seen this type of problem?

Regards,
          Tom Creek

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

Date:    Wed, 01 Aug 90 16:04:20 -0500
From:    martha rapp <[e-mail]>
Subject: Virusafe

Has anyone ever head of Virusafe?  I have never seen any reference to it in
Virus-l.  Thanks.
                                    Martha Rapp
                                    Computing Services
                                    IUPUI

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

Date:    02 Aug 90 03:54:42 +0000
From:    [e-mail] (Woody Baker @ Eagle Signal)
Subject: Re: LaserWriter virus?

I'd like to thank Ken for posting the code, and to aplogize to him for
the rather abrasive note that I sent him.  I have since recieved a
series of questions from an individual about the contents of the code.
I have examined the hex code.  It is encrypted via a standard
encryption routine used by Adobe, and documented in the new Black Book
(the Type 1 Font Spec) book.  The core routine, the 68000 machine
language rotine is identical to the routine that I use for reading the
eeprom, right down to the checksum.  Since machine language routines
have to be installed by the cexec operator, and since that operator
will not function unless it is invoked from within a procedure that
has been called via eexec (known as executing from within an eexec
context), Nigel simply did the following:

<
......680000 code
> userdict begin cexec currentfile closefile

and eexeced it.  Then when eexec executes, the machine language will
be executed by cexec, and the operator installed.  I have taken
a slightly diffrent tack, to achieve the same result.  The dangerous
routine,  writeeeprom is a separate bit of 68000 code.  I have decided
to remove that from my code, so at this point my code is essentialy
the same as Nigels code, except that I don't chage the password.  I just
report it.

As was pointed out, this is a double edged sword.  If you know the
password you can reset the password.  This routine shows you the
password.  If you choose, you can then reset it to some other value.
This means that this routine could be used as the primary attack to
change the password, and mess things up.  It also means that if that
happens, you can know about it and fix it.  The universe is perverse.
It is, however, better to be able to undo the damage when it is done
than not to be able to undo the damage.

Cheers
Woody

p.s.  The code posted is a simple text file that can be sent to any
Adobe 68000 postscript printer by any means whatsoever from any host
whatsoever.  It cannot hurt the host in anyway.

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

End of VIRUS-L Digest [Volume 3 Issue 137]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253