Hacker Chronicles 2/HACKER2.BIN/VIRUSL3/VIRUSL3.106

Text File | 1994-07-17 | 23.6 KB | 566 lines

VIRUS-L Digest   Tuesday,  5 Jun 1990    Volume 3 : Issue 106

Today's Topics:

clearing ps/2 pw, faces on screen (PC)
removing Stoned from harddisks (PC)
New files to MIBSRV... (PC)
123nhalf virus (PC)
Listserv with virus information. (PC)
Re: mainframe viruses
Intentional Virus(es?)
Call for definition for common computer beasts (ie viruses...)
Mac Happy Face turns into a Devil... (Mac)
Documented mainframe viral attacks
SCAN Version 63 (PC)
Re: File tranfser of software--A way to curb commercial infections?
Re: How to reset CMOS configuration that prevents booting? (PC)

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.  Please sign submissions with your real name.  Send
contributions to [e-mail] (that's equivalent to
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, documentation, 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:    01 Jun 90 16:02:55 +0000
From:    "The.Gar" <[e-mail]>
Subject: clearing ps/2 pw, faces on screen (PC)

Dimitri -
    I can't help you with your problem, other than to tell you that
IBM's recommended procedure for a forgotten password USED TO BE to
remove the battery from the motherboard (I had an original PS/2 70.)
THIS HAS CHANGED, however, and they now have a "trick" that let's you
quickly clear the password.  What one is now able to do, is unplug the
speaker connector from the bus adapter card, and plug it in in the
opposite direction.  PRESTO! Your password is cleared!
    I REALLY doubt this would work on non-IBM hardware, though.


Joest@DD0RUD81 -
    What you describe sounds very much like a practical joke program
that I have seen a dozen times around campus.  It is called FACES, and
is quite small  (about 3K I believe.)  What I would ask you to check is
whether your program does in fact set the KEYBOARD=GR?  If it does not
I would suggest that someone modified the FACES program to make it smaller
and has simply renamed it and copied it over your other program.

Later
THE GAR

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

Date:    Fri, 01 Jun 90 16:56:04 -0500
From:    martin zejma <[e-mail]>
Subject: removing Stoned from harddisks (PC)

During the last two months there were several asks how to remove
the STONED-virus from harddisks. The solution is quite easy :

1) Boot from a clean write-protected floppy disk

2) Use a disk-monitoring program
      ( the good old DEBUG would make it also, but better are programs
      like the Norton Utilities )

3) Read sector 7 from the boot track
      ( Exactly : Head 0 , Track 0 , Sector 7 )
   At the begin of this sector you should find the system description of your
   operating system ( f.e. DOS 3.3, PCDOS 4.00, etc) and the volume label of
   your harddisk.There is also the partition table viewable, but most people
   can't read it ;-) .

4) Write this sector over the infected boot sector of the harddisk
   ( that's Head 0 , Track 0, Sector 0  , just to make it failsafe).

5) Remove the floppy disk, and make a cold-boot from the harddisk.
   Now everything should work fine.

If you don't have backups from your harddisk, backup the infected disk,
the bootsector is not backed up like files, and the virus doesn't
infect files , just the boot sector.

All that stuff should work fine, because until now I heard nothing
about other variants of this virus floating around.  On disks which
you can't clean transfering the OS using the SYS A: Command this
operation works also, but the ORIGINAL sector is stored at Head 1 ,
Track 0, Sector 3 .

Hope this solves the nightmares with this virus.

( All errors included without extra-fee )

                                        sincerly yours,

                                        Martin Zejma

+--------------------------------------------------------------------+
|                                                                    |
|  Martin Zejma                           8326442 @ AWIWUW11.BITNET  |
|                                                                    |
| Wirtschaftsuniversitaet Wien --- Univ.of Economics Vienna /Austria |
+--------------------------------------------------------------------+

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

Date:    Sun, 03 Jun 90 16:46:06 -0500
From:    James Ford <[e-mail]>
Subject: New files to MIBSRV... (PC)

The following files have been added to MIBSRV.MIB.ENG.UA.EDU
(130.160.20.80) in the directory pub/ibm-antivirus:

scanv63.zip  - Latest SCAN. Scan files for several vir(insert_your_ending_here)
cleanp63.zip - McAfee's Clean-Up program.
netscn63.zip - McAfee's SCAN for networks
vshld63.zip  - McAfee's VSHIELD
shez55.zip   - Shez Version 55.

The files were downloaded from Homebase on June 3, 1990 at 2:00pm.
The files have not been re-compressed in any way.  Older version will
remain on MIBSRV until June 6, 1990 for possible pending requests at
BITFTP@PUCC.

For those who cannot FTP, send a one line mail message (help) to
BITFTP@PUCC for information on how to FTP via BITNET.

- ----------
Whether you think you can or whether you think you can't, you're right.
- ----------
James Ford -  [e-mail], [e-mail]
              THE University of Alabama (in Tuscaloosa, Alabama  USA)

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

Date:    Mon, 04 Jun 90 12:33:00 -0100
From:    Marco Colombini <[e-mail]>
Subject: 123nhalf virus (PC)

Hi people,
    it seems that a friend of mine has been infected by the 123nhalf
virus reported by IA96000 in september '89.
    Could you please give me more informations on it (where to find the
123scan.exe code, how clean up things, and so on...) together with some
news (if exist) on other lotus 1-2-3 viruses.
    Any information on the appropriate virus killer(s) is welcome too.
Many thanks.

Marco Colombini
IDPO at IGECUNIV

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

Date:    Mon, 04 Jun 90 09:17:30
From:    Eduardo Rodriguez S. <[e-mail]>
Subject: Listserv with virus information. (PC)

  Hi. In Virus-l v3-i103, there are two request for virus information:

>From:    [e-mail] ( STUG)
>Subject: Virus Information

>From:    <[e-mail]>
>Subject: additional request tag to 1813 virus sighting (PC)

  In our local listserv (LISTSERV@UCHCECVM), in the SOFT_L FILELIST
has been placed the Dr. Brunnstein Catalog (with Dr. Brunnstein
authorization). This catalog can be retrieved with this command:

  GET MSDOSVIR A89 SOFT-L
  GET MSDOSVIR 290 SOFT-L

  both can be send via MAIL, MESSAGE or simple FILE. To obtain a
list of all the files available in this FILELIST you can send:

  INDEX SOFT-L

  the description is in spanish. If anyone have some problem, can
contact me.

- -----------
She may be late.
- -----------
[Eduardo Rodriguez S]
[Universidad de Chile]
- -----------

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

Date:    Mon, 04 Jun 90 10:10:30 -0400
From:    Arthur Gutowski <[e-mail]>
Subject: Re: mainframe viruses

[e-mail] (Craig Harmer) writes:

>...wasn't there even something on Bitnet (i'm not sure)?  i suspect
>that MVS and VM have *more* holes than Unix, for the simple reason that
>there are less people around looking for holes to exploit.  far fewer
>people have access to the source, or machines that run it.  they cost
>more than $1 million each, after all.
>...{stuff about VM's frailties deleted}...

I believe you're referring to the infamous XMAS (or CHRISTMA) EXEC that
could in fact crash VM by filling up it's spool space.  But, as with any
other system, alert staff here were able to nip it in the bud *before*
VM came crashing down (similarly, we have been able to avoid XMAS clones
by making the operations staff aware of them as they appear).  It is my
intuition that any system that has a file transfer mechanism has to have
dasd to put files onto, and thus runs the risk of crashing when that dasd
area runs dry (I don't know, other systems may handle it better, e.g., by
rejecting files when spool space is dry; in fact, I think VM can be set up
in this way).  As for stepping all the way to class 'A' once you get beyond
'G', I really don't know; VM isn't my specialty.  But it seems to me that
there would be *some* measures against this built into the system.

I disagree with your premise about Unix vs. VM or MVS security, though.
MVS has been in development far longer than Unix has been alive (even
back beyond the days of MVT), and there are many shops that use MVS and VM
(IBM ain't making it on PS/2s alone).  Thus, these operating systems have
had much more opportunity for people to poke around in them.  Not to say
they are invincible, mind you, but I think they're less susceptible than
Unix.

As for the source being readily available, that was a matter of choice, and
one that should, and has, been stood by.  I wrote a shareware program with
a friend, and we decided not to distribute source because we felt it would
make it harder for someone to break our code that way.  For the same reasons,
I'm inclined to believe that building back doors and spreading viruses in
Unix is easier with the source readily available.  The technical knowledge
isn't as necessary as general programming knowledge if the source is there.

Again, it is just a matter of choice.  Unix was intended to be a programmer's
system; as such it does a great job.  With all systems, there is a tradeoff
between functionality and security, the trick is to find the right balance.

  /==="   Arthur J. Gutowski, System Programmer
 : o o :  MVS & Antiviral Group / WSU University Computing Center
 : --- :  Bitnet: AGUTOWS@WAYNEST1  Internet: [e-mail]
  \===/                                       [e-mail]
 Have a day.
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 "Please all and you will please none."   -Aesop

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

Date:    04 Jun 90 19:05:57 +0000
From:    [e-mail] (Richard W West)
Subject: Intentional Virus(es?)

I have had just the strangest thought about all of the commercial
products out there on the market that protect from viruses, for
example Symantec's Anti-Virus for the Macintosh -- a product that
"learns."  Did the thought ever occur to anyone that the possibility
is there for companies to make and distribute their own new viruses
just to keep purchases of their product up?  I mean the potential
there is great, and all of the benefits go to the companies.  Each
time a virus comes out, the companies soon follow the viruses with
their "vaccine".  Take my example of SAM.  Sure, the program allows
for definitions of new viruses, but you need to buy an update to the
program if you want to have the capability of removing the infection
from programs.  As with most other programs (the good ones), you have
to purchase a brand new version (an update) to combat the new virus.
This leaves a greater potential for companies to profit from the
creation of new viruses.

Hey, sorry.. it was just a thought.

- -Rich West
Siemens Corporate Research and Development
Princeton, New Jersey
Internet: [e-mail]

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

Date:    Mon, 04 Jun 90 19:59:50 +0200
From:    [e-mail] (Morton Swimmer)
Subject: Call for definition for common computer beasts (ie viruses...)

          I have been increasingly perplexed by the fact that there seems
to be little consensus on what the definition of the term
"Computer Virus" actually includes. This goes for other computer
"beasts" such as "Trojan Horses" and "Worms". I would be interrested
in hearing what other people think a virus is.

          Here are my own definitions:

Computer Virus: a non-autonomous program that has the ability to
copy itself onto a target.

Trojan Horse: an autonomous program that has a function unknown
(and unwanted) by the user.

Worm: a program or set of programs that have the ability to
propagate throughout a network of computers.

          Please note that both worm and virus definitions do not
include the possibility of a payload. This may or may not be a
weak point. Also note that the definitions of virus and trojan
differ greatly from how Cohen defines them. This is intentional
as I feel that Cohen's definition of virus is too broad (it can
include a normal program such as DISKCOPY!). I'm not happy with
my definition of worm myself. Also, (and this should be obvious)
none of my definitions are very formal.

NB:
          I feel it would be more economical if any contributors
would send their pet definitions directly to me. I will then
summerize and post them. (After the viruses vs. virii discussion
I caused, I'd rather not be the cause of any more of Ken's
aggravation. :-)) Here are my addresses (addressii?):

          [e-mail]
or        [e-mail]

(Yes, I know they are long, but what can I do about it?)

Cheers, Morton
Virus Test Center

 .morton swimmer..virus-test-center..university of hamburg....odenwaldstr. 9.
 ...2000.hamburg.20..frg........eunet: [e-mail].
 ...God grant me the solemnity to accept the things I cannot change/Courage to.
 .change the things I can/And the wisdom to tell the difference.Sinead O'Conner

disclaimer: does anybody read these things anyway?

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

Date:    Mon, 04 Jun 90 16:27:31 -0400
From:    [e-mail] (Pete)
Subject: Mac Happy Face turns into a Devil... (Mac)

I just experimented with a public Mac which wasn't
working too well. When I watched it boot up, the usual
smiling Macintosh icon turned into a devil with horns,
fangs and a long tail. I checked it with Disinfectant 1.8
and found nothing.

My questions are:

1) Is this a virus or is it some legitimate program I've
never experienced before?
2) If it is a legitimate program, shouldn't programmers start
considering the side effects of putting neat garnishes on their
software? I know several people who have been complaining
about hidden about boxes. Looks like all the fun is going to be
gone soon.

- -Peter

Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
EMail:[e-mail]    Office: 607-255-9202 or 255-1008
Home: 116 Oak Ave, Ithaca, NY 14850  Phone: [phone]

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

Date:    04 Jun 90 18:51:08 +0000
From:    [e-mail] (Gordon Spoelhof)
Subject: Documented mainframe viral attacks

As an occasional browser of this newsgroup, I have noticed that discussions
surrounding mainframe viruses tend to be theoretcial in nature.

Questions:

1.  How many mainframe viral attacks are documented?
2.  How many incidents are reported/not reported?
3.  In general, how are the viruses introduced?
4.  What corrective measures had to be taken?
5.  What preventative measures are taken?
6.  What is the level of risk?

Discussion anyone?

Disclaimer:        "Neither my wife nor my employer endorse opinion according
                   to Gordi..."

Internet:          [e-mail]
Telephone:         [phone]
Secretary:         716-724-1365 (Sharon)
FAX:               716-781-5799
US Mail:           Gordon Spoelhof
                   CIS/ITM 2-9-KO
                   Eastman Kodak Co
                   343 State Street
                   Rochester, NY 14650-0724

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

Date:    Mon, 04 Jun 90 11:08:21 -0700
From:    [e-mail]
Subject: SCAN Version 63 (PC)

This is a forward from John McAfee:
==========================================================================

          Creating bogus VIRUSCAN programs is becoming an increasingly popular
pastime for underground hackers.  In the past two months 5 such programs have
appeared.  Three of them appear to be innocuous, but the bogus version 65
discovered in Israel was extremely destructive, and the version 72 reported
in the U.S. last week causes system crashes and file losses.
          I believe these problems are here to stay, and we can count on future
bogus appearances.  For this reason, it is important that all SCAN users
obtain their updates from reliable sources.  A reliable source, by my
definition, is one that obtains their copy directly from HomeBase.  If you
are unsure of your source, then do not use the program.  In any case, each
new release should be Validated before using.  When validating a new release
of SCAN, use your known good copy of Validate.  Do not replace your known
copy with the copy distributed with each release.  Validate has not changed
since it was first released and no changes are planned for the forseeable
future.  So once you obtain a good copy, hang on to it.  If you do not
currently have a copy, then download it from a known reliable source.  As
a final precaution, verify the validate numbers by checking the on-line
validation data base on HomeBase.  The numbers within the data base are
secure and cannot be tampered with.  These same numbers are published on
the larger public bulletin boards and some of the national networks.
          I have also been asked by a number of users to publish the validate
numbers on VIRUS-L.  Version 63 was released this past weekend and here are
the numbers:

SCAN.EXE    -  Size:46,535   Date:6-2-90  Check1:D30F   Check2:1F82
CLEAN.EXE   -  Size:58,835   Date:6-2-90  Check1:429C   Check2:062E
VSHIELD.EXE -  Size:40,987   Date:6-2-90  Check1:CCE7   Check2:01FB
NETSCAN.EXE -  Size:46,535   Date:6-2-90  Check1:2B07   Check2:0E87

John McAfee
408 988 3832 -voice
408 970 9727 -fax
408 988 4004 -BBS

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

Date:    04 Jun 90 18:15:33 +0000
From:    ctycal![e-mail] (Terry Ingoldsby)
Subject: Re: File tranfser of software--A way to curb commercial infections?

In article <[e-mail]>, [e-mail]
m (Gary Heston) writes:
> ctycal![e-mail] (Terry Ingoldsby) writes:
>
> > I've always felt that networks are less likely to transmit viruses
> > than floppy disks because it is more likely that the culprit will be
> > caught.  I grant that games can be played with the signatures, etc.,
> > but chances are that some sort of log files are kept by the system
> > administrators about what came in, and when.  Although difficult, in a
> > crisis there is at least some hope that the dissemination path used by
> > the virus can be discovered.  Although not foolproof, this should act
> > as somewhat of a deterrent to virus writers.
>
...
> Networks can propagate a virus thru several avenues, particularly if
> the netadmin is inexperienced and hasn't quite got file protections
> for network executables set correctly. If user Fred logs in to a

I freely concede this.  Networks are no safer than floppies.  You miss
the point.

> Now, we have a logfile that shows Fred, Barney, and 30 other users
> ran this particular piece of software, at various times during the
> day, and probably more than once. What points to the infection
> source?
Not *that* logfile.  I'm uninterested in who runs it on the (now)
infected system.  What I am trying to establish is the pattern of
transmission for the virus.  For instance, it is of interest to
know the general propogation path through the network.  This can
lead you back towards the site where the virus initially started.
Once you get to that site, then you can try to find the user who
owns the *source* code to the virus.  Since we do backups at
unpredictable times on our system, it would be tricky (but not
impossible) for a virus writer to hide the source code.
>
> This can be controlled somewhat by the netadmin getting the
> setup correct; however, this is a somewhat optomistic hope in
> view of the complexity of network software and the limited
> training new admins get (I'm trying to learn Novell right
> now; the company decided nobody needs to go to seminars for
> anything). It's difficult to track down a security hole when
> the boss is asking hourly "Why isn't the network up yet?".

Then your boss deserves what he gets.

> is necessary. Training admins to check EVERY piece of software
> prior to installation, no matter how many layers of plastic it
> was (or wasn't) wrapped in, along with safe setups. Teaching
> management that this really is necessary, not just a waste
> of resources, and you really do need that many tapes for
> backups. Etc.

Agreed.

>
> > Floppy disks are almost untraceable since they carry *no* copy history,
> > *no* history of what machines they visited and almost no means of
> > identifying the offender.
>
> True. However, the person holding it can explain why they were
> running the software without checking it....

Thereby punishing the victim rather than the perpetrator.  This is
somewhat like telling a rape victim that it was their fault for
walking down an alley at night.  It is true that they might be
considered foolish for doing so, but they are not the party that
should be held responsible for the offense.

My point is not that viruses are less able to infect systems via
networks than via floppy disks, but rather that the significant
possibility of getting caught (say 1 chance in 5 ??)  should
dissuade people who otherwise have no chance of getting caught.

Virus prevention has got to focus more on identifying the
culprits, and less on treating the symptoms if this is ever
going to occur.  Networks (perhaps better networks than what we
have today) are our best chance of finding violators.

Sorry to be so long-winded, but I feel that this is a philosophical
point that is often missed in comp.virus discussions.

- --
  Terry Ingoldsby                ctycal![e-mail]
  Land Information Services                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb


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

Date:    Tue, 05 Jun 90 19:27:05 -0500
From:    [e-mail]
Subject: Re: How to reset CMOS configuration that prevents booting? (PC)

[e-mail] writes:
> I've managed to do something truly bizarre to my computer. :)
>
> I have a '386 motherboard with lots of Chips and Technologies stuff on
> it. At boot time, I have the option to run setup/extended setup. While
> trying to do something, I managed to alter the settings in 'extended
> setup' part (the bits in various 'C&T CMOS registers') in such a
> manner that the machine will no longer boot; when I reset it, it goes
> beep-beep-beep pause beep-beep-beep...
> ...
> Thanks,
> Dimitri Vulis

          The three beeps seem to indicate a memory error.  You may have
          done some unintentional mods to your memory configuration on the
          motherboard.  Any PC will not boot if it either finds an error in
          the first 16KB of RAM or cannot locate it as this is usually where
          it tries to load the startup BIOS.

          Regards Robert,
          (University of QLD)

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

End of VIRUS-L Digest [Volume 3 Issue 106]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253