Subject: RISKS DIGEST 13.47 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 7 May 1992 Volume 13 : Issue 47 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: $70 million bank scam (PGN) Insurance Computer Can't Handle Twins (Ed Ravin) High-tech software + low-tech hardware == network failure (Jonathan Hardwick) Secure phones easily available (Alexis Porras) Re: F-22 crash (Robb Watson) Re: Free TRW Credit Report (Jack Holleran, Dave Turner) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Thu, 7 May 92 18:33:41 PDT From: "Peter G. Neumann" Subject: $70 million bank scam 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] ------------------------------ Date: Tue, 5 May 92 21:27:06 EDT From: eravin@panix.com (Ed Ravin) Subject: Insurance Computer Can't Handle Twins 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 .] ------------------------------ Date: Wed, 06 May 92 18:24:37 -0400 From: Jonathan_Hardwick@GS69.SP.CS.CMU.EDU Subject: high-tech software + low-tech hardware == network failure 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. ------------------------------ Date: Thu, 7 May 92 14:15 CDT From: ap@wnb3b2.att.com Subject: Secure phones easily available 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 ------------------------------ Date: Mon, 4 May 92 13:45:56 PDT From: Robb.Watson@eng.sun.com (Robert A. Watson - SunNet Manager Engineering.) Subject: Re: F-22 crash 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 ------------------------------ Date: Wed, 6 May 92 09:09 EDT From: Jack Holleran Subject: Re: Free TRW Credit Report (Culnan, RISKS-13.46) 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. ------------------------------ Date: Mon, 4 May 92 12:56:30 PDT From: ptsfa!dmturne@pacbell.com Subject: Re: Free TRW credit Report 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 ------------------------------ End of RISKS-FORUM Digest 13.47 ************************