OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Risks Digest 21.14
From: riskscsl.sri.com
Date: Tue Dec 12 2000 - 20:13:00 CST


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" <neumanncsl.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 <laurenvortex.com> and <laurenpfir.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 <benalgroup.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 <egercksafevote.com
> >
> >Dave Farber wrote:
> >
> > > >Date: Sun, 3 Dec 2000 9:59:37 PST
> > > >From: "Peter G. Neumann" <neumanncsl.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 <pnowaksuperiorcourt.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 <USACMACM.ORG>
From: Lauren Gelman <gelmanEFF.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 <gelmaneff.org>

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

Date: Mon, 4 Dec 2000 10:08:58 -0000
From: Mike Ellims <mike.ellimspitechnology.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.ellimspitechnology.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" <neumanncsl.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 <bhinessan.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 <roesslerdoes-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" <rsladesprint.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 amysyngress.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
rsladevcn.bc.ca rsladesprint.ca sladevictoria.tc.ca p1canada.com
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

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

Date: 15 Aug 2000 (LAST-MODIFIED)
From: RISKS-requestcsl.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-requestcsl.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-requestpica.army.mil> (Dennis Rears).
 .UK users should contact <Lindsay.Marshallnewcastle.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 risksCSL.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
************************