Handbook of Infosec Terms 2.0/Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso/text/virusl/vl04_011.txt

Internet Message Format | 1996-09-04 | 27KB

From:       Kenneth R. van Wyk (The Moderator) <[e-mail]>
Errors-To: [e-mail]
To:       [e-mail]
Path:      cert.sei.cmu.edu!krvw
Subject:   VIRUS-L Digest V4 #11
Reply-To:  [e-mail]
--------
VIRUS-L Digest   Wednesday, 16 Jan 1991    Volume 4 : Issue 11

Today's Topics:

Worm / Virus on BITnet??? (IBM VM/CMS)
4096 virus (PC)
re: Stone-2 (PC)
GAME2 (VM/CMS)
re: Reoccurence of Stoned on formatted drives (PC)
re: Johsi / Stoned2 (PC)
Re: (No) Viruses in Irak's EXOCET?
STONED and NON-bootable floppies (PC)
RETRACTION: Disk Scanning (PC)
Jerusalem Virus (PC)
Re: Stoned in KC, Mo. (PC)
hardware (PC)
Auto-scanning Virus Vaccine? (PC)
Re: possible macintosh virus (Mac)
GAME2 MODULE in CERNVM (IBM VM/CMS)
Re: SCAN program for IBM's (PC)
TSR Attackers? (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
VIRUS-L at LEHIIBM1 for you 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:    Tue, 15 Jan 91 15:13:29 -0500
From:    Till Koerner <[e-mail]>
Subject: Worm / Virus on BITnet??? (IBM VM/CMS)

Hello,

I just found an item called GAME2 MODULE in my readerlist. My
readerlist display says that it comes from LISTSERV AT DEARN but when
peeking into the file the status line says it is from ERDAL AT TRMETU.
I sent a mail to that address but haven't got any response yet. I
haven't had contact to that userid before and so I am a bit suspicious
it could be some kind of virus or net worm.

Could anybody give me a hint, what to do now? Please mail to my userid
as I am not a subscriber of valert-l.

Any help is appreciated.

There just came a message from erdal at trmetu, it says that game2 module
is a trojan!!!!

+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+
Till Koerner,  <ht050ko at dacth11.bitnet>,  Tel. [phone]
Inst. f. Industrieofenbau u. Waermetechnik im Huettenwesen
RWTH Aachen  (Aachen University of Technology)
Kopernikusstrasse 16             +------------------------------------+
D-W5100 Aachen                   !      Always be on the bright       !
Federal Republic of Germany      !      side of life!                 !
                                 !                       Monty Python !
<Standard Disclaimer>            +------------------------------------+

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

Date:    Tue, 15 Jan 91 09:19:12 -0500
From:    Cory Sanders <[e-mail]>
Subject: 4096 virus (PC)

  Could someone provide me with info about the 4096 virus?
  How an infection occurs and possible cures?
  Please e-mail directly to me.   Thanks in advance.

  Cory Sanders, Department of Geography, U. of Guelph

   [e-mail]

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

Date:    15 Jan 91 09:55:26 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: re: Stone-2 (PC)

[e-mail]:
> Someone mentioned that Stone-2 has not reached the States yet.  Maybe
> not.  But I have had an infection that has been "dual."  Running Scan,
> I would be told that I had an infection of Stone and Stone II.

Early on, a signature for the "Stoned 2" (or "Stoned II") was
circulated that in fact occurred in the normal Stoned virus.  Because
of this, at least one scanner would report both Stoned and Stoned II
when scanning a disk with the usual Stoned on it.  I suspect that's
what you saw...  DC

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

Date:    Tue, 15 Jan 91 14:22:47 +0000
From:    Alan Thew <[e-mail]>
Subject: GAME2 (VM/CMS)

This appears to be a REXX exec 'converted' to a module using EXECMOD, thus
the REXX source can get through mail only gateways, i.e. to the UK.

I have 28th November 1990 as the date with the originator being from
the Turkish site TRMETU.BITNET

Alan Thew  : University of Liverpool Computer Laboratory
Bitnet/Earn: [e-mail] or QQ11%UK.AC.LIVERPOOL @ UKACRL
    UUCP   :           ....!mcsun!ukc!liv!qq11
   Voice   :  [phone]        FAX : [phone]
Internet   : [e-mail] or QQ11%LIVERPOOL.AC.UK @ NSFNET-RELAY.AC.UK

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

Date:    15 Jan 91 09:59:18 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: re: Reoccurence of Stoned on formatted drives (PC)

Hm, interesting.  The Stoned infects the master boot record
(synonymous with "partition table") on the first physical hard drive
(BIOS drive id "80" hex).  In your case, that's the master boot record
on the 80Mb hard disk.  The master boot record (and therefore the
partition table) are stored at the very bottom of the disk, lower than
any of the partitions (E F G and H).

Did you test whether or not, after booting from a clean floppy and
then switching to E: and back to A:, the virus was actually *active*
(infecting new diskettes), as well as being in memory?  My guess would
be that, although the virus code was in memory (in the buffer used by
DOS to hold the partition table of the hard drive), the virus was not
active (that is, not hooked into INT 13, and never actually getting
control passed to it).  That is, after step <4> I would suggest that,
although the virus was in memory, it wasn't actually -doing- anything.
(Memory scanning in general has the problem that it can't tell an
active virus from a "ghost" of the virus that just happens to be
sitting in a buffer somewhere, never running).  The only way the usual
Stoned virus can get control is if it's present on the boot record or
the disk or diskette that the system is booted from.

DC

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

Date:    15 Jan 91 10:08:02 -0500
From:    "David.M.Chess" <[e-mail]>
Subject: re: Johsi / Stoned2 (PC)

Jeffrey <[e-mail]>:
> The virus was apparently picked up from someone who
> accessed a bulletin board and executed some code they had down-loaded.

That's not really very likely (unless what was downloaded was a
disk-image that the person then booted from); the Stoned and Joshi
viruses are both boot-sector infectors only.  You can only become
infected by either of them by booting from an infected diskette (or,
in theory, by running a program that "injects" them onto your disk; no
such program has ever been reported, though).  You might (f you
haven't already) scan all diskettes in the neighborhood that the
machine might have accidentally been booted from (even "non-system"
diskettes can be infected); you might find the source more accurately
that way (or you might not; source-tracing succeeds depressingly
rarely).  DC

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

Date:    Tue, 15 Jan 91 09:06:43 -0600
From:    [e-mail]
Subject: Re: (No) Viruses in Irak's EXOCET?

Klaus Brunnstein <[e-mail]> writes:

 > French press (La Liberation) and media reported (Jan.10) in  some
    (stuff deleted)
 > reports about "viruses in Hussein's rockets".  According to  dpa,
 > (unnamed) French computer scientists said:
 >
 >    - manufacturers of war material  usually  implant,  "for  mere
 >      commercial reasons",  viruses in exported war electronics to
 >      provoke,  after  some time,  faults and  "profitable  repair
 >      work";

This is not very likely.  Most modern defen(s|c)e contracts provide
reliability targets which the contractor must warrant, or include
maintenance to meet the goals.

 >    - though  Irakian weapon computers are  "hermetically  cut-off
 >      from the outside world", computer viruses could be implanted
 >      e.g. via "weather data";

This is entirely concievable, but fairly unlikely.  The coordination
required to pull this off would be immense.  The more people that
handle a secret, the less likely it is to remain one...

 >    - moreover,  the built-in computers contain programs which may
 >      be triggered remotely;  the control system of (French-built)
 >      EXOCET rockets could be switched-off from French ships;  the
 >      only  problem  would be the mass of weapon computers  to  be
 >      switched-off simultaneously.

Same comment as previous paragraph.

 > As usual in events related to malicious code,  truth is mixed  up
 > with misunderstandings, errors and impossibilities:
 >
 >    - the implementation of weapon software makes self-reproducing
 >      programs (=viruses) impossible;  moreover,   it is very  im-
 >      probable, that such systems may be (re-)programmed remotely;
 >      French "experts" with such arguments are non-trustable;

Not entirely correct.  Weapons software is often incredibly complex.
It also often loadable.  I assume that you are assuming that it is
ROM'd which is not neccessarily correct in newer, more complex sys-
tems.  The code is usually handled by fairly physically secure means,
but anything is possible.  NEVER say never....

 >
 >    - on  the other hand,  other aspects of "malicious  code"  may
 >      well  be present in weapon computers;  at least in the  test >
 phase,  rockets  can  be  destroyed by  triggering  a  self-
 >      destruction system remotely;  following the well-established
 >      principle "never change a running program", such "backdoors"
 >      (the  proper  name for this type of  malicious  code)  could
 >      survive the test version;

The self-destruct systems are usually seperate, independent systems,
developed to be reliable, and, hence, simple.  They are not present in
production weapons.  Maintenance modes/codes might fall into this
category, but almost always require a hardware action to enable them
(switch closure, special connector, etc.) for this very reason.

 >    - moreover,  French  system analysis might well have  foreseen
 >      scenarios  in  which to defend against  French-made  rockets
 >      (e.g. EXOCETS); French warships might remotely influence the
 >      EXOCET  control  systems if this remains  unchanged  by  the
 >      (Irakian) users of such technology;  with equivalent probab-
 >      ility,  other  Western weapon control systems could  contain
 >      similar self-protection mechanisms  (e.g.  US' Hawk missiles
 >      having been captured in Kuweit) ;

All within the realm of possibility, but logistically unlikely.  More
likely is that the French know well the weaknesses of the sensor sys-
tems on their weapons, and can effectively exploit them. Ditto the
British, US, and others.

 >    - finally,  it is well-published (even in non-military period-
 >      icals)  that  and how electronic countermeasures  (ECM)  may
 >      mislead weapon electronics.

See comments from previous paragraph

 > Some interesting questions following from such "possibilities":
 >
 >    - May Irak detect, influence or adapt such weapon software? As
 >      software  technology  is not well-enough developed  in  Irak
 >      (and most part of the Arab world),  they probably must  rely
 >      on  foreign experts (as they evidently do in  other  Hi-Tech
 >      areas).

Generally true, but the Ira(q|k)is are not fools.  While their overall
technological base is not great, they do have some extremely competent
people.  Given the potential for treachery of this sort, I would ex-
pect that they would have considered the possibility and taken the
steps that their resources and needs would support.

 >    - If French EXOCET rockets are remotely controllable:  why did
 >      the  French  not warn their "friends"  who  suffered  severe
 >      losses through their weaponry (e.g.  UK in Falkland  crisis,
 >      or US in the Iran crisis,  see accident of USS  STARK)?  Did
 >      they  at least now warn and properly equip their  allies  in
 >      the Arabian desert?

I we assume (dangerous) that the premise is correct, the French could
not predict the USS Stark incident (which incidentally was fired byIra(q|k) NOT
 Iran, but did happen during the war period, and whose ac-
cident status is questioned almost as often as the USS America inci-
dent is).   Further there is a risk/return issue.  To save British
ships, the (postulated) secret would have have to spread further, AND
would eliminate the weapon as an option should Britain and France go
head to head.  While this is unlikely, anything is possible.  Conser-
vative military thinkers always strive to preserve options. Paraphras-
ing Sir Winston Churchill, countries have interests, not friends.

 > For  "RISK  experienced"  experts,  it  is  not  surprising  that

Some good stuff deleted, see the original message if you haven't al-
ready...

 > Postscriptum:  computer "viruses" may nevertheless play a role in
 > "Operation Desert Shield".  There are (yet unconfirmed) news that
 > several  thousands  PCs (5000?) have been  infected  by  ordinary
 > "computer viruses".  This would not be a surprising experience as
 > the  soldiers  had to "vaste" ample waiting for  Jan.15;  in  the
 > absence of other possibilities for spending free  time,  computer
 > games (usually a source of "virus" infections) may have played  a
 > major  psychological  role,  maybe  with  some  impact  on  their
 > "ordinary functional behaviour".

Hadn't heard about this one, where did you?

Oz (Rich Osman, WB0HUQ)            INTERNET: [e-mail]
[phone] (w); [phone] (h, merciless machine)
[phone] (just the fax)

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

Date:    Tue, 15 Jan 91 10:48:25 -0600
From:    [e-mail]
Subject: STONED and NON-bootable floppies (PC)

I got this message from one of our LAN administrators today.  I suspect
that the Guru's have already heard this, but, I've been watching this list
for a long time and it was a REAL surprise to me.

===========================================================================
            forwarded message follows
===========================================================================

I learned something new about the STONED virus today.  One of our users' PCs
was infected by the STONED virus by attempting to boot from a NON-bootable
diskette that was infected!

All MS/DOS diskettes (bootable and non-bootable) have a sector reserved
for the boot code (the boot sector).  I was under the impression that the
DOS boot code had to be present (bootable) in order for the STONED virus
to move itself to the hard disk.  This was an incorrect assumption.

This is what happened this morning:

1)    Non-Bootable disk left in A: by mistake
2)    System was rebooted
3)    "Your PC has been Stoned"
4)    "Non-System disk ... Remove and strike any key"
5)    SCAN shows virus in boot sector of non-bootable floppy disk
6)    SCAN shows virus in boot sector of C:

*** It might be a good idea to start SCANing non-bootable floppy disks !!!
===========================================================================
===========================================================================

After I got this message I dropped him a note asking whether he knew
scan worked on non-bootable floppies.  He indicated that it does.

Oz (Rich Osman)                     INTERNET: [e-mail]
[phone] (w); [phone] (h, merciless machine)
[phone] (just the fax)

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

Date:    Tue, 15 Jan 91 12:31:29 +0000
From:    Douglas Barlow <[e-mail]>
Subject: RETRACTION: Disk Scanning (PC)

    YES, I MADE A MISTAKE!  I put my foot in my mouth before checking my
doumentation!  Sorry about the misinformation.
    Here is the best answer I received on the PC disk scanning problem.

Doug Barlow

> ------- Forwarded message
> Date: Fri, 11 Jan 91 08:23:01 -0500
>
> Doug,
> I am sure that by now you have gotten replies up the wazoo about having
> a floppy automatically checked on insertion. I do know of a software
> package that will check a disk on any access (COPY DIR etc.) called VI-
> SPY by RG Software.
> VI-SPY checks a disk on the first access if it is not removed then it does
> not check again. The way that it checks to see if a disk has been
> inserted/removed is something called the DRIVE CHANGE LINE. This is
> supported by both 3.5 and 5.25 inch disk drives and is dependent on the
> drive's manufacturer. Most computers since the AT support this. I know
> that all current IBM and Dell computers support this along with the
> external disk drives from PROCOM technologies.
> We use VI-SPY here at the U of PA and it has been very effective in
> stopping disk based nasties.
> Hope that this helps!
> Caroline Ferguson
> Computing Resource Center Manager
> University of Pennsylvania
>
> Standard disclaimer applies
>
> The opinions expressed are not my own but those of my evil twin who is
> not affiliated with the University.
>
> ------- End of Forwarded message

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

Date:    Wed, 16 Jan 91 02:53:08 +0000
From:    [e-mail] (Neal Miller)
Subject: Jerusalem Virus (PC)

    We're having a minor epidemic of a Jerusalem strain at
Clarkson U., and even though the CLEAN##.EXE program tries to remove
it, it keeps popping up!  Any ideas/info on the JERU strains?
E-mail/post...  I'll get it...

Much Thanks

- ------------------------------------------------------------------------------
 Neal Miller          |  "Why not go mad?"     |  [e-mail]
 Clarkson University  |        - Ford Prefect  |  [e-mail]
- ------------------------------------------------------------------------------

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

Date:    15 Jan 91 16:14:22 +0000
From:    [e-mail] (Herb Presley, Emergency Planning Officer)
Subject: Re: Stoned in KC, Mo. (PC)

[e-mail] (Arthur Gutowski) writes:
> Just got off the phone with a friend of mine in Kansas City, MO.  He
> has been infected with the Stoned virus (don't know which variant).

My 8088 based PC became infected with the [Stoned] virus on Christmas Day.  At
least that is when its "gotcha" message first appeared.

> He apparently contracted the infection from a borrowed copy of
> Ontrack's Disk Manager.  The diskette was obtained from the Computer
> Resale Center in Kansas City.  He has not booted up with any other
> diskettes in quite some time, so he strongly suspects the Disk Manager
> diskette.  Fortunately for him, he had already cleaned off the drive
> and was preparing to low-level format the hard drive anyway.  He will
> start with a cold boot from a clean diskette before proceeding (don't
> want to spread the beast any further).

I used the DOS FDISK and FORMAT programs and unfortunately that didn't solve
the problem either.  When I ran a McAfee's SCAN program, it detected the virus
still on the system.  However, the only problem that was manifesting itself was
the inability to load RAMDRIVE on bootup.  The error message -

    RAMDRIVE:Insufficient memory

kept appearing.

In the end I never did find out where the infection came from.  Several
floppies were also infected, but that could have been as a result of
interaction with the hard drive when copying files, etc.

Finally, I took the following steps and that seemed to get rid of it:

1. I opened the boot sector/partition table of the hard disk with NORTON
   UTILITIES and overwrote the entire disk area with a value of "0" manually.

2. I used the NORTON INTEGRATOR WIPEDISK program to wipe the hard disk three
   times with a value of "0".

3. I then re-partitioned the hard disk and reformatted with DOS FORMAT /v/s.

4. I have created a SAFE BOOT disk by copying my original system files (DOS
   3.3) onto a floppy and write protected it.  I placed an AUTOEXEC.BAT file on
   it that restricts the path to SET PATH=A:\  I use it when I am running a
   floppy for the first time or of questionable origin by rebooting the
   computer with SAFE BOOT and running the McAfee SCAN program from drive "B:"
   (I have two floppy drives).

   If I find a floppy with a virus (particularly [Stoned]) on it, I open it's
   boot sector with write protected NORTON UTILITIES disks, overwrite it with a
   value of "0", copy each individual file over to a scanned and clean floppy,
   and format the infected floppy.  Then I scan the second floppy to ensure
   that the virus didn't transfer in the file copying and perform DISKCOPY to
   restore the original floppy.

   So far this method seems to have kept my hard drive virus free.

5. This is a poor man's way of virus protection.  Very cumbersome, but I do not
   want to have to go through an emergency backup of the hard disk again!

Hope this helps.  Good luck to your friend.

______________________________________________________________________________
DISCLAIMER: Any views expressed here are mine alone and
        do not represent those of this organization
    email : [e-mail]  (...UUCP!alberta!aunro!apss!....)
     mail : 10320 - 146 St., Edmonton, Alberta, Canada  T5N 3A2

    phone : [phone]

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

Date:    16 Jan 91 03:24:53 +0000
From:    [e-mail] (Fred Waller)
Subject: hardware

Fridirik Skulasson ([e-mail]) writes in response to an inquiry:
> >Is there any way to prevent a virus from infecting a hard disk when
> >you cold boot with an infected diskette in drive a: ?
>
> Not without additional hardware I'm afraid.  Any program run from

That's true, but the "additional hardware" can be as simple as a very
small spst switch wired across wire No. 6 of the HD controller ribbon
cable.  It will effectively stop ANY and ALL disk writes without
interfering with any other computer processes. Not even a DOS error
message will be generated.

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

Date:    16 Jan 91 03:16:46 +0000
From:    [e-mail] (Fred Waller)
Subject: Auto-scanning Virus Vaccine? (PC)

> Only one problem with that idea: How can the machine tell when a disk
> is inserted?  There isn't any type of sensor in IBM floppy drives like
> in the Mac.

But yes they do have it: it's called the changeline. I have a little
continuous formatting program which senses when a diskette has been
inserted and automatically starts the format operation without any
need for keypresses.

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

Date:    16 Jan 91 08:18:07 +0000
From:    [e-mail] (Puneet Pasrich/;093091;eeugrad)
Subject: Re: possible macintosh virus (Mac)

jade![e-mail] (Brenda Barabash) writes:
>We are also experiencing problems with floppy disks appearing to be
>locked when they aren't.  This is happening on both new disks and old
>disks.  It's definitely got to be a virus.  If anyone knows which one
>please let us know.

No! It does not "definitely have to be a virus".  Just as with all
hardware the floppy drive mechanism can be mal-aligned.  So, if the
part of the drive that checks to see if the disk is locked is not in
the correct position is may 'sense' the disk is locked, uncorrectly.
When I was working for a VAR, a number of Macs came in w/ similar
problems (ie. All floppies are locked).  Just letting the rest of the
world know...
==============================================================================
== Puneet Pasrich ============ Internet:  [e-mail] ==============
== Karate Kid ================ Macs rule, and that's all there is to it ======
== In Capitalism, man exploits man. In Communism, it's the other way around. =

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

Date:    Wed, 16 Jan 91 15:33:33 +0700
From:    Geraldo Xexeo <[e-mail]>
Subject: GAME2 MODULE in CERNVM (IBM VM/CMS)

I am sad to inform that GAME2 MODULE was received at CERNVM (altough,
not by myself). It came from the NETNWS-L list and the origin was
ERDAL@TRMETU.

As stated by the user consultancy office:
 "The code appears to be an assembler program that has an imbedded
REXX exec coded in the format that EXECLOAD would put it in memory.
The module NUCEXT loads itself and then EXECs the internal exec. If
there is no NAMES file it dies (our recipient was suspicius and tried
it on an ID with no user files)"

I hope this information can help anyone trying to trace the worm.

                        Geraldo Xexeo

Geraldo Xexeo - GXEXEO@CERNVM, [e-mail]
Editor of HIT@UFRJ, The Highly Imaginative Tech. - Science Fiction List
"No institution would  ever be proprietary of my words!"

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

Date:    Wed, 16 Jan 91 16:04:03 +0000
From:    [e-mail] (Magnus Olsson)
Subject: Re: SCAN program for IBM's (PC)

[e-mail] (Woody Baker @ Eagle Signal) writes:
>Fastback senses when a disk is inserted.  There is a flag that is used
>to determine if a disk has been removed or inserted.  A program such
>as this can certainly query that flag.  No problem

Yes, but to do this, it has to keep the drive in question selected all
the time, drive motor running. Would you really want to have drive A:
going all the time your computer was up? And how could the program
check if a disk was inserted in another drive (only one drive can be
active at a time)?

Magnus Olsson                   | \e+      /_
Dept. of Theoretical Physics    |  \  Z   / q
University of Lund, Sweden      |   >----<
Internet: [e-mail]     |  /      \===== g
Bitnet: THEPMO@SELDC52          | /e-      \q

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

Date:    Wed, 16 Jan 91 11:57:39 -0700
From:    [e-mail] (Richard W Travsky)
Subject: TSR Attackers? (PC)

Not that I'm trying to give anyone ideas, but: Does there exist a
virus or whatever that attacks TSRs?  For example, If I have device
drivers or memory managers resident, the virus either interferes with
them or attaches itself to them or <insert scenario>.  Just curious,
haven't a report of one or suspecting one.

Richard Travsky                        Bitnet:   RTRAVSKY @ UWYO
Division of Information Technology     Internet: RTRAVSKY @ CORRAL.UWYO.EDU
University of Wyoming                  (307) 766 - 3663 / 3668

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

End of VIRUS-L Digest [Volume 4 Issue 11]
*****************************************