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 13 Issue 47

Thursday 7 May 1992

Contents

o $70 million bank scam
PGN
o Insurance Computer Can't Handle Twins
Ed Ravin
o High-tech software + low-tech hardware == network failure
Jonathan Hardwick
o Secure phones easily available
Alexis Porras
o Re: F-22 crash
Robb Watson
o Re: Free TRW Credit Report
Jack Holleran
Dave Turner
o Info on RISKS (comp.risks)

$70 million bank scam

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 7 May 92 18:33:41 PDT
The FBI is probing an electronic funds transfer scam that nearly cost First
Interstate Bank of California $70 million.  A bogus request was made late last
year to transfer the funds from `one or more accounts' at FIBofC to `one or
more accounts' at other banks over the automated clearing house network.  The
request was made by computer tape, and apparently came with authorization forms
and a signature -- possibly forged -- from a bank client.  FIBofC apparently
approved the transaction without validating its legitimacy, although this is
not an uncommon practice.  The bogus transaction was detected only because it
caused an overdraft.  This was the largest fraud attempt in the almost 20 years
of the automated clearinghouse.  The network handles transfers up to $100
million, and carried about 1.7 billion transactions last year.  [Source:
American Banker, from the San Francisco Chronicle, 7 May 1992, p.C3]


Insurance Computer Can't Handle Twins

Ed Ravin <eravin@panix.com>
Tue, 5 May 92 21:27:06 EDT
LABOR PAINS, 1 YEAR LATER by Gail Collins (Excerpted from NY Newsday, 4 May 1992)

  (Good morning. This is the Empire Blue Cross computer. If you have a problem
  with your insurance claim, press one to speak to a powerless employee. Press
  two if you would like to vent your grievance to a tape recorder.

  (If you are not calling from a touch-tone phone, hang on until you get
  discouraged and give up. (Beep).)

OK, not the true tape recording. The true tape recording is less upfront. But
it does yell: "I did not hear your response!" if it feels you are slow in
pressing the appropriate button. Empire Blue Cross is the biggest health
insurer in the state, and owner of one of New York's most infamous
bureaucracies.  Every day, innocent citizens fall into its maw.

"They'll never let you speak to a supervisor," said Michael Jacoby, another
embattled customer. "They say: 'This is not a supervisor problem. ' "

I met Jacoby back in February, when he told me about his suspicion that Empire
Blue Cross did not believe in the existence of twins.

At the time. Jacohy was in his 11th month of fighting over $5,000 in doctors'
fees connected to the birth of his twin daughters, Ashley and Brooke.

"I think they're discriminating against people with multiple births," he said.
"My wife met somebody who had triplets. They were having the same problem.
Basically, when the computer looks at the claims, it only looks at the birth
date. It throws out the second child as a duplicate bill." Empire Blue Cross
totally rejected this theory. "It must be a glitch. It's definitely not related
to twins," said Michael Costa, a spokesman for the company. Meanwhile, the
insurance company's lowly clerks were confirming Jacoby's suspicions. "It
happens all the time." said one. taking time out from her duties in keeping
Jacoby away from any person with authority to solve his problem.

Jacoby got no satisfaction, but lots of correspondence. And it did seem to
buttress his theory about twins. There was a lot of documentation about
payments for Ashley's treatment. But Brooke appeared to be a computer
nonperson.

The twins were approaching their first birthday. The computer overpaid one of
the pediatricians, while stonewalling the neonatologist who treated the girls
when they were premies at North Shore University Hospital. "Our doctor was
threatening to send the bill to a collection agency," said Jacoby.  Actually.
the neonatologist and her staff were understanding.  It was the doctor's
computer that was losing patience.

Jacoby sought help from the [New York] state Department of Insurance.  "It will
take a month," a woman at the state agency told him. A month later, there was
no response from Empire Blue Cross.

"What do you do now?" Jacoby asked.
"We send a second letter."
"Then what do you do?"
"We send a third letter."
"Then what do you do?"
"After the third letter, they have to respond. It's the law."

After the third letter, the agency did indeed get a response, from Linda
Gummer, who holds the exalted title of Empire Blue Cross Executive
Correspondent.

"Our claims processing system does have difficulty in distinguishing between
one patient and another if both patients are covered by the same policy, have
the same sex, birth date and are treated by the same doctor on the same date,"
she reported.

Translation: Our computer can't do twins.

"We shall see to it that our Customer Service area is alerted once again to
this situation and that training... is reinforced."

The neonatologist got her money - just in time for the twins' first birthday.

"Now they're sending me benefits for using the North Adams Ambulance Service,"
Jacoby reported recently. "That's someplace in Massachusetts."

   [Also noted by Joe Brennan <brennan@cunixf.cc.columbia.edu>.]


high-tech software + low-tech hardware == network failure

<Jonathan_Hardwick@GS69.SP.CS.CMU.EDU>
Wed, 06 May 92 18:24:37 -0400
This network failure analysis was just posted to the facilities bboard here at
CMU SCS.  I guess it illustrates a potential risk of making a hard-copy log of
all console messages...
                                 Jonathan Hardwick, jch@cs.cmu.edu

                     ==============================

Date: Wed, 06 May 92 17:17:12 -0400
Subject: AFS tokens expiring
Organization: School of Computer Science, Carnegie Mellon

This morning from about 11:30 am to 1:00 pm users who attempted to access afs
files located on PEACH.SRV would get back an error saying that their token had
expired. This anomaly was caused by the fact that PEACH's clock was an hour
behind, so newly aquired tokens presented to its fileserver appeared to have a
start time in the future and thus were rejected. The problem was fixed by
manually resetting the time

The clock got so far behind due to the following series of events:

A process on PEACH was writing a file into AFS which was larger than the AFS
cache on that machine. This caused the in-kernel AFS cache manager to
continiously print the message :

   " PEACH vmunix: afs: cache too small: flushing active file"

Since this message was being written to a 300 baud hardcopy console at a high
interupt level, it was causing significant delays to the rest of the system.
One of the results of these delays was that clock interupts were lost, and
another was that 'ntpd' was not given a chance to run and fix the time skew. By
the time the process acausing the problem finished the time skew was too large
for ntpd to make adjustements, thus manual intervention was required.


Secure phones easily available

<ap@wnb3b2.att.com>
Thu, 7 May 92 14:15 CDT
Well, it didn't take very long for the FBI's proposed new rules to be defeated
by the marketplace... this is an excerpt from an AT&T newsbrief (quoting
Reuters).

        *** SECURE PHONE -- AT&T said it introduced a new line of secure
        telephone equipment intended for business use.  The model 4100,
        the first product in the 4000 Series, is designed to protect
        domestic and international voice and data communications.  The
        company said that in the past, a secure telephone meant
        sacrificing voice quality, and the model 4100 offers voice quality
        comparable to a non-secure phone. [Reuters, 5/6]

                Alexis Porras, a.porras@att.com


Re: F-22 crash

Robert A. Watson - SunNet Manager Engineering. <Robb.Watson@eng.sun.com>
Mon, 4 May 92 13:45:56 PDT
I saw a 6 or 7 second video clip of this crash on a TV news program early last
week.  This video was shot from around the threshold of the runway, look
towards the rear of the aircraft as it (fortunately :-)) flew away from the
camera.  During this sequence you could see massive (subjective term) up and
down movements of the all-moving horizontal tail surfaces as the pilot (or the
computer?) tried to stabilise the aircraft.  As far as I can recall the gear
was up for the duration of this sequence.

Odd that the software should be seen as a possible cause of the crash, when
it would seem (to me) that this is exactly the sort of situation where it
should have helped, assisting the pilot in managing a heavy aircraft flying
close to the ground by compensating for extreme pilot input...  humm, more or
less what the General said, but with a different emphasis!

I though most aircraft could dump/vent excess fuel, you don't have to be at low
altitude to do this, do you?
                                                  Robb


Re: Free TRW Credit Report (Culnan, RISKS-13.46)

Jack Holleran <Holleran@DOCKMASTER.NCSC.MIL>
Wed, 6 May 92 09:09 EDT
Wow!  What an advertising coup.  If you weren't on their database before the
request, you certainly are now.

And you can provide them with your SSN (without a privacy statement!), and your
spouses' name, and a copy of a current bill ... from anyone will get you your
record.

And if the business that sent the bill isn't a TRW customer, I would project
that they will receive some advertising literature on how TRW can help their
business.

Some other risks --- someone could set up a "favored" credit rating by using a
false address on a short street.  e.g.-My street has 7 houses {1-6, 8}; I could
invent 7 (in the range) or 11 (a typo for my # 1); I could send a false bill to
myself; and I could use a SSN.  This could allow me to establish a potentially
false credit information base for fraudulent use.


Re: Free TRW credit Report

<ptsfa!dmturne@pacbell.com>
Mon, 4 May 92 12:56:30 PDT
The RISK of blindly mailing private information to an address posted in a
computer bulletin board should be obvious.

Dave Turner (510) 823-2001  {att,bellcore,sun,ames,decwrl}!pacbell!dmturne

Please report problems with the web pages to the maintainer

Top