Text File

precedence: bulk Subject: Risks Digest 21.14

RISKS-LIST: Risks-Forum Digest Tuesday 12 December 2000 Volume 21 : Issue 14

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/21.14.html> and by anonymous ftp at ftp.sri.com, cd risks .

Contents: Internet and Electronic Voting (PGN Rebecca Mercuri Lauren Weinstein) Re: Perspective on election processes (Ben Laurie) Arizona Motor Vehicle counterfeiting rings (Paul Nowak) Seattle Hospital Hacked (Lauren Gelman) A new Chinook inquiry? (Mike Ellims) Another Osprey crash (PGN) Space Station risks (Ben Hines) comp.risks considered harmful -- by some (Thomas Roessler) REVIEW: "Hack Proofing Your Network", Ryan Russell et al. (Rob Slade) Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Tue, 12 Dec 2000 17:30:56 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: IP: Internet and Electronic Voting

[Reproduced from Dave Farber's IP distribution, Date: Tue, 12 Dec 2000 20:36:19 -0500.]

A recurring mantra heard from some entities involved in the development and promotion of Internet-based voting systems is that they have conducted "public tests" and thus their systems are secure. If hackers don't break into such systems, the tests are declared a success.

This is of course illogical on its face, because it seems unlikely that people (both U.S. and internationally based) with an interest in subverting the U.S. election process would care to tip their hands by participating in what are essentially publicity stunts. These might attract your average 12-year old hacker, but not the pros who wait for production systems for their carefully mounted attacks.

In fact, using such "tests" as any sort of validation technique runs contrary to long-established computer and engineering verification practices, and makes a mockery of the rigorous design and testing that is required of systems that are to be deemed secure through extensive and methodical processes (e.g., to gain certification under the ISO Common Criteria or its predecessors TCSEC/ITSEC). "I left my Porsche out in the parking lot with the doors unlocked and the key in the ignition and since it doesn't appear to have been stolen this must be a safe neighborhood," would be an equally nonsensical statement of supposed validation. All proposed voting systems should be subjected to rigorous evaluation, public inspection, and *open-source code* license agreements. Some applicable methodologies do exist, but have not been required. For example, Level 4 Common Criteria should be a *minimum* standard, although even that is not enough.

Security is only as strong as its weakest links. Internet voting (I-voting) will *always* be limited in its integrity by factors beyond the I-voting algorithms. For example, encryption can be an important part of an overall election system. However, although we have strong cryptographic algorithms, we do not have systems with adequate security into which the cryptography can be embedded. Furthermore, voter authentication, vote integrity, voter anonymity, auditability, accountability, recountability, and so on, are all involved, and many of these requirements operate at cross-purposes with one another. The massive vulnerabilities of standard personal-computer operating systems represent very serious concerns, in terms of hidden viruses, worms, Trojan horses, and further surprises unknowingly downloaded by the user with other packages, and waiting to pounce on election day. One proposed solution would be to boot a fresh system from external media in order to vote, but even such an approach does not adequately address these potential vulnerabilities.

Deficient network protocols and the opportunities for insider fraud and accidental misuse abound. In addition to the issues noted above are the weaknesses that result from inadequate operational environments. Neither the client nor the server systems will be adequately secure under foreseeable technology -- including Internet Service Providers and Web servers. For example, proposals such as the use of rotating IP numbers and multiple systems to try to defend against denial of service attacks can be rendered impotent by similar attacks on network concentration points.

As always in any election environment, there are many opportunities for fraud, mischief, and manipulation -- despite ostensible checks and balances. These problems are exacerbated with electronic and Internet voting, where the lack of any physical ballots makes such manipulations impossible to detect and correct -- because there is no meaningful recount capability. Extraordinary vigilance is necessary, but never sufficient.

In the wake of the recent Presidential election problems, the knee-jerk reaction of "gee, can't we modernize and solve all this with electronic and/or Internet voting?" is predictable, but still wrongheaded. The shining lure of these "hype-tech" voting schemes is only a technological fool's gold that will create new problems far more intractable than those they claim to solve.

Peter Neumann, Rebecca Mercuri, and Lauren Weinstein

-----

Peter Neumann moderates the ACM Risks Forum, Chairs the ACM Committee on Computers and Public Policy, and is a cofounder of PFIR -- People For Internet Responsibility <http://www.pfir.org>.

Rebecca Mercuri is a Professor of Computer Science at Bryn Mawr College. She has provided expert testimony on voting systems throughout the past decade. For information on her Penn doctoral thesis and other writings on this subject, see http://www.notablesoftware.com .

Lauren Weinstein <lauren@vortex.com> and <lauren@pfir.org> moderates the Privacy Forum <http://www.vortex.com> and is a cofounder of PFIR -- People For Internet Responsibility <http://www.pfir.org>, and Member of the ACM Committee on Computers and Public Policy.

Information on the Common Criteria is at http://csrc.nist.gov/cc An earlier statement on I-voting is at http://www.pfir.org/statements/voting

------------------------------

Date: Tue, 12 Dec 2000 13:17:26 +0000 From: Ben Laurie <ben@algroup.co.uk> Subject: Re: Perspective on election processes (RISKS-21.13)

[From Dave Farber's IP]

> >Date: Sun, 10 Dec 2000 10:19:54 -0800 > >From: Ed Gerck <egerck@safevote.com > > > >Dave Farber wrote: > > > > > >Date: Sun, 3 Dec 2000 9:59:37 PST > > > >From: "Peter G. Neumann" <neumann@csl.sri.com> > > > >Subject: Perspective on election processes > > > > > > > .... > > > > * Voting by the Internet, even if only from well established polling > > > > places, is and will remain extraordinarily risky because of the > > inherent > > > > untrustworthiness of computer systems attached to the Internet and > > > > indeed the networking itself. It should not be recommended for use > > > > in the foreseeable future. > > > > > > > >The concern is justified but Peter ignores that there is a hacker-proof way > >to make an Internet-connected computer as secure as a non-connected one. > >The method was made public in its details and fire tested in a week-long > >24-hour-a-day open attack test -- as reported in USA Today, Wired, and > >in http://www.safevote.com/tech.htm

"Hacker-proof"? Get real - cracker-resistant, perhaps, but what's new? Safevote has a number of "snake oil" warning signs, including:

a) Use of multiple protocols: "in a real election Safevote would not know which algorithm is being used for encryption at any precinct", which is actually a rather silly claim - someone must know, or it would not be possible to decrypt - but ignoring that point, use of multiple algorithms merely adds a few bits to the keysize. Since there are not that many algorithms that are actually any good, this really is very few bits.

b) Use of proprietary algorithms (DVC and friends).

c) Mysterious claims of the properties of a small number of bits ("Each DVC also contains independent, multiple secure communication channels such as the voter's password, the ballot style to be used by the voter, and an internal secret.", yet they are only 30 bits long!).

d) "Cracking test" without disclosure of algorithms ("The specifications for Safevote's products and services under the Multi-Party technology will be made fully public and documented with open protocols, protected by flexible intellectual property rights that allow free non-commercial use." [note use of future tense]).

e) Existence of this "hacker-proof" technology brought to our attention by the owner - without bothering to mention this fact.

Of course, it could be great, but at this stage there's no way to tell.

Ben <http://www.apache-ssl.org/ben.html>

------------------------------

Date: Tue, 5 Dec 2000 15:48:29 -0700 From: Paul Nowak - SUPCRTX <pnowak@superiorcourt.maricopa.gov> Subject: Arizona Motor Vehicle counterfeiting rings

[In the wake of voting irregularities, we have this another license fraud case. Surprised? PGN]

Thus far, 14 people have been indicted -- including four AZ Motor Vehicle Division customer service employees and an Arizona Department of Transportation computer information worker. Several more arrests are expected, with more arrests expected. Four groups are accused of issuing bogus licenses and ID cards, at a cost over $1000 each. "Buyers apparently included criminals, illegal immigrants and motorists with suspended or revoked licenses." [Source: Article by Senta Scarborough, *The Arizona Republic*, 25 Nov 2000]

------------------------------

Date: Wed, 6 Dec 2000 19:26:05 -0500 Sender: ACM US Public Policy Committee <USACM@ACM.ORG> From: Lauren Gelman <gelman@EFF.ORG> Subject: Seattle Hospital Hacked

http://www.securityfocus.com/news/122

Seattle Hospital Hacked

Dutch hacker downloads thousands of patient records. By Kevin Poulsen December 6, 2000 3:54 PM PT

A sophisticated hacker took command of large portions of the University of Washington Medical Center's internal network earlier this year, and downloaded computerized admissions records for four thousand heart patients, SecurityFocus.com has learned.

The intrusions began in June, and continued until at least mid-July, before network administrators at the Seattle teaching hospital detected the hacker and cut him off. The medical center was purportedly unaware that patient records were downloaded, and elected not to notify law enforcement agencies of the intrusions.

"It's a story of great incompetence," said the hacker, a 25-year-old Dutch man who calls himself "Kane." "All the data taken from these computers was taken over the Internet. All the machines were exposed without any firewalls of any kind."

SecurityFocus.com reviewed portions of the databases the hacker downloaded. One of the files catalogs the name, address, birth date, social security number, height and weight of over four thousand cardiology patients, along with each medical procedure they underwent. Another file provides similar information on seven hundred physical rehabilitation patients. A third file chronicles every admission, discharge and transfer within the hospital during a five-month period.

"I can say we're investing an incident," said hospital spokesperson Walter Neary. "We are taking it very seriously."

In a telephone interview, Kane said he did not tamper with any hospital data, and described his forays into the hospital's network as a renegade public service aimed at exposing the poor security surrounding medical information. A self-described computer security consultant by trade, the hacker's illicit investigation was inspired by a conversation with a colleague, in which they wondered aloud about how well highly sensitive computers were protected. "The conversation came around to medical data, which is sensitive indeed, and I thought I'd have a look around," said Kane. <...>

Lauren Gelman, Director of Public Policy, Electronic Frontier Foundation 1-202/487-0420 <gelman@eff.org>

------------------------------

Date: Mon, 4 Dec 2000 10:08:58 -0000 From: Mike Ellims <mike.ellims@pitechnology.com> Subject: A new Chinook inquiry?

This is an update on an earlier series of postings. Apparently efforts to have a new inquiry into the Chinook crash on the Mull of Kintyre have been vetoed by the UK government.

The BBC quotes the public accounts committee report as saying that " there were repeated problems with the aircraft and the pilots should be exonerated" and that "the refit process was flawed".

Full story at, http://news.bbc.co.uk/hi/english/uk/scotland/newsid_1047000/1047469.stm

In an earlier news item they report that in an earlier incident with another Chinook where no one was killed they report that there are "documents showing that Boeing, the helicopter's manufacturer, had agreed with software contractors that the FADEC was the cause of the 1989 accident and that the system needed to be redesigned".

Full story at, http://news.bbc.co.uk/hi/english/uk/scotland/newsid_821000/821274.stm

Mike Ellims Pi Technology mike.ellims@pitechnology.com www.pitechnology.com phone +44 (0)1223 203 913 (direct) phone +44 (0)1223 441 434 (reception)

------------------------------

Date: Tue, 12 Dec 2000 08:39:41 -0800 (PST) From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Another Osprey crash

Four Marines were killed on 11 Dec 2000 in North Carolina when another experimental MV-22 Osprey tilt-rotor aircraft crashed. The remaining eight Ospreys have been grounded, pending review by an expert panel. This followed the loss of 19 Marines in Arizona in the spring 2000. [Source: PGN-ed from http://abcnews.go.com/sections/us/DailyNews/osprey001212.html]

------------------------------

Date: Wed, 6 Dec 2000 01:15:01 -0800 From: Ben Hines <bhines@san.rr.com> Subject: Space Station risks

Jim Oberg has written a great article in November's *IEEE SPECTRUM* discussing many risk issues and failure modes discovered during the recent space station missions.

It can be found here: http://www.spectrum.ieee.org/publicfeature/nov00/spac.html

Ben <http://tunnels.tripod.com/>

------------------------------

Date: Fri, 8 Dec 2000 14:25:34 +0100 From: Thomas Roessler <roessler@does-not-exist.org> Subject: comp.risks considered harmful (by some)

This site: <http://sethf.com/anticensorware/smartfilter/gotalist.php> lists some results from a reverse-engineering effort against the black list used by "SmartFilter". Apparently, comp.risks is being blocked by that software under the "Criminal Skills" category, as are comp.dcom.telecom, comp.org.cpsr.announce, comp.org.eff.news, comp.protocols.tcp-ip, comp.security.announce, and others.

------------------------------

Date: Mon, 4 Dec 2000 08:16:41 -0800 From: "Rob Slade, doting grandpa of Ryan and Trevor" <rslade@sprint.ca> Subject: REVIEW: "Hack Proofing Your Network", Ryan Russell et al

BKHPYNIT.RVW 20000831

"Hack Proofing Your Network", Ryan Russell et al, 2000, 1-928994-15-6, U$49.95/C$77.50/UK#31.95 %E Ryan Russell %E Stace Cunningham %C 800 Hingham Street, Rockland, MA 02370 %D 2000 %G 1-928994-15-6 %I Syngress Media, Inc. %O U$49.95/C$77.50/UK#31.95 781-681-5151 fax: 781-681-3585 %O www.syngress.com amy@syngress.com %P 450 p. %T "Hack Proofing Your Network: Internet Tradecraft"

According to the introduction, this book will teach you how to hack, or break into computer systems. With the best of intentions, of course. As it states, if you don't hack your system, who will? The intent is to teach you how to approach security breaking, with a view to finding, and then patching, the holes in your network.

Being an educator, and fairly cynical about anyone who tells me something is "safe," I have a lot of sympathy for this position. In theory. The implementation, though, may leave something to be desired. After all, those who are charged with protecting systems generally have other things to do. They have limited resources. They don't have a lot of leisure, or interest, in testing every single piece of software for any possible buffer overflow condition. So security managers may not be all that interested in spending all of their non-existent free time obsessively hacking their own systems.

Well, having reviewed the book, and sent off the draft, the lead author, Ryan Russell, informed me that security managers were not the real intended audience. This work was actually aimed at the keeners, those few who *do* really want to get behind the user interface, and poke about in the workings. But it may have some use beyond that rather select crowd. In Russell's own words, this is what you do after you've got good policies in place, and you've got your routine down for applying patches, watching for new vulnerability announcements, and so forth.

Part one, rather oddly entitled "Theory and Ideals," seems to concentrate on basic concepts. It also may seem strange that chapter one, called "Politics," starts out by defining "hacker" and other related terms. On the other hand, any text that tries to argue for the social value of criminals and frauds is bound to be considered political. Ultimately, this piece seems to be trying to justify system breaking activities. All the usual arguments are trotted out, and make the normal amount of sense (very little). (I should also point out that this book started life as an electronic text. This is evident in the frequent citations of Web sites in the course of the work. They may support the content in the context of a Web page, but in print they are annoying, since the relevant material is not incorporated into the book.) Chapter two, "Security Laws," is more a set of cliches: what can go wrong will go wrong, security by obscurity doesn't work. Some of them are wrong (passwords can be securely stored with one-way encryption, albeit still at some risk of brute force attacks; and the NSA has goofed on an algorithm), some are naive (the assertion that there is no guaranteed protection against viruses makes no mention of Fred Cohen's work), and most are of questionable utility. The classes of attack listed in chapter three are neither comprehensive nor fully explained. (Most of the space in the chapter is given over to source listings of attack tools.) "Methodologies" seems to be a collection of random thoughts on analysis in chapter four.

Part two describes some activities intended to be undertaken on a computer over which you have complete control, mostly related to decryption. Chapter five looks at making small changes to a system, and checking for modifications. This is a useful function in any kind of analysis, but the examples chosen will hardly be of use to sysadmins. The author admits that chapter six really does not explain cryptography, it really only mentions some password cracking tools. Both chapters seven and eight essentially deal with bad data, first in general terms and then in the specific problem of buffer overflows. While the discussion might be of interest to programmers, it is of limited use to security managers.

Part three talks about attacks on remote systems. There is a little explanation about sniffing (which requires some level of local access), session hijacking, and spoofing. Chapters twelve and thirteen list some security holes in server and client software respectively. Oddly, given all the problems in earlier parts of the book, the material on viruses and malware, in chapter fourteen, isn't too bad. It's not great, it displays too much virus code to very little effect, and has a few holes, but it is generally better than the stuff found in standard security texts, and stands out above the rest of the book.

Part four contains a single chapter. Although the titular subject is reporting, most of the material promotes the concept of "full disclosure." This is the tenet that security is best served by having all security loopholes disclosed. The discussion does take a fairly responsible tack, recommending that vendors be contacted first, and allowed some time to fix the problem, before the vulnerability or exploit is released to the public. The text is fairly reasonable, although is does contain the full text of a number of email exchanges which add little to the debate. The remaining pages concentrate on the importance of continual study in the security field.

The people who have contributed to this book are a step above the usual "wannabes" who tend to write "hacker" security books. The information presented is also somewhat more reliable, and covers a broader range. However, both the thesis and the execution of the work contain flaws. The material still seems more interested in justifying security breaking expeditions than in giving the security administrator a complete and useful reference for protection. Errors, while less rampant than in other, similar texts, are still too common for the content to be considered really dependable. In particular, basic concepts are too quickly dismissed in the eagerness to pass along news of the latest "cool tool." Experienced security managers may find some helpful recent data in this volume, but probably already have resources of their own. Newcomers to the field are advised not to rely too heavily on this as a single source of knowledge.

As noted, though, the authors were not really writing for managers or novices. For software engineers, programmers, and testers, there is possibly more utility. Those doing sophisticated software evaluations, and particularly those with sufficient resources to really "test to destruction," might get the most out of the book, especially considering the concentration on breaking, rather than fixing. Still, some research in the RISKS and BUGTRAQ archives would likely get you just as much.

copyright Robert M. Slade, 2000 BKHPYNIT.RVW 20000831 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

------------------------------

Date: 15 Aug 2000 (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 DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => 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.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 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. http://the.wiretapped.net/security/textfiles/risks-digest/ . ==> PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 21.14 ************************