precedence: bulk Subject: RISKS DIGEST 19.48 RISKS-LIST: Risks-Forum Digest Friday 5 December 1997 Volume 19 : Issue 48 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. ***** Contents: Risks in a public database (David Lesher) Risks of bundling in Microsoft Internet Explorer (Bear Giles) Point-of-sale data diddling in Quebec (Mich Kabay) Lufthansa combats mobile phone Risk (Jim Griffith) GSM hack -- operator flunks the challenge (Ross Anderson) Bug threatens Net software: land.c (Stevan Milunovic) Kuji Walks (David Kennedy) Date-based random numbers and Y2K (Alan Hamilton) Re: Y2K and canned-goods expiration dates (Mark Brader) Ontario removes privacy controls on education (David Collier-Brown) Re: SET security (Jerome Svigals) nando.net shut down by custodian (Jitendra Padhye) Damage from powerline surges (David R Brooks) Web cache risks (Bjorn Borud) Perils of grammar checkers redux (Azeem Azhar) URL for paper on European encryption policy (Mike Ellims) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 4 Dec 1997 17:43:24 -0500 (EST) From: David Lesher Subject: Risks in a public database At least a hundred criminal defense lawyers across Maryland are legally soliciting new clients by notifying people wanted by the police, sometimes tipping off suspects before officers have had a chance to arrest them. In Maryland, arrest warrants are public records when issued. The lawyers pay LETS Co. in Edgewater MD to search those records, generating mailing lists, and sending letters to the defendants. In some cases, suspects have been tipped off before they could be arrested. [Source: Philip P. Pan and Katherine Shaver, Lawyers' Solicitations Tipping Off Suspects, *The Washington Post*, 4 Dec 1997, Page A01, PGN Abstracting] [http://www.washingtonpost.com/wp-srv/WPlate/1997-12/04/178l-120497-idx.html] The RISK? Public data being used by the public? [DL] ------------------------------ Date: Fri, 5 Dec 1997 14:10:13 -0700 (MST) From: Bear Giles Subject: Risks of bundling in Microsoft Internet Explorer The online press has been reporting an unexpected risk of bundled MS Internet Explorer. Some programs automatically install MS IE 3.0 during installation -- and a few don't provide a way for the user to prevent this installation. If MS IE 4.0 is already installed, the resulting mess leaves neither 3.0 nor 4.0 in a runnable state. I've also heard rumors that installing (at least one version of) MS IE will remove competing browsers from the registry. This is easier to fix than mismatched MSIE DLLs, but few people would understand why installing one program (e.g., Quicken was listed) would result in their preferred browser becoming unusable or deregistered. Finally, such bundling disregards the fact that some of us actually prefer the earlier releases of the browers. My copy of Netscape (2.02) may not have all of the latest bells & whistles, but on the other hand it doesn't have all of the latest bells & whistles. If it meets my needs, why would I want to load a larger, slower program which includes "features" I'll never use, such as "push channels." Bear Giles bear@coyotesong.com ------------------------------ Date: Fri, 5 Dec 1997 09:03:51 -0500 From: "Mich Kabay [NCSA]" Subject: Point-of-sale data diddling in Quebec Some Quebec restaurateurs have been using a U.S.-made computer program (a "zapper") that skimmed off up to 30% of the receipts, thereby evading Revenue Canada and provincial government tax payments (millions of dollars estimated for the latter). [Source: Timothy Appleby, Rhe'al Se'guin and Geoffrey Rowan, Restaurants' tax-evasion scam pursued: System found in Quebec may be used elsewhere, Revenue Canada says, *The Globe and Mail*, 05 Dec 1997, p. A:1. PGN Abstracting] A related story in the *Montreal Gazette* added that *Le Point* journalists succeeded in getting technical support on the zapper programs from POS equipment vendors; there seemed to be nothing unusual about the programs, judging from the matter-of-fact way the vendors responded to requests. M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) (will be *International* Computer Security Association as of 1 Jan 1998) ------------------------------ Date: Wed, 3 Dec 1997 15:39:13 -0800 (PST) From: Jim Griffith Subject: Lufthansa combats mobile phone Risk A Reuters article today describes a new effort by Lufthansa to identify dangerous in-flight use of mobile telephones. They are testing a hand-held passive sensing device which detects mobile phone signals and helps the operator locate the offender. The article goes on to mention that beyond the safety factor, using mobile phones in flight is illegal in Germany (along with use of CD players or laptops with CD-ROM drives or printers). What actually drew my attention to the article was its poorly-chosen title -- "Lufthansa to snoop on airborne phone users". The device is clearly neither able nor intended to "snoop". Considering the idiocy of using a device that can directly cause the death of you and several hundred people around you, it occurs to me that the detector can double as an in-flight IQ test... Jim ------------------------------ Date: Wed, 26 Nov 1997 17:36:36 +0000 From: Ross Anderson Subject: GSM hack -- operator flunks the challenge On Friday 13th September 1996, I read in comp.risks that: > MobilCom, a subsidiary of German TeleKom (since 100 years monopolist on > telephone communication in Germany, with its monopoly ending in 1998) > publicly offers 100,000 DM to a telephone hacker who is able to communicate > at the expense of the (national) number 0171-3289966. The related chipcard > is said to be safely stored in lawyer`s office. In an attempt to paint this > dubious offer somewhat "politically correct", the successful hacker will > have to donate his earnings to a social institution of his(her) choice. This caught our attention - Cambridge University, being a registered charity, surely qualifies as a `social institution', and 100,000 DM would buy us a state-of-the-art triple-wavelength laser microprobe workstation for chipcard breaking. So we had a look at GSM and found a way to hack it. We worked out what equipment we'd need and where we could borrow it, assembled the team, checked that the attack would work in principle, and then started trying to find the right person in Deutsche Telekom to speak to. We needed to know the IMSI (international mobile subscriber identification) and get written confirmation of the challenge; otherwise the attack might have been interpreted as an offence under Britain's Wireless Telegraphy Act. After some chasing around, unanswered e-mails and so on, we went to a mobile phone fraud conference in June and made contacts there which suggested some names, leading to further unanswered correspondence, and finally a faxed reply. Here is a translation of the original German, online at : Dear Dr Anderson Many thanks for your fax of the 6th October 1997. Please excuse the late reply to your fax. The matter that you mentioned did not originate from T-Mobil but from one of our service providers, the firm Mobilcom in Schleswig. We understand that the offer has since also been withdrawn by them. Yours etc. How does our attack work? Well, when a GSM phone is turned on, its identity (the IMSI) is relayed to the authentication centre of the company that issued it, and this centre sends back to the base station a set of five `triples'. Each triple consists of a random challenge, a response that the handset must return to authenticate itself, and a content key for encrypting subsequent traffic between the mobile and the base station. The base station then relays the random challenge to the handset. The SIMcard which personalises the handset holds a secret issued by the authentication centre, and it computes both the response and the content key from the random challenge using this secret. The vulnerability we planned to exploit is that, although there is provision in the standard for encrypting the traffic between the base station and the authentication centre, in practice operators leave the transmissions in clear. This is supposedly `for simplicity' (but see below). To break GSM, we transmit the target IMSI from a handset and intercept the five triples as they come back on the microwave link to the base station. Now we can give the correct response to the authentication challenge, and encrypt the traffic with the correct key. We can do this online with a smartcard emulator hooked up through a PC to a microwave protocol analyser; in a less sophisticated implementation, you could load the handset offline with the responses and content keys corresponding to challenges 2 through 5 which will be used on the next four occasions that you call. The necessary microwave test set costs about $20,000 to buy, but could be home built: it's more than an undergraduate project but much less than a PhD, and any 23cm radio ham should be able to put one together. We would have borrowed this, and reckoned on at most 3 person months for SIM-handset protocol implementation, system integration, debugging and operational testing. Given such an apparatus, you can charge calls to essentially any GSM phone whose IMSI you know. IMSIs can be harvested by eavesdropping, both passive and active; `IMSI-catchers' are commercially available. The fix for our attack is to turn on traffic encryption between the GSM base stations. But that will not be politically acceptable, since the spooks listen to GSM traffic by monitoring the microwave links between base stations: these links contain not only clear keys but also clear telephony traffic. Such monitoring was reported in the UK press last year, and now the necessary equipment is advertised openly on the net. See for example . The RISK for intelligence agencies? Making systems like GSM give government access to keys can have horrendous side effects (especially where this access is via channels that aren't properly documented and evaluated). These side effects can get you into serious conflict with powerful commercial interests. The RISKS for phone companies? Firstly, letting spook agencies bully you into a bad security design with the assurance that it will only compromise your customers' privacy, has as a likely side-effect the compromise of your signalling and thus your revenue. (David Wagner, Bruce Schneier and John Kelsey made this point for the US cellular system: see .) Secondly, most phone companies have no crypto expertise. Their security managers are largely ex-policemen or accountants, and so are unable to evaluate the security claims made by equipment manufacturers and intelligence agency representatives. Thirdly, by restricting parts of the security specification to people who signed a non-disclosure agreement, the GSM consortium deprived itself of the benefit of open scrutiny by the research community. It is this scrutiny that has led to protocols such as SSL and SET having their holes found and fixed. However, the global deployment of GSM ensured that many people would be cleared to know the design, most of which can be got anyway by observing traffic or by reverse engineering unprotected equipment. So public scrutiny was inevitable - but only after billions of dollars' worth of equipment had been deployed and the system could not changed. So the GSM security-by-obscurity strategy gave them the worst of all possible worlds. The consumer electronics industry should take note. The specific RISK for Deutsche Telekom: responding to cynicism about GSM security claims by putting up a reckless challenge and thus motivating an attack. The RISK for GSM users: that crooks running a call-sell operation will book a very expensive phone call on your account. An established modus operandi is to set up a conference call which their clients and counterparties join in succession. As the bill isn't forwarded to the service provider until the phone goes on-hook, you can end up with a five-figure bill for a call that lasted several days and involved hundreds of overseas telephone numbers. Some GSM operators (such as Vodafone) limit this exposure by terminating all calls after six hours; but your IMSI can be used on a network that doesn't do this. And of course, as with `phantom withdrawals' from cash machines, the use of cryptography will `prove' that you're liable for the bill. Ross Anderson, Cambridge University Computer Laboratory Acknowledgement: our research students Stefan Hild, Abida Khattak, Markus Kuhn and Frank Stajano contributed in various ways to researching and planning this attack. An academic paper on the subject will appear in due course. ------------------------------ Date: Fri, 05 Dec 1997 09:10:05 -0800 From: stevan@netscape.com (Stevan Milunovic) Subject: Bug threatens Net software: land.c Somebody has released a program, known as land.c or Land Attack, which can be used to launch denial of service attacks against various TCP implementations. The program sends a TCP SYN packet (a connection initiation), giving the target host's address as both source and destination, and using the same port on the target host as both source and destination. Vulnerable systems include Windows NT, some versions of SunOs, Cisco routers and Catalyst software. [Source: Bug threatens Net software, 4 Dec 1997 http://www.news.com/News/Item/0%2C4%2C17009%2C00.html?ndh.idirect] ------------------------------ Date: Wed, 26 Nov 1997 02:38:10 -0500 From: David Kennedy <76702.3557@compuserve.com> Subject: Kuji Walks Matthew Bevan (a.k.a. Kuji), now 23, has been cleared in court, when three charges of "unauthorised access and modification" (into systems at Griffiss Air Force base and Lockheed Space and Missile Company in California) were dropped. He had been allegedly involved with Richard Pryce (a.k.a. Datastream Cowboy, breaking into NASA, USAF, and USArmy systems; see RISKS-18.15), who was fined 1,200 British pounds earlier this year. [Source: Lucie Morris, Security Risk Claim Computer Ace Cleared, *PA News*, 21 Nov 1997; PGN Abstracting] [DMK: Two of the best publications regarding the Rome Air Force Base hack-ins are the GAO Report available online through http://www.gao.gov/reports.htm under title [AIMD-96-92] Information Security: Computer Attacks at Department of Defense Pose Increasing Risks and the Fall 96 Computer Security Institute's journal, both articles written in whole or in part by Jim Christy, the Air Force investigator involved. Mixed messages. Is the interpretation to be, if you hack, you'll get off? Or if you hack some other country's computers, you won't be prosecuted because it costs too much? Of if your partner in crime gets off with just a fine, prosecutors won't spend a lot of money going after you? So Bevan *may* have hacked into computers worldwide. But he has no convictions. How long until he's peddling his skills as a computer security expert, or even on a "Tiger Team" or penetration testing group?] Dave Kennedy [CISSP] Director of Research, National Computer Security Assoc. ------------------------------ Date: 1 Dec 1997 13:05:02 -0700 From: alanh@primenet.com (Alan Hamilton) Subject: Date-based random numbers and Y2K I had a friend report to me a problem with the game Freecell on his PC. Ordinarily, Freecell starts a different numbered game each time a new game is started. However, his copy was stuck on #3389. It turns out that his system date had been accidentally changed to 2097 rather than 1997. Correcting the date fixed the problem. This made me think about how many programs use time/date-based random number generators. You would not expect Freecell to have a date-based bug, but it does. I suspect there are a lot of other programs with the same bug. Although they may not necessarily fail at 1/1/2000, they may fail at some other point. (Where a computed value exceeds 16 bits, for instance.) There are a lot of programs that obviously use dates, but I'm afraid we're going to find a lot of others that seemingly don't fail due to date-based problems too. Alan Hamilton ------------------------------ Date: Wed, 26 Nov 97 23:37:21 EST From: msb@sq.com Subject: Re: Y2K and canned-goods expiration dates (Pereira, Risks-19.47) There is, of course, a different and much simpler Y2K problem that also affects expiry dates, though it's unlikely to pertain to canned goods. If you see an expiry date of APR01, say, then it's useless unless you correctly understand whether the product is one likely to last for several years or not. Otherwise -- well, is that next (or perhaps *last*) April 1, or is it April of 2001? (People who would write the former as "01 APR" are probably laughing at this point, but they need only think about the confusions when April is converted to 04 instead, and a common standard is not followed...) I've been pleased to see a number of long-lived products these days using 4-digit years in their expiry dates, but as Fernando's story shows, there are still plenty that don't. Mark Brader, Toronto, msb@sq.com [For Your Amusement: I initially wrote the item using February as the example month, and then did a substitution to a more foolish example. I missed one instance at first, and nearly sent off the message with a reference to April being converted to 02...] ------------------------------ Date: Mon, 01 Dec 1997 13:38:33 -0500 From: David Collier-Brown Subject: Ontario removes privacy controls on education In a(n otherwise somewhat contentious) bill, the Government of Ontario has removed the ``personal information'' of students from the control of the Protection of Privacy acts. Later in the bill, it deems disclosure by institutions to automagically ` `be for the purposes of complying with this act''. This would be merely annoying, until one finds out the definition of ``personal information''. This happens to include things such s sexual orientation and political beliefs. Further comment withheld to avoid intemperate remarks (:-)) David Collier-Brown, 185 Ellerslie Ave., Willowdale, Ontario CANADA M2N 1Y3 davecb@hobbes.ss.org, 416-223-8968 http://java.science.yorku.ca/~davecb ------------------------------ Date: Tue, 25 Nov 1997 17:42:54 -0800 From: smartcard@sprynet.com Subject: Re: SET security (RISKS-19.31-36) InternetWeek Newsletter - Nov. 25 (Copyrighted CMP Media Inc). Mr Matthew Friedman of the InternetWeek Newsletter offers the following report on the SET specifications progress: After six months there is not one operational deployment. Merchants and banks report a serious flaw - set compliance does not guarantee cross vendor compatibility. set is reported as too complex to integrate cleanly with existing legacy transaction systems. Two implementers (HP/Verifone and IBM) have provided their own set 1.0 program to assure interoperability. Set was supposed to be interoperable. set 0.0 use has been extended three months to avoid a christmas season work conflict in migrating to set 1.0. Set providers acknowledge its three tiered architecture is complex. These are the client wallet, the merchant server and the banks gateway. These use software from multiple vendors. The set process will be dependent on millions of certificates from merchants and consumers. The bank industry must resolve the operational issues to tie together the specs, the system components, software, the actions of many people (users, merchants, bankers), card acceptor units and issuing/using millions of certificates. jerome svigals, smartcard@sprynet.com ------------------------------ Date: Fri, 21 Nov 1997 10:08:52 -0500 From: Jitendra Padhye Subject: nando.net shut down by custodian The Nando.net site was out of service for about three hours on 20 Nov 1997 because of a power outage. During routine custodial service, a vacuum cleaner caused an electrical overload in the room that houses Nando.net's main servers, which cut power to the main data servers, which in turn caused them to crash, requiring 2.5 hours to repair. [Seen on the *News and Observer Times* Web site by Jitu .] Seth Effron, Exec. Editor, Nando.net, 21 Nov 1997, http://www.nando.net. PGN Abstracting.] ------------------------------ Date: Tue, 25 Nov 1997 18:40:56 +0800 From: David R Brooks Subject: Damage from powerline surges [While this doesn't strictly involve computers, it certainly shows what a bad power surge can do. Dave Brooks ] A three-hour crisis at Broken Hill Proprietary Ltd. (Australia's biggest steel producer) resulted from a power surge that ignited the plant's high-voltage transformer, causing a series of fires and evacuation of all 3,500 workers. The general consensus is that the consequences could have been much worse. [Source: Richard Macey and Helen Trinca, Steelworks fire emergency blamed on power surge, *Sydney Morning Herald*, 25 Nov 1997, PGN Abstracting] ------------------------------ Date: 27 Nov 1997 18:22:33 +0100 From: Bjorn Borud Subject: Web cache risks Picture this: you are standing in front of a classroom full of students (most of them female I might add). You are going to teach the students how to use a service that lets you perform searches a huge library database containing alle the books in Norwegian college libraries. Your PC is hooked up with a video canon that projects a LARGE image of what's on your screen on the wall. You bring up the web page of the service you are about to demonstrate. The page loads, the graphics for the various buttons in the interface is loading...but something is wrong. One of the buttons is not a button at all. It's a large, particularly nasty, pornographic image which was definitely NOT put there by the providers said service. This happened earlier this week at a Norwegian college where a friend of mine works as a system administrator. Now, how did this happen? Well, like every responsible institution on the net they have a local web cache in order to speed things up and save bandwidth. this cache sometimes forwards request to yet another cache, and it was this cache that caused the embarrassing incident. It turns out the second cache was out of disk space and somehow this messed up the mappings between URLs and the actual images stored in the disk cache, so every now and then the cache would serve the wrong file from the cache. several people could confirm this behaviour. Bjørn Borud Guardian Networks AS http://www.pvv.org/~borud/ http://www.guardian.no/ ------------------------------ Date: 28 Nov 1997 10:20:54 GMT From: "Azeem Azhar" Subject: Perils of grammar checkers redux Several people asked what the sentence I referred to in RISKS-19.47 was. It was (without the quotes) "However, as this flexibility applies only to the time at which we will seek payment and not to the liability for payment, we will not be issuing a credit note. " [I've run it through my version of Word 97 SR-1, standard grammar checker, and it certainly works.] Azeem BBC [Back reference corrected in Archive copy] ------------------------------ Date: Thu, 27 Nov 1997 09:36:37 -0000 From: Mike Ellims Subject: URL for paper on European encryption policy (Ellims, RISKS-19.47) Looks like "the cat" has struck again. It seems that the URL I gave for the EC report on the use of encryption was incorrect. The full title of the report (from it's web title page) is as follows, Towards A European Framework for Digital Signatures And Encryption Communication from the Commission to the European Parliament, the Council, the Economic and Social Committee and the Committee of the Regions ensuring Security and Trust in Electronic Communication (Adopted by the Commission on 8 October 1997) Title page at http://www.ispo.cec.be/eif/policy , content at http://www.ispo.cec.be/eif/policy/97503.html . The following address also works: http://194.119.255.200/eif/policy/97503.html I have checked out these address and they appear to work. I've checked the spelling but this doesn't mean anything as it's a MS spell check program. I'd also like to thank the people who pointed the correction. None of the above reflect the views of my employer or my cat. The cat is hiding from embarrassment. Mike Ellims - Pi Technology - mike@pires.co.uk - +44 (0)1223 441 256 [Also noted by Lindsay F. Marshall, Jim Horning, Sander Tekelenburg. PGN] ------------------------------ Date: 1 Apr 1997 (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. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 19.48 ************************