The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 5 Issue 72

Saturday, 12 December 1987

Contents

o Risks to the Rodent Public in the Use of Computers
Peter Ladkin
o Yet another virus program announcement fyi
Martin Minow
o IBM invaded by a Christmas virus
Dave Curry
o Virus Protection Strategies
Joe Dellinger
o New chain letter running around internet/usenet
Rich Kulawiec
o On-line bank credit cards
John R. Levine
o Central Locking
Martyn Thomas
o Product Liability
Martyn Thomas
o Wishing the deceased a merry christmas (automatically)
Bill Lee
o Air Traffic Control Computer Replacement Schedule
Dan Ball
o Re: United Airlines O'Hare Sabotage?
Dave Mills
o Info on RISKS (comp.risks)

`Risks to the Rodent Public in the Use of Computers'

Peter Ladkin <ladkin@kestrel.ARPA>
Fri, 11 Dec 87 11:18:20 PDT
  Stray Rodent Halts Nasdaq Computers, by Kenneth N. Gilpin
  NYT Thursday, Dec 10, 1987, p.33

  An adventurous squirrel touched off a power failure in Trumbull, Conn.,
  that shut down the National Association of Securities Dealers'
  automatic quotation service for 82 minutes yesterday.
     A Nasdaq official estimated that the power failure might have kept
  slightly more than 20 million shares from being traded. [......]
  The breakdown was also felt at stock exchanges around the country on
  which options on over-the-counter issues are traded
     Power in the Trumbull area, where Nasdaq's main computer center is
  situated, was restored by the United Illuminating Company shortly after
  the squirrel lost its life - and Nasdaq its power - at 10:43 A.M.
     But a power surge that accompanied the utility's resumption of
  service disabled Nasdaq's mainframe computers and seriously damaged the
  electrical system at the complex, making it impossible to use backup
  generators.
     Nasdaq officials then switched to a backup computer system in
  Rockville, Md. By 12:05 P.M., service had been partly restored. 
  Full service was available by 2:30 [the Nasdaq official] said . [......]

Well, I guess a martyr to one segment of the mammal population is a scapegoat
to another. The disruption could have been more serious if more people hadn't
squirrelled away their savings after black monday.
                                                         peter ladkin


Yet another virus program announcement fyi

Martin Minow ML3-5/U26 223-9922 <minow%thundr.DEC@decwrl.dec.com>
11 Dec 87 11:55
From CRTNET, number 115.  From T3B%PSUVM.BITNET.

Subject:      Christmas Virus Warning

If you are at a CMS site and receive a program called CHRISTMA EXEC, please
(a) warn your postmaster and (b) discard the exec (or keep a copy for the
postmaster to look at, but DO NOT RUN IT).  This exec paints a Christmas
tree on your screen and then sends itself to everyone named in either your
NAMES or NETLOG files.  The result is potentially serious stress on Bitnet
and on your local spool system, and possibly a few system crashes here and
there as the number of reader files soars and exceeds the maximum.  The
Christmas tree isn't all that pretty, and the joke is pretty mean.

A word to the wise.  Your postmaster will thank you. Michael Sperberg-McQueen


IBM invaded by a Christmas virus

Dave Curry <davy@intrepid.ecn.purdue.edu>
Sat, 12 Dec 87 10:02:24 EST
  (From the Lafayette (Indiana) Journal & Courier, December 12, 1987.  Quoted
  without permission.)

  IBM Woes -- Computerized grinch jams the mail

     BINGHAMTON, N.Y.- A computerized Grinch invaded IBM's electronic
  mail Friday.
     An illegal software-style so-called Christmas card sent through
  IBM's electronic mail jammed desk-top computer terminals, spokesman
  Joseph E. Dahm said.
     The so-called virus program forced plant officials to turn off
  internal links between computer terminals and mainframe systems to
  purge the message, Dahm said.
     IBM sources say the link was off from 45 minutes to 90 minutes
  depending on the location.
     The program is known as a virus because it enters computer programs
  and replicates itself automatically.
     Curious employees who read the message titles "Christmas" in the
  morning electronic mail discovered an illustration of a Christmas tree
  with "Holiday Greetings" superimposed on it.  A caption advised "Don't
  browse it, it's more fun to run it."
     "That was the hook," an IBM source said.  "A lot of people thought
  they could take a peek and then kill the message, but once opened, it
  was too late."
     The program automatically entered a security log listing contacts
  made from the individual computer terminal, duplicated and mailed
  itself to new victims.
     Like a Pandora's Box, once opened, the program rarely accepted
  commands to stop, sources said.  Operators who turned off their
  terminals to stop the Christmas message lost electronic mail or
  unfinished reports not filed in the computer.

This article seems to have a lot of things in it that the reporter didn't
understand.  I assume that the "terminals" in question are really PC's
connected to the mainframes; for one thing.  Plus, I presume the "Don't
browse it" refers to the VM/CMS "BROWSE" command used for looking through
files, and not just to the regular English word.

Does anyone have any more info from a source which understands all the
big words?
                                  --Dave Curry, Purdue University


Virus Protection Strategies

Joe Dellinger <joe@hanauma.STANFORD.EDU>
Wed, 9 Dec 87 02:22:36 pst
    From recent postings it sounds like Personal Computer viruses
are getting to be a problem. In 1982 when I wrote my Virus, nobody I knew
thought such things could even exist. When I explained what I had made to
fellow hacker types, the usual reaction was "What a wonderful idea! But an
innocuous virus is boring. I want to create an EVIL one...". Given this
reaction, and the increasing knowledge of how such things work, I would
expect the number of viruses to increase.

    What strategies can we use to protect ourselves? Best, of course,
is to make it impossible. Make the DOS area on the disk read only. Put DOS
in rom on the machine. Write protect as many disks in your collection as
feasible. Make sure write protection is done in hardware.

    Whenever a new disk is used for the first time, compare the DOS
on that disk with the DOS in memory. If they don't match, issue a warning.
Make a program that performs such a check a standard utility.

    The best solution, I think, is to simply make writing a Virus
difficult. Don't leave any convenient holes in DOS where a Virus can hide
out. Have many places in the boot process where parity checks on pieces of
DOS are done. Have unused bytes scattered here and there in DOS that are
different in every copy of DOS sold. Have code in ROM that performs
some sort of verification before booting a disk. Have several different
versions of this ROM in use, sensitive to different things, so that you
can't assume a virus that works on your machine will also work on all
machines. Use self-modifying code in the boot process. Have several different
ways that DOS can be layed out on the disk, and pick a random one at
initialization time.

While none of these schemes would make a Virus impossible, any of them
would make creating one very tedious. I think the only reason we aren't
experiencing a plague of viruses already is that it is a fair amount of
work to create one. It is also a lot more work to create a "careful" virus
than it is to create a "careless" one. Most of the viruses I have heard
of are not purposefully evil, they just don't bother to check that they
aren't accidentally damaging something.


Rich Kulawiec <rsk@s.cc.purdue.edu>
Thu, 10 Dec 87 21:37:57 EST
        postmaster@decwrl.dec.com
Subject: New chain letter running around internet/usenet

Yes, there's another chain letter running around out there.  We've just wiped
out a few hundred local copies, and it looks like it got here after bouncing
around a DECnet site somewhere.  The oldest letter in the chain is from
'DECWSE::ROST "Randi Rost"' but of course I've no idea if that's the original
point of origin.  There's no telling how much mail spooler space or xmit time
is being chewed up by this @($#*&!@ letter, of course; but I figured I'll tell
y'all...well, those of you that didn't already know the good news.
                                                                       Rich
   [Enormous sequential history of the chain letter deleted...  PGN]


On-line bank credit cards

John R. Levine <johnl@ima.ISC.COM>
Tue, 8 Dec 87 22:06:30 EST
In a recent job, I was involved in processing Master Card and Visa credit
card charges, and it seems to me that their automated processing system is
enormously vulnerable to fraud.  Let me explain how it works.

We were taking a lot of credit card orders over the phone, and had all of
the order information in a data base.  It seemed like a bad idea to print
out zillions of charge slips, so I investigated submitting the charges
on-line.  It turned out to be unbelievably easy.

Readers are doubtless familiar with the verification terminals found next
to cash registers, into which a clerk puts the card, keys in the amount of
the sale, it calls in and comes back with an approval code or denial
message.  It turns out that the terminals can do considerably more than
that.  They can post charges to a customer's bill, making it unnecessary
to physically send in a slip, and can also post refunds.  Many stores use
an "auth/post" transaction which authorizes and posts a charge in a single
operation while you wait.  When the terminal runs the transaction, it
calls a local concentrator which sends the request to the Giant Bank
Computer in Omaha, which in turns sends the request to the cardholder's
bank, with the bank sending back the response.  The authorization code the
merchant writes on the check comes from the cardholder's bank.  I've
watched while requests for European cards ran, and they take only a few
more seconds than usual.  It's pretty impressive.  Funds from transactions
posted by 7:00 PM each day are supposed to be available in the merchant's
bank account the next morning.  The Giant Bank Computer sends a printed
log of posting transactions which usually arrives about a week after the
actual transaction.  Each call that posts anything produces a separate log
page.  The bank, by the way, thinks this is all great since they are
spared all of the physical work of processing the charges, and charged us
about half what they would have had we sent in slips.

The protocol between the authorization terminal and the concentrator is
unencrypted 300 baud ASCII.  It took me about a day to write a program for
a PC that implemented the protocol and that we used to process our
thousands of credit card sales via auth/post transactions.  The terminal
calls in, and after the concentrator answers it sends a record consisting of
the merchant's account number, the customer's account number, the amount
to charge, and a code indicating what kind of transaction to perform.  The
response is the actual string displayed on the transaction terminal, e.g.
"AUTHORIZED: 123456".  The messages in each direction are protected by a
simple one-byte checksum, with messages with bad checksums being ignored.
There is no log-on or log-off protocol; the terminal calls up, sends and
recieves as many transactions as it wants, and then hangs up.

The first problem is that there is no protection against duplicated
transactions when a message is thrown away due to a bad checksum.  We had
a few, most of which we fortunately noticed and fixed before the customer
got the bill, and would probably have had many more had the concentrator
not been physically very close on a clean phone line.  More importantly,
this scheme seems awfully easy to spoof.  Merchant numbers are usually
printed next to the merchant's name on a charge slip.  Card numbers are
all over the place.  For example, imagine that I just bought something at
a store that runs a slip, then does an auth/post on its terminal and then
just files the slip.  (I know lots of stores that do that.)  I then run
home and call up from my PC, sending a refund transaction for the same
amount and merchant number.  The merchant probably would never notice the
refund in the blizzard of paper that comes from the Giant Bank Computer,
or if it did, would probably assume that it was a voided sale or
accidental overcharge.  Another less subtle risk is that were someone to
sabotage the Giant Bank Computer, as far as I can tell all bank card
charges would stop.  I'm sure they have good physical security and
backups, but even a day or two of downtime could cause major trouble for a
lot of merchants.

We probably have yet another case here of banks using security through
obscurity (which is why I'm certainly not going to go into any more detail
about the protocols.)  I've heard that they are very touchy about people
discussing the checksum algorithm used in credit card numbers, even though
the algorithm is printed in the ANSI standard for financial transaction
cards.  The online transaction scheme is, to put it mildly, a much greater
exposure.

American Express was much less willing to automate the procedure -- they
were happy to do on-line authorizations through the same simulated
transaction terminal.  We still had to send in physical charge slips.  I
thought they were just being obnoxious, but upon reflection, I can see
that they may have had their reasons.

John Levine, johnl@ima.isc.com or ima!johnl or Levine@YALE.something


Central Locking

Martyn Thomas <mcvax!praxis!mct@uunet.UU.NET>
Tue, 8 Dec 87 12:09:10 BST
A colleague's BMW 525e developed a disturbing fault.  After we had returned
to it on several occasions to find all the doors unlocked, we set a trap.
After parking it, we locked the doors, went 20 yards away and waited.  Five
minutes later, we heard the central 'locking' system unlock all the doors.

The fault was traced to a loose wire.

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:   ...!uunet!mcvax!ukc!praxis!mct 


Product Liability

Martyn Thomas <mcvax!praxis!mct@uunet.UU.NET>
Tue, 8 Dec 87 12:25:07 BST
An EEC Directive, mandatory throughout the Community from Summer 1988,
imposes strict (ie no-fault) liability on manufacturers of products which
cause personal injury or damage to personal property as a result of a
manufacturing defect.  For imported goods, the original importer into the
EEC is liable.

Liability is strict: the purpose of the Directive is to ensure that injured
people can recover damages without having to prove negligence (usually
impossible and always expensive).

The UK has enacted the Directive as Part 1 of the Comsumer Protection Act 1987
(which comes into force on March 1st 1988).  The UK has included a defence:
"that the state of scientific and technical knowledge at the relevant time was
not such that a producer of products of the same description as the product in
question might be expected to have discovered the defect if it had existed in
his products while they were under his control".  This defence is not allowed
in France, the Netherlands, or Luxembourg.  West Germany allows the defence
except for Pharmaceutical products.

It is expected that the Act will greatly increase the adoption of software
Quality Assurance (to conform to ISO standard ISO 9001) and the use of
mathematically rigorous specification and development methods (VDM, Z etc).

Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK.
Tel:    +44-225-444700.   Email:   ...!uunet!mcvax!ukc!praxis!mct 


Wishing the deceased a merry christmas (automatically)

Bill Lee <munnari!phadfa.adfa.oz.au!lee@uunet.UU.NET>
Text in << <> was lifted without permission from the
"Sydney Morning Herald" Friday Dec. 11 1987

     << The Advance Bank sent a Christmas letter to a Manly
    account holder.  It read: "Dear Valued Customer, On
    behalf of your local branch team, may I wish you a
    very safe and happy Christmas 1987, and a prosperous
    1988."  The man died earlier this year - and the
    bank recognised this by addressing the letter to
    Mr Arthur .... Decd. <>

An example (presumably) of blindly asking a computer to print out one
christmas letter for each human customer (as against company or corporate
entity) without first checking to see if the person is still thought to be
alive (by the absence of contary notice, such as a death certificate sent to
the bank to allow access to the deceased's account).  The Bank did receive
notice, otherwise they would not have marked it to be sent to a person "Decd."

Mail: Bill Lee, Dept. Electrical & Electronic Engineering, University College,
UNSW, ADFA, Canberra. 2600.  Phone:  (062) 68 8193,  Telex:  ADFADM AA62030,
ACSNET: "bill@eeadfa.ee.adfa.oz"


Air Traffic Control Computer Replacement Schedule

Dan Ball <ball@mitre.arpa>
Thu, 10 Dec 87 10:09:26 EST
In RISKS 5.67 (01 Dec 87), Rodney Hoffman indicated that news accounts
concerning the recent failure of the 9020 computer at the Los Angeles Center
made no mention of a date for installation of a replacement computer system.

For your information, the replacement system has been installed at Los 
Angeles and is scheduled to be fully operational by March 01, 1988.
The replacement program has been proceeding ahead of schedule, with 
replacement computers operational at about one-third of the centers.
All sites are scheduled to be operational by June of 1988.

The 9020 computers are being replaced with dual redundant IBM 3083
processors which will rehost the existing applications software.
Reports from the field indicate that the reliability of the new
systems is significantly better than that of the 9020 as a result of
the new hardware and improvements in the operating system.

However, the new computers are running 18-year-old software, and the
display channel computer will not be replaced until the Advanced
Automation System is introduced in the next decade, so it may still
be necessary occasionally to shift to the less capable backup system,
hopefully much less frequently.


Re: United Airlines O'Hare Sabotage?

<Mills@UDEL.EDU>
Thu, 10 Dec 87 10:26:29 EST
There was a famous incident at an AT&T CO in Manhattan many years ago when a
fire destroyed much of the office. The rebuilding program was so intricate and
extensive that it was written up in a technical journal. Recently a similar
thing happened in Brooklyn, but I don't have the details. I was told at a NAS
meeting yesterday that AT&T has a videotape documenting the rebuilding effort.
Apparently, most of the effort goes into re-coppering and re-framing the
loops. I would guess that extensive use of highly multiplexed glass might make
such rebuilding much easier. Maybe the increase in robustness in the face of
massive destruction of CO facilities will balance the vulerability to backhoe
attack.
                                    Dave

Please report problems with the web pages to the maintainer