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

Text File | 1995-01-03 | 12KB | 278 lines

VIRUS-L Digest              Monday, 13 Mar 1989         Volume 2 : Issue 63

Today's Topics:
Computer Security Conference in NJ
Espionage
Notarization
Use of Digital Signatures
Use of Digital Signatures
Re: Macs with wills of their own
Merry Christmas... I think :-(

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

Date: Fri, 10 Mar 89 09:10:26 EST
From: [e-mail] (Joe Sieczkowski)
Subject: Computer Security Conference in NJ

Apparently someone's holding a computer security conference soon.

[Taken from IEEE Newsletter, March 1989, Vol. 35, Number 9]
[Reprinted without Permission]

   On March 23, 1989 the North Jersey Joint Computers and
Communications Society will meet to hear a talk on "Computer
Security." The speaker will be Dr. Roy S. Freedman of the Polytechnic
University.  This meeting replaces the one planned on March 22nd
entitled "Cryptography" and will broaden the subject to include the
whole field of computer security.
                         ...[Cut Paragraph]...
   ...He [Dr. Freedman] will also discuss how some recent work in
cryptographis systems may thwart computer virus attacks, and how
computer surveillance should be used to assess the "health" of an
installation.
                         ...[Cut Paragraph]...
Time: 8:00 PM, Thursday, March 23, 1989.
Place: ITT Club House, 417 River Road, Nutley, NJ
Further Info: Elliot L. Gruenberg [phone]

[End of article]

Has anyone heard anything about this conference?
Perhaps its worth attending...

Joe

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

Date: Fri, 10 Mar 89 12:49:01 EST
From: [e-mail] (Joe Sieczkowski)
Subject: Espionage

All (or almost all) of the viruses/worms/trojans we have seen on the
list have been found because of one of the following:
  (1) An error [Lehigh virus, Internet worm]
  (2) It advertised itself [ping-pong, scores]
  (3) It blatently destroyed something [...(I'm sure you can think of some)..]
Most of which were propably developed and released immediately; ie V1.0
(I guess most of you had experience with V1.0 software packages :-)

Picture a group of programmers from firm "A" who wish to see their
competetor's (firm "B") data.  Firm A designs a virus that will place
a very special back-door in a computer system.  After the virus
successfully installs the back-door, it removes itself from the system
leaving no trace.  However, Firm A doesn't release it right away.
They put this very "controlled" virus on their own computer system for
testing.  They watch for symptoms, accumulate statistics, and wait for
their users to have trouble with normal operations.  After six months
or so, when the have all the bugs worked out Firm A manages to have
Firm B's computer infected.  In a certain amount of time (whatever
Firm A's statistics say), Firm A is pretty sure Firm B's computer
has the back door installed.  Firm A then proceeds to steal Firm B's
data through the back-door.

You have to start to wonder, if a single person can quickly hack out a
decent virus, what can a company do if they dedicate a team of system
programers to the project.

Joe

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

Date:  Fri, 10 Mar 89 21:38 EST
From:  [e-mail]
Subject:  Notarization

I would like to reiterate that - cryptographic notarization can be a
strong tool for protecting computer systems from virus attacks.  It is
not the only mechanism required for complete protection.  Other
components of a complete system might include strong memory
management, a "trusted" software base, and security policies and
procedures.  The policies and procedures are actually the most
important in that they are what most of us now rely on.

Since the only feedback on my proposal so far has been negative, I
would like to respond to Jeff Ogata's criticism:

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

Wrong.  Many mechanisms can be used to protect the software that might
check a "cryptographically sealed" program.  The simplest is to
restart a computer with the verification software on a disk with the
write protect tab set.  Other schemes are possible and are independent
of the cryptography and data formats.

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

I am proposing a hierarchical notarization system.  Only one piece of
information and the verification software, or hardware, must be
delivered to all users.  All further notarization signatures are
delivered with the "sealed" information.  This means that "untrusted"
means can be used for the distribution of the software and the
softwares signature.  If you are interested please read ISO 9594-8
(aka CCITT X.509).

>   ...  Such signatures would be just as easily corrupted as the
>programs in question.

Wrong.  Read any recent article on public key cryptography.

In response to Don Alvarez's comments that:

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

It is interesting to note that public key algorithms are based on
NP-complete algorithms (eg RSA).  In this branch of mathematics, know
as complexity theory, it possible to prove that the problem in the
class NP-complete, but not if a particular problem might be "solved".
In particular, the RSA scheme would be weakened if a major
breakthrough was made in the factoring of numbers.  This is very
unlikely, but not provable.  The RSA algorithm, even with this slight
uncertainty, is considered to be "good".  This is an interesting
topic, but I believe that Don was referring to issues relating to
proving implementations correct.  He is correct that this is desirable
for a specific implementation.  I still maintain that the development
of a software notarization standard is independent of these
considerations.

>Unless that black-box is designed into the physical architecture of
>the computer you get NO PROTECTION from it.

Yes, but the "black-box" could be software.  The minimum required of
the physical architecture is a reset switch and a disk write protect
mechanism.  I would propose that given a single "trusted" verification
program, a system could be "bootstrapped" so that all installed
software was verified.  It is possible that a "sealed" program might
contain a virus.  This virus would be detectable if it altered any
other "sealed" information.  The source of the virus would then be
directly traceable to the notarization authority, in this case the
issuing software house.

Once again, the software notarization does not solve all computer
security problems.  Policies and procedures are still required to
ensure the correct usage of this tool in existing systems.  Future
computing systems could provide more assurances and the verification
"black-box" in hardware.

Paul A. Lambert              Motorola GEG, Secure Network Section
Lambert -at docmaster.arpa   8201 E. McDowell
[phone]               Scottsdale, Az. 85252

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

Date:  Sat, 11 Mar 89 10:48 EST
From:  [e-mail]
Subject:  Use of Digital Signatures

Even in the face of digital signatures
>The operating system and signature-computing program are still
>healthy targets for attack.

True.  Digital signatures are not mechanisms for preventing attack.
Rather, they are mechanisms for preserving trust, fixing
accountability, and relieving the innocent.

If you corrupt my signature verification mechanism, I can no longer
rely upon it.  However, in the presence and use of such a mechanism, I
had to trust you before you could do that.  If I trust you, you can
always damage me, ONCE.  That does not diminish the value of knowing
that it is truly you (rather than someone pretending to be you) that I
can no longer trust.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

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

Date:  Sat, 11 Mar 89 10:32 EST
From:  [e-mail]
Subject:  Use of Digital Signatures

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

The signature can be distributed with the program.  If you verify it,
it will give you confidence that it has not been corrupted since being
signed.  If you trust the signer, you can trust the code.

Of course, you must have a trusted copy of the public key of the
signer.  You may get this from any trusted source (usually signed by
the private key of that source, whose public key you already have and
trust.)

You must also have a small trusted space in which to verify the
signature and store the keys.  This will usually be your PC and a
diskette for that purpose.  (We cannot trust the managers of shared
systems for this purpose.)

Note that this is not a mechanism for creating trust; it is only a
mechanism for maintaining and distributing trust which already
exists.

This does not require any invention or even implementation; an
implementation is already available and its use has been endorsed by
the Internet Activities Board.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

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

Date: 9  Mar 89  9:11 +0100
From: Danny Schwendener <[e-mail]>
Subject: Re: Macs with wills of their own

>If, when this is happening, there is a small "hand" icon in the upper
>right hand corner of the screen (in the menu bar) then it IS Timbuktu,

Note that there are other "foreign screen control" programs on the
marketplace.  One I'm particularly aware of is MoNet, by Juri Munkki
<[e-mail]> in Finland. His package does the same, but
does not display a warning on the foreign Mac, like Timbuktu does with
the "eye" or "hand" icons.

- -- Danny Schwendener
   ETH Macintosh Support

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

Date:         Sun, 12 Mar 1989 16:07 EST
From:         Grey Fox <[e-mail]>
Subject:      Merry Christmas... I think :-(

Oooh... Nasty christmas exec programs running around... It's an easy
concept to grasp once someone does it... But has anyone thought to
execute the original author of the damn thing? Oh well.. Anyway...

Anyone ever think that one reason hackers write viruses is to prove
that it can be done? I have a program that lowercases entire IBM VM
directories... Dangerous to run, but written to prove that it could
be done... And it could probably be hooked to a christmas exec spreader,
or some sort of virus thingy that would corrupt other Exec files in
a directory or a combination of the two... It has the potential to be
devastating. (Which is why I am not releasing it).
                        -Bruce Ide

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

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