precedence: bulk Subject: Risks Digest 22.69 RISKS-LIST: Risks-Forum Digest Tuesday 15 April 2003 Volume 22 : Issue 69 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at http://catless.ncl.ac.uk/Risks/22.69.html and by anonymous ftp at ftp.sri.com, cd risks . Contents: NSW forced to hand count poll result (Chris Maltby) Web Site for posting local election results crashes after virus attack (Monty Solomon) UK Demon ISP suffers three-fold power loss (Walter Roberson) Nevada hospital system hack traced to Russia (Monty Solomon) Automated denial-of-service attack using the U.S. Post Office (Bruce Schneier via Monty Solomon) Risks posed by online systems for college and graduate admissions (Matt Hiller) Paypal Meets the Patriot Act (Solveig Singleton via Hanah Metchis) Risks of *not* being lost (David Lesher) Nova Scotia police track suspect with GPS (M Taylor) "Quick Deposit" systems (Gervase Markham) Double-barrelled surname costs disabled mother (Nigel Metheringham) New,comprehensive Federal rules on privacy of medical information (Jack Goldberg) 75+ organizations urge FBI NCIC database accuracy (Marc Rotenberg) Re: POW Social Security numbers revealed (Crispin Cowan) Re: The reality behind these laws (Bill Gunshannon) Re: Millennium trains taken off the tracks (Bob Frankston) Re: Friendly Fire (Peter B. Ladkin, Allan Goodall) Changing Domain Registration info without verification (risks@Orwellian.Org) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 14 Apr 2003 18:24:16 +1000 From: Chris Maltby Subject: NSW forced to hand count poll result "Computer problems have forced the New South Wales electoral office to start manually counting nearly 4 million upper house ballot papers. NSW Electoral Commissioner John Wasson says it will be a mammoth task to have all the votes counted and preferences allocated before the declaration of the poll at the end of the month. It is hoped the computer glitches will be fixed later this week, but Mr Wasson says he can not afford to delay the count any longer. [...] My (slightly informed) guess is that the NSW Electoral Office acquired and made changes to the Australian Electoral Commission's election management software. The changes are to allow for the new NSW Upper House voting system and they have not been a success. This is probably due to inadequate testing as the changes to the Electoral Act were made quite some time ago. To give them some credit, it's quite a challenge to simulate an election with 4 million voters in a realistic way. My experience with testing the AEC software in the pre-outsourced mid-1990s was that the stresses imposed by a real election were always well in excess of anything that could be simulated -- and some elections were conducted with changes to the counting requirements made in the last few months before the election... I'll bet he's hoping the software starts working though. Mind you, it's hard to be all that confident in the results -- even leaving aside that the requirement for random sampling of papers in NSW upper house elections (unlike the Senate) makes exact reproduction of results problematic. The return of the writs is required by 29 Apr 2003 IIRC. ------------------------------ Date: Sun, 13 Apr 2003 01:30:50 -0400 From: Monty Solomon Subject: Web Site for posting local election results crashes after virus attack A Web site designed to tally and publish the results of a local election in Will County, Illinois was unable to perform as expected because it was deluged with phony requests. The Will County Director of Information Systems has informed the FBI. http://www.theage.com.au/articles/2003/04/07/1049567599656.html [Excerpted from SANS NewsBites April 9, 2003 Vol. 5, Num. 14 http://www.sans.org/newsletters/newsbites/vol5_14.php along with Eugene Schultz's Editor's Note: Although this news item might superficially appear to not be all that important, it is really quite significant. There is considerable apprehension concerning computerized voting systems, and incidents such as this one will only increase the level of concern. ES] ------------------------------ Date: Tue, 15 Apr 2003 00:24:30 -0500 (CDT) From: Walter Roberson Subject: UK Demon ISP suffers three-fold power loss The UK ISP Demon suffered a multiple-failure power loss that left them with a backlog to process afterwards. The public grid went down, the backup generator had a control problem, and the standby batteries ran out before replacement parts for the generator could be located. http://www.theregister.co.uk/content/6/30194.html ------------------------------ Date: Sun, 13 Apr 2003 01:30:52 -0400 From: Monty Solomon Subject: Nevada hospital system hack traced to Russia The security of a small Nevada hospital's computer system was breached by a hacker who has been traced back to Russia. The hacker routed the attack through the al-Jazeera Web site to make it look as if the attack came from the Middle East. The hacker may have accessed employees' social security numbers and bank account information. A Trojan horse program embedded in a game some employees had downloaded allowed the attackers access. The hospital's payroll system has been removed from the network and employees have been instructed never to install software or sign on to streaming Internet services. [Source: *USA Today*, 7 Apr 2003 http://www.usatoday.com/tech/webguide/internetlife/ 2003-04-07-hospital-hack_x.htm excerpted from SANS NewsBites April 9, 2003 Vol. 5, Num. 14 http://www.sans.org/newsletters/newsbites/vol5_14.php along with Eugene Schultz's Editor's Note: Employees installing software or signing on to streaming Internet services may have been a problem, but I wonder whether the hospital's failing to set requirements for and failing to enforce a baseline level of security may have had a lot to do with what happened here. ES] ------------------------------ Date: Mon, 14 Apr 2003 03:33:40 -0400 From: Monty Solomon Subject: Automated denial-of-service attack using the U.S. Post Office In December 2002, the notorious "spam king" Alan Ralsky gave an interview. Aside from his usual comments that antagonized spam-hating e-mail users, he mentioned his new home in West Bloomfield, Michigan. The interview was posted on Slashdot, and some enterprising reader found his address in some database. Egging each other on, the Slashdot readership subscribed him to thousands of catalogs, mailing lists, information requests, etc. The results were devastating: within weeks he was getting hundreds of pounds of junk mail per day and was unable to find his real mail amongst the deluge. Ironic, definitely. But more interesting is the related paper by security researchers Simon Byers, Avi Rubin and Dave Kormann, who have demonstrated how to automate this attack. [Source: Bruce Schneier's cryptogram] http://www.counterpane.com/crypto-gram-0304.html#1 ------------------------------ Date: Mon, 14 Apr 2003 11:28:52 -0700 (PDT) From: Matt Hiller Subject: Risks posed by online systems for college and graduate admissions Late last year, I sent out a number of applications to masters programs in computer science. Where possible, I submitted my applications by way of online application systems, and had my recommendation providers submit their recommendations online. (In fact, a number of programs charge an increased application fee to applicants who choose to submit their applications on paper rather than using the online system; paper seems to be deprecated.) I did not realize that in doing this I was exposing myself to a significant computer-related risk, as illustrated by my experience with the University of Virginia. I applied online to Virginia's MS program in computer science, and had my recommendations provided online. When I had yet to hear an admissions decision by early April, I called the department to find out when I could expect to know. I was informed that my application had not been evaluated because the paper file on which the admissions committee was basing its decisions seemed to be incomplete; it was missing one of the three required recommendations. I was very confused by this, as I'd been using the online application system to track and confirm the successful arrival of all of my application materials. To my knowledge, everything was in order, and had been for quite some time. The recommendation thought to be missing had been submitted in mid-November. I pointed this out, and the "missing" recommendation was promptly found and added to the paper file, but by then the damage was done. Notices were already out to accepted applicants; the best that could be done for me was placement on the waitlist. What are the risks here? Generating paper applications from online may introduce errors, errors that will not be visible to the applicant. If these paper files are treated as authoritative -- if the online application is not consulted in the case of seeming incompleteness or inconsistency -- applications may be passed over for no good reason at all. ------------------------------ Date: Mon, 14 Apr 2003 14:35:01 -0400 From: "Hanah Metchis" Subject: Paypal Meets the Patriot Act CEI C:\SPIN [Excerpted by PGN] Paypal Meets the Patriot Act, by Solveig Singleton, Senior Policy Analyst , Project on Technology and Innovation, CEI 14 Apr 2003. Paypal has been in the news lately. In this case, a Missouri prosecutor sent eBay a letter insisting that its recent acquisition, Paypal, was violating the Patriot Act by processing payments from Internet gambling operations. Internet gambling is illegal in the U.S., but about 5 million Americans use overseas sites; eBay discontinued Paypal's gambling operations last fall. This comes on top of troubles Paypal has had with the New York attorney general and authorities in other states. So what's up with Paypal? Is something sinister going on there? Far from it. Prosecutors may get paid by the public, but they don't always serve the public. [...] C:\SPIN is produced by the Competitive Enterprise Institute. ------------------------------ Date: Mon, 31 Mar 2003 10:59:17 -0500 (EST) From: David Lesher Subject: Risks of *not* being lost Seems many of the ""embedded"" media procured Thuraya brand sat/cell phones before departing. These are controlled by a ground station in Abu Dhabi, and to optimize performance, the phone locates itself with an on-board GPS and reports back that position to the ground station. Ooops, current exact location is one thing the US does NOT want the Other Guys to know. While you could in theory use triangulation or other schemes to locate any EM emitter, including a phone, making it easy for Them is hardly ever a good idea. The military has confiscated the phones. The competitor, Iridium, may well also do this too, but allegedly the GPS reporting can be turned off [how? hardware or ....software?] and in any case, that ground station is in the US. Given that Iridium is running at all only because Uncle Sam bought a govt-wide license, one could hope that someone has considered the integrity of that aspect beforehand. Note that the FBI is mandating tracking of all domestic cell phones as well, with the already past due-date being slipped back time and again. Security at our myriad providers can not help but be worse than at that single Iridium ground station. And in both TV and real life, cops and FBI agents carry cell phones. In the future will oh, Willy Sutton | John Brown | Jonathan Pollard | Paul Reubens be able to track the FBI agents tracking them? Risk: Be careful what you wish for; most swords do have two sides. ------------------------------ Date: Tue, 15 Apr 2003 18:36:04 +0100 From: M Taylor Subject: Nova Scotia police track suspect with GPS Police in Nova Scotia use the On Star system, a GPS based service included in the car to locate the car within minutes of contacting On Star operators in United States. [Source: *Globe and Mail*, 15 Apr 2003] http://www.globeandmail.com/servlet/RTGAMArticleHTMLTemplate ?tf=RT/fullstory_print.html&slug=gtbeatapr15&date=20030415 It is nice to know that occasionally technology increases risk of getting caught to criminals. M Taylor http://www.mctaylor.com/ ------------------------------ Date: Mon, 31 Mar 2003 16:13:00 +0100 From: Gervase Markham Subject: "Quick Deposit" systems I wandered into my branch of Barclays Bank in Enfield, UK, this afternoon in order to deposit a couple of cheques. For quite a while, Barclays has had a "Quick Deposit" machine - obviously old tech, green text on a character-mapped screen, no buttons; you just insert your envelope with the cheques and a deposit slip, and it prints a receipt. Recently, an additional machine of a newer design has been installed. This one looks much more like a cashpoint - number keypad, buttons on the side of the screen - and has card slots, cheque slots, and all sorts of attachments. It's far harder to use and takes much more time than the original. But its UI flaws are for another mailing list. This afternoon I walked up to it, and noticed that the screen said "NTDetect 4.00". I watched in amazement as the NT 4 boot sequence proceeded, via the "Press Space for Last Known Good menu" (unfortunately, pressing of keys only revealed that none were mapped to Space), the Blue Screen of Bootup (NT4 SP6, 128MB RAM), and the splash screen ("with Internet Explorer"), to an NT 4 desktop, complete with "Outlook Express" icon! Some startup scripts ran, which showed me that I was logged in as Administrator, and then some sort of debugging application popped up. Because it left me in a text input window in this debugging app, I was able to work out the key mappings of the built-in keypad. The number keys produced numbers, Cancel was Backspace and Enter was return. The other keypad keys seemed to have little effect. Pressing the keys on the side of the monitor seemed to trigger something, because several bits of attached machinery began whirring. Shame it's not a cashpoint, I thought. I didn't try feeding bits of paper into it. Other sundry error dialogs and DOS boxes gave me some idea of the filesystem layout, running software and so on. After a couple of minutes, the scripts must have finished, because the desktop disappeared to be replaced with "This Terminal is not in use" in Barclays livery. The RISKS are many: - Using a general-purpose OS for an embedded application - Having the input and output devices connected before the embedded app is ready to accept input - Using an Administrator account to run your app - Mapping keys to their obvious equivalents (Return is dangerous; mapping "Enter" to e.g. "G" would have been safer) - Keeping debugging applications installed on production machines, and having them automatically invoked ------------------------------ Date: 14 Apr 2003 10:54:08 +0100 From: Nigel Metheringham Subject: Double-barrelled surname costs disabled mother A disabled mother of three has been barred from receiving tax credits worth 190 pounds a week because she is among hundreds of claimants whose double-barrel surnames are not recognised by Government computers. Sue Evan-Jones has fought for more than three months to persuade the Inland Revenue that her surname has two parts after she was told the system was confused by hyphens. The fact that obvious input validation problems, and properly specifying the valid forms of input in the original design are still being got horribly wrong in 2003 fills me with despair. Source: http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2003/04/14/ncred14.xml ------------------------------ Date: Sat, 12 Apr 2003 22:59:51 -0700 From: Jack Goldberg Subject: New comprehensive Federal rules on privacy of medical information The article in the 12 Apr 2003 *San Jose Mercury News* http://www.bayarea.com/mld/mercurynews/news/5614657.htm is an easy to read summary of the new Federal rules on privacy of medical information privacy, just being put into effect. There is a very large body of literature on the general subject and on the development of the standards, and the set of rules itself is a huge body of text. This reader sees lots of good intentions, but also lots of problems, such as how medical and computer personnel -- and citizens, can understand the complex rules to determine what is allowed and what is not, how to help a client know whether exercising an option is a good idea or not, whether implementation of the rules will be an intolerable burden on health care practice, and how the integrity of a given implementation can be verified and preserved. On the last point, there seems to be no provision in the law for certification; rather it seems that it will be up to the courts to decide if the rules were violated in a particular case. This development deserves attention. ------------------------------ Date: Tue, 8 Apr 2003 12:34:55 -0400 From: Marc Rotenberg Subject: 75+ Organizations urge FBI NCIC database accuracy A broad coalition of organizations across the United States has endorsed a letter urging the reestablishment of accuracy requirements for the FBI's National Crime Information Center (NCIC), the nation's largest criminal justice database. More than 3,000 individuals from 47 states and the District of Columbia have signed an online petition to the Office of Management and Budget (OMB) also supporting the Privacy Act accuracy requirements. The petition drive will continue until the OMB acts on the request. Individuals may sign the petition online at: http://www.petitiononline.com/ncic/petition.html [Excerpted for RISKS. See RISKS-22.65 and 22.67 for items on the termination of the NCIC accuracy requirements. PGN] ------------------------------ Date: Fri, 04 Apr 2003 19:32:26 -0800 From: Crispin Cowan Subject: Re: POW Social Security numbers revealed (Hirose, RISK-22.67) It is often suggested that disclosure of SSN's is a great risk. In the current climate, where SSN's are used to *authenticate* an individual ("tell us your SSN so we know it is you") that certainly is true. However, I suggest an alternate approach to solving the problem of identity theft. SSN's are hopelessly easy to obtain; attempting to curtail the broadcast of these numbers (e.g. hoping the Iraqi state television will control the release) is futile. Instead, I suggest that the US Government *prohibit* the use of SSN's as authenticators. If all of the US organizations that currently authenticate with SSN's were forced to use something else (anything else) the state of the identity theft crisis would improve drastically. The "*anything* else" part is important to this proposal. It is tempting to propose something prescriptive, specifying how organizations should authenticate people. However, I suspect that such prescriptions would make the law founder on impracticality, as organizations find high quality authentication difficult to implement for one reason or anther. In contrast, simply forcing organizations to choose something else at least has the scattershot effect that they are unlikely to choose all the same attributes, making wholesale identity theft much more difficult. Just me proposing this idea here and getting a few folks to agree that it would be beneficial is fun & all :-) but won't actually change anything. More constructive would be if those who do agree with the idea, and have more influence in the financial regulation space than I do, would take up the idea and start spreading it around. Crispin Cowan, Chief Scientist, WireX http://wirex.com http://wirex.com/~crispin/ ------------------------------ Date: Sun, 13 Apr 2003 09:21:39 -0400 (EDT) From: Bill Gunshannon Subject: Re: The reality behind these laws (Re: Shalunov, RISKS-22.68) Assuming that the failure of one of the postulates results in the failure of the premise, we can put this one to bed. Since when is a NAT box "intended to conceal the actual origin of IP traffic"? The intended purpose of NAT and the use it is put to in every case I am aware of is to allow persons with a single IP Address to have more than one host on their network that can all access the INTERNET and I am certain that is the reason LinkSYS gives for selling the products that have NAT built in. On top of that, NAT hides nothing. You still need at least one valid routable IP address and that address is traceable to a fixed location and person responsible. If the purpose of NAT were to "conceal the actual origin of IP traffic", what then of DHCP? The RISK here is that we start chasing after demons that don't exist while missing the ones that really do. Bill Gunshannon, University of Scranton, Scranton, Pennsylvania ------------------------------ Date: Sat, 12 Apr 2003 23:31:09 -0400 From: "Bob Frankston" Subject: Re: Millennium trains taken off the tracks (Colville, RISKS-22.68) "Train signals interfering with the frequency of the underground signalling system ... turning lights red for all following trains." I can't help but wonder what kind of signaling system was being used. This seems to be an ancient analog system that uses the frequency as part of the message rather than a digital signal that has some independence from the path and would have some resilience. Turning a signal red in the absence of other information is understandable but why is the signal so fragile? I might not have commented were it not for the name "Millennium" train which would indicate a design that reflects today's understanding of signaling. Instead this seems to rely on old techniques such as the use of pristine frequencies because that's the only technique we knew a century ago. ------------------------------ Date: Mon, 14 Apr 2003 13:52:48 +0200 From: "Peter B. Ladkin" Subject: Re: Friendly Fire (RISKS-22.65 to 22.68) In RISKS-22.68, I gave some figures from [1, Figure 1.1, p1-2] suggesting that the number of fratricide incidents in recent conflicts (from WW II) lay around 1% of casualties. The figure for Desert Storm/Shield that I gave was mistaken. The figures from FM 100-14 Figure 1.1 are: World War II Korea Vietnam Desert Storm/Shield (1942-45) (1950-53) (1965-72) (1990-1991) Accidents 56% 44% 54% 75% Friendly Fire 1% 1% 1% 5% Enemy Actions 43% 55% 45% 20% Paul Marks of the *New Scientist* pointed out to me that the UK National Audit Office takes a different view. It says that "American research shows that, historically, fratricide accounts for between ten and 15 per cent of friendly casualties during operations." [2, paragraph 1.5] FM 100-14 speaks simply of "losses". The UK NAO defines fratricide as "destruction of friendly or allied forces". It is possible that these are two different concepts. But it is also possible that people aren't counting very precisely. It's a shame that one cannot tell from either of these documents what the figures actually represent. [1] U.S. Army Field Manual 100-14, Risk Management, 23 April 1998, available from http://www.irwin.army.mil/g3/tacticalsafety.html [2] National Audit Office, UK, Combat Identification, Report by the Comptroller and Auditor General, HC661 Session 2001-2002: 7 March 2002, available from http://www.nao.gov.uk/pn/01-02/0102661.htm Peter Ladkin, University of Bielefeld, Germany http://www.rvs.uni-bielefeld.de ------------------------------ Date: Mon, 14 Apr 2003 14:50:41 -0500 From: Allan Goodall Subject: Re: Friendly Fire (Van Meter, RISKS-22.68) Mr. Van Meter explains that the term "casualty" refers to persons "killed or injured". This is not correct. Casualties refer to persons killed, injured, or *missing*. "Missing" includes anyone whose whereabouts are unknown. The soldier may have been captured by the enemy, or they may have run away to -- possibly -- turn up later, or they may have been killed but their remains hadn't been identified or their remains were unidentifiable. I agree with Mr. Van Meter that confusion over the term "casualty" has caused much misinformation. In September 2002, on the 140th anniversary of the American Civil War battle of Antietam (the single bloodiest day in American history), CNN Headline News mentioned that there were 23,000 men killed in the battle. The total casualties were just less than 23,000, 3600 of whom were killed (though many of the 1700 missing men were likely dead and buried in unmarked graves, and many of the wounded would die sometime later). This error is particularly ironic as Ted Turner is a Civil War buff. Allan Goodall agoodall@hyperbear.com http://www.hyperbear.com ------------------------------ Date: Sun, 30 Mar 2003 16:41:51 -0500 From: risks@Orwellian.Org Subject: Changing Domain Registration info without verification I found a reference to a USPS Web site allowing anyone to issue a change of address via the web in a 1997 issue of RISKS. [Actually, it allowed you to print a form that you could mail in. See RISKS-19.18 to 19.20. PGN] Here's a twist I recently noticed, as conveyed in a message I just sent Network Solutions: I just tried to login to my ******** account for the first time in a long time, and it is trying to force me to accept a service agreement before I can access my account. I don't know if it was in the previous service agreement, but this provision is UNACCEPTABLE: # 4) You agree that VeriSign is authorized, but not obligated, # to use Coding Accuracy Support System (CASS) certified software # and/or the National Change of Address program (and/or such other # systems or programs as may be recognized by the United States # Postal Service or other international postal authority for # updating and/or standardizing address information) to change # any address information associated with your account (e.g., # registrant address, billing contact address, etc.), and you agree # that VeriSign may use and rely upon any such changed address # information for all purposes in connection with your account # (including the sending of invoices and other important account # information) as though such changes had been made directly by you. This USPS change-of-address can be done BY ANYBODY WITHOUT VERIFICATION at https://moversguide.usps.com/ I DO NOT authorize that my contact information be changeable by anyone via this process. (The USPS site even lets the e-mail address be changed.) If you cannot remove this clause from my agreement to service, I will transfer my registration to Register.com, which does not have this provision. ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@CSL.sri.com . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address " ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 21" for volume 21] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.69 ************************