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

Text File | 1995-01-03 | 27KB | 649 lines

VIRUS-L Digest   Tuesday,  2 Jan 1990    Volume 3 : Issue 1

Today's Topics:

Re: WDEF / Apology to Mainstay Software (Mac)
Tracking Infections
Re: AIDS TROJAN RESEARCH
Call for Papers --- 13th National Computer Security Conference
Questions re VIRUS-L
Re: DES Availability
Re: Virus trends
Comments Attributed to SWE
AIDS Program (PC)
Ascii 255
"Do not use this Diskette"
Spafford's Theorems
Re: Virus Trends

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:    Fri, 22 Dec 89 16:17:00 -0500
From:    [e-mail]
Subject: Re: WDEF / Apology to Mainstay Software (Mac)

[e-mail] writes:

> 1st Aid Software deserves a great deal of credit for having the only
> virus prevention tool that was capable of catching WDEF.  Everybody
> else failed, including Symantec's SAM, HJC's Virex, Gatekeeper, and
> Vaccine.  I don't know about MainStay's AntiToxin - I don't have a
> copy of that either (yet).

Disinfectant 1.5 can also catch/remove WDEF virus.

 Binod Taterway, User Consultant, Lehigh University Computing Center
 Lehigh University, Bethlehem, PA 18015.         Tel: [phone]
 E-mail: [e-mail] (Internet),     [e-mail]

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

Date:    Fri, 22 Dec 89 16:07:21 -0600
From:    "McMahon,Brian D" <[e-mail]>
Subject: Tracking Infections

The current flurry of WDEF infection reports has reawakened a long-standing
interest of mine in tracking the propagation of nasties (term intended to
include both virus and Trojan horse).  I know people will occasionally post
messages to this list along the lines of, "If anyone's keeping track of
infection reports...", but this seems to be rather sporadic and haphazard.

Question:  Who is collecting such information, and in what form?  I would
certainly be willing to offer my assistance in the collection effort, but
how much of this wheel has already been invented, and what remains to be
done?

Going one step further, what if we were to formalize the procedure of
reporting, at least for the academic sites, by enlisting "spotters" at
various institutions, who would then file a brief report on any infections
at their location?  Microcomputer coordinators and user-support staffers
would be likely candidates.  This is a suggestion for discussion, so I'd
welcome any feedback, positive or negative.

Brian McMahon  <[e-mail]>
Academic Programmer
Grinnell College
Grinnell, Iowa 50112
[phone]

Standard disclaimer ... my opinions only. <mumble>

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

Date:    Fri, 22 Dec 00 19:89:01 +0000
From:    microsoft![e-mail]
Subject: Re: AIDS TROJAN RESEARCH

>              AIDS "TROJAN" DISK UPDATE - DECEMBER 17, 1989
>
> First, let us say for the record that everything reported so far by
> Mr. McAfee is correct. Our tests bear out the results he has obtained.
>
> A form of public key encryption is then used to perform the actual
> encryption. This was determined by the brute force decryption method.
> SWE has several 80486's and access to a VAX and they were put to work
> decrypting the files. It was made easier by the fact that the original
> contents of the test disk were known. One nasty little trick the AIDS
> "trojan" uses is that after each file is encrypted the encryption key
> is modified slightly.

Can either of you shed some light on the above message?  It contains
serious contradictions with both itself and the statements of Mr.
McAfee with whom it purports to agree.

The comments about DES and public key encryption contained in the
above message are extremely confused.  All indication is that the AIDS
trojan does simple substitutions on file names.  The above message
claims that the entire disk is encrypted with a public key encryption
scheme.

My conclusion is that this message was not posted in good faith.  The
last thing anyone needs is this kind of purposeful misinformation.
This conclusion is supported by the claim that the so-called SWE
company has moved and "returned" their sample disks to the owners.

By associating yourselves with this nonsense, you have seriously impaired
your reputations.

sincerely,

Alonzo Gariepy
alonzo@microsoft

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

Date:    Sat, 23 Dec 89 08:59:00 -0500
From:    Jack Holleran <[e-mail]>
Subject: Call for Papers --- 13th National Computer Security Conference

CALL  FOR  PAPERS:

           13th NATIONAL COMPUTER  SECURITY CONFERENCE
                          Sponsored by
            the National Computer Security Center
                               and
       the National Institute of Standards and Technology

Theme:    Information Systems Security:  Standards - The Key to the Future

Date:                   OCTOBER 1-4, 1990

Location:                WASHINGTON, D.C.

This conference provides a forum for the Government and the private sector to
share current information that is useful and of general interest to the
conference participants on technologies, present and future, that are designed
to meet the ever-growing challenge of telecommunications and automated
information systems security.  The conference will offer multiple tracks for
the needs of users, vendors, and the research and development communities.
The focus of the conference will be on: Systems Application Guidance,
Awareness, Training, and Education, Ethics and Issues, Evaluation and
Certification, Innovations and New Products, Management and Administration,
and Disaster Prevention and Recovery.  We encourage submission of papers on
the following topics of high interest:

Systems Application Guidance
    -    Access Control Strategies
    -    Achieving Network Security
    -    Building on Trusted Computing Bases
    -    Integrating INFOSEC into Systems
    -    Preparing Security Plans
    -    Secure Architectures
    -    Securing Heterogeneous Networks
    -    Small Systems Security

Innovations and New Products
    -    Approved/Endorsed Products
    -    Audit Reduction Tools and Techniques
    -    Biometric Authentication
    -    Data Base Security
    -    Personal Identification and Authentication
    -    Smart Card Applications
    -    Tools and Technology

Awareness, Training and Education
    -    Building Security Awareness
    -    Compusec Training:  Curricula, Effectiveness, Media
    -    Curriculum for Differing Levels of Users
    -    Keeping Security In Step With Technology
    -    Policies, Standards, and Guidelines
    -    Understanding the Threat

Evaluation and Certification
    -    Assurance and Analytic Techniques
    -    Conducting Security Evaluations
    -    Covert Channel Analysis
    -    Experiences in Applying Verification
    -    Formal Policy Models
    -    Techniques

Management and Administration
    -    Accrediting Information Systems and Networks
    -    Defining and Specifying Computer Security Requirements
    -    Life Cycle Management
    -    Managing Risk
    -    Role of Standards
    -    Security Requirements

Disaster Prevention and Recovery
    -    Assurance of Service
    -    Computer Viruses
    -    Contingency Planning
    -    Disaster Recovery
    -    Malicious Code
    -    Survivability

Ethics and Issues
    -    Computer Abuse/Misuse
    -    Ethics in the Workplace
    -    Individual Rights
    -    Laws
    -    Relationship of Ethics to Technology
    -    Standards of Ethics in Information Technology


BY FEBRUARY 16, 1990:  Send eight copies of your draft paper* or panel
suggestions to one of the following addresses.  Include the topical category
of your submission, author name(s), address, and telephone number on the cover
sheet only.

    1.  FOR PAPERS SENT VIA        National Computer Security Conference
          U.S. or Foreign             ATTN:  NCS Conference Secretary
         Government  MAIL             National Computer Security Center
              ONLY:                   Fort George G. Meade, MD 20755-6000

    2.   FOR PAPERS SENT VIA       National Computer Security Conference
         COMMERCIAL COURIER           c/o NCS Conference Secretary
       SERVICES (e.g.-FEDERAL         National Computer Security Center
         EXPRESS, EMERY, UPS,         911 Elkridge Landing Road
              etc.):                  Linthicum, MD  21090

    3.  FOR Electronic Mail:  [e-mail]   (1 copy)

BY MAY 4, 1990: Speakers selected to participate in the conference will be
notified.

BY JUNE 22, 1990:  Final, camera-ready papers are due.

 * Government employees or those under Government sponsorship must so identify
their papers.

For additional information on submissions, please call [phone].

     To assist the Technical Review Committee, the following is required for
all submissions:

        Page 1:     Title of paper or submission
                           Topical Category & keywords
                           Author(s)
                           Organization(s)
                           Phone number(s)
                           Net address(es), if available
                           Point of Contact
     Additionally, submissions sponsored by the U.S. Government must provide
the following information:
                        U.S. Government Program Sponsor or Procuring Element
                        Contract number (if applicable)
                        U.S. Government Publication Release Authority
                           (Note:  Responsibility for U.S. Government
                            pre-publication review lies with the author(s).)

      Page 2:      Title of the paper or submission
        -last       abstract
                    The paper   (Suggested length:  6 pages, double columns)

     A Technical Review Committee, composed of U.S. Government and Industry
Computer Security experts, will referee submissions only for technical merit
for publication and presentation at the National Computer Security (NCS)
Conference.  No classified submissions will be accepted for review.

     Papers drafted as part of the author's official U.S. Government duties
may not be subject to copyright.  Papers submitted that are subject to
copyright must be accompanied by a written assignment to the NCS Conference
Committee or written authorization to publish and release the paper at the
Committee's discretion.  Papers selected for presentation at the NCS
Conference requiring U.S. Government pre-publication review must include,
with the submission of the final paper no later than June 22, 1990 to the
committee, a written release from the U.S. Government Department or Agency
responsible for pre-publication review.  Failure to comply may result in
rescinding selection for publication and for presentation at the 13th NCS
Conference.

     Technical questions can be addressed to the NCS Conference Committee
through the following means:

            Phone:                   (301) 850-0CSC  [0272]

            Electronic Mail:         [e-mail]

            Government Mail:         National Computer Security Conference
                                       National Computer Security Center
                                       Fort George G. Meade, MD 20755-6000

            Commercial Carriers:     National Computer Security Conference
                                       c/o NCS Conference Secretary
                                       National Computer Security Center
                                       911 Elkridge Landing Road
                                       Linthicum, MD  21090

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

Date:    Sat, 23 Dec 89 21:38:00 -0500
From:    "Peter S. Graham" <[e-mail]>
Subject: Questions re VIRUS-L

I have two questions which the digest has probably dealt with but for
newcomers might be worth responding to again:

1.  Does the Digest provide a way to query the effectiveness of commercial
antivirus programs against known viruses? --e.g., a kind of table with
commercial (or other published programs) across the top and known viruses
down the side and an X at the intersection if the program handles it.  This
would be a real service.

2.  Does this Digest have a formal feedback mechanism to commercial and other
antivirus program developers, so that they get a sense of what needs to be
done and pronto?  Or do we know that they are all members of the listserv and
we leave it at that, depending on laissez-faire economics?

As a new reader I appreciate the service and the effort that goes into it.

Peter Graham
Associate Vice President for Information Services
Rutgers University / New Jersey

[Ed. To answer 1., there have been various informal product reviews
sent in to the VIRUS-L digest by various readers (perhaps someone out
there has put them together in one doc?) as well as pointers to other
reviews (e.g., PC Mag).

The digest does not offer a formal feedback mechanism.  However,
numerous shareware and commercial anti-virus product vendors to
monitor and (in some cases) contribute to the digest.  Feedback sent
to the digest does reach them.]

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

Date:    Sun, 24 Dec 89 16:49:07 +0200
From:    [e-mail] (Timo Kiravuo)
Subject: Re: DES Availability

>>For those not aware, the U.S. Government guards the DES formula,

>   Please correct me if I'm wrong, but isn't DES or DES-like
>encryption algorithms readily available?

As far as I understand, the DES formula is public, but exporting
impelemntations is prohibited in the USA. However there is
nothing preventing one to make a DES implementation outside the
USA and distributing it. Here in Helsinki University of
Technology Antti Louko has written one, it is available by
anonymous ftp from kampi.hut.fi (130.233.224.2), file is
alo/des-dist.tar.Z.

It was also posted to USENET comp.sources.??? group a while ago,
the posting was dove via a moderator in Australia, since
importing DES to the is legal by the US law. (Please note that
whatever the US government has to say about DES does not apply to
us outside the US territory, the most USA can do is to contact
our government or send a spy killer or invade Finland like they
did invade Panama.)

As to what this has to do with viruses, I don't know, but I think
that a public DES implementation might be interesting enough to
many people in the virus field, so maybe the moderator will be
nice and let this pass.
- --
Timo Kiravuo
Helsinki University of Technology, Computing Center
work: 90-451 4328, home: 90-676 076
[e-mail]  sorvi::kiravuo  [e-mail]

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

Date:    Tue, 26 Dec 89 08:17:52 -0500
From:    [e-mail] (David Gursky)
Subject: Re: Virus trends

> To: [e-mail]
> Date: Fri, 22 Dec 89 19:13:24 -0500
> From: [e-mail]
>
> One of the best-known and best researched anti-viral programs for the Amiga
> is VirusX by Steve Tibbetts. A few months ago a new version of this program
> began appearing which was really a trojan. It got rather wide distribution
> before anyone noticed that Tibbetts hadn't really written it. Since that
> time, Tibbetts no longer publishes his source code when he releases a new
> version.
>
> In other words: The prediction you didn't like was really true; it already
> came about!

Oops!  Minor omission on my part.  I neglected to include in my
comment about the authors being well known that they should be easily
and widely reachable!

There is also the underlying presumption in my message that a new
release is confirmed from the author before publication of the
application

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

Date:    Thu, 21 Dec 89 10:22:00 -0500
From:    [e-mail]
Subject: Comments Attributed to SWE

The following comments indicated by ">" were attributed to SWE in
VIRUS-L 1234.

>SWE first suspected and tested for the public key encryption method
>for several reasons. The major reason was the lack of access people
>outside of the United States would have to the DES encryption formula.

[The DEA is an encryption algorithm developed and licensed by IBM. The
DES is a U. S. Government standard for the implementation of that
algorithm.]

The DES is published and available from The Superintendent of
Documents, U.S.  Government Printing Office Washington, D.C.  It
can be implemented in software without much difficulty.  It is
widely available outside the U.  S.

>For those not aware, the U.S. Government guards the DES formula, and
>software which makes use of this formula may not be exported out of
>the United States. Should it turn out that the DES formula was also
>used, the authors of the AIDS "trojan", could possibly be prosecuted
>under United States statutes pertaining to national security.

While export of any munitions, including cryptography, from the U.S.
msut be licensed, possession or use of the DES or DES outside the U. S.
is not a crime.

>The second reason deals with the DES encryption method. Students of
>cryptology are well aware that the DES formula has been considered
>vulnerable for some time now.

Students of cryptology are aware of an untruth.  While there have
been flawed implementations of the DEA, the cheapest know attack
against the DES is an exhaustive attack against the key.
Such an attack is measured in centuries of 3090 time.

>It is also a well know fact that DES
>specific processors have been produced, which make "cracking" a DES
>encrypted file much easier than the public key method. The DES method
>also limits to a greater degree the length of the encryption key.

Have you seen one?  Do you even know anyone that has seen one?        (Of
course everyone knows someone who knows someone who has seen one, but
that is true of UFO's too.

As to the relative strength of the two method, each is, in part a
function of the key length chosen.  However, in general, public
key lengths of 8 to 10 times as long are required to achieve
comparable security with the DEA.

While the DES limits the length of the key to 56 bits, choice of
key length in an implementation is arbitrary.  IBM sells an
implementation that employs a 112 bit key, if only to protect other
keys.

>Combining these two reasons along with the extraordinary expense the
>authors of the AIDS "trojan" went to, we guessed that they would also
>use a "first class" encryption method.

Very naive analysis.  John McAfee writes:

>    A comparison of the encrypted and unencrypted entries
>indicates that some form of linear character mapping was used
>i.e.     # = I, } = A, 8 = E, @ = D, etc.)

In other words, "first class" equates to a Captain Midnight decoder
ring.  So much for this writer's expert analysis.

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

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

Date:    Thu, 21 Dec 89 15:15:00 -0500
From:    [e-mail]
Subject: AIDS Program (PC)

Does the AIDS program do what it purports to do?  Is that something that
the recipients were interested in having done?  Was it worth $.50 a day?

It is necessary to understand the answers to these questions in order to
know whether we are dealing with:

1) Attempted extortion;

2) A very expensive, obscurely motivated, and otherwise gratuitous
attack;

3) Or, a peculiarly inept attempt to market a program.

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

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

Date:    Thu, 21 Dec 89 15:21:00 -0500
From:    [e-mail]
Subject: Ascii 255

I like the idea of using a non-displayable character to conceal the
presence of a directory.  I also like the idea of using it on the end of
a file name in order to make it hard to establish addressability to the
file.

I like it now almost as much as I did when I first read the idea in the
readers' contributions to PC Magazine.

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

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

Date:    Thu, 21 Dec 89 15:26:00 -0500
From:    [e-mail]
Subject: "Do not use this Diskette"

This advice published in association with the AIDS program is good
advice.

It is a special case of the advice that says use only programs or
diskettes that you expect from trusted sources.

This is a special case of the advice that says do not open mail that has
no return address, is not expected, or is otherwise suspicious.  In a
small number of cases it may be very dangerous to do so.

____________________________________________________________________
William Hugh Murray                     216-861-5000
Fellow,                                 203-966-4769
Information System Security             203-964-7348 (CELLULAR)
                                        ARPA: WHMurray@DOCKMASTER
Ernst & Young                           MCI-Mail: 315-8580
2000 National City Center               TELEX: 6503158580
Cleveland, Ohio 44114                   FAX: [phone]
                                        Compu-Serve: 75126,1722
                                        INET: WH.MURRAY/EWINET.USA
21 Locust Avenue, Suite 2D              DASnet: [DCM1WM]WMURRAY
New Canaan, Connecticut 06840           PRODIGY: DXBM57A
- --------------------------------------------------------------------

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

Date:    Fri, 22 Dec 89 12:28:00 -0500
From:    [e-mail]
Subject: Spafford's Theorems

In general, I agree with theorems 1, 2, and 3.  I think that those that
deal with the future, are speculative.  However, in the same spirit and
along the same lines, I offer the following:

1. The amount of damage to data and availability done by viruses to date
has been less than users do to themselves by error every day.

2. The press speculation about the DATACRIME virus was much more
damaging than the virus.

3. The amount of damage that has been done to trust within the community
is orders of magnitude worse.

4. Viruses and rumors of viruses have the potential to destroy society's
already fragile trust in our ability to get computers to do that which
we intend while avoiding unintended adverse consequences.

5. We learn from the biological analogy that viruses are self-limiting.

Clinically, if you catch a cold, you will either get over it, or you
will die.  Epidemiologically, a virus in a limited population
will either make its hosts immune, or destroy the population.  Even in
open population, a virus must have a long incubation period and slow
replication in order to be successful (that is, replicate and spread).

6. The current vector for viruses is floppy disks and diskettes, not
programs.  That is to say, it is the media, rather than the programs,
that are moving and being shared.

A virus that is stored on such media will be very persistent.  One
infected diskette pulled from a drawer may began a new cycle.

On the other hand, diskettes as media have a limited life expectancy.
Punched paper lasted just a century; 8.5" floppies only a decade.  The
life of such media is a function of a number of complex factors.  The
success of the current technology augers for a long life, while the pace
of technology suggests that it will be short.

7. AIDS not withstanding, terrorists have more effective and efficient
mechanisms at hand.  Amateurs have a very high vested interest in a
community in which programs can be relied upon to do only what they
advertise.  It is to be hoped that they can be socialized not "to soil
their own sandpiles."

Season's Greetings.

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

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

Date:    Mon, 25 Dec 89 19:45:47 -0800
From:    [e-mail]
Subject: Re: Virus Trends

     Back in the 1970s, when I was working on secure operating systems,
I never dreamed that the day would come when there would be twenty five
million computers in the world running without memory protection.

     And it's going to get worse.  New and interesting programmatic objects
are coming into being.  Attacks need not be through object programs.
Already, there have been attacks via mail, and via text files editable by
GNU EMACS.  But this is just the beginning.

     - PostScript is a programming language.  Trojan horses could be
       embedded in PostScript files.  While attacking a printer isn't
       all that productive, Display PostScript offers more tempting
       targets.

     - A FAX message is a bitstream interpreted by an interpreter at
       the receving end.  Could it be induced to do something interesting
       through the use of illegal bit patterns?  Group III is probably too
       simple to be attacked, but group IV?  Imagine a message which
       causes a FAX machine to send an extra copy of transmitted documents
       to another location.

     - Network transmittable C++ objects are being developed.  Security
       doesn't seem to be mentioned.  This has promise.

     - Multi-media electronic mail offers new avenues of attack.

The basic problem is that the transmission of programmatic objects is
on the increase, and anything interpreted at the receiving end is
potentially a means of attack.  I predict that this will grow to a
moderately serious problem in the 1990s.

                                        John Nagle

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

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