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

Text File | 1995-01-03 | 13KB | 261 lines

VIRUS-L Digest             Thursday, 9 Mar 1989         Volume 2 : Issue 61

Today's Topics:
Cartoons and wily hackers
Re: Bouncing ball virus (PC)
Warning: Urgent: A CHRISTMAS EXEC is around (IBM REXX)
BUL EXEC - second issue (IBM REXX)
Notarization
re: notorizing

[Ed. Please be advised that April 1 (fool's day) is rapidly
approaching; it is not uncommon on the networks to find fake e-mail
every year around this time.  I will do my best to keep such mail from
making it into a digest...]

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

Date: Wed, 8 Mar 89 09:52:59 est
From: ubu![e-mail]
Subject: Cartoons and wily hackers

A couple of topics that have gotten a lot of attention recently on
RISKS, among other places, are the use of cartoons to talk about
viruses and the arrest of three West German "computer spies" (for lack
of a better name).  I thought I'd mention this here to find out what
peoples' thoughts are on the subjects.

Recent Dick Tracy (and reportedly other) comic strips have portrayed
viruses and virus authors (the Dick Tracy strip apparently has a
character who is using a virus for extortion).  RISKS readers seem to
think (by and large) that comic strips aren't too bad for talking
about these things *if* they are portrayed accurately.  Any thoughts?

Also, those of us who've read Cliff Stoll's "Stalking the Wily
Hacker" will be interested to hear that three people have now been
arrested in West Germany in regards to the case described by Dr.
Stoll.  While this isn't directly virus related, it is interesting to
note that the suspects used various computers and networks for
espionage purposes.  It will also be interesting to see the outcome of
the case in the courts.

Ken

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

Date:        Tue,  07 Mar 89 16:31:28 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: Bouncing ball virus (PC)

  In #58 Rob Nauta asked about the bouncing ball virus.  This was
described in #18 (18 Jan), where I referred to it as the Ping-Pong
virus.  As I described it then,

>                                                   It is a virus
>which first appeared in Israel [in October 1988], and which got
>its name because of a bouncing point which appears on the screen.
>Like the Brain virus, it resides in the boot sector of disks, in bad
>sectors, and in high RAM.  ....
>  Among the points in which it differs from the Brain virus: (1) It
>infects hard disks, not only 5 1/4-inch floppies.  (2) It marks only
>one cluster as bad.  (3) It grabs only 2K of high RAM.  (4) To the
>best of my knowledge, it does not cause any damage to files or to the
>FAT.  In particular, the bad sectors seem to always be chosen from
>unused clusters.

  The bouncing dot appears only under very special conditions: when
(1) the system clock shows a multiple of 30 minutes and (2) the disk
is being accessed.  The simplest way to force the dot to appear (if
RAM is infected) is to enter TIME 0 and then immediately type a cha-
racter and press Enter.  (Even after the dot appears, you can continue
working.  The dot will disappear only when you reboot or turn off the
computer.)
  Other symptoms: 2K missing from RAM (or a multiple of 2K if infec-
tion has taken place more than once); one bad cluster on disks.  Both
of these can be checked by performing CHKDSK, of course.  If you see
1K in bad sectors on a diskette, that's a pretty sure sign of this
virus since FORMAT marks bad sectors in blocks of 5K.  (Anyone know
why?)  Note that when the virus marks the bad cluster, it does so on
only one copy of the FAT.
  Finally, the virus causes access to diskettes to be slower because
of the attempts to infect them.
  It seems to be more contagious than the Brain virus; presumably the
main reason is its infection of hard disks also.
  In response to Rob's other questions, I'm fairly sure that there's
no counter which will trigger further damage when it reaches some
specified value, and that there's no specific "seeder" program.
However, when Rob said that it spreads on bootable disks, he
presumably meant *only* bootable disks, which is incorrect: like
Brain, it also spreads on non-system diskettes.  (They too have boot
sectors.)
  At the time I posted my earlier article, I had not heard of this
virus outside of Israel, so I assumed that it was a local product.
Since then I've heard of it (or something very similar to it) in the
UK (in May 88) and in Italy (and now in the Netherlands).  In the UK
it is referred to as the Italian virus since it was traced (by Dr.
Alan Solomon) to Torino, Italy.  (Some of the information given above
was supplied by him.)
  In answer to Joseph Beckman's question, this virus is not just a
splice of the Brain virus with ball code.  On the one hand, it infects
hard disks too; on the other hand it's considerably smaller than Brain
and lacks some of Brain's features, such as feeding you the contents
of the original boot sector when you try to look at the infected boot
sector.

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

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

Date:         Wed, 8 Mar 89 16:19:26 GMT
From:         nad Turgut Kalfaoglu <[e-mail]>
Subject:      Warning: Urgent: A CHRISTMAS EXEC is around (IBM REXX)

From Linkfail list:

A user here wrote a file called BUL EXEC which can distribute itself
by using userid() NAMES.. it is almost identical to CHRISTMAS EXEC,
but different picture.. Checks :node tag as well, and can jump from
node to node..  The link will be down until we clean the problems
here. -turgut

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

Date:         Wed, 8 Mar 89 20:40:46 GMT
From:         Turgut Kalfaoglu <[e-mail]>
Subject:      BUL EXEC - second issue (IBM REXX)

A follow up on BUL EXEC.........

- ----------------------------Original message----------------------------

After several hours of automatic reader scanning, there are no more
copies of BUL EXEC on spool areas on TREARN. There are some that are
RECEIVED to disks, but I have sent several warnings, and will be
notifying everyone on this. I have a disconnected-running program to
scan the RSCS queue repeatedly, and will be purging them if it comes
accross a copy.  Fortunately, we discovered the program, 10 minutes
after it was released, by its author who warned us.

I hope, and don't think that the file has jumped to the FRMOP22 line,
but it may have jumped to the other Turkish nodes. (I have closed the
FRMOP line for several hours due to this).  Again, the filename is BUL
EXEC, and it is a christmas exec (it sends itself to everyone on NAMES
file) Regards, -turgut

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

Date:     Wed, 8 Mar 89 16:13:47 EST
From:     Jefferson Ogata (me!) <[e-mail]>
Subject:  Notarization

>>.................... a simple virus like Brain will spread regard-
>>less of program encryption, because it attaches to code that could be
>>stored encrypted.

I think this is a misquote.  The original message said Brain will
spread because it attaches to code that canNOT be stored encrypted.
This was in reference to yet another suggestion that encryption (not
cryptography in general) be used to keep executable files in a
protected state, only to be unencrypted before execution.  I'd like
to remind readers that this scheme has important flaws: namely, the
encryption program itself can be attacked; and the operating system
can be attacked (by such as Brain).

Regarding the idea of notarization of programs, I must assume you
are referring to some method of distributing signatures of some
kind, to be compared with signatures computed by the user who wants
to know if a program is secure.  It has been pointed out several
times that if some channel exists whereby these signatures can be
distributed without corruption, there is no reason why the programs
themselves could not be distributed by the same channels.  One must
consider where the user needing authentication is going to acquire
signatures: probably the same place he got the program -- a bulletin
board.  Such signatures would be just as easily corrupted as the
programs in question.

In order for a signature verification method to be viable, someone
must come up with a method for verifying the signatures.  Perhaps
when this has been accomplished, we might discuss standards for
signature generation.  The operating system and signature-computing
program are still healthy targets for attack.

If you have some way of verifying signatures, or if you are talking
about an entirely different mode of protection, I'd be very inter-
ested to hear about it.

- - Jeff Ogata

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

Date: Thu, 9 Mar 89 00:36:53 EST
From: Don Alvarez <[e-mail]>
Subject: re: notorizing

Paul Lambert suggests that cryptographic notorizing is the solution to
viruses, and then goes on to state:

" To support the development of real cryptographic devices, standards
must be available to ensure interoperability.  The issues of a virus
working their way around an implementation are not relevant to the
development of the standards.  Only the local implementation of a
verification mechanism must be conserned with these issues."

NOT TRUE!!!
A standard is ONLY of value if you can PROVE that it can be
implemented without theoretical weaknesses.  Any cryptographic
solution includes some black-box which does the magic to check the
notorizing value, encrypt the password, or whatever.

Unless that black-box is designed into the physical architecture of
the computer you get NO PROTECTION from it.  Why? because you can't
trust the black-box.  There is and will continue to be an enormous
installed base of PC's, Vaxen, Suns, etc.  These existing machines do
not have any special notorizing hardware attached.  That means either
you force every IBM-PC user to install some $500 board in his machine
that probably won't be compatible with his existing software, OR you
modify his MS-DOS do to the cryptographic checks in software.  The
hardware solution is prohibitively expensive, and the software
solution is worthless.  The software solution is PARTICULARLY
worthless if it's standardized (as many others have pointed out)
because if it's standardized, then somebody has a standard they can
set their virus to attack.  DOS on your hard disk is just like any
other file.  It can be attacked and altered by viruses.  It is true
that there are excellent secure communication models for sharing data
over an untrusted medium between mutually untrusting hosts (see
Needham and Schroeder, for example, or any of the alphanumeric strings
that Mr. Lambert quotes to prove this is all a solved problem) but all
such models assume that the local magic box can be trusted.  As long
as the magic box is reprogrammable it is fundamentally untrustworthy.

You can't use software to protect yourself against viruses, because
software can be reprogrammed by the very computer you are trying to
protect.  You can't use hardware to protect existing computers against
viruses, because it's not economically feasible.  The only machines
you can have any hope of absolutely protecting against viruses are
next-generation machines which have watch-dog hardware built in (and
I'm not even convinced that's possible).

Standards are all well and good, but you HAVE to think about how they
are going to be implemented, because if it can't be implemented
securely, your standard isn't any good.

I will be accused of being negative and pessimistic.  That is true.
If you are designing a security system you HAVE to assume the worst
case, and the worst case in this case is that somebody writes a virus
to attack the cryptographic software which your machine depends on.

                        - Don

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

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

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