Return-Path: <[email protected]>
Received: from csmes.ncsl.nist.gov (MACBETH.NCSL.NIST.GOV) by csrc.ncsl.nist.gov (4.1/NIST)
       id AA05000; Tue, 22 Sep 92 15:36:48 EDT
Posted-Date: Tue, 22 Sep 1992 15:13:59 -0400
Received-Date: Tue, 22 Sep 92 15:36:48 EDT
Errors-To: [email protected]
Received: from Fidoii.CC.Lehigh.EDU by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm))
       id AA01059; Tue, 22 Sep 92 15:31:24 EDT
Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA14158
 (5.65c/IDA-1.4.4); Tue, 22 Sep 1992 15:13:59 -0400
Date: Tue, 22 Sep 1992 15:13:59 -0400
Message-Id: <[email protected]>
Comment: Virus Discussion List
Originator: [email protected]
Errors-To: [email protected]
Reply-To: <[email protected]>
Sender: [email protected]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: Kenneth R. van Wyk <[email protected]>
To: Multiple recipients of list <[email protected]>
Subject: VIRUS-L Digest V5 #154
Status: R
VIRUS-L Digest   Tuesday, 22 Sep 1992    Volume 5 : Issue 154

Today's Topics:

Re: Auto-detecting Virus (PC)
Michelangelo/Stoned ? (PC)
Re: F-prot false alarm? (PC)
Jerusalem and Netware (PC)
Re: Castlewoflenstein (PC)
Maltese Amoeba Virus (PC)
Help with Soned A virus (PC)
virus dissection (PC)
Re[2]: NAVSCAN (PC)
F-PROT V2.05 problems (PC)
Re: tbscanx41 and scan95 ! (PC)
Re: Maltese Amoeba virus (PC)
Re: Network Virus protection. Help. (PC)
Write protection of floppies (again) (PC)
Symantec promo mailing (PC)
Re: Problem w' booting C: then A: (PC)
Viruses and OS/2 (OS/2)
Re: Self-checking programs
"New trends and other stuff"
Looking '88 RTM Internet worm papers. (UNIX)
MacMag authorship (CVP)

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.  (The complete set of posting guidelines is available by
FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
your real name.  Send contributions to [email protected].
Information on accessing anti-virus, documentation, and back-issue
archives is distributed periodically on the list.  A FAQ (Frequently
Asked Questions) document and all of the back-issues are available by
anonymous FTP on cert.org (192.88.209.5).  Administrative mail
(comments, suggestions, and so forth) should be sent to me at:
<[email protected]>.

  Ken van Wyk

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

Date:    18 Sep 92 10:17:12 +0000
>From:    [email protected] (Vesselin Bontchev)
Subject: Re: Auto-detecting Virus (PC)

[email protected] (A. Padgett Peterson) writes:

> I must respectfully disagree. Every version of DOS since then
> including DOS 5.0 provides a method for validating the original Int
> 13h vector.

You mean the INT 2Fh/AH=13h stuff? I works only since DOS 3.30, is not
documented, and is used mostly by the viruses themselves...

> >Unfortunately, since DOS 3.20 the interrupt vector for INT 13h never
> >points to the BIOS area (except at boot time), since DOS intercepts it
                           ^^^^^^^^^^^^^^^^^^^^

> Personally, I use a program that runs before DOS (from the BIOS level)
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No disagreement here... :-)

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 18 Sep 92 12:42:40 +0000
>From:    [email protected] (Dick Cleek)
Subject: Michelangelo/Stoned ? (PC)

We run a lab w/stand-alone 8088s and networked 286s. The 8088s are
protected by an old version of fprot. It triggered yesterday and
locked up the machines with the message about a program trying to
write to INT 13.  The networked machines were protected by FPROT 2.0,
BUT, we had disabled that last week as we switched to a new server.
Several network machines zapped student disks, making them unreadable;
usually a bad sector error.

I used Fprot 2.04 to see what was going on. It reported Michelangelo
on the 286s.  It reported Michelangelo on the 8088s IF I booted the
machine with FPROT on a system disk. However, if I booted the infected
8088s with a standard system disk and THEN ran FPROT, it reported
STONED? Everything has now been disinfected and we are checking all
disks entering the lab, but I'm curious.

Does this sound like Michelangelo? Only high density disks were
blasted. It is NOT March 6. And why does STONED get reported in this
one situation?

Thanks  in advance.
- --
........   .........................         .......................
: |_|\/\/ :   Dick Cleek                        [email protected]
:.centers.:   Univ.of Wisconsin Centers         [email protected]

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

Date:    Fri, 18 Sep 92 11:03:00 -0400
>From:    [email protected] (Andy Lo A Foe)
Subject: Re: F-prot false alarm? (PC)

[email protected] writes:

>Unless Andy has a different version of Dos 5 to mine then I think he
>really might have a problem. My copy is not PkLited, nor are any of
>the Dos 5 files for that matter,

I forgot to mention that I compressed the executables myself.

>nor does FP-205 report any infection.
>Backup.Exe is 36092 bytes and the CRC-32 is 5591A20A hex.

The original (non-pklite'd) version is indeed 36092 bytes. I don't have
a program that generates CRC-32, but McAfee's validate program gave the
following two CRC's:

Method 1 - D2A1
Method 2 - 1FD4

Try pkliting your backup.exe and I think you'll end up with an
"infected" file.

Thanks,
Andy


 /\  |\ | |~\ |_|   Internet : [email protected]
/~~\ | \| |_/  |        UUCP : ...!upr2.clu.net!uvs!exp!andy
Andy R. Lo A Foe    Faxmodem : 597/491-117

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

Date:    Fri, 18 Sep 92 11:23:57 -0400
>From:    [email protected] (A. Padgett Peterson)
Subject: Jerusalem and Netware (PC)

>From:    G J Scobie <[email protected]>

>>From:    [email protected] (A. Padgett Peterson)
>>Subject: Re: NetWare and viruses - some new results (PC)

>>Unfortunately, many users (and some applications) become very unhappy
>>if they do not have WRITE right in their own directories. This was the
>>problem I had with one LAN last year, the custom MAIL facility
>>demanded WRITE right to itself. JERUSALEM spread like mad.

>My experience of the Jerusalem Virus on netware 3.11 is that an
>infected station cannot infect a file on the server because of the use
>of INT 21h by the netware shell and the virus itself.  Workstations
>just bomb out if an infected program is run from the workstations hard
>disk before any infection can take place. I am assuming that the above
>LAN was not netware or have I have just been lucky?

That is correct and I observed the same thing *under 3.11*, it has to do
with an interrupt used for the print server and is not any deliberate
anti-viral function. With enough fiddling J can be made to spread on 3.11
if the conflicting functions are disabled.

Being lazy, I just used another of the Jerusalem family & it worked
just fine (please, no questions about which one).

                                       Warmly,

                                               Padgett

BTW - am not surprised that Fred & I arrived at the same conclusions
     about Netware protection (see Vesselin's posting in #152). Logic
     is explicit. Was surprised that Fred puts as much faith in ATTRIBUTES
     as RIGHTS. RIGHTS are a server function and cannot be changed without
     permission. ATTRIBUTES are a function of the client shell and are
     mutable by code. In archaeic terms, ATTRIBUTES are enforced from
     inside the user state. RIGHTS are not.

     Next we must consider that different versions of NetWare used different
     enforcement mechanisms. For instance, though I have not tested it, I
     would not be surprised to find that the DOS ATTRIB could be used to
     change early READONLY even though it will not under 3.11 given only
     CRWF.

     Further, the equations Vess listed from Fred left out some of the
     combinational effects such as ~C is effectively as protected as
     C+R+~W (NOT CREATE is as safe as CREATE AND READ AND NOT WRITE). This
     is why I found an odd (not 2^n) number of protected states.

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

Date:    Fri, 18 Sep 92 12:12:40 -0400
>From:    [email protected] (Olivier M.J. Crepin-Leblond) (Olivier M.J. Crepin-L
         eblond)
Subject: Re: Castlewoflenstein (PC)

[email protected] (Rick Schryvers) writes:

> This is just a friendly little warning to all in echoland.  Seems as
> if some generous "programmer" has taken upon himself to construct a
> virus and attach it to a hacked game.  The game is called "CASTLE
> WOLFENSTEIN" , the virus is in a file called "wolfchet.exe" its
> basically a cheat program that allows you to have unlimited lives and
> unlimited ammunition in the game.

I recall a problem involving this game earlier this year. The matter
was extensively discussed in the USENET group comp.sys.ibm.pc.games.
CASTLE WOLFENSTEIN for the PC is a shareware program which was made
available by Apogee Games on the Internet via anonymous FTP. A great
number of hacks were made by isolated individuals, copies loaded on
BBS all around the place, and, of course, map editors and cheats
written by hackers. One program, a Map Editor, was in fact a Trojan
Horse, and destroyed data on your disk. It looks as though
"wolfchet.exe" is that program. Then again, it may be yet ANOTHER
crack by some malicious hacker.

> However, it also infects your boot
> track of your hard disk.  McCaffee v.91b identified this virus as the
> "Wolf" virus, however others have mentioned it may be a variant of the
> "Whale" virus.

I am not sure whether the Trojan horse I'm talking about could be
actually classified as a virus. FYI, it was discovered sometime in
May or April 1992 (my memory is weak... perhaps a bit earlier).

> Just thought I would let you know...by the way...the virus made its
> way to South Florida by way of a British sailor.  As many people know,
> the Port of Tampa is a stop off point for many British warships.  One
> of these warships had a sailor on it who with the use of his Laptop
> computer brought over software from Europe and
> posted it on Florida BBS's.  I'm not accusing the sailor that he knew
> what was going on, however, it does seem that alot of viruses seem to
> orginate in places other than the USA.

Rumours rumours....
BTW, we do have computers outside USA ! ;-)

- --
Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department
Imperial College of Science, Technology and Medicine, London SW7 2BT, UK
      Internet/Bitnet: <[email protected]> - Janet: <[email protected]>
WARNING: Please send any reply to above addresses, NOT to FROM-field !!!

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

Date:    Fri, 18 Sep 92 15:55:32 +0000
>From:    [email protected] (Gerald L Jr Reno)
Subject: Maltese Amoeba Virus (PC)

Can anyone tell me about the Maltese Amoeba virus? I just got a
warning from a software company that one of their disks may have been
infected, and that only Norton Anti-Virus can detect it.

Can anything else detect it? (tr: are they getting kickback from
Norton?) (tr: shouldn't they have to shell out the two thousand bucks
for a site-license for NAV for my department, since they caused any
infection?) What does the virus do?

Thanks in advance,

Jerry Reno (MSU Dept. of Statistics) [email protected]

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

Date:    Fri, 18 Sep 92 15:40:09 -0400
>From:    [email protected]
Subject: Help with Soned A virus (PC)

I am new to this list and don't know if this has come up in recent
discussions but I need immediate help.  Please feel free to answer
directly to me.

We have a small lab in our library with just a few machines.  The
three are not networked but are connected via a switch box to a
printer.  All three machines have the exact same problem and came up
with it at the exact asame time.  Upon boot up, it goes through its
memory scan then tries to access the A drive then accesses the C
drive.  At this point the screen clears (of the memory count) and the
cursor sits about mid screen.  Then it will do one of two things.  It
will either freeze at this point and just not do anything or after a
few seconds, garbage (colored boxes, smiley faces, weird symbols) will
appear across the top of the screen and in the middle of the screen.
At this point it will freeze and do nothing but blink colored boxes.

The machines will boot from the A drive and access everything on the C
drive just fine from that point on.  Now the real tricky part.  I ran
F-PROT on the machines and all three came up with Michelangelo
viruses.  It said that it removed them.  Reboot and same problem.  So
I rebooted again from A and ran F-PROT and this time it says infected
with Stoned-A and a variant of Stoned.  But then it says removed.  As
soon as I run F-PROT again, it continues to say Stoned variant is in
boot sector.  No matter how many times I run the program, Stoned is
always there.  And it still gives the same problem on booting from the
C drive.

Now getting frustrated, I decided to just format the hard drive and be
done with it.  But low and behold, after installing the system files,
same problem on boot up and after running F-Prot, same Stoned variant
in boot sector.

Now I will admit to being behind on my knowledge of viruses and how
they work, so this might seem like a pretty simple problem.  But we
have a lab down and desperatly need to get the machines up and going
again.  Any help would be greatly appreciated.

Oh, by the way, the only thing done to these machines in the past few
weeks was a Localtalk PC card (to put into mac network)was installed.
But they were checked out after the installation and worked for a
couple of weeks after.  I did remove the card just to be sure and the
same thing happened.

Thanks for any help.

Jean
*******************************************************************************
* TTTTT W     W  U   U     Jean Mankoff         [email protected]      *
*   T   W     W  U   U     Academic Computing   Bitnet - MANKOFF@TWU          *
*   T   W  W  W  U   U     P.O. Box 23836  TWU Sta.      (817) 898-3286       *
*   T    WW WW    UUU      Denton,  TX  76204        FAX (817) 898-3198       *
*******************************************************************************

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

Date:    Fri, 18 Sep 92 17:03:32 -0400
>From:    Brian Seborg <[email protected]>
Subject: virus dissection (PC)

Ken De Cruyenaere writes:

>McAfee v95 identifies it as "1530" but will not clean it.

>CPAV (1.2) does not detect it.

> F-PROT (V2.05) does not detect it (even in HEURISTICS) (!)
> When infected, VIRSTOP does note that it has been changed and >
> tells one to  boot from a clean diskette, but VIRSTOP doesn't >
> stop the boot at that point (?!).

> It appears to infect .EXEs and .COMs.  It seems to go for
> COMMAND.COM first.  Infected files increase in size (by apprx >
> 1960) but the date doesn't change.

Patricia Hoffman's VSUM lists the 1530 virus as CB-1530 (according to
her July 1992 version).  Your description seems to more closely
resemble the 1963 virus.  Both of these viruses are related to the
Dark Avenger Virus so this may account for McAfee's seeming mis-
identification.  The only thing which doesn't jibe is that 1963 is
reported to be a stealth virus, and your brief report does not seem to
support this.  You may want to download this file and compare your
findings with her description of these two viruses to determine
whether or not you have one of these viruses, or a variant.  Your
report of the file size increase suggests either a mis-identification
by SCAN or a variant at this point.  Mis-identification by SCAN of a
virus has been known to happen in the past! :-) It is always best to
check the characteristics of a captured virus against its description
to see if in fact you have the same beast.  Patricia's VSUM should be
helpful in determining if you are at least talking about a similar
virus or not.

To test the virus' properties you can do the following:

1) Get an isolated test system which you don't care about.
2) Make sure it is clean to start with
3) Make copies of the MBR, CMOS values, BR, FAT, COMMAND.COM so
that you can recover if these are damaged.
4) Make sure you have clean, write-protected bootable copies of
DOS, your favorite scanner(s), and your favorite disk utility (I
like Norton myself).
5) Make a directory on the hard-disk of your machine and fill it
with clean decoys (use various size .com and .exe files for
example.  Record all of the dates, file sizes, attributes etc. for
these files.  Make sure that a wide variety of file sizes are
represented since some viruses have minimum length requirements.
Include a copy of a file you believe to be infected with the virus,
but don't run it yet.
6) make sure that no device drivers are running, a "vanilla" system
is best to start with, you can try adding device drivers later to
see if they are impacted.  The best thing to do is to make sure
that no autoexec.bat or config.sys file exists on your test system.

7) Run chkdsk and record all of the values including RAM, Disk
space etc.
8) run mapmem or some other utility and record all of the values.
9) check the length of command.com and record this and the time and
date values.
10) run your virus infected file.
11) run chkdsk and see if any of the values have changed.  If so,
by how much?
12) run mapmem and see if any values have changed.  If so, what?
13) try copying and renaming some of your decoy files.  Did any of
them change?  If so, which ones and by how much?
14) try executing some of your files.  Did they change?  If so, by
how much?
15) look at command.com, did it change? How?
16) do a directory of your decoy directory and record all values.
17) turn off the machine and reboot from a clean version of DOS.
18) Look at command.com, your decoys, and run chkdsk.  Do your
findings jibe with what you found with the virus active?  If not,
you may have a stealth beast.
19) run an exe and a com out of the set of decoys you used.  Do
they run?
20) if they run, is the virus active?
21) repeat the above experiments changing time and date before
activating the virus.  Also, try adding read only and hidden DOS
attributes.  Does it infect hidden or read-only files?  If so,
does it restore the attribute (you can check this by checking the
attributes before and after infections).
22) Do files which are infected increase in size by a constant
amount, or is it variable?  How long for .com files? .exe files?
23) Using your disk utility see if you can find any strings in the
body of infected files which are common to all infected files.
What are they?
24) If you know how to use debug, trace a program before and after
infection.  How was it changed?
25) Do you see any indication of decryption in the assembly code?
26) Check the BR, and MBR, have they been changed?

It sounds like you may have performed many of the above experiments
and should have the answers to many of the questions.
Compare your results to the description of the virus in VSUM or
some other source.  If they seem to be the same then you have the
same virus and can use the information provided there to recover.
If it is not, (your findings will likely be more in-depth than
those provided in VSUM) then you can use what you know from your
experiments to help you recover.  If you can extract a scan string
feed this into your favorite scanner (via an external file function
which most provide) and see if the string accurately detects all of
the decoys you have infected.  If so, you can use this to scan all
of your machines and erase all infected files (this is ALWAYS the
best policy) then replace them from clean back-ups.  Try your
eradication techniques on your test machine to see if this works.
If they don't work, refine them until you can confidently eradicate
the virus from your test system.  Then go out and wipe it out on
production systems.

This is a simple-minded approach, and does not take into account
some fine points, but should be sufficient to allow you to rid
yourself of most viruses.  Good luck and feel free to e-mail me
if all-else fails.

Sincerely,

Brian Seborg

VDS Advanced Research Group

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

Date:    Fri, 18 Sep 92 20:25:14 -0400
>From:    Jimmy Kuo <[email protected]>
Subject: Re[2]: NAVSCAN (PC)

Robert Slade reports:
>> Where can i get NAVSCAN?  or When its gonna be out?

>It's on Compuserve.  As far as when it will get out, don't hold your
>breath.

>Jimmy has stated that Compuserve is the best the company can do right
>now.  It will *not* be posted to BBSes "around the world".  If anyone
>has acces to it on CompuServe, they are allowed to repost it.  Perhaps
>some kind soul will download it, and send xxencoded copies to site
>maintainers.

Robert and I seem to have miscommunicated a little.

It is on Compuserve in the following locations: NORUTL, VIRUS, IBMSYS,
and UKFORUM.  It is available from the Symantec BBSs: 2400:
408-973-9598, 9600: 408-973-9834.  It has also been sent to over 200
other BBSs across the US and other Symantec offices around the world
have distributed it.  (I haven't mentioned any of the other BBSs
because I didn't want to make any endorsements, etc.  (You know how
companies tend to travel the middle of the road.  :-( ))

It would be too difficult for me to send people electronic copies
because we have a 100Kbyte file maximum on our gateway to internet.  I
would really appreciate it if someone would put the package on
SIMTEL20.  I had hoped it would eventually work its way there.

Sorry for the delay in responding to all this.  I also was in Scotland
and had too much stuff to catch up on upon my return.  (Vesselin's
back!  There was so much to read!  :-) )

And last, a reminder, it is freeware for individuals.  Everyone should
have a copy!

Jimmy Kuo                                       [email protected]
Norton AntiVirus Research

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

Date:    Sat, 19 Sep 92 19:22:21 +0000
>From:    [email protected] (Leon Duong Luong Dang)
Subject: F-PROT V2.05 problems (PC)

I test F-prot v2.05 on a Novell 386 network and found that f-prot
would report a memory virus detection if more than 31 files fail to
open.  This happens in the G: drive which is our system volume for the
LAN. In the same time we also create a report file and I found that
there is no virus reported in this file, so I deduced that it may be
the errorlevel 4 which trigger our batch file to report a virus is
found.

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

Date:    Mon, 14 Sep 92 21:15:00 -0000
>From:    [email protected] (Roland Van Der Put)
Subject: Re: tbscanx41 and scan95 ! (PC)

Hello [email protected]!

In a msg of Saturday January 01 2028, [email protected] wrote to All:

Ib>      I was working on my computer...and had tbscanx41 resident when i
Ib> tried scan95 (new!) for the first time....and it found Israeli Boot
Ib> virus..  in the boot sector!

I have had the same experience! I will now try it with Scan95B and
TbScan 4.3

Ib>  Is it a bug...?  (must be)

It must be.

Greetings,
Roland

- --- GEcho 1.00/beta

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

Date:    21 Sep 92 10:29:41 +0000
>From:    [email protected] (Vesselin Bontchev)
Subject: Re: Maltese Amoeba virus (PC)

[email protected] (Gerald L Jr Reno) writes:

> Does anyone know anything about the Maltese Amoeba virus? I've

Yup! It's a very polymorphic multi-partite virus, which will activate
on November 1 and March 15 of any year, overwriting the first 4
sectors of the first 30 tracks of side 0 of the hard disk. It does not
infect COMMAND.COM. It is a fast infector - infects files even if you
just copy them. The infective length is 2457 bytes + up to 99 bytes
decryptor..

> been out of it for a bit, and just got a memo from a software
> company (John Wiley & Sons) informing me that some of their disks
> were infected.

> The letter only suggests that the virus "may, unfortunately,
> affect files on your hard drive"

Ha! They've been more than modest!

> and that it is only detectable
> by the Norton Anti-Virus (Version 2.0).

Nonsense! McAfee's SCAN and Fridrik Skulason's F-Prot are two programs
that are able to detect this virus reliably. Both are shareware and
available on most ftp sites.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected]    D-2000 Hamburg 54, Germany

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

Date:    Mon, 21 Sep 92 15:14:28 +0000
>From:    [email protected] (Karen S. Stallworth)
Subject: Re: Network Virus protection. Help. (PC)

Help!  We're experiencing something similar; the one I've just cleaned up is
a set of DOS 5.0 installation disks.
F-prot 2.05 secure scan on the DOS 5 floppies indicate:
 FORMAT.COM  "Possibly a dropper program for a new varient of Stoned"
 SETUP.EXE   "Possibly ...  "
       etc. for .EXE and COM files
SCAN v95 does not show anything.

Then we run the SETUP program on a hard drive.
 F-prot the hard drive, same message as on floppies.
 SCAN the hard drive, no viruses

 SCAN the formatted floppy, no viruses.
 F-prot the floppy, no viruses.
 SCAN the hard drive,
       Found Azusa  [Azusa] in partition table.
 F-prot the hard drive
       Boot sector infection of possible new varient of Stoned
               (not exact wording)
 CLEAN [Azusa]   on hard drive removes the virus
 Deleting the "possible dropper files" removes the danger.

I assume that this is not really Azusa -- so what could it be?
Thanks.
- -Karen Stallworth
Western Illinois University

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

Date:    Mon, 21 Sep 92 12:30:32 -0700
>From:    [email protected]
Subject: Write protection of floppies (again) (PC)

Further to the discussion of hardware write protection and its efficacy, a
note from one of the participants in the DECUS Canada Security SIG:

MUKLUK::DAVIDPM "David P. Maroun, Vancouver PC LUG " 13 lines  20-SEP-1992

        One common way to be safe while using a computer is to write-protect a
   diskette.  However, I have used a few double-density, 40-track diskette
   drives which would write to a diskette even if it had a write-protect
   tab in place.  I thought this indicated flaws in the drives, but
   recently I examined a Shugart drive which could be configured either to
   respect or ignore write-protect tabs.  On the drive is a jumper with
   two possible positions, one marked '-WP' the other marked '+WP'.  If
   the jumper is in the -WP position, the drive ignores write-protect
   tabs; putting the jumper in the +WP position prevents writing to
   diskettes that wear write-protect tabs.  I am told that the -WP
   position allows software suppliers to put software onto write-protected
   diskettes for clients.


=============
Vancouver      [email protected]         | Life is
Institute for  [email protected]      | unpredictable:
Research into  [email protected]         | eat dessert
User           [email protected]         | first.
Security       Canada V7K 2G6           |

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

Date:    Mon, 21 Sep 92 12:35:37 -0700
>From:    [email protected]
Subject: Symantec promo mailing (PC)

Received in the mail today a mailing from Symantec/Norton (to whom I
am apparently known as "Nam Inst Of 4 Res 2 Usersec").  It is
illustrated with a bogus "Symantec Times", the lead article of which,
under the picture of Peter Norton, is headlined "3 New Viruses Hit as
City Sleeps!", and starts out "It's true.  The `crazies' are still out
there ... "

Remind me.  Whom was it, as late as 1989, was still saying that viral programs
were an urban legend? ...

=============
Vancouver      [email protected]         | "The client interface
Institute for  [email protected]      |  is the boundary of
Research into  [email protected]         |  trustworthiness."
User           [email protected]         |    - Tony Buckland, UBC
Security       Canada V7K 2G6           |

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

Date:    Tue, 22 Sep 92 05:58:56 -0400
>From:    Anthony Naggs <[email protected]>
Subject: Re: Problem w' booting C: then A: (PC)

Keith R. Watson, <[email protected]>, reports:
> Someone recently noted that there is a trend in BIOS for boot from C:
> then A:. We have machines in use like this and have found a problem.
> Systems that have a SCSI controller will boot from A: even though the
> BIOS setup is set for C: then A:.  ...

This seems to be quite a common problem.

> ...  SCSI controllers have built in BIOS so CMOS is set to no hard drives
> installed. ...

The BIOS on hard drive controller cards has the obvious task of making the
drives available to software, (through Int 13H functions).

On PC and XT compatible computers the main BIOS often has no knowledge of
hard drives, and will not boot from them.  The solution to this is for the
BIOS on the controller card to takeover the boot process.  Thus ensuring that
the hard drive is checked at boot time, after the floppy drive.

In your case I can think of 2 diagnoses:
1   you are using a PC type controller card, such as a Seagate ST01 or ST02,
2   the manufacturer of your controller card has copied these functions from
   the PC version to the AT (ISA) / EISA / MCA card you are using.
   I am interested to learn which controller cards behave in this way,
   please email details to me.

[Note: PC cards can be distinguished, as they have one 'tongue' to fit the
main board slot, and AT/EISA cards have two.]

If you want the C: then A: boot sequence to work, you should change to a
controller cards that is compatible.  Alternately there are an increasing
number of security and anti-virus products supplied on plug-in cards,
these may enforce such behaviour.

Hope this helps,
Anthony Naggs
Software/Electronics Engineer                   P O Box 1080, Peacehaven
(and virus researcher)                          East Sussex  BN10 8PZ
Phone: +44 273 589701                           Great Britain
Email: (c/o Univ of Brighton) [email protected]  or  [email protected]

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

Date:    Fri, 18 Sep 92 17:27:37 +0000
>From:    [email protected] (Byron Thomas Faber)
Subject: Viruses and OS/2 (OS/2)

I'm currently using os/2 with no virus protection because I know of
nothing that would work correctly with os/2 (for protection methods).
I don't believe that alot of viruses (current) will run under os/2.

Does anybody know anything about os/2 and viruses who can
tell me if I'm right or wrong?

e-mail please

Byron Faber

- --
Question:  What's the fastest way       Internet:  [email protected]
          to run Windows?                         [email protected]
Answer:    Turn the computer off.                  Byron "Bohr" Faber

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

Date:    18 Sep 92 10:40:33 +0000
>From:    [email protected] (Vesselin Bontchev)
Subject: Re: Self-checking programs

[email protected] (Kevin Dean) writes:

>  AO> Your approach will fail to detect a stealth virus like 1963 or dir2.
                                                                    ^^^^^

> Stealth Bomber 2.2 should be available from several sites via
> anonymous FTP (I've been off VIRUS-L for a while so I don't remember
> where exactly).  Stealth Bomber is a set of C- and Pascal-callable
> routines that perform a CRC check on the running program and do a
> system check for any suspicious behaviour related to stealth viruses.

Have you actually tried it against Dir_II?

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: [email protected]    D-2000 Hamburg 54, Germany

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

Date:    Fri, 18 Sep 92 18:06:48 -0400
>From:    Brian Seborg <[email protected]>
Subject: "New trends and other stuff"

I have been watching the re-discovery of the already discovered with
some dismay.  Regarding the "new trend" to allow your computer to boot
off of the C: drive rather than the a: drive, this is not new.  Hasn't
anyone heard of a Zenith 248?  The military only has about 650,000 of
them.  This boot redirection has been re-definable in cmos for
some-time.  We're talking pre 1988 here.

Regarding Cohen's paper, I guess I am somewhat tired of hearing about
a paper that I do not have a copy of and perhaps that is making me
somewhat testy, but let's be serious about network security.  I hope
we are not going to have to find out that networks can be set up in an
un-secure manner.  What a surprise!  I work in a Banyan environment
and not Novell, but there are some general concepts that can be
readily translated into Novell or Banyan, or Lan Manager etc. which
can increase security, especially security against computer viruses.
Having aided in securing a relatively large number of LAN's connected
to a nation-wide WAN, I have some experience here.  I understand the
need to quantify security policy, but taking common practices and
reducing them to set notation for the sake of publishing a paper seems
to do nothing to advance the field.

Let me put down some controls which you can implement on your favorite
network (provided it's a client-server model and not peer-to-peer) to
decrease the probability of computer viruses running rampant.

1) Set the access rights for applications drives (file-services) to
read only for all users including administrators.  Administrators can
always change the permissions back temporarily when making updates or
changes, but will be protected from inadvertantly infecting the system
in general.

Some programs require users to have modification rights to
applications directories.  My experience suggests that most programs
of this sort can be set up so that users are given modify rights to
some files which are put in a seperate directory, and the application
itself can still be write-protected.  This is true for Paradox for
example (although several administrators will insist otherwise).  Call
Paradox or any other vendor for help setting your files up correctly.
They are aware of user's concerns and have solutions.  If the package
cannot operate with the application drive set to read-only, then dump
them.  There are plenty of similar products which will work this way,
let competition fix this problem.

2) If possible, do away with all file services where multiple user's
have write-access (except in small groups).  "Bit Bucket" file
services where everyone has write access are good places for Trojan
Horse programs, companion, and path companion viruses (or standard
trojans), and, in addition, are hard to manage since determining
ownership is a problem.  If you must have these type of file services,
limit the number of users (i.e. fragment them into smaller chunks, by
functional working group for example), don't allow any .bat, .com,
exe, files to reside in these directories.  Any applications,
including batch files, should reside in write-protected areas.

Also, make sure that user's path statements do not contain directories
where multiple people have write-access.  This is not only
unnecessary, but dangerous as well.

3) Scan all applications before and after installation.  Make a backup
tape of applications file-services so that they can easily be
re-created if a virus does get in.  Don't backup applications files
unless there is a change such as an upgrade.  Then only backup
applications after ensuring that they are virus free.

4) If possible, have all administrators maintain two accounts with
seperate passwords.  One account should have admin privileges, the
other should be a standard user account.  The administrator should
only use his/her admin account when performing administrator duties,
and should use the standard user account for day-to-day use.  If this
is not possible, administrators should ensure that both the station
they are logging in from, and the programs executed during the login
sequence (and during the post-login sequence) are guaranteed clean.
There is nothing like an infected administrator to spread viruses like
wild-fire.

5) Scan applications files daily.  Also, periodically scan personal
drives.  Personal drives are not as dangerous if they become infected
since only one user has access to these, but the danger becomes great
if the rest of the network is not protected correctly, or if the user
happens to be an administrator.

6) Scan administrator stations at least daily.  If an admin moves to a
different PC than his own to perform work, then this work-station
should be scanned prior to the administrator logging in.  User's
should be scanned at least weekly, if not more often (depending on
environment).

7) Administrators and users should be taught about security and
viruses through awareness courses, conference participation, corporate
bulletin boards, news- letters, etc. so that they understand the
importance of their participation in guaranteeing the security of
their workstation, and of the network in general.

8) Disaster recovery plans should be in existence and should be
practiced so that administrators and users know what to do in case of
a virus infection, how to assess the damage, and how to recover.

9) All virus incidents in a company should be reported (eventually) to
one central location.  This will allow for assessing the companies
overall virus program effectiveness, and will enable central staff to
keep track of what viruses are likely to appear.  It will also
facillitate standard recovery procedures.

There are other controls which I probably forgot, but I'm sure one of
your readers will point them out.  There is no mystery to securing a
network properly.  You just have to understand what facilities exist
and use them properly.  No one ever said it was easy, but this does
not mean that networks are intrinsically not secure, you just have to
take the time and effort to properly secure them with the security
they provide.  Now, if this security is not sufficient, then okay,
that is noteworthy, but, if it is just difficult, that can be remedied
by making sure your administrators not only understand the basic
operational elements of the network operating system, but also
understand the security risks and how to remedy them.  Currently, most
competent admin- istrators still need to understand more about
security and most security professionals need to understand more about
networks.

Sincerely,

Brian Seborg

VDS Advanced Research Group

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

Date:    22 Sep 92 00:54:26
>From:    [email protected] (Jeff Blaine)
Subject: Looking '88 RTM Internet worm papers. (UNIX)

Subject says it all.  Preferably in straight ASCII.  Please be
specific when giving FTP sites.  I am looking for anything and
everything about what happened.  The whole shebang.  Thanks for your
time.

- ----------------------------------------------------------------------------
Jeff Blaine - [email protected] - Jr. CS Major - Whee  ---------------
- ----------------------------------------------------------------------------

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

Date:    Sat, 19 Sep 92 01:05:05 +0000
>From:    [email protected] (Robert Slade)
Subject: MacMag authorship (CVP)



HISVIRB.CVP   920903

                    MacMag virus - Authorship

Richard Brandow was the publisher and editor of the MacMag computer
magazine.  Based out of Montreal, it was reported at the time to
have a circulation of about 40,000.  An electronic bulletin board
was also run in conjunction with the magazine.

Brandow at one point said that he had been thinking about the
"message" for two years prior to releasing it.  (Interesting, in
view of the fact that the date selected as a "trigger", March 2,
1988, was the first anniversary of the introduction of the Macintosh
II line.  It is also interesting that a "bug" in the virus which
caused system crashes affected only the Mac II.)  Confronted by
users upset by the virus, Brandow never denied it.  Indeed, he was
proud to claim "authorship", in spite of the fact that he did not,
himself, write the virus.  (Brandow had commissioned the programming
of the virus, and internal structure contains the name "Drew
Davidson".)

Brandow gave various reasons at various times for the writing of the
virus.  He once stated that he wanted to make a statement about
piracy and copying of computer programs.  (As stated before in
association with the Brain virus, a viral program can have little to
do with piracy per se, since the virus will spread on its own.)
However, most often he simply stated that the virus was a "message",
and seemed to imply that somehow it would promote world peace.  When
challenged by those who had found and disassembled the virus that
this was not an impressively friendly action, Brandow tended to fall
back on rather irrational arguments concerning the excessive level
of handgun ownership in the United States.  (My apologies on behalf
of my countrymen.  While few of us like handguns, not many of us
show this level of illogic.)

(It is interesting, in view of the "Dutch Crackers" group, the Chaos
Computer Club and the Bulgarian "virus factory", that Brandow
apparently felt he had a lot of support from those who had seen the
virus in Europe.  The level of social acceptance of cracking and
virus writing shows an intriguing cultural difference between the
European states and the United States.)

My suspicion, once again, is that the MacMag virus was written
primarily with advertising in mind.  Although it backfired almost
immediately, Richard Brandow seems to have milked it for all it was
worth, in terms of notoriety.  For a time, in fact, he was the
"computer commentator" for the CBC's national mid-morning radio
show, "Morningside" (somewhat of an institution in Canada.)  While I
never heard of MacMag before the virus, I've never seen a copy
since, either.  According to the recent news reports, Richard
Brandow now writes for "Star Trek".

copyright Robert M. Slade, 1992   HISVIRB.CVP   9209031

==============
Vancouver      [email protected]         | "Is it plugged in?"
Institute for  [email protected]      | "I can't see."
Research into  [email protected]         | "Why not?"
User           [email protected]         | "The power's off
Security       Canada V7K 2G6           |  here."

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

End of VIRUS-L Digest [Volume 5 Issue 154]
******************************************



Downloaded From P-80 International Information Systems 304-744-2253

You are viewing proxied material from infinitelyremote.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.