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 24 Issue 28

Thursday 11 May 2006

Contents

The Problem of Test-Induced Failure & the Space Shuttle
Harry Crowther
BA website discloses passenger passport numbers and DoB
Adam Laurie
Open Letter to Google on Privacy
Lauren Weinstein
Fraud in tampering with tamper-proof chip-and-PIN equipment
Nick Rothwell
Re: Triple DES Upgrades May Introduce New ATM Vulnerability
Jim Daley
Bill Cheswick
NYPD deputy inspector caught rigging crime statistics
Ed Ravin
Google Captcha
Mark Johnson
Re: 911 call show wrong address
Ray Arsenault
Bell inadvertently blocks 1-866 numbers
Rod Davison
Re: Scarily Prophetic Ad
John Linwood Griffin
Re: New Private Investigator laws for e-USA
Stanley F. Quayle
In Wake of SAT Errors, Senator Seeks New Rules on College Testing
Karen Arenson via Monty Solomon
Spelling
Richard S. Russell
REVIEW: "Governance Guidebook", Fred Cohen
Rob Slade
Info on RISKS (comp.risks)

The Problem of Test-Induced Failure & the Space Shuttle

<"Harry Crowther" <hdcrowther@comcast.net>>
Sun, 7 May 2006 13:43:42 -0400

  NASA managers decided on Thursday to skip a launch pad test of the shuttle
  Discovery's redesigned fuel tank because of the risk the test itself could
  damage the tank.  The test would have entailed filling the shuttle's fuel
  tank with cryogenic propellants and testing its systems. The fuel tank has
  been the focus of NASA's shuttle safety upgrades since the 2003 Columbia
  accident.  [Source: Irene Klotz, NASA to skip shuttle tank test ahead of
  July launch Reuters, 5 May 2006; PGN-ed]

There must be a better way.  When there's doubt or trouble, skip the test
(!?!).  There may indeed be some practical wisdom in evidence here, but it
doesn't bode well.


BA website discloses passenger passport numbers and DoB

<Adam Laurie <adam.laurie@thebunker.net>>
Wed, 03 May 2006 14:43:53 +0100

In January of this year I reported to British Airways that it was possible
to recover arbitrary passengers' confidential information, including Date Of
Birth and passport details, by simply matching a frequent flier number to a
surname when purchasing a ticket via their website. Since this information
is printed on every boarding pass, any discarded passes can potentially
provide an attacker with the information he needs to access the data via the
website.

The problem exists because of the US Government's requirement for airlines
to provide Advance Passenger Information for all passengers destined for
their shores. It is left to the airlines themselves to administer the data
collection systems, and, therefore, to make their own mistakes in the
security systems that control access to that data.  The more airlines that
implement these systems, the more potential security holes will exist.

Full story here:

   http://www.guardian.co.uk/g2/story/0,,1766138,00.html

Adam Laurie, The Bunker Secure Hosting Ltd., Ash Radar Station, Sandwich, Kent
CT13 0PL UK  http://www.thebunker.net  +44 (0) 1304 814800

  [Joel Baskin also noted
    http://www.guardian.co.uk/idcards/story/0,,1766266,00.html
  PGN]


Open Letter to Google on Privacy

<Lauren Weinstein <lauren@vortex.com>>
Tue, 9 May 2006 15:50:28 -0700 (PDT)

                        An Open Letter to Google:
               Concepts for a Google Privacy Initiative
                           Lauren Weinstein
                              May 9, 2006

	     http://www.vortex.com/google-privacy-initiative

      Preface: The overall situation relating to U.S. and global
      privacy issues is deteriorating rapidly.  Recent Congressional
      moves toward legislating broad, government-mandated data
      retention laws ( http://lauren.vortex.com/archive/000175.html )
      are particularly alarming.  The manners in which we
      collectively choose to address these sorts of issues are
      likely to have drastic impacts not only on our own lives, but
      also broadly on the shape of society, both today and in the
      future.

Greetings. When I was recently invited to speak at Google's Santa Monica
center ( Video at http://lauren.vortex.com/archive/000168.html ), I was
impressed by the quality of the facilities, but even more so by the caliber
of the Google employees I met during my visit.  Google's capabilities are
extraordinary.  While I have been publicly critical of some Google policies,
my concerns have been focused not on Google today, but rather mainly on how
Google's immense data processing, storage, and related infrastructures might
be abused in the future, particularly by outside entities in a position to
force Google's hand despite Google's own best intentions.

As discussed in my talk, I consider Google to be an incredibly important and
admirable resource with vast potential to do good.  But by the same token,
it is largely this very power that increases the risks of serious abuses of
Google capabilities being forced upon the organization, and Google will
likely be unable to mitigate many of these unless it takes major proactive
steps on an immediate and ongoing basis, particularly including
privacy-related efforts.

Increasingly, Internet users are becoming highly sensitized to both
perceived and real risks to their privacy associated with their use of the
Net.  While the real risks we face in this arena are serious enough,
people's confidence (or lack thereof) in products and services will in many
cases be shaped primarily by perceptions, and often significantly less by
the underlying realities.  This highlights the critical fact that to be
truly successful, efforts to reduce privacy risks must not only have genuine
and ongoing positive privacy effects, but also need to be clearly perceived
by users and the broader public to be in place and fully supported as
primary goals of the organizations involved.

Web-based search engines are an obvious current focus of many privacy
concerns, but as more traditional "desktop" applications migrate to tightly
coupled topologies with user data stored on remote servers not under users'
direct local control (e.g. for PC searches, document preparation, e-mail,
etc.), these issues and related potential risks are rapidly spreading across
the entire computer and Internet spectra.

Fears that users' private information may be increasingly subject to
intrusive perusal by law enforcement or other authorities (often with
minimal and/or questionable cause) are further damaging user confidence in
such services, with a range of issues related to data retention being an
important element at the heart of these concerns.  To the extent that
potentially sensitive data is stored for extended periods, particularly in
non-anonymous forms, it is inevitable that outside demands for access to it
-- on ever broader scales -- will be accelerating.  While individual court
cases will of course vary in their results, the court system cannot be
relied upon to always render appropriate decisions regarding such matters,
particularly in today's political and legislative environments.

I believe that Google, by virtue of its Internet industry leadership,
technical and human resources, and corporate culture, is in a unique
position.  Google can demonstrate how world-class privacy protection
policies and technologies can be developed and deployed in ways that enhance
user confidence in current and future Google services -- by proactively
protecting users' private data without interfering with service operations,
innovation, R&D, or the legitimate concerns of law enforcement.  Google
could be the acknowledged global leader in this area, becoming synonymous
with the concept of integrating new and advanced privacy capabilities into
world-class Internet services and products.

Obviously the confidence such efforts would engender in Google's users would
be healthy for Google's bottom line, but more importantly it will provide
genuine and continuing real benefits to the Google user community itself
(i.e. the entire world).  Where non-proprietary information is involved,
further benefits to society could be achieved through making publicly
available (via published papers, conferences, etc.) those aspects of
resulting privacy-related R&D technologies that could be deployed by other
entities to the benefit of the global community.

I recommend that Google establish a team explicitly dedicated to the
development and deployment of privacy-related efforts as outlined above.
Such a team would be tasked with establishing the framework of these
projects in a consistent manner, and ensuring to the greatest extent
practicable that all current and future Google products and services would
be integrated (from the outset when possible) with these privacy
technologies and policies.  The team would need access to other individuals
within both the development and operational aspects of Google, and ideally
would report directly to high-level management.

To be effective, such a team would need to be significantly
interdisciplinary in its makeup and scope, including a variety of skills.
Some of these would include a broad range of CS capabilities (including
specialized mathematical disciplines related to encryption, among many
others).  Experience in dealing with the particular and complex interplay
between technology and societal issues will also be an important component
of such a team.

Google's growing scale and influence suggest that the sorts of privacy
efforts suggested herein could be among the most important non-governmental
privacy-related endeavors for many years to come, and could have vast
positive impacts far into the future not only for Google and its users, but
throughout the commercial, nonprofit, and government sectors.

This document represents a very brief conceptual outline, offered with only
the best interests of both Google and the world at large in mind.  Google
and the broader Internet are at a critical crossroads in many respects, and
I believe that Google has the opportunity to do enormous good by initiating
the types of efforts that I've described.

I would welcome the opportunity to discuss these concepts with you in more
detail and to work with Google toward their realization, as you may deem
appropriate.

Thank you very much for your consideration.

Lauren Weinstein  lauren@pfir.org http://www.pfir.org/lauren +1(818)225-2800
Co-Founder, PFIR People For Internet Responsibility - http://www.pfir.org


Fraud in tampering with tamper-proof chip-and-PIN equipment

<Nick Rothwell <nick@cassiel.com>>
Tue, 2 May 2006 12:29:45 +0100

Something of a breaking story (currently being reported by BBC Radio 4's
"You and Yours" news magazine program, http://www.bbc.co.uk/
radio4/youandyours/). Shell UK have withdrawn chip-and-PIN credit card
payment facilities from 160 of their garages, following incidents of
fraud. Chip-and-PIN has been publicised by the vendors as "safer, faster,
more secure" than signature-based authentication (see the publicity at
http://www.chipandpin.co.uk), although the security of the PIN numbers is
the responsibility of the card holders. (This suggests that any fraud which
occurs puts the onus on the card holder to prove that the PIN number was not
divulged; with the old signature method, the onus is on the retailer to
produce the sales slip.)

In this particular case, it appears that the card terminal devices designed
by Trintech, although tamper-resistant (i.e. will fail to operate if
tampered with), were tampered with to commit the fraud. Trintech are
claiming that their equipment is not at fault, and the issue is one of the
"environment" in which they were installed.

I am hoping that this story will be picked up by the science press, so that
we can learn some of the details.

According to You and Yours, there have been previous incidents of
chip-and-PIN fraud where unscrupulous retailers were able to add items to a
customer's bill after the payment transaction.

nick rothwell -- composition, systems, performance -- http://www.cassiel.com

  [Pete Mellor noted a BBC item on this:
    http://news.bbc.co.uk/go/pr/fr/-/1/hi/england/4980190.stm
  noting that this situation "rather dents the claim that the introduction
  of chip-and-pin would dramatically reduce the level of 'plastic fraud'."
  PGN]


Re: Triple DES Upgrades May Introduce New ATM Vulnerability (R-24.26)

<jdaley@cix.compulink.co.uk (Jim Daley)>
Sun, 7 May 2006 16:11 +0100 (BST)

If it really is only the pin that is being encrypted and it is accompanied
with the account no - then isn't there an even greater risk of the bank's
des keys being considerably more open to attack than in the past?

Effectively you have any number of ciphertext samples each corresponding to
4 digit pins, with repeat pins being easily identified by the account no,
also each ciphertext has a very limited range of equivalent plaintext
(0-9999), and it wouldn't be too difficult to obtain a reasonable quantity
of ciphertext with known plaintext by simply opening accounts in the
compromised bank.


Re: Triple DES Upgrades (Redspin, RISKS-24.26)

<ches@cheswick.com (ches)>
Mon, 1 May 2006 16:27:29 -0400 (EDT)

> In stereotypical and steadfastly arrogant fashion, USA banks are refusing
> to move to chip- and-PIN

I have heard briefings from highly-placed people at both MC and Visa
discussing this.  They are steadfast and firm: chips will not be implemented
in the US credit cards.  There is insufficient justification for the
expense, given the cheap modems and phone system available to retail
outlets.


NYPD deputy inspector caught rigging crime statistics

<Ed Ravin <eravin@panix.com>>
Wed, 10 May 2006 13:21:45 -0400

The *NY Post* reports that an NY City Police Department (NYPD) deputy
inspector was demoted down to captain after NYPD investigators concluded
that he had rigged crime statistics when he was in charge of a Queens
precinct in 2004.  Full story at:

  http://www.nypost.com/news/regionalnews/63480.htm

There have been previous reports of police commanders accused of falsifying
the crime statistics (nicknamed "CompStat") in various ways, as they are
under great pressure to show "good numbers", even if the criminals don't
cooperate by committing less crimes.  But this time there's a twist - the
former inspector is also accused of "infiltrating the department's CompStat
program to increase archived crime numbers for his precinct from before he
arrived there" so that his ratings would look even better!

I'd love to hear the details about how the NYPD's database was altered - but
the Department is rarely that forthcoming with its dirty laundry.  They have
stonewalled every outside investigation of this problem, especially the
Mayor's Commission to Combat Police Corruption, whose chairman quietly
resigned after the NYPD refused to cooperate with the Commission.

Most of the other reports involve rigging the statistics before the data is
entered - felony crimes get "demoted" to lesser categories, and police
discourage reports or "lose the paperwork" so that some crimes don't even
get into the system in the first place.  Even the head of the NYPD
Patrolmen's Benevolent Association, the police officer's union, has
complained about this.

*The Village Voice* published an excellent report that compared the police
numbers with similar statistics from local hospitals, showing suspicious
drops in assaults reported by the NYPD even though hospital admissions for
assault were going up:

http://www.villagevoice.com/news/0544,moses,69552,5.htmlhttp://www.villagevoice.com/news/0544,moses,69552,5.html

The RISK?  The NYPD (and the many police departments worldwide who copy
them) have become such slaves of their CompStat system that they spend their
effort gaming it rather than doing their jobs and actually reducing crime.

[See also my post in RISKS-13.69 describing how the NYPD plays similar
computer games with a performance metric in their 911 dispatch system,
online at http://catless.ncl.ac.uk/Risks/13.69.html#subj7 ]

[Another review of how the NYPD uses technology (including IBM Selectric
typewriters!) is at:
   http://www.baselinemag.com/print_article2/0,1217,a=30781,00.asp
(see the two articles "NYPD Rethinks its Dispatch System" and "The
Disconnected Cop") ]


Google Captcha

<"Mark Johnson" <mhjohnson@gmail.com>>
Wed, 10 May 2006 15:03:15 -0600

Apparently Google has been getting too many "automated" searches on
their main site
  http://www.google.com/
or the personalized page at
  http://www.google.com/ig/
and has added a "captcha" that you must answer prior to getting to the
search page. However, there seem to be some bugs including:
  - repeated prompts for the captcha (about once per hour so far...)
  - a frame with customized content is replaced by a Google error
message that indicates your machine is possibly spyware or virus infected

I find it odd that Google would deploy something that prevents users from
seeing all those advertisements that make money from the company (a side
effect of doing searches). It would be interesting to find out the back
story on this problem and why the "solution" is so broken for users of the
search service.

  [As a follow up, the captcha appears to have been removed after being
  up about four hours.]


Re: 911 call show wrong address

<"Ray Arsenault" <ray.arsenault@gmail.com>>
Fri, 5 May 2006 18:20:58 -0700

I think this is an issue not only with PBX's, but perhaps to a lesser extent
CLEC's as well.  I used to work for a business that had a regular need for
interaction with the City Police.  In Vancouver (BC), if you need the city
Police to attend anywhere, even if it's not a 911-type emergency, the only
way to reach someone who can actually dispatch a car is to call 911.

Thus, I used to call 911 on a semi-regular basis, explain my issue-du-jour
to the operator, and get the usual "We'll wander a car by when we have a
minute, call us back if it escalates.."

But I also got more than my fair share of calls back saying either "We were
at 401 West Georgia, and we can't find your business there..." or they'd
call back a minute or so later and say "Uh, I thought you guys were over at
(location). Our ANI says 401 West Georgia.."

We were using Allstream (formerly AT&T Canada), and I guess that their
business offices in Vancouver were at 401 West Georgia, and so Telus (the
ILEC) had that show up on ANI from thier trunks.  I called Allstream
repeatedly, and they just kept telling me "Well, we have your address as
being (whatever), and so that's what should show up on ANI. There's nothing
we can do about it."


Bell inadvertently blocks 1-866 numbers

<Rod Davison <rod@critsys.com>>
Tue, 9 May 2006 10:02:44 -0400

The 613 area code (Ottawa and eastern Ontario Canada) is moving from seven
digit local calling to 10 digit local calling, a common transition.  The
first stage seemed to work okay with the caller id now showing the ten
digits of local callers' numbers instead of the seven, but this morning, a
new glitch appeared.

There is a local 866 exchange so that the phone number 866-1234 (just made
up) is a local call.  As of this morning, when I tried to dial
1-866-123-4567 I received the message "This is not a long distance call." as
soon as I pressed the "4" in the sequence.  Dialing "866-1234" got me the
message "The mailbox of 866-1234 is full."  I'm not really surprised.

In another several months, when full ten digit calling is required, this
clearly will not occur.  However, until then, one has to wonder about
several issues:

(1) Why did Bell, or whoever else is involved, not test the possible effect
of this change before it was made in the phone system.  It is reasonable to
assume that most 1-866 customers are businesses, which implies that this
could have a a significant impact on those businesses that rely on their
toll free service to receive orders from customers and perform other
business functions.  The liability issue alone should have flagged this
change as one that had to be tested thoroughly.

(2) When attempting to contact Bell about this issue, I received one of two
responses.  Either the Bell operator placed the call for me without
listening to why I was calling, or they wanted me to schedule a service
call.  Finally after a number of attempts, someone at Bell repair finally
"got it" and decided to relay my report to their supervisor.  When someone
reports unusual system behavior (and reports they observed it on several
different phone lines) it should raise some sort of red flag.

Rod Davison, Critical Knowledge Systems Inc. (613) 834-7018 rod@critsys.com


<John Linwood Griffin <griffin2@ece.cmu.edu>>
Tue, 2 May 2006 14:59:01 -0400 (EDT)

For those like me who would like to know more about where a link goes before
clicking on it, this is the ACLU Pizza flash animation.  Also, for those
like me who had trouble accessing adcritic's web site, you may go straight
to the source: http://aclu.org/pizza/


Re: New Private Investigator laws for e-USA

<"Stanley F. Quayle" <stan-at-stanq-dot-com>>
Thu, 04 May 2006 19:11:37 -0400

> Some computer professionals will need to get a Private Investigator license
> just to continue doing their computer work.

The Ohio law requires this already:

  The business of private investigation is [...] determine the cause of or
  responsibility for [...] damage to property, or to secure evidence for use
  in any legislative, administrative, or judicial investigation or
  proceeding.

> I imagine this will also apply to accountants and auditors

The law exempts, among other groups, lawyers and accountants.

> We will have to be asking suppliers of firewall, anti-virus, anti-spam,
> anti-spyware etc. if they have a PI license

Ohio law also exempts licensed professional engineers.  Ask your supplier if
they employ professional engineers -- after all, your software should follow
sound engineering principles.

My signature line includes "P.E.", which stands for Professional Engineer.
Now I know why I got my license...

The Ohio private investigator FAQ:

http://www.homelandsecurity.ohio.gov/PISG_information/Classes_Licensure.htm

Stanley F. Quayle, P.E. N8SQ 8572 North Spring Ct., Pickerington, OH 43147
Quayle Consulting Inc.  http://www.stanq.com/charon-vax.html 1-888-I-LUV-VAX


In Wake of SAT Errors, Senator Seeks New Rules on College Testing

<Monty Solomon <monty@roscom.com>>
Wed, 3 May 2006 01:14:16 -0400

In Wake of SAT Errors, Senator Seeks New Rules on College Testing

[Source: Karen W. Arenson, *The New York Times*, 3 May 2006; PGN-ed]

NY State Senator Kenneth P. LaValle, chairman of the State Senate's higher
education committee, said he would push for stricter government oversight of
the college admissions testing industry, including a requirement that all
questions and answers be disclosed after the exams without charge.


Spelling

<"Richard S. Russell" <RichardSRussell@tds.net>>
Tue, 2 May 2006 15:15:37 -0500

Several of your recent correspondents seem to need this reminder:

"Lead" (pron. "leed") is present tense; "led" (pron. "ledd") is past
tense; "lead" (pron. "ledd") is a heavy gray metal.

Just to confuse things:

"Read" (pron. "reed") is present tense; "read" (pron. "redd") is past
tense; "red" (pron. "redd") is a color; "Redd" (pron. "redd") is a
guard for the Milwaukee Bucks.

Spell checkers will only flag the last item.

Richard S. Russell http://richardsrussell.livejournal.com/ 608+233-5640

  [NOTE: RISKS cannot be responsible for such errors.  Your moderator
  already fixes many typos, but cannot begin to attempt to overcome the
  growing general lack of attention to writing correctness.  PGN]


REVIEW: "Governance Guidebook", Fred Cohen

<Rob Slade <rMslade@shaw.ca>>
Tue, 09 May 2006 11:53:57 -0800

BKCISOGG.RVW   20051119

"Governance Guidebook", Fred Cohen, 2005, 1-878109-34-0
%A   Fred Cohen http://all.net
%D   2005
%G   1-878109-34-0
%I   ASP Press
%O  http://www.amazon.com/exec/obidos/ASIN/1878109340/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1878109340/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1878109340/robsladesin03-20
%O   Audience a+ Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   204 p.
%T   "Governance Guidebook"

The very short section one of the Governance Guidebook explains that it is
intended for the CISO (Chief Information Security Officer) of a large
concern.  Which is to say that the reader should be experienced in security
and the management thereof.  At that point one wonders what such a work
would entail: presumably such a person would already know pretty much
anything you could put into a book.  This introduction then goes on to
detail the organization of the guidebook.  Section two is an overview of the
structure of a security plan or protection strategy.  It also notes that the
illustrations in this section of the text are very busy and cluttered, but
that careful study will make the situation clearer.

All of this is true.  This is definitely not your standard security
textbook.  It is extremely demanding of the reader, but will amply repay the
effort put into using the volume.  And I say "using," rather than merely
"reading": this is a tome that requires application.  Bed- time reading it
is not.

This is not a primer to be read quickly in one sitting.  The illustrations
are dense, and so is the text, but dense with meaning and import.  This is a
work to be worked through, a page or even a paragraph at a time.  And then,
when you are finished, work through it again.  If you are a CISO it won't
teach you anything--but it will remind you of things, practices, and
procedures that have possibly been forgotten in the press of other
urgencies.  This volume becomes, therefore, an aide memoire for the
strategic planning of information protection.

This is not to say that there are no details provided.  Section three,
entitled "Drill Down," provides greater depth to a number of the areas (one
example is an intriguing use of the human life span to address personnel and
human resources issues).  The content does not deal with specific technical
areas of security, but does provide a very solid overview of security
management--or, if you prefer, governance.

This is a handy and useful guide for those in the CISO position.  It is
destined to become well-thumbed, dirty, and dog-eared, over time.  Those who
are not yet into a CISO job will not recognize all of the value in its
pages, yet.  However, those who aspire to the calling would do well to get a
start on learning from it.

copyright Robert M. Slade, 2005   BKCISOGG.RVW   20051119
rslade@vcn.bc.ca     slade@victoria.tc.ca     rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm

Please report problems with the web pages to the maintainer

Top