RISKS-LIST: Risks-Forum Digest Sunday 26 January 2003 Volume 22 : Issue 51 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 <URL:http://catless.ncl.ac.uk/Risks/22.51.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Keep it secret, stupid! (Matt Blaze) DoD offering admin privileges on .mil Web sites (Thomas C Greene via Fuzzy Gorilla) A. Guadamuz: Trouble with Prime Numbers: DeCSS, DVD, ... (Monty Solomon) Drunk driver hack (David Wj Stringer-Calvert) TurboTax 'activation' annoys users (Monty Solomon) Spam continues to increase (Monty Solomon) Canadian Centre for Identity Theft? (Richard Akerman) NASTAR web site provides personal skier information to anyone (Robert H'obbes' Zakon) Re: Hard-coded calendar dates (John Sullivan) REVIEW: "Internet Cryptography", Richard E. Smith (Rob Slade) REVIEW: "Cryptography Decrypted", H. X. Mel/Doris Baker (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sun, 26 Jan 2003 17:46:49 -0500 From: Matt Blaze <mabat_private> Subject: Keep it secret, stupid! Last year, I started wondering whether cryptologic approaches might be useful for the analysis of things that don't use computers. Mechanical locks seemed like a natural place to start, since they provided many of the metaphors we used to think about computer security in the first place. So I read everything I could get my hands on about locks, which included most of the available open literature and at least some of the "closed" literature of that field. Once I understood the basics, I quickly discovered, or more accurately re-discovered, a simple and practical rights amplification (or privilege escalation) attack to which most master-keyed locks are vulnerable. The attack uses access to a single lock and key to get the master key to the entire system, and is very easy to perform. For details, see http://www.crypto.com/masterkey.html I wrote up the attack, in a paper aimed more at convincing computer scientists that locks are worth our attention than anything else (I called it "Rights amplification in master-keyed mechanical locks"). As I pointed out in the paper, surely I could not have been the first to discover this -- locksmiths, criminals, and college students must have figured this out long ago. Indeed, several colleagues mentioned that my paper reminded them of their college days. There is considerable evidence that similar methods for master key decoding have been discovered and rediscovered over the years, used illicitly and passed along as folklore (several people have unearthed Internet postings dating back as much as 15 years describing how to make master keys). Curious college students -- and professional burglars -- have long been able to get their hands on master keys to the places that interest them. But the method does not seem to appear in the literature of locks and security, and certainly users of master keyed locks did not seem to know about this risk. I submitted the paper to a journal and circulated it to colleagues in the security community. Eventually, the paper reached the attention of a reporter at the New York Times, who wrote it up in a story on the front page of the business section last week. The response surprised me. For a few days, my e-mail inbox was full of angry letters from locksmiths, the majority of which made both the point that I'm a moron, because everyone knew about this already, as well as the point that I'm irresponsible, because this method is much too dangerous to publish. A few managed to also work in a third point, which is that the method couldn't possibly work because obviously I'm just some egghead who doesn't know anything about locks. Those letters, with their self-canceling inconsistency, are easy enough to brush aside, but there seems to be a more serious problem here, one that has led to a significant real-world vulnerability for lock users but that is sadly all too familiar to contemporary observers of computer security. The existence of this method, and the reaction of the locksmithing profession to it, strikes me as a classic instance of the complete failure of the "keep vulnerabilities secret" security model. I'm told that the industry has known about this vulnerability and chosen to do nothing -- not even warn their customers -- for over a century. Instead it was kept secret and passed along as folklore, sometimes used as a shortcut for recovering lost master keys for paying customers. If at some point in the last hundred years this method had been documented properly, surely the threat could have been addressed and lock customers allowed to make informed decisions about their own security. The tragic part is that there are alternatives. There are several lock designs that turn out to resist this threat, including master rings and bicentric locks. While these designs aren't perfect, they resist completely the adaptive oracle attack described in my paper. It's a pity that stronger alternative designs have been allowed to die a quiet death in the marketplace while customers, ignorant of the risks, have spent over a hundred years investing in inferior systems. Although a few people have confused my reporting of the vulnerability with causing the vulnerability itself, I can take comfort in a story that Richard Feynman famously told about his days on the Manhattan project. Some simple vulnerabilities (and user interface problems) made it easy to open most of the safes in use at Los Alamos. He eventually demonstrated the problem to the Army officials in charge. Horrified, they promised to do something about it. The response? A memo ordering the staff to keep Feynman away from their safes. ------------------------------ Date: Sun, 26 Jan 2003 14:29:34 -0500 From: "Fuzzy Gorilla" <fuzzygorillaat_private> Subject: DoD offering admin privileges on .mil Web sites DoD offering admin privileges on .mil Web sites *The Register*, Thomas C Greene, 24 Jan 2003 Care to register a .mil Web site of your own for free? The DoD has gone out of its way to make it a snap. An unbelievably badly-protected admin interface welcomes you to register whatever domain you please (http://Rotten.mil anyone?), or edit anything they've already got. The interface is so ludicrously unprotected that it's been cached by Google and fails to mention that you must be authorized to muck about with it. Incredibly, default passwords are cheerfully provided on the page. Following an anonymous tip from an observant Reg reader, we've encountered the page in question in the Google cache, and after a bit of our own poking about have also discovered an equally unprotected (and Google-cached) admin interface encouraging us to add a new user, like ourselves, say, which requires no authentication. All you have to do is find that page and you can set yourself up with a user account, manage your new .mil Web site, fiddle about with other people's .mil Web sites, and generally make an incredible nuisance of yourself. We are, of course, straining against every natural, journalistic impulse in our beings by neglecting to mention any useful search strings with which to find it. Another unprotected and cached page, this one discovered by our tipster, lists traffic to a major DoD Web site by URL/IP address. This worries us because it may list .mil sites and networked DoD machines that are not public, not hotlinked anywhere, and which might contain (or be networked with other machines that contain) sensitive data. Merely knowing that all those URLs and IP addys are valid and owned by DoD would give a significant advantage to attackers by narrowing their target area dramatically. We have e-mailed the person who manages these sites - twice in fact - but so far have not been graced with a reply. We were hoping that they might be inclined to fix this mess quickly so that we could safely include the details in our report. Unfortunately we have to withhold them until we're confident that these security snafus are under control. Ironically, US Defense Secretary Donald Rumsfeld recently ordered DoD to purge military Web sites of information that might benefit evildoers. That's all well and good, but it might behoove the DoD to stop offering them admin privileges first. http://212.100.234.54/content/55/29026.html ------------------------------ Date: Fri, 24 Jan 2003 13:39:23 -0500 From: Monty Solomon <montyat_private> Subject: A. Guadamuz: Trouble with Prime Numbers: DeCSS, DVD, ... A. Guadamuz Trouble with Prime Numbers: DeCSS, DVD and the Protection of Proprietary Encryption Tools *The Journal of Information, Law and Technology* (JILT), 2002 (3) Andrés Guadamuz González Law Lecturer University of Edinburgh a.guadamuzat_private Abstract The DVD video format has become one of the most important developments in the home entertainment market since the popularisation of the magnetic video recording. The film industry delivered this format with a built in security system which was supposed to avoid illegal copying of the discs, much as what is taking place with the music CD and the almost indiscriminate copying of music into MP3 format over the Internet. This was achieved by means of encryption technology. This essay deals with the cracking of DVD encryption and its further diffusion as a computer programme named DeCSS, which has been made available over the Internet in various formats, including t-shirts and a numerical representation of the code. There are three court cases based on the online posting of this programme, two in the United States and one in Norway. The article starts by describing the technology involved, as it is felt by the author that some of these technical issues are of importance to the legal implications of the case and should be understood properly. The article then deals with the developments in all of the three cases up to this date. The essay then finishes with a look at the legal issues involved, including hyper-linking, trade secrets, freedom of speech and the translation of DeCSS into numerical format. This is a Refereed article published on 6 December 2002. http://elj.warwick.ac.uk/jilt/02-3/guadamuz.html ------------------------------ Date: Wed, 22 Jan 2003 22:22:35 -0800 From: "David Wj Stringer-Calvert" <david.stringer-calvertat_private> Subject: Drunk driver hack A 19-year-old in Besancon, France, was arrested for drunk driving. Arriving for his court hearing, he discovered an unattended computer, and proceeded to erase his record -- replacing it with a winking smiley face. The judge was not amused, and gave him a three-month suspended prison sentence, a $425 fine, and a three-month suspension of his driving license. [Source: Reuters item, From CNN.com, 21 Jan 2003; PGN-ed] ------------------------------ Date: Sun, 26 Jan 2003 00:25:26 -0500 From: Monty Solomon <montyat_private> Subject: TurboTax 'activation' annoys users A new "product activation" system in many 2003 editions of Intuit Inc.'s TurboTax software prevents people from letting anyone else use the CD-ROM on another computer in anything other than trial mode. [Source: Mike Musgrove, *The Washington Post*, 26 Jan 2003] http://www.washingtonpost.com/wp-dyn/articles/A40873-2003Jan24.html ------------------------------ Date: Thu, 16 Jan 2003 22:38:57 -0500 From: Monty Solomon <montyat_private> Subject: Spam continues to increase The number of spam messages sent increased nearly 300 percent from 2001 to 2002 -- from 14,078,511 to 55,683,103, according to e-mail filtering company Brightmail. If you think you're getting more spam than ever, you're right. Spam has dramatically increased in the past year. And next year will be even worse. One new report says that by July, the volume of spam sent to business e-mail addresses will exceed the amount of regular e-mail. [Source: *Newsfactor.com*, Janet Kornblum, 13 Jan 2003; PGN-ed] http://www.newsfactor.com/perl/story/20447.html ------------------------------ Date: Wed, 15 Jan 2003 06:50:45 -0500 From: Richard Akerman <rakermanat_private> Subject: Canadian Centre for Identity Theft? The National Archives of Canada already provide some Genealogy Research links and services http://www.archives.ca/02/020202_e.html They are polling, as part of the Canadian Genealogy Centre initiative http://cgc-ccg.archives.ca/ Earlier poll results have been released http://www.globeandmail.com/servlet/ArticleNews/PEstory/TGAM/20030106/UFAMIO Q/national/national/national_temp/3/3/14/ http://www.canada.com/ottawa/story.asp?id=%7B64AA74C1-25C8-415A-8574-5EA6499 47708%7D "Exactly half of those surveyed said they were either very interested (21 per cent) or somewhat interested (29 per cent) in being able to search for all Canadian genealogical information on a single Internet site." Considering that most online and telephone credit card security consists of "shared secrets" such as: your name, address, phone number plus date of birth and mother's maiden name, this new Centre would seem to be an identity thief's paradise. Just to make things even easier, the current Archives Genealogy FAQ points people at telephone directories, which can fill in the name-phone-address triplet: http://www.archives.ca/02/02020201_e.html#8 I don't see that any consideration of this risk has been taken into account. ------------------------------ Date: Thu, 16 Jan 2003 13:56:44 -0500 From: "Robert H'obbes' Zakon" <Robertat_private> Subject: NASTAR web site provides personal skier information to anyone NASTAR, the largest organization tracking amateur and professional ski races, is kind enough to post race results on its web site. You can even search for a ski racer by name. By clicking on the ski racer's name, you get a page stating "I am <ski racer name> and I would like to login! [Click Here]". If the skier has not done so before (and most probably don't even know about it), you are prompted to *create* a password, and can then access a page containing the racer's full home address and birth date! Seeing as NASTAR tracks not only professional racers, but amateur and community racers as well, they have quite an extensive database of individuals. After noticing the above behavior during last year's ski season, I e-mailed NASTAR and notified the local ski resort I race at. Of course I never heard back from NASTAR, and could only hope their system would have been fixed for And I thought I just had to look out for trees... No such luck though. ------------------------------ Date: Mon, 6 Jan 2003 14:46:45 +0000 From: John Sullivan <john.sullivanat_private> Subject: Re: Hard-coded calendar dates It's OK now though - they've fixed the JavaScript to read: document.write(dayNames[day] + ", " + monthNames[month] + " " + date + ", 2003"); I'm stunned. There are just so many things wrong with this. First of all I can't see any benefit to using a client generated date string anyway - why not just get the server to fill it in - one assumes amongst other things the server's clock is going to be more reliable than any random client's, plus I think it really should be tied to the time of the last update rather than whatever time it happens to be read at. Second, the code immediately preceding initialises a variable called year - why, if they're just going to hard code the year as a string anyway? I suspect they had trouble deciding whether to add 1900 to the number returned from getYear or not. JS treatment of this varies between browser versions, and support for the improved getFullYear method may be patchy, but again a server filled date would solve this. (Actually, getFullYear is now sufficiently old for cross-browser support to be probably good enough.) Thirdly, if you're doing it on the client, why not just use the Date object's own string formatting capability? The paper is English language only and none of the rest of the site is going to respond to the client's locale settings so I can see a stylistic point to fixing the date to the paper's own preferred format, but at least the Date object would get the year right without additional hackery. ------------------------------ Date: Tue, 21 Jan 2003 08:14:34 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Internet Cryptography", Richard E. Smith BKINTCRP.RVW 20021215 "Internet Cryptography", Richard E. Smith, 1997, 0-201-92480-3, U$29.95/C$44.95 %A Richard E. Smith internet-cryptoat_private %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 1997 %G 0-201-92480-3 %I Addison-Wesley Publishing Co. %O U$29.95/C$44.95 416-447-5101 fax: 416-443-0948 bkexpressat_private %O http://www.amazon.com/exec/obidos/ASIN/0201924803/robsladesinterne %P 356 p. %T "Internet Cryptography" According to the preface, this book is aimed at non-specialists who need to know just enough about cryptography to make informed technical decisions. As an example, Smith suggests systems administrators and managers who, while not formally charged with security, still have to use cryptographic techniques to secure their networks or transmissions. Chapter one is an introduction, contrasting what we want; secure communications; with the environment we have to work in; a wide open Internet. The text also looks at the balance that must be maintained between convenience and requirements. Encryption basics, in chapter two, presents the concepts of symmetric cryptography, use, and choice. There is a clear explanation of the ideas without overwhelming technical details. (It is interesting to note how quickly the cryptographic technology changes: SKIPJACK and ITAR were still important when the book was written, and are now basically irrelevant.) Some random thoughts on network implementation of encryption are given in chapter three. Managing secret keys, in chapter four, provides good conceptual coverage of generation and management, although the discussion of the problems of key escrow is weak. Because of the requirements for technical details when discussing protocols, chapter five, on IPSec, is different from other material in the book. It also includes a brief mention of other protocols. Chapter six discusses the use of IPSec in virtual private networks, while seven examines IPSec in terms of remote access. Chapter eight looks at IPSec in relation to firewalls, but it is difficult to see how this would be used in an actual application. Chapter nine reviews public key encryption and SSL (Secure Sockets Layer). The basic concepts of asymmetric cryptography are presented well, but may be unconvincing due to the lack of mathematical support and details. While there is an introduction to the related idea of digital signatures, SSL is really only barely mentioned. World Wide Web transaction security, in chapter ten, provides practical examples of the technologies discussed. The same is true of email, in chapter eleven, but digital signatures get a bit more explanation. Chapter twelve builds on the signature concept to introduce PKI (Public Key Infrastructure) notions. The fundamentals are written clearly and well, and are quite suitable for managers and users. Despite the lack of detail, the text may even be suitable for some security professionals who need a rough background without needing to work with the technology itself. The work is easy to read, although the idiosyncratic structure may be confusing, and the value of some chapters questionable. copyright Robert M. Slade, 2002 BKINTCRP.RVW 20021215 ====================== (quote inserted randomly by Pegasus Mailer) rsladeat_private rsladeat_private sladeat_private p1at_private A fanatic is one who can't change his mind and won't change the subject. - Winston Churchill http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Wed, 22 Jan 2003 08:24:16 -0800 From: Rob Slade <rsladeat_private> Subject: REVIEW: "Cryptography Decrypted", H. X. Mel/Doris Baker BKCRPDEC.RVW 20021215 "Cryptography Decrypted", H. X. Mel/Doris Baker, 2001, 0-201-61647-5, U$29.95/C$44.95 %A H. X. Mel www.hxmel.com %A Doris Baker %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2001 %G 0-201-61647-5 %I Addison-Wesley Publishing Co. %O U$29.95/C$44.95 800-822-6339 fax 617-944-7273 bkexpressat_private %O http://www.amazon.com/exec/obidos/ASIN/0201616475/robsladesinterne %P 352 p. %T "Cryptography Decrypted" The book seems to be rather ambitious, since the preface says that it is addressed to any (and therefore all) audience(s), without any limitation on the stated purpose. In general, it is an attempt to portray the basic concepts of cryptography, without getting too far into technical details. Many other books have tried to do the same thing, and signally failed. Mel and Baker by and large succeed. Part one addressed secret key (symmetric) cryptography. Chapter one tries to draw an analogy between locks and encryption, although the relation is strained at best. Substitution, frequency analysis, and polyalphabetic ciphers are covered in chapter two. Chapter three introduces transposition. The Polybius square is used, in chapter four, as an example of the combination of substitution and transposition. For those in the know, this leads nicely into the discussion of DES (Data Encryption Standard), in chapter five, although the neat segue would be lost on most readers, since the details of DES are not given. The history of cryptography appears rather abruptly in chapter six. Chapter seven covers the attempts to use cryptographic methods for confidentiality, integrity, authentication, and non-repudiation, and shows that the last point is not possible with purely symmetric cryptography. A simplistic examination of key exchange is given in chapter eight. Part two deals with public key (asymmetric) encryption. Chapter nine is a confusing introduction using the Merkle puzzle space (with some mention of Diffie-Hellman) as the example. A simplistic review of public key encryption is in chapter ten. Math tricks, in chapter eleven, seems pointless as it begins, but the development to the examples of modular inverses do provide both a basic form of asymmetric cryptography, and a demonstration of the mathematical concepts underlying more advanced cryptographic algorithms. Chapter twelve introduces authentication and digital signatures, with hashes and message digests in chapter thirteen, and a discussion of digest assurances (reviewing collisions and encrypted message authentication codes) in fourteen. A comparison of cryptographic strength and speed (between symmetric and asymmetric systems) is in chapter fifteen. Part three covers the distribution of public keys, and introduces some of the concepts of PKI (Public Key Infrastructure). Chapter sixteen deals with certificates. The title of chapter seventeen relates to the X.509 certificate structure, but the topics covered mostly concern hierarchical certificate authorities. PGP (Pretty Good Privacy) and the "Web of Trust" model are explained in chapter eighteen. Part four looks at real world systems and actual applications. Chapter nineteen explains email security, but in a generic fashion. SSL (Secure Sockets Layer) is clearly described in chapter twenty, but, given the lack of detail in the rest of the book, the technical material is rather odd. IPSec, in chapter twenty one, is presented in a confused manner. Various problems of, and attacks against, cryptography are outlined in chapter twenty two. The final chapter is a simplistic review of the storage of cryptographic keys on smart cards. This book does present most of the core concepts in cryptography. The text is readable, and, within the limited scope of the material, generally accurate. For non-specialists, it is a reasonable introduction to the topic. This might even include security professionals who are not directly involved with cryptographic systems. However, the lack of detail in the explanations of the theory is a weakness, since the text would be more convincing with more background. copyright Robert M. Slade, 2002 BKCRPDEC.RVW 20021215 rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-requestat_private 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 <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; 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. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => 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 risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>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.51 ************************
This archive was generated by hypermail 2b30 : Sun Jan 26 2003 - 21:13:30 PST