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

Text File | 1995-01-03 | 15KB | 353 lines

VIRUS-L Digest              Friday, 17 Mar 1989         Volume 2 : Issue 66

Today's Topics:
re: Virus hysteria.
overprotection, lowercase VM filenames, corporate espionage
Re: File lock protection?  (Mac)
Virus Publicity & the Media
Re: File lock protection?  (Mac)
notarization
New virus (PC)
nVIR infection on MAC

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

Date: Tue, 14 Mar 89 15:07 EST
From: Eric Thies <[e-mail]>
Subject: re: Virus hysteria.

>Date:     Mon, 13 Mar 89 08:40 EST
>From:     Cincinnati Bengals. <[e-mail]>
>Subject:  Virus hysteria.
>
>     I was wondering if anyone has comments on the way reports of
>viruses seem to be given too much attention by the media.  As an
[...]
>Surely this is newsworthy, but front page?  This seems comparable to
>placing reports on the front page every time the common cold breaks
>out on campus.  Comments?

Yeah.  We got about the same reaction a while back when we had a few
problems with a virus.  And about a week later, the internet virus
hit.  The papers sort of lumped everything together; one even claimed
that we had 25 or so computers hit by the internet virus.  Actually we
had 25 or so floppy disks hit by the PC virus and weren't touched by
the internet virus (we aren't on the internet (yet) :-)

I get the feeling that computer viruses are the new boogie man.  For
most people, computers are these big, mysterious things which sort of
'control' things...and the idea that these viruses can 'destroy
everything' is terribly frightening to most.  This parallels the fear
that the word Communist used to (and for some still does) invoke.

Something that most don't know much about and that can destroy
everything...  something we can't control...since it has
control...makes us feel HELPLESS.  The media love to pick up on things
that scare the hell out of folks...fear and sex sell.  Just wait for a
virus that draws sexy pictures...:-)

>Tom Kummer

- -eric
++==++==++==++==++==++==++==++==++==++=++==++==++==++==++==++==++==++==++
Eric Thies, Systems                    [e-mail]
Academic Computer Center               [e-mail]
Univ. of N. Carolina at Greensboro     [e-mail]
Greensboro, NC 27412-5001  Tel: [phone]   "Peace, love, waterbed."
++==++==++==++==++==++==++==++==++==++==++==++==+==++==++==++==++==++==++

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

Date:         Wed, 15 Mar 89 04:22:11 EST
From:         Steve <[e-mail]>
Subject:      overprotection, lowercase VM filenames, corporate espionage

I just wanted to comment on some things:

   Reed Rector suggests that he'd be willing to pay more for a program
that incorporated some kind of anti-viral or virus-detection feature.  I
wouldn't.  First of all, I am very picky and have enough trouble finding
software that has precisely the features I want, so I could care less
about an added new-fangled and probably ineffective anti-viral feature.
Second, I rarely come across viruses (none so far that I know of.  In
fact I don't think I even know anybody who has actually seen a virus.
Yes, I got a copy of CHRISTMA EXEC, but I wasn't stupid enough to run
it...).  Second, I prefer to protect myself by keeping backup copies of
things I care about (on write-locked diskettes); this is also good
protection against the most common problem I encounter: corrupted
portions of a disk (NOT due to a virus or the like, but instead due to
a bad or marginal sector, or a program that doesn't check to see that
you haven't switched diskettes before it writes).  Sophisticated file
encryption schemes would waste my time (but it wouldn't hurt to have
checksums somewhere so I could check the integrity of my files should I
ever suspect viral activity).  I am in agreement with what Don Alvarez
said so very well about all this a few months ago.

   Bruce Ide mentions a program that changes all your (VM) filenames to
lowercase on an IBM mainframe system.  I encountered lowercase
filenames by accident initially (created by one of my own programs).
I now have EXECs which rename mixed-case filenames to or from uppercase.
This sort of thing is really not a problem.  And there's always VMBACKUP
(automatic backups) if one finds a few files missing...

   Joe Sieczkowski raises the very interesting issue of a company
patching a trapdoor into a competitor's computer.  I would think that no
company would be willing to risk their reputation on such an escapade.
The secret would very likely come out eventually (or even serve very well
as blackmail material for a disgruntled systems programmer).  However...

Steve Woronick         | Disclaimer:  Always check it out for yourself...
Physics Dept.          |
SUNY at                |
Stony Brook, NY  11794 |
Acknowledge-To: <XRAYSROK@SBCCVM>

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

Date:     Wed, 15 Mar 89 09:10 EST
From:     "Brian D. McMahon" <[e-mail]>
Subject:  Re: File lock protection?  (Mac)

>MacUser magazine reported in the Tip Sheet section of their April
>issue that locking individual files using the Locked bit of the Finder
>info (using the Locked button in the Get Info window, or a file
>utility program) will prevent virus infection.
[ . . . ]
>My question -- will this really accomplish anything?  Can any known
>viruses infect an application file that has its Locked bit set?

No.  A file that has been locked by software can also be *unlocked* by
software.  On the Mac, this is darn near trivial -- I think it would
be a matter of only a few bytes of code in the virus, to call the
appropriate unlocking routine.  (Where is my _Inside Macintosh_ when I
need it?)  While I don't know for certain whether any of the known
nasties actually do this, relying on software locks is definitely
unsafe.

>Mark H. Anbinder
>Department of Media Services
>Cornell University

Brian McMahon    <BRIAN@UC780>
Administrative Computing
University of Maryland University College

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

Date:     Wed, 15 Mar 89 09:02 MDT
From:     "Craig M." <[e-mail]>
Subject:  Virus Publicity & the Media

I agree with Tom Kummer--I think there is too much "sensationalizing"
of a virus outbreak.  An even more obvious example than the front-page
newspaper article is our University of Utah's Mac outbreak.  It not
only hit the Deseret News and Salt Lake Tribune (although not front
page), all three network station carriers reported it on the evening
news.  It also hit a cable news station, but it was later at night.

They must think that something like this is outstanding and will
capture more-than-normal public attention; I can't imagine what else
it could be.

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

From: Danny Schwendener <[e-mail]>
Subject: Re: File lock protection?  (Mac)

>MacUser magazine reported in the Tip Sheet section of their April
>issue that locking individual files using the Locked bit of the Finder
>info (using the Locked button in the Get Info window, or a file
>utility program) will prevent virus infection.

All currently known viruses will fail to infect a file if the latter
is locked. All viruses (current and future) will fail if the *disk*
the file is on is locked. The difference is that locking a file merely
causes a bit in the file information to be changed, while
(hardware-)locking a disk physically disables all write-accesses to
the volume.

Software-locking of files or volumes may be bypassed, albeit not
easily. Moreover, some applications, which save their settings in the
data fork or in a resource within the application file, won't work
correctly if they have been previously locked. So it is not a good
idea to rely on software-locking as only protection against viruses.

- -- Danny Schwendener
   ETH Macintosh Support

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

Date:  Thu, 16 Mar 89 08:55 EST
From:  [e-mail]
Subject:  notarization

>You STILL need a clean channel for transmitting the decryption key;
>else anyone can modify a decrypted version of the signature file,
>encrypt it again with another public key set and distribute the
>new decryption key with the new signature file.  This is a trivial
>step for anyone who actually desires to modify the signature file.
>Public-key cryptography is just begging the question.

Not true.  All signatures for a hierarchical notarization system
would be verifiable to a single primary authority.  The ONLY
trusted distribution required for the system would be the
public certificate of the "root" certification authority.

The following illustration should clarify this proposal.

Pa      is the public certificate of authority "A"
Sa(Pb)  is the public certificate of "B" signed by "A"

                                   Pa
                             |
                   -------------------
                   |                  |
                   | Sa(Pb)           | Sa(Pc)
              ------------       ------------
              |          |       |          |
              |          |       |          |
             Sb(Pd)     Sb(Pe)  Sc(Pf)     Sc(Pg)

A more formal description  can be found in ISO DIS 9594-8
where ASN.1 is used to define a certificate as:

Certificate  ::= SIGNED SEQUENCE {
        signature             AlgorithmIdentifer,
        issuer                Name,
        validity              Validity,  -- a time period
        subject               Name,
        subjectPublicKeyInfo  SubjectPublicKeyInfo}

The important part of this certificate defintion is
that the certification authority (CA) binds the
subjects name, the subjects public information,
and the certification authorites name (issuer) together
with a digital signature.

Extending the definitions in 9594-8 for the notarization of files
a posible "dataseal" would be:

DataSeal  ::= SIGNED SEQUENCE {
        filename              OCTET STRING,
        filelength            INTEGER,
        algid                 AlgorithmIdentifer,
        issuer                Name,
        filehashvalue         ENCRYPTED OCTET STRING
                              -- where the octet string is the
                              -- result of the hashing of
                              -- data in 'filename'
        }

The definition above would allow the sealed data, the "dataseal"
and the certificates to be distributed separatly.


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

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

Date: Thu Mar 16 09:16:13 1989
From: utoday![e-mail]
Subject: New virus (PC)

Just a quick note on a relatively new virus, and a "directed" virus at
that:

One of my larger clients called me in because they discovered that
some of their dBase files were corrupt. Wanted me to fix them up.
When I got there, I discovered that a database file (all have .DBF
extensions) worked on machine A, but when the files were copied to
floppy, they didn't work on machine B.  But they would work on a
machine which had Machine A's copy of DBASE brought over to it.

Upon investigation, I discovered a small TSR virus on Machine A.  It
had infected the DBASE program which was later run on MAchine C, hence
why it worked there.

The virus, after spreading to all .COM and .EXE files in the current
directory, would look for an open operation on a .DBF file.  All
writes to the file would have two bytes transposed at random. These
bytes' offsets were stored in a file called "BUG.DAT" (a hidden file)
in the .DBF's directory.  Subsequent reads of this data would cause
the transposition of the same data, and everything would look nifty.
After this code had run for 90 days (after the BUG.DAT file was 90
days old), it would trash the disk (eat the FAT and root directory).

Getting rid of the virus wasn't difficult: just copy in new
executables from your backup.  However! If you did this, your data is
history - nothing to transpose it back into "real" form.  What I did
was to debug the heck out of the virus, find the *write* transposition
and null it out, then read each corrupted data file and write it back
out.  Look for the sequence
   "MOV  AL, ds:[bx+si]
    MOV  AH, ds:[dx+di]
    XCHG AH, AL
    MOV  ds:[bx+si], al
    MOV  ds:[bx+di], ah"

and either null out the XCHG operation or all of the above.  This
effectively will remove the transposition only only on the write (for
some reason, the reverse transposition on the read used substantially
different code).

After nulling it out, simply use the infected DBASE program to read
all the corrputed files and to write them back out to a new file.
Viola! Now, copy over the infected code with your backup copy of the
executable and things should work out well.

Since this is a TSR virus, make sure to do a boot operation after
you've done the "repair" on the DBASE program.  Obviously, you'll have
to disinfect all the other programs on your disk as well.  Look for
the sequence "ssi" at offset location 7. If found, you've found an
infected file.

The scary part: if you're infected and just remove the infection, your
data becomes worthless.

I've only seen this virus at one site so far.

Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   PCMagNet: 72241,36

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

Date: 17 March 1989, 01:30:05 ECT
From: Anders Christensen   [phone] <[e-mail]>
Subject: nVIR infection on MAC

Some users at our university claim that their Macintoshes have been
infected by nVIR after they inserted and then removed an infected
diskette, without executing any program on (or booting from) the
infected diskette.

One of the users claims this happened:
   - He booted from a writeprotected 'clean' original diskette
   - He formated the harddisk, and moved the system and some other
        software there (all writeprotected and 'clean')
   - He then tested the system with VirusDetective and Interferon
        without getting any warnings
   - Then he inserted an infected diskette, and removed it immediately
        without running any program
   - He then ran VirusDetective and Interferon and got a message that
        the harddisk has been infected by nVIR.

The above would be possible if the Mac loaded executable code from the
diskette into memory and started executing it whenever a diskette is
inserted. Is there any Mac-Wizard who can tell me if Macs behave like
this or not?

Anders Christensen
User Consultant
Computer Center (RUNIT-D)
Norwegian Institute of Technology

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

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