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 93

Tuesday 7 October 2003

Contents

Walter Cronkite: The New Inquisition
Chuck Messall via Dave Farber
Re: Spam abounds
PGN
California spammin'
NewsScan
Worm FAQ
Stuart Staniford
Jury convicts man in DMCA case
Paul Festa via Monty Solomon
Broward considers dumping $17 million in touch voting machines
Kim Alexander
Diebold voting machines in Volusia County FL
Brent M.P. Beleskey
Identity Denial really exists
Roger Clarke
Difficulties with Census Bureau income data among wealthiest
George Mannes
Fun with stolen credit-card numbers
Jonathan Kamens
Credit cards as ID
Ben Laurie
REVIEW: "Intrusion Detection with Snort", Jack Koziol
Rob Slade
Info on RISKS (comp.risks)

Walter Cronkite: The New Inquisition

<Dave Farber <dave@farber.net>>
Tue, 07 Oct 2003 13:58:43 -0400

  [The last sentence is right on. djf]

From: CMESSALL <CMESSALL@mykotronx.com>

  Walter Cronkite: "...Unfortunately, security and liberty form a zero-sum
  equation. The inevitable trade-off: to increase security is to decrease
  liberty and vice versa.  In the past, such trade-offs have been temporary
  -- for the duration of the crisis of the moment.  But today, we cannot see
  an end to the War on Terrorism, and that forces us to decide how secure we
  have to be and how free we want to be."

Wow, have we already forgotten Ben Franklin's statement: "People who are
willing to trade security for freedom soon find out that they have
neither."?  In all fairness to Walter (who, I would have thought, might have
actually *heard* Ben say those magic words ;-)), the trade-off might be
correct at any given point in time, for the technology that applies at that
instant.  The secret of course is to change the rules (i.e., the technology)
so that we can have more security AND retain our liberty. - Chuck Messall

IP Archives at: http://www.interesting-people.org/archives/interesting-people/


Re: Spam abounds (RISKS-22.92)

<"Peter G. Neumann" <neumann@csl.sri.com>>
Tue, 7 Oct 2003 11:16:28 PDT

Thanks to many of you who responded thoughtfully to my plaintive cries of
Spam-woe.  The simplest approach something that I have been contemplating
for some time is to suggest that, if you want to significantly raise the
probability that your message to RISKS will not be ignored, use the current
string to include in the subject line.  "RISKS" itself in the subject line
is less than ideal, because a surprising number of spams actually include
that.  But for the foreseeable future, to radically improve my well-being
and ability to separate the wheat from the chaff, let's try the string
  notsp:
in the subject line followed by a meaningful subject, or perhaps "notsp"
appended to the subject line (CASE INSENSITIVE).  This pass-string will
remain relatively stable unless it gets abused, in which case I will
announce a phased-in change.  Many thanks for putting up with this
inconvenience.

Other remedies were suggested by RISKS readers (although some of them
are not really suitable for RISKS-types of operations):

  * Greylisting
    <http://projects.puremagic.com/greylisting/>
  * Spambayes
    <http://spambayes.sf.net>
    (following the inspiration of Graham, extensively tested and improved)
  * Indirection to a Web page that has the CURRENT valid address that
    changes as needed, plus procmail filters
  * TMDA anti-spam challenge-response software
    <http://tmda.net>
  * Client-side POPFile proxy (open source, cross-platform)
    <http://popfile.sourceforge.net>
  * Bogofilter and various other filters
  * Just change your e-mail address as often as desired, and notify your
    regular communicators (clearly not applicable for RISKS, which
    graciously receives e-mail from first-time contributors and needs
    the stability of a permanent address).

An important concept in any such approach is that YOU should have flexible
control over it, rather than some third-party who tells you what you should
be willing to accept or reject.  There is no one-size-fits-all.  However,

  * Tripoli is a flexible approach that could help significantly.
    <http://www.pfir.org/tripoli-overview>


California spammin'

<"NewsScan" <newsscan@newsscan.com>>
Thu, 25 Sep 2003 06:31:25 -0700

California's new anti-spam law may face the same fate as a similar law in
Utah earlier this year.  Kevin Johnson of the e-mail marketing company
Digital Impact warns: "Hard-core spam will still come through, but
legitimate companies will be more hesitant to send e-mail"; he also warns
that when companies try to determine whether e-mail recipients live in
California, spammers and advertisers may be forced to learn more about
consumers, thereby reducing privacy.  E-mail marketer Trevor Hughes suggests
that the only answer is national legislation to harmonize spam laws in more
than 30 states.  [*USA Today*, 24 Sep 2003; NewsScan Daily, 25 Sep 2003]
  http://www.usatoday.com/tech/news/2003-09-24-spam_x.htm


Worm FAQ

<Stuart Staniford <stuart@silicondefense.com>>
Mon, 6 Oct 2003 15:34:48 -0700

I just finished a first cut at a FAQ on worms and worm containment (my
obsession for the last couple of years).  It may be of interest to RISKS
readers:
  http://www.NetWorm.org/faq/

Stuart Staniford, President    Tel: 707-445-4355 x 15
Silicon Defense - The Cyberwar Defense Company


Jury convicts man in DMCA case (Paul Festa)

<Monty Solomon <monty@roscom.com>>
Thu, 25 Sep 2003 01:51:39 -0400

Paul Festa, Staff Writer, CNET News.com, 23 Sep 2003

A federal jury has convicted a Florida man of violating the Digital
Millennium Copyright Act, in the first jury-trial conviction under the
controversial law, according to a U.S. attorney's office.  The Los Angeles
jury found 38-year-old Thomas Michael Whitehead guilty on Friday of selling
hardware that could access DirecTV satellite broadcasts without paying for
them, according to the U.S.  attorney's office in Los Angeles.  Whitehead,
who was also known by his computer name "JungleMike," was convicted on one
count of conspiracy, two counts of selling hardware that unlawfully
decrypted the broadcasts, and three counts of violating the DMCA.  With the
six felony convictions, Whitehead faces up to 30 years in federal prison and
fines of as much as $2.75 million. Sentencing is scheduled for Jan. 26,
2004.  ...
  http://news.com.com/2100-1025-5080807.html


Broward considers dumping $17 million in touch voting machines

<Kim Alexander <kimalex@calvoter.org>>
Thu, 25 Sep 2003 08:39:48 -0700

Here's some good news out of Florida.  Broward County is lobbying for
approval of printers for touchscreens, and one of their election officials
expresses regret for purchasing them in the first place.  Here's an excerpt:

The touch-screen machinery accounted for part of the problems in the 2002
elections in Broward.

During the September primary, election workers found more than 1,000 votes
that had not been reported in initial tallies to the state because machines
had not been shut down properly.  And then in the November election,
officials botched the numbers by not including in the tallies ballots cast
by English-speaking early voters.

"Hindsight is 20/20, but I wish we had stayed with optical scan,"
Commissioner Kristin Jacobs said.

  Source: Broward considers dumping $17 million in touch voting machines,
  Scott Wyman, 24 Sep 2003, *South Florida Sun-Sentinel* <Sun-Sentinel.com>

Kim Alexander, President, California Voter Foundation
kimalex@calvoter.org, 916-441-2494, http://www.calvoter.org


Diebold voting machines in Volusia County FL

<"Brent M.P. Beleskey" <voterscoalition@rogers.com>>
Wed, 24 Sep 2003 09:57:44 -0400

ELECTION THEFT 2000! A NEW BOMBSHELL!: A Diebold Voting Machines in Volusia
County, Florida, Tallied a Vote-Count of -16,022. That's NEGATIVE 16,022:
When will this all-important story break out in the US mainstream press?
When will the Democrats confront the issue? What is at stake here is the
future of democracy.

Diebold Internal Support Memos

[The original article to which this post refers was originally published on
29 Nov 2000 in *USA Today* by Philip Meyer. When I did a search for the
article on the www.usatoday.com website I came up with this page which
clearly provides the details of the article and even offers a link to a free
preview of the article. However, when you click on the link, it gives you a
page void of the article. What happened to it? One can only speculate.
Nevertheless, I have obtained the original article.  BMPB]

  [Contact Brent Beleskey <voterscoalition@rogers.com> for the article,  PGN]

A remarkable exchange concerning Diebold's voting machines in Volusia
County, Florida: On January 17, 2001, Lana Hines, a county elections
official sends out an inquiry as to how Al Gore ended up with a vote-count
of -16,022. That's NEGATIVE 16,022 -- which just happens also to have been
the total number of votes cast for various independent and third-party
candidates who also ran.  (It was the largest number of such votes cast in
Volusia County's history.)

Pay close attention to the final entry, from "Tab" (Talbot) Iredale,
Vice President of Research & Development at Global/Diebold:

  ...The error could only occur in one of four ways:

  1.Corrupt memory card. This is the most likely explanation for the problem
  but since I know nothing about the 'second' memory card I have no ability
  to confirm the probability of this.

  2.Invalid read from good memory card. This is unlikely since the
  candidates['] results for the race are not all read at the same time and
  the corruption was limited to a single race.  There is a possib[ili]ty
  that a section of the memory card was bad but since I do not know anything
  more about the 'second' memory card I cannot validate this.

  3.Corruption of memory, whether on the host or Accu-Vote.  Again this is
  unlikely due to the localization of the problem to a single race.

  4.Invalid memory card (i.e., one that should not have been uploaded).
  There is always the possib[i]lity that the 'second memory card' or 'second
  upload' came from an unauthorised source.

And that's only the tip of the iceberg.


Identity Denial really exists

<Roger Clarke <Roger.Clarke@xamax.com.au>>
Sat, 27 Sep 2003 11:17:22 +0800

[Admittedly this is a story from mainlaind China, and stories from there are
often mistranslated linguistically and culturally when they reach English-
language papers.  But it appeared in the quality Hong Kong daily.  It would
seem reasonable to assume that their staff can read the original, and not
make too many mistakes in the translation.]

Woman wins case against in-law for ID cancellation

A 98-year-old woman will be paid damages for psychological injury inflicted
by her daughter-in-law, a Beijing court has ruled.  The *Beijing Daily*
reports that the elderly woman discovered her relative cancelled her
identity registration card seven years ago.  The defendant claims she
cancelled the card to ensure her mother-in-law would not be cremated after
she died.  Cancelling the card made the woman non-existent in the eyes of
the law.

Source: *South China Morning Post*, dateline Beijing, 26 Sep 2003
[They have a closed web-site, so I can't find the URL]

Roger Clarke  http://www.anu.edu.au/people/Roger.Clarke/  +61 2 6288 1472
Xamax Consultancy Pty Ltd, 78 Sidaway St, Chapman ACT 2611 AUSTRALIA


Difficulties with Census Bureau income data among wealthiest

<George Mannes <George.Mannes@thestreet.com>>
Tue, 7 Oct 2003 14:46:24 -0400

The Five Dumbest Things on Wall Street This Week
By George Mannes, Senior Writer, 3 Oct 2003
http://www.thestreet.com/markets/dumbestgm/10117038.html

  [George sent RISKS an excerpt, namely, the FIRST of five dumbest things.
  I had difficulty trying to abridge it for RISKS, and decided to include
  it in its entirety.  See the URL for the other four.  PGN]

1. I Dream of the Gini Index

We at the Five Dumbest Things Research Lab hate to go all anti-academic on
you, but here's a little advice: The next time you see a statistic in the
newspaper, don't believe it. It's wrong.  OK, OK. That's overstating our
case a little. It's not necessarily wrong.  But it's not right, either.

Exhibit A: The 2002 household income figures released last Friday by the
U.S. Census Bureau.

The takeaway from the report, as you may have read in *The Wall Street
Journal*'s Monday account, was that the poverty level rose, but income
inequality didn't, because rich folk's income took a beating, too.

But something further down in the write-up caught our eye. "Difficulties in
recording seven-figure incomes," reported the Journal, might have resulted
in underreported income among the wealthiest Americans.

In other words, the rich may be richer.

That's odd, we thought. People pay a lot of attention to these annual
income-disparity figures. How come no one's getting worked up about
inaccurate data from such a key segment of the surveyed population? This
can't be true.

We called up Edward Welniak, chief of the Census Bureau's income survey, to
check.

Indeed, there are difficulties with high-income data, Welniak told us.

Here's why: Starting with the 1993 numbers, the bureau's staff -- which
interviews a sample of 78,000 households for the income survey either in
person or over the phone -- has been entering people's responses directly
into portable or desktop PCs. As part of the survey, respondents are asked
to report how much money they made the previous year from numerous sources
-- stuff like the job held the longest, interest and dividends.

And here's the catch: In each category, the highest dollar amount one can
enter is $999,999.

So let's say a Census employee had dropped by the $15,000-umbrella-stand-
festooned apartment of ousted Tyco Chairman Dennis Kozlowski in 2001. And
let's say the then-executive wanted to report the $50 million or so in
undisclosed compensation the Securities and Exchange Commission says he
received in 2000.

Well, Kozlowski couldn't have done it. The Census would have recorded his
salary at a mere million bucks.

"The fact that we're not recording the full dollar value is going to
understate the share of income controlled by households at the highest
levels," says Welniak.

But, says Welniak, there's a good reason for capping monetary entries at six
digits: It limits the potential for error. One extra digit at the high end,
and you're talking about, say, a $9 million paycheck instead of a $900,000
payout. Errors at the high end of the income scale have a much larger impact
than errors at the bottom. The increased accuracy introduced by more
possible digits, says Welniak, would be more than offset by the decreased
accuracy from newly enabled errors.

Welniak has even investigated the exact effect of rounding all
multimillion-dollar income sources down to a megabuck. According to his
analysis of numbers from 1999 -- a year for which 26 respondents reported
employment compensation of at least $1 million in at least one category --
data-entry limitations effectively understated income inequality by 1%,
using a standard measure of income distribution known as the Gini Index.

But, given that the error appears to be constant year after year, says
Welniak, "Measuring changes in income inequality from one year to the next
is not going to be affected." In other words, ignore the absolute number and
look at the trend.

Mindful of that, we point out that over the past decade, the Census Bureau's
Gini Index has been creeping upward -- implying increased income
inequality. Starting at 45.4 in 1993, it peaked at 46.6 in 2001 but
retreated to 46.2 last year. (For purposes of comparison, the United Nations
Development Program -- which puts the U.S. at 40.8 -- says Japan is a 24.9
and Brazil is a 60.7.)

In fact, someone has gotten worked up about the low-balled high incomes: the
Center on Budget and Policy Priorities, a D.C.-based research group.  The
CBPP has been complaining about the Census data for years, griping not only
about the $999,999 cap but also about the Bureau's exclusion of capital
gains from household income.

"The census data has useful information," says Isaac Shapiro, a CBPP senior
fellow. "But at the high end, it's not useful."

Based on Congressional Budget Office data, the CBPP says the average
household after-tax income in the top 1% of the population tripled from
$286,000 in 1979 to $863,000 in 2000, while the lowest fifth of the
population saw household income rise a mere $1,100 to $13,700 over the same
time period.

Put that in your Gini Index and smoke it.

George Mannes, 14 Wall Street - 15th Floor / New York, NY  10005
phone: 212-321-5208 / mobile: 646-641-2093
http://find.thestreet.com/cgi-bin/texis/author/?au=A0000332


Fun with stolen credit-card numbers

<Jonathan Kamens <jik@kamens.brookline.ma.us>>
Fri, 5 Sep 2003 11:31:57 -0400

Yesterday, I got an e-mail message from Amazon.com which I am including here
in full (word wrapped and with some details obscured but otherwise
unmodified) because I believe it will be of interest to RISKS readers.
Additional comments from me follow the message.

  X-AMAZON-TRACK: <jik@kamens.brookline.ma.us>
  Date: Thu, 4 Sep 2003 16:01:07 -0700
  From: charge-inquiries@amazon.com
  To: jik@kamens.brookline.ma.us
  Cc: charge-inquiries@amazon.com
  Subject: Your Credit Card Account

  Greetings from Amazon.com.

  We perform routine reviews of orders to protect our customers. During one
  of these reviews we discovered that an account was opened with a card used
  by you on another account.  For your reference the card in question is a
  American Express card with the last five digits of [deleted].

  As it appears the card was used without your authorization, we have closed
  this new account and cancelled any outstanding orders.  If the account is
  indeed yours, we apologize for any inconvenience caused and ask that you
  notify us by replying to this email message as soon as possible.  If the
  card was used without your authorization, we recommend you cancel the card
  immediately by contacting the financial institution that issued the card.
  Unfortunately, if this is the situation, you should know that a charge in
  the amount of $556.94 was processed by us.

  You should review all recent charges made to this card, reporting any
  unauthorized charges, including those mentioned above, to your financial
  institution.  The financial institution, in turn, will send you forms to
  formally dispute the unauthorized charges, the applicable merchants will
  be notified and charged back, and your account subsequently credited.
  Additionally, you may wish to report this matter to the applicable law
  enforcement agency.

  We were able to verify that your card was not compromised from our site.
  Our credit and debit card data is stored on a computer that is not
  connected to the Internet.  When data is received it is sent to a
  dedicated computer via a proprietary one-way interface across a simple
  serial connection.  The information is stored no other place, access to
  the data is restricted and, when accessed, logged.

  Although we are not permitted to provide you with any details about the
  unauthorized use, we will provide this information to any law enforcement
  agency investigating this matter as well as to the financial institution.
  Please don't hesitate to contact us if you have any further questions or
  concerns.

  Sincerely,

  Ben
  Investigation Specialist
  Amazon.com
  http://www.amazon.com
  Earth's Biggest Selection
  =========================

I went to the American Express Web site and checked the unbilled activity on
the card, and, indeed, found a charge of $556.94 to Amazon.com on August 31
which I did not make.  I also found another charge I did not make of over
$500 to Amazon.com on August 27.

I called the telephone number on the back of my card, navigated through
voice-mail for several minutes and then spoke to three representatives.  The
first deactivated my card, issued me a new one, and transferred me to the
customer service department.  The customer service rep transferred me to the
fraud department.  The fraud rep ask me a few questions that were probably
from a script ("Was your card ever out of your possession?" "Did you make
these charges?", etc.).  Then she said that the charges would be removed
from my account and investigated.

Some things here worked very well.  It's good that Amazon caught the bogus
charges relatively quickly and notified me about them.  It's good that
American Express was polite and was able to deactivate my card, issue me a
new one, and remove the bogus charges from my account quickly.

Some things did not work so well.  Why didn't Amazon stop the perpetrators
in real-time from making a purchase using a card already registered to
another account, as opposed to only detecting the situation after the fact?
Since I assume that the fraudulent purchase was shipped to an address other
than mine, why didn't Amazon require additional verification before shipping
over $500 of merchandise to an address other than the card's billing
address?

There are some questions whose answers I do not know, and neither Amazon nor
American Express is telling.  Did the perpetrator use my name?  Did s/he
know my correct billing address?  Did s/he know the security code printed on
the front of the card?  And if the answer to any of these questions is "no,"
why did Amazon allow the charge?  And the biggest question, to which I'll
probably never know the answer, is, how did the perpetrator steal my info?
Even if they catch him/her and find out, it's unlikely that the information
will trickle back to me.

Today I'll be contacting all the credit-reporting agencies to put a fraud
alert on my report and ask them for free copies so that I can verify that
this is merely a case of isolated credit-card number fraud as opposed to
full-scale identity theft.  Who knows, this may be the start of a very bumpy
ride.

Jonathan Kamens


Credit cards as ID

<Ben Laurie <ben@algroup.co.uk>>
Fri, 03 Oct 2003 12:50:21 +0100

About a week ago, our front door was broken down at 3 in the morning.  The
burglars took my wife's handbag from the hall and ran (luckily, it didn't
contain her car keys, because a common strategy is to return in a few hours
and take the car, too).

Today, we received a number of phone contracts. These may or may not have
been paid for with the stolen credit cards [1], but (we are informed) the
credit cards were used for ID.

This got me thinking. My credit cards are often used for ID, too. But they
never check whether the card has been stolen - all they check is that it has
the right name on it.

Now, given that the most common case of this occurring is when I take
internal flights in the UK, I'm suddenly worried. The risk is obvious.

Incidentally, the incidents also show the lack of value of photo ID - at
least one of the contracts requires proof of address, and the only proof in
the handbag was my wife's driving licence. Which has a photo on it.  So I
guess we can add that as a second risk (i.e. relying on photo IDs for fraud
prevention).

[1] Since my wife spent the time waiting for the police cancelling all
her cards, they may not have been used.

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/


REVIEW: "Intrusion Detection with Snort", Jack Koziol

<Rob Slade <rslade@sprint.ca>>
Mon, 6 Oct 2003 21:22:12 -0800

BKINDTSN.RVW   20030901

"Intrusion Detection with Snort", Jack Koziol, 2003, 1-57870-281-X,
U$45.00/C$69.99/UK#32.99
%A   Jack Koziol
%C   201 W. 103rd Street, Indianapolis, IN   46290
%D   2003
%G   1-57870-281-X
%I   Macmillan Computer Publishing (MCP)
%O   U$45.00/C$69.99/UK#32.99 800-858-7674 info@mcp.com
%O  http://www.amazon.com/exec/obidos/ASIN/157870281X/robsladesinterne
    http://www.amazon.co.uk/exec/obidos/ASIN/157870281X/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/157870281X/robsladesin03-20
%P   340 p.
%T   "Intrusion Detection with Snort"

Chapter one is a good introduction to the basics of intrusion detection,
although it is odd that the list of detection methods is missing some
important entries, such as heuristic rule-based and statistical methods.
The background overview of Snort, in chapter two, describes alerts, related
applications, and even has recommendations for sensor net architecture.
Most of the content in regard to the components of Snort, in chapter three,
deals with the preprocessors, and various attack signatures.  Chapter four's
advice about planning for the installation of Snort is broadly based,
addressing policy, architecture, and even incident response, but the
material is quite abstract, and could have benefitted from more practical
examples.  Some of these missing considerations are dealt with in chapter
five, which looks at hardware and operating system factors.  The text
concentrates on server and sensor performance, but also addresses the
network connection.  Directions on building a Snort server under Red Hat
Linux version 7.3 are given in chapter six.  The sensor and console
instructions are provided in chapters seven and eight, respectively.  A few
optional architectures are described in chapter nine.

Chapter ten deals with tuning various rulesets and components in order to
reduce the level of false alarms.  Creating real-time alert systems is
discussed in chapter eleven.  Chapter twelve is a major one, outlining the
creation and modification of rules for filtering and analyzing traffic.
Chapter thirteen is supposed to be about upgrading and maintaining Snort,
but concentrates on ancillary management tools.  Advanced or unusual
configurations of Snort are described in chapter fourteen.

The book is generally lucidly written and easy to study, but it contains
many typographical errors and a great deal of clumsy wording in the text.
Better copy editing word have improved readability, as well as confidence in
the reliability of various commands and settings.  However, the meaning is
usually clear, even if the expression is sometimes jarring.  For those
planning to use Snort, this should be a serviceable introduction.

copyright Robert M. Slade, 2003   BKINDTSN.RVW   20030901
rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

Top