The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 22 Issue 39

Saturday 23 November 2002

Contents

More on the Breeders Cup Pick-6 fix
Danny Lawrence
Crackers steal 52,000 university passwords
Monty Solomon
Slashdot suggests X-Box gamezone open to DoS
George Michaelson
Laptop injures lap
Gene Spafford
"AccuVote" comes to Boston -- argh!
Jonathan Kamens
NSF FastLane promotes excessive sharing?
Lee Rudolph
Interesting new spammer trick
Jonathan Kamens
Bad assumption in automated toll collection
Andrew Goodman-Jones
REVIEW: "Security Engineering", Ross Anderson
Rob Slade
REVIEW: "Network Intrusion Detection", Northcutt/Novak/McLachlan
Rob Slade
Info on RISKS (comp.risks)

More on the Breeders Cup Pick-6 fix

<Danny Lawrence <Danny@TiassaTech.com>>
Thu, 21 Nov 2002 13:07:40 -0500

Unsurprisingly, the *Daily Racing Form* is doing a better job of covering
the scam than the general media, here are a couple of references:

  The "3rd member" of the party (whose account was used to make the "test
  runs" of the fix prior to the Breeders Cup) was already under
  investigation by the OTB
  http://www.drf.com/members/web_news.generate_article_html?p_news_head=42153&p_arc=1

The fired Autotote employee pleads guilty to one count of wire fraud:
  http://www.drf.com/news/article/42458.html
Also it seems that he (and his 2 confederates) were cashing unclaimed
tickets that he found in the Autotote system.

As in many cases of this type it looks like greed was their undoing.
Here's a link to another betting scam from the 1970's:
  http://www.drf.com/members/web_news.generate_article_html?p_news_head=42077&p_arc=1

I think that the fact that the OTB was already looking into the 3rd person's
suspect account indicates that the checks were there, that they didn't act
sooner indicates prudence on their part.  The worst thing (from a
creditability standpoint) that a betting organization can do is withhold a
payout and accuse a player of cheating, only to be proved wrong.

--Danny Lawrence, Tiassa Technologies Inc.
http://www.tiassatech.com/domino/saga.nsf/story/uk


Crackers steal 52,000 university passwords

<Monty Solomon <monty@roscom.com>>
Wed, 20 Nov 2002 02:05:07 -0500

The University of Oslo had to change the passwords of 52,000 users and
reinstall software on dozens of computers after crackers managed to
infiltrate the network and extract the institution's central password file.
  http://www.aftenposten.no/english/local/article.jhtml?articleID=437439


Slashdot suggests X-Box gamezone open to DoS

<George Michaelson <ggm@apnic.net>>
Fri, 22 Nov 2002 10:59:30 +1000 (EST)

***UNPROVEN RISK***

gamers with modded XBoxes are banned by Microsoft. banning means
they can be recognized. recognition requires a unique ID, the pozited
unique ID is serial no and MAC address.

Xbox hackers allege that by changing serial number and MAC address and
turning off their modchip they succeeded in registering in Xbox gamezone.

Therefore, since integers between 0 and the size of the register in the
chip are a finite resource, they have 'stolen' some unsold/unregistered
machines ID.

Therefore there is an identity theft risk.

	And there is a DoS game here: walk the space, with your modded
	box, and lock out the entire XBox userspace from the gamezone

Yes, its a large numberfield, maybe a 128-bit sequence space. But I bet you
can walk it for fun and profit...

>From SlashDot:

>Changing serial numbers and macs...
>by AtariDatacenter on 11:11 AM November 22nd, 2002 (Score:5, Insightful)
>(#4727735)
>(User #31657 Info) mailto:jmccorm@yahoo.com?Subject=SlashdotResponse Neutral
>
>
> So they said they changed their serial number *and* MAC address to
> get back on. This is interesting and points back to something
> someone said in a previous thread. All you need to do is to make
> a program to burn through serial number space and get them marked
> invalid, and you've got a DoS of entertaining proportions.


Laptop injures lap

<Gene Spafford <spaf@cerias.purdue.edu>>
Fri, 22 Nov 2002 18:23:57 -0500

There are all kinds of new risks with higher-power processors and metal cases:

http://www.cnn.com/2002/WORLD/europe/11/22/health.laptop.reut/index.html

  [Alo noted by Mark Brader.  PGN]


"AccuVote" comes to Boston -- argh!

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Thu, 14 Nov 2002 22:06:38 -0500

  [A letter I'm about to send to the Massachusetts Secretary of State and
  the City of Boston's Election Department:]

Dear Sirs,

I was dismayed to learn recently that the City of Boston has decided
to replace its lever-activated voting booths with Diebold AccuVote-OS
machines, and indeed has already purchased the Diebold machines.

As you may know, with the Diebold machines you mark your votes by
coloring in circles on a paper ballot, then you feed the ballot
through the machine and into a ballot box.  After you feed your vote
through the machine, a count of successful votes displayed by an LED
on the front of the machine is incremented.

I asked the volunteer demonstrating the machine to me, "But how do I
know that the machine recorded my vote correctly?"  In response, she
told me that since the number was incremented, my vote was counted.  I
didn't even try to make her understand that since a ballot could have
multiple races on it, and since I could abstain from any of them by
not filling in any of the circles for that race, there was no way for
me to distinguish between the machine correctly registering all the
votes I recorded and the machine registering some of them and missing
some and treating them as abstentions.  Not to mention the possibility
that the machine might register my votes wrong, rather than just
register some abstentions where I actually voted.

It's certainly a good thing that this voting machine uses a paper
ballot.  Such a human-readable, physical record of each vote is an
essential part of any reliable voting system, electronic or otherwise.

However, without explicit acknowledgment from the machine to the voter
of which votes were and were not registered, and a chance for the
voter to correct any errors or omissions revealed by that
acknowledgment, the functionality provided by this machine is simply
not adequate for reliable, accurate voting.

Furthermore, I cannot help but wonder what happens if the machine says
that it didn't successfully register my vote, if the back of the
machine feeds directly into a ballot box as the volunteers at my
polling place led me to believe it would.  Presumably the ballot box
is locked, so they can't remove my first ballot.  Do I get to try
again?  And what if there is then a recount of the paper ballots, and
my first ballot is legible the during the recount -- I got to vote
twice!

In short, this technology is simply not acceptable.  I am deeply
disturbed that the City of Boston has chosen to ignore the reams of
scholarly evidence of this fact and went ahead with the purchase of
simply inadequate voting technology.

If you are unfamiliar with all the evidence of why most electronic
voting machines are inadequate and of how electronic voting might be
done properly, a good place to start researching it is at the Web site
of Rebecca Mercuri, "http://www.notablesoftware.com/evote.html".

Thank you for your time.

Sincerely,   Jonathan Kamens


NSF FastLane promotes excessive sharing?

<lrudolph@panix.com (Lee Rudolph)>
12 Nov 2002 14:00:54 -0500

I'm in the middle of preparing a grant proposal for the National Science
Foundation, using FastLane, NSF's (now mandatory) online system for proposal
preparation, submission, reviewing, etc.  For the first time in my
grant-writing life, I'm going to have "Co-PIs" (co-Principal Investigators;
I am the PI on this proposal).  Each Co-PI has to be able to log in to
access and modify the proposal; (Co)-PIs' names must be entered on the
"Cover Sheet" form, and that form states that "Only Co-PIs entered here will
be available on other forms in this proposal."

How must they be entered?  "To add Co-PIs, enter the SSNs of the Co-PIs and
then save the remainder of the cover sheet by clicking on the "OK" button at
the bottom of this screen."

In other words (as I have confirmed with a phonecall to the FastLane help
desk), *either* my Co-PIs have to give me their Social Security numbers so
that I can enter them on this form (and thereafter they can log in by
themselves), *or* I have to give my Co-PIs my FastLane password (and my SSN,
that being [unfortunately] required as well as the password to log in) so
that they can log in as me and enter their own SSNs (and thereafter log in
by, but not necessarily *as*, themselves).

Of course, there's a third choice, the one I will actually make: I can walk
over to each Co-PI's office in turn, log in to FastLane on that Co-PI's
computer, and let him or her enter his or her SSN.  That's easy enough;
we're all working at the same university.  However, if we were at several
universities several hundred miles apart, using FastLane to *facilitate
collaboration* among distant colleagues (one of its purported reasons for
being), this third choice would not be quite so practical.

The RISK is left to the reader.


Interesting new spammer trick

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Thu, 14 Nov 2002 09:56:17 -0500

Since many of you are interested in the topic of E-mail spam, e.g.,
the techniques used by the spammers to evade filtering and the
techniques used by everybody else to try to outsmart them, I thought
you might be interested in the following new spammer trick which I
first saw on October 17 and have seen numerous times since then.

I use a home-grown script to analyze the "Received:" headers of the
spam that I receive, determine the appropriate sites to whom to
complain, and generate the complaint messages.  Spammers figured out
quite a while ago to insert forged Received: headers in their
messages, but they're usually pretty easy to weed out, e.g., they
refer to nonexistent hosts, they list bogus envelope recipients, they
have bogus dates, the destination host of one Received: header doesn't
match the sender host of the next one in the chain, etc.  However, at
least one spammer has figured out how to forge a Received: header which
more convincing than any I've seen.  Here are some of the headers of a
spam message I received on October 17:

  Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83])
	  by jik.kamens.brookline.ma.us (8.12.5/8.12.5) with ESMTP id g9HBd2aP009915
	  for <jik@kamens.brookline.ma.us>; Thu, 17 Oct 2002 07:39:02 -0400
  Received: from 146-153-179-208.pajo.com (146-153-179-208.pajo.com [208.179.153.146] (may be forged))
	  by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with SMTP id HAA12722
	  for <jik@mit.edu>; Thu, 17 Oct 2002 07:39:01 -0400 (EDT)
  Received: from 13217 (20458 [53.86.86.54])
	    by 6432 (8.12.1/8.12.1) with ESMTP id 27244
	    for <jik@mit.edu>; Thu, 17 Oct 2002 04:39:00 -0700
  From: "Consult" <wizard_21@360.ru>
  To: "jik@mit.edu" <jik@mit.edu>
  Subject: Компьютеры и комплектующие по САМЫМ низким ценам.
  Date: Thu, 17 Oct 2002 04:39:00 -0700
  Message-ID: <811325562@mlnCplw1hgx>

Note the last Received header.  Both the date and the envelope
recipient listed in it are correct, and the rest of the header is
pretty much formatted correctly; the only tip-off that something
strange is going on is the numeric host names.  But whoever is doing
this got a little smarter pretty quickly.  Here's the last Received:
header from a spam message I receive on November 6:

  Received: from delphi.com (mailexcite.com [85.34.182.181])
	    by aol.com (8.11.6/8.11.6) with ESMTP id 9874
	    for <jik@mit.edu>; Wed, 6 Nov 2002 09:37:38 +0000

Much better, eh?  I've seen various incarnations of this since then
with data that seems at first glance to be correct but does not
withstand closer inspection.

Note that you can't use a simple regular expression match to filter
out all messages with headers in this format, because this is a valid
Received: header format and I've received real non-spam messages that
use it (albeit with data that isn't bogus).

They're getting smarter.  I just hope by bogofilter database can keep
up with them :-).


Bad assumption in automated toll collection

<"Andrew Goodman-Jones" <goodie@ozemail.com.au>>
Thu, 14 Nov 2002 17:09:47 +1100

eTags are (optionally) used in Sydney for automated highway toll collection.

[risk #1 - well known - loss of privacy]

Background:

If the tag does not read electronically, then your licence plate is
photographed.  Before sending out an infringement notice, they lookup your
licence plate on the database of eTag account holders.  In Sydney we have
many different types and colours of licence plates (for fashion reasons) and
the type of plate forms part of the unique key. [risk #2 - makes identity
harder] Motorcyclists are not allowed to have eTags because they haven't
found a secure way to attach them to motorcycles.

My friend Robyn had this experience:

  I have an eTag for my car which I have used on my bike on a number of
  occasions. Once it didn't work when I used it on my bike so I thought
  rather than wait to get a fine I'd ring them. Although they did tell me I
  should not be using it on my bike they said it didn't matter because it
  had come up as a misread on my account and that they had just
  automatically charge my account anyway.

  The interesting thing is that I had not told them that I have a bike!!!

  So how did they know to charge it to my account ???

  Well, the number plate [licence plate] on my car is exactly the same as
  the number plate on my bike (car has black & white plate with 2 letters &
  3 numbers the same as the bike plate but its yellow).

  So basically if you have a number plate on your bike that is the same as a
  car with an eTag you can go through the express lane and it will just get
  charged to someone else's account.  (A bit of a worry if you're the
  account holder.)

  Robyn

[The main risk, #3, their licence plate database apparently does not seem to
include the colour of the plate in the field.]

  [Robbin' Robyn to Pay Pal?  That's Round-Robyn.  PGN]


REVIEW: "Security Engineering", Ross Anderson

<Rob Slade <rslade@sprint.ca>>
Mon, 18 Nov 2002 08:14:55 -0800

BKSECENG.RVW   20021015

"Security Engineering", Ross Anderson, 2001, 0-471-38922-6, U$65.00
%A   Ross Anderson ross.anderson@ieee.org rja14@cam.ac.uk
%C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
%D   2001
%G   0-471-38922-6
%I   John Wiley & Sons, Inc.
%O   U$65.00 416-236-4433 fax: 416-236-4448
%P   612 p.
%T   "Security Engineering: A Guide to Building Dependable Distributed
      Systems"

The preface states that this book is intended as a text for self-study or
for a one term course, a reference for professionals, an introduction to the
underlying concepts, and an original scientific contribution in terms of the
foundational principles for security engineering.  A very tall order to
promise, but one which, for once, seems to have been fulfilled.  I have
often been asked, in regard to these reviews, whether there are, in fact,
any books that I like.  Well, I like this one.  If you are involved with
security and you haven't read it, you should.

Part one deals with the basic concepts of engineering and security.  Chapter
one presents four example situations of security needs.  Protocols are not
limited to the precise but limited structures computer people are familiar
with.  A set of more conceptual, but more formal, authentication problems
and protocols are advanced in chapter two.  It is unlikely that the models
presented exhaust the field, but some thought indicates that they are
applicable to a wide variety of applications.  (Anderson's writing is clear
enough, but he does betray a taste for symbolic logic that might limit the
audience for the book.  Still, perseverence on the part of the reader will
be amply rewarded.)  Much the usual thoughts and advice on passwords is
issued in chapter three, although the research is better documented, and
some additional research (passphrase generated passwords are as secure as
randomly assigned ones, and as memorable as naively chosen ones) is
presented.  It is strange not to see any mention of the work factor of
passwords overall.  Chapter four reviews access control, but primarily from
the perspective of system and hardware internals.  Cryptography, in chapter
five, is covered reliably and well, although Anderson does not work overly
hard to make the material easy to follow.  The problems of distributed
systems are examined; in terms of concurrency, failure resistance, and
naming; in chapter six.

Part two uses a number of applications of secure systems to introduce
particular concepts or technologies.  Chapter seven discusses multi- level
security, which encompasses most of the formal security models such as
Bell-LaPadula.  Medical (and census) databases are used, in chapter eight,
as examples of multilateral, or compartmented, security: the need to deal
with information of equal sensitivity, but restricted to different groups.
There is good discussion of inference and aggregation problems.  Integrity
controls, particularly related to the banking system and fraud, are
presented in chapter nine, although the material is long on anecdotes, and
contains weaker analysis than the preceding text.  Chapter ten reviews
monitoring systems, of both monitoring and metering types.  In regard to
nuclear command and control systems, chapter eleven examines the tension
between availability (the ability to fire a missile) and confidentiality (or
authentication: making sure nobody else does).  Various aspects of the
technology for security printing and seals is dealt with in chapter twelve.
Biometrics, in chapter thirteen, gets a good, but fairly standard,
treatment.  Chapter fourteen delves into tamper-resistance in cryptographic
gear and smartcards.  The TEMPEST and Teapot (no, I'm not kidding) projects
on emission security are reviewed in chapter fifteen.  There is good
coverage of the basics of traditional electronic warfare in chapter sixteen,
although the material on information warfare is not as thorough.  Chapter
seventeen looks at telecommunications system security, with some material on
phone phreaking and lots on cellular encryption.  Network attack and
defense, in chapter eighteen, is less focussed than other chapters, and adds
malware.  (There is an odd, and unexplained, assertion that malware would
formerly have merited a full chapter: In correspondence, Anderson has said
that the new email viruses show less diversity than the old DOS versions.  I
disagree.  But then, I would, wouldn't I?  :-) The relation of types of
antiviral and intrusion detection systems is good.  Chapter nineteen, on
protecting e-commerce systems, has good information but mixed in a bit of a
grab bag: e-commerce is always a bit of a fuzzy topic.  There is solid
coverage of recent controversies in regard to copyright and privacy
protection, in chapter twenty.

Part three turns to politics, management, and assurance.  Chapter twenty one
has a fascinating discussion of major issues in public policy.  Management
issues, in chapter twenty two, are presented in an interesting but generic
manner.  The discussion of system evaluation and assurance asks the usual
question of how we know our systems are secure.  In a sense, though, the
subtitle of the book is wrong: much of the material points out how *not* to
build dependable systems, and chapter twenty three is a bit disheartening.
The conclusion, in chapter twenty four, is that we need more engineers and
engineering.

Although the material is presented in a very formal way, the writing is
usually quite readable, and the exceptional stilted passages are still
accessible to the determined reader.  On occasion, one could hope for
additional explanations of some items that are mentioned briefly and passed
over, but, by and large, one has to agree with Bruce Schneier's assessment,
reprinted on the book jacket, that this is one of the most comprehensive
works on security concepts that is available.  The constant emphasis on how
security protections have failed can be depressing, but the examination of
the errors of others does provide the basis for better designs in the
future.

copyright Robert M. Slade, 2002   BKSECENG.RVW   20021015
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com


REVIEW: "Network Intrusion Detection", Northcutt/Novak/McLachlan

<Rob Slade <rslade@sprint.ca>>
Fri, 15 Nov 2002 07:44:13 -0800

BKNTINDT.RVW   20021009

"Network Intrusion Detection", Stephen Northcutt/Judy Novak/Donald
McLachlan, 2001, 0-7357-1008-2, U$45.00/C$67.95/UK#34.99
%A   Stephen Northcutt stephen@sans.org snorthcutt@hawaiian.net
%A   Judy Novak
%A   Donald McLachlan don_mclachlan@hotmail.com
%C   201 W. 103rd Street, Indianapolis, IN   46290
%D   2001
%G   0-7357-1008-2
%I   Macmillan Computer Publishing (MCP)/New Riders
%O   U$45.00/C$67.95/UK#34.99 800-858-7674 http://www.newriders.com
%P   430 p.
%T   "Network Intrusion Detection: An Analyst's Handbook, Second Ed."

The introduction for the first edition of this work was a bit confusing.
The front matter for the second edition is much more so.  The only item
listed in the table of contents is the introduction, but, while still
stating that the book is intended as a training aid and reference for
intrusion detection analysts, it is much the smallest item of the many at
the beginning of the book.  There is a longish, and not very clear, history
of the "shadow" program.  In addition, there is a preface, which meanders
around presenting opinions about various aspects of the Internet and
security.  It does finally provide a rather interesting definition of
intrusion detection; the purpose is to identify threats and make sure the
network is hardened against them; but does not make clear what the book is
for, or how it approaches the subject.

Chapter one is a basic overview of TCP/IP.  The material is reasonable,
albeit limited, but not exemplary.  TCPdump is examined before TCP itself,
in chapter two.  Again, the content is informative, but there are definite
gaps.  Fragmentation uses, issues, and patterns in TCPdump are presented in
chapter three.  Chapter four does provide some idea of the use of ICMP
(Internet Control Message Protocol), but not a comprehensive or clear one,
and not in the stated introduction.  The coverage of ICMP attacks is neither
particularly lucid nor particularly complete.  It does, however, furnish
some convincing arguments for the use of stateful inspection.

Chapter five presents a few "normal" transactions that you might see in
network traffic, and some that might indicate some type of attack.  The
material is interesting, but is not displayed in a structure that would make
it useful to the reader.  DNS (Domain Name Service) is explained in some
detail in chapter six, although the attack and exploit coverage is terse.
In chapter seven (chapter one, from the first edition), we are given some
details of the TCP hijacking attack Kevin Mitnick launched against computers
used by Tsutomu Shimomura.  In fact we are given rather a lot of details,
and not a little C code, much of which is simply thrown out at us.  The
experienced UNIX network analyst and C programmer will, of course, have no
difficulty with the material, and any reasonably experienced computer user
will likely be able to find references in order to work through the real
implications of the text.  Late in the chapter there is a promise of
explaining how to detect such an intrusion with two different systems: this
promise is not fulfilled.  The concept of filters and signatures is
introduced in chapter eight, although the examples tend to be either system
specific and heavily coded, or overly simplistic.

The initial section of chapter nine attempts to present a means for
determining which events are important enough to record and analyze, and
does not succeed very well.  The latter portion, on considerations for
intrusion detection system (IDS) architecture is much more useful.  Chapter
ten starts out with a look at a variety of attempts at interoperability
between intrusion detection vendors (making me think of the bygone days of
standardized virus signature files: the availability of standards is shown
to be problematic) and then tenders some ideas about suspicious types of
traffic, finishing with a few thoughts on database queries and data
reduction.  A number of IDSes are described in chapter eleven, although the
level of detail, and even the general writeup structure, varies greatly.

Chapter twelve seems to be out of place: the prediction about the future
usually happens at the end of the book.  Exploits, denial of service, and
scan patterns are described in chapters thirteen, fourteen, and fifteen,
repeating some of the material from chapters five and seven.  Although
interesting, not all of the content would be helpful to analysts or IDS
administrators.  Signatures related to the use of RPC (Remote Procedure
Calls) as an attack tool are given in chapter sixteen.  Chapter seventeen
describes various options for filtering traffic for or with TCPdump.  A
"cracking" session, after a system has been penetrated, is presented in
limited detail in chapter eighteen.  In this case we are presented with a
log of UNIX shell commands, and, rather ironically, a great deal more
exegesis than is available in other sections (although the attempts at
humour do confuse the issue, here and elsewhere in the book).  A discussion
of blackhat communities and resources has been added in this edition.  A
"detection" is outlined in chapter nineteen, but with a supremely
anticlimactic ending: the summary admits that no reason for the anomalous
traffic has been found.

Chapter twenty reviews some basic security topics, such as policy
development and risk assessment, but in a very simplistic and terse fashion.
A number of possible responses to an intrusion are outlined in chapter
twenty one.  Chapter twenty two closes with suggestions on ow to make a
business case.

Those who need to know about intrusion detection should probably first look
at Bace's (cf. BKNTRDET.RVW) or Amoroso's (cf. BKINTDET.RVW) books, both
(somewhat annoyingly) titled "Intrusion Detection."  Because of the lack of
structure in the work, this volume is not usable as an overview introduction
to the field, although the examples do contain a great deal of informative
content: if you can dig it out.  For those who do have the basic concepts,
the material does provide numerous practical examples, and some real-life
considerations for implementation.

copyright Robert M. Slade, 1999, 2002   BKNTINDT.RVW   20021009
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

Please report problems with the web pages to the maintainer

Top