The RISKS Digest
Volume 23 Issue 91

Wednesday, 22nd June 2005

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


New Zealand Outage Shut Down Stock Exchange
Marcus H. Sachs
First no more air maps, next no more road maps?
Dan Jacobson
TSA kept passenger information it promised not to
Libraries Say Yes, Officials Do Quiz Them About Users
Eric Lichtblau from Richard Forno via Dave Farber
Jim Horning
US e-government risks
Al Macintyre
Asian Hackers Blamed for Attacks On U.K., U.S. Computer Networks
Cassell Bryan-Low
CardSystems' noncompliant practice compromises credit information
Eric Dash via Monty Solomon
CardSystems' Systems
Al Macintyre
Hacker accesses files at Equifax
Bob Heuman
Cell Phones Now Playing Role of Wallet
Bruce Meyerson via Monty Solomon
SIM Cards with GPRS
Darryl Smith
New 'Heathrow Connect' Trains - do not want to go to Heathrow!
S Byers
Re: Plane diverts after erroneous hijack alert
Dan Jacobson
REVIEW: "Brute Force", Matt Curtin
Rob Slade
Info on RISKS (comp.risks)

New Zealand Outage Shut Down Stock Exchange

<"Marcus H. Sachs" <>>
Mon, 20 Jun 2005 19:57:49 -0400

A major outage in New Zealand Telecom Corp.'s cable network Monday disrupted
data services, electronic cash transactions, mobile phone, and Internet
services, as well as shutting down the nation's stock exchange for hours
(the third time in the past nine months that data link failures have halted
trading).  Widespread disruption to business and private services was caused
by two cable breaks on its North Island network.  They were repaired by
mid-afternoon Monday--at least five hours after they occurred.  [Internet
service and mobile phones were also out of commission due to two cable
breaks.  MHS]

The outage was caused by two separate incidents, including a fiber cable
break north of the capital, Wellington, and a second cable being cut in
Taranaki province on the west coast of North Island, more than 300
kilometers (188 miles) north of Wellington.  [Source: Associated Press, 20
Jun 2005; PGN-ed]

First no more air maps, next no more road maps?

<Dan Jacobson <>>
Mon, 20 Jun 2005 19:06:46 +0800

The U.S. National Geospatial-Intelligence Agency (NGA) has proposed to
withdraw all aeronautical data and products from public distribution.

TSA kept passenger information it promised not to

<"Peter G. Neumann" <>>
Tue, 21 Jun 2005 11:15:52 PDT

"The Transportation Security Administration has done exactly what Congress
told it not to do — and what it said it wouldn't do."  [Source: Associated
Press item, 20 Jun 2005]

Libraries Say Yes, Officials Do Quiz Them About Users

<Richard Forno <>>
June 20, 2005 4:29:12 PM EDT
  (from article by Eric Lichtblau, via Dave Farber's IP)

Law enforcement officials have made at least 200 formal and informal
inquiries to libraries for information on reading material and other
internal matters since October 2001, according to a new study that adds
grist to the growing debate in Congress over the government's
counterterrorism powers.  In some cases, agents used subpoenas or other
formal demands to obtain information like lists of users checking out a book
on Osama bin Laden.  Other requests were informal — and were sometimes
turned down by librarians who chafed at the notion of turning over such
material, said the American Library Association, which commissioned the
study.  [Source: Eric Lichtblau, *The New York Times*, 20 Jun 2005; PGN-ed]

Dave Farber's IP Archives:


<"Horning, Jim" <>>
Thu, 16 Jun 2005 13:06:52 -0700

There's a recent report by the Center for National Software Studies that
does not seem to have been adequately publicized, and hence has not received
the attention it deserves: "SOFTWARE 2015: A National Software Strategy to
Ensure U.S. Security and Competitiveness"

Risks loom large in the discussion, including
* Risk of critical infrastructure failures
* Risk of sudden and severe economic loss
* Risk of loss of life and limb
* Risk of loss of public confidence
* Risk of loss of our technological edge and leadership

I've posted excerpts from the Executive Summary at both

US e-government risks

<Al Mac <>>
Thu, 16 Jun 2005 08:35:28 -0500

The GAO surveyed what passes for computer security at scores of US
Government agencies, and conducted some tests to see what is needed.  This
investigative arm of the US Congress determined that the fast majority of
US Gov agencies are oblivious to most of the threats, detailing what they
found in a 79 page report
with a 1 page summary

Your pal Al read through the whole story and wrote up a 5 page summary
which you can find in the archives of other discussion groups

Al Macintyre BPCS/400 Computer Janitor

Asian Hackers Blamed for Attacks On U.K., U.S. Computer Networks

<"Peter G. Neumann" <>>
Mon, 20 Jun 2005 17:12:34 PDT

Bid to Steal Valuable Data Targets Corporate Systems, Government Institutions
Article by Cassell Bryan-Low, *The Wall Street Journal*, 20 Jun 2005; PGN-ed]

A U.K.'s National Infrastructure Security Coordination Center (NISCC) report
says unidentified hackers from Asia have been launching a wave of attacks on
government and corporate computer systems in the U.S., Canada, and the
U.K. in an effort to steal sensitive commercially and economically valuable

CardSystems' noncompliant practice compromises credit information

<Monty Solomon <>>
Mon, 20 Jun 2005 01:45:54 -0400
  (Eric Dash)

CardSystems (a Tucson AZ company that handles credit card transactions for
smaller banks and merchants) turns out to have been the source what was
reported as the potential compromise of 40,000,000 credit cards (Visa,
MasterCard, and American Express).  In violation of established procedures,
CardSystems was keeping old transactions online — for research purposes --
with the intent of analyzing incompletely processed transactions.  Something
on the order of of 200,000 cards may be particularly at risk, and 70,000
bogus charges have already been reported.  The CardSystems systems were hit
with a virus that resulted in the capture of the information.  [Source: Lost
Credit Data Improperly Kept, Company Admits, Eric Dash, *The New York
Times*, 20 Jun 2005; PGN-ed]

CardSystems' Systems

<Al Mac <>>
Tue, 21 Jun 2005 04:55:38 -0500

We can figure out what kind of computer system was at CardSystems when they
  (a) placed 40 million credit card transactions at risk of breach
  (b) had 200,000 actually hacked

May 22 they discovered the breach by magic, independently of Master Card
tracing fraud to them, and fixed the problem immediately May 27 they flunked
a Visa security audit, to check whether in fact they had fixed the problem

According to (the recruiting page
for the company), CardSystems has the following types of systems installed:
  Microsoft .NET (and Windows servers)
  Oracle databases

A few years ago CardSystems advertised for a Programmer Analyst in
  Experience in one or more of the following areas:
  C++, Java, Visual Basic reqd.
  E-commerce,  HTML, XML, ASP, MTS, COM, CORBA, UML Windows/NT

A few days before this breach news story hit the fan, CardSystems was
boasting about their great systems.

  CardSystems Solutions Inc. is a leading provider of integrated payment
  solutions to associations, financial institutions, Independent Sales
  Organizations and retail merchants.

  With CardSystems' comprehensive and flexible array of processing services,
  clients can manage the entire payment processing cycle and customize
  services to fit their needs while maintaining complete control of risk,
  dispute resolution and proprietary customer data. CardSystems' intelligent
  enabling technologies include an expert system, neural network and service
  offerings optimized for the card processing industry. CardSystems products
  include traditional terminals, integrated applications and e-payment
  solutions. The company processes payment transactions for more than
  125,000 customer locations.

  Data at risk: Credit Card Account #s, their expiration dates, what brand
  (e.g. Visa), what bank (e.g. MBNA) Names of people on the credit cards the
  3-4 security #s found on back of cards

  Data NOT taken: addresses, phone #s, date of birth, mother's maiden name,
  nationality, gender, social security #s etc. for the names of people on
  the credit cards PIN # where the credit card can be used in an ATM machine

Al Macintyre

Hacker accesses files at Equifax

<RsH <>>
Fri, 17 Jun 2005 21:55:34 -0600

As per CBC news, 17 June 2005, another hack into a sensitive area at one of
Canada's two major credit bureaus:

A computer hacker has accessed the files of about 600 consumers at Equifax
Canada, one of Canada's major credit bureaus.  Most of the files are for
consumers from British Columbia.  Equifax Canada uses data provided by banks
to compile credit records on Canadian consumers. Those records include
personal information such as social insurance numbers, bank account numbers
and up to six years of credit and banking history ...  Equifax said all
affected customers in this latest breach have been contacted. The RCMP is

R.S. (Bob) Heuman, Toronto, ON, Canada, Indep. Computer Security Consulting
Web Site Auditing for Compliance with Standards

Cell Phones Now Playing Role of Wallet (Bruce Meyerson)

<Monty Solomon <>>
Sat, 18 Jun 2005 00:11:34 -0400

With the number of cell phones in the world is reportedly about 1/4 of the
world's population, the next step seems to be incorporating all of your
credit and debit cards into a single wireless multipurpose mobile device.
In Japan, DoCoMo already has 3 million cell-phone subscribers using its
Mobile Wallet.  The next step seems to be the incorporation of checkbooks,
Quicken, PayPal, CheckFree, etc.  [Source: Bruce Meyerson, Associated Press,
17 Jun 2005; PGN-ed]

  Risks??? What risks?

SIM Cards with GPRS

<"Darryl Smith" <>>
Thu, 16 Jun 2005 18:54:04 +1000

I am a GPS tracking consultant - and I usually use GPRS, which is a packet
switched data service built on top of GSM. Unlike AMPS and CDMA, the
personality of each mobile device is stored in a Smart Card called a SIM
card. This stores the local encryption key as well as a serial number that
points to your phone number. It also stores information on the preferred GSM
network to connect to and your phonebook.

If you want to swap phones you just swap SIM cards. This makes upgrading
phones really easy, and also makes it easy to rent a phone in another
country if your phone does not work in that country because it operates on a
different frequency.

One of my clients was issued 80 SIM cards for a project I was doing for
them. The carrier supplied the SIM cards as well as printed documentation
listing the serial number for each card. This serial number is the reference
that translates into a phone number and a billing identifier.

This customer also arranged to have their own VPN set up so that their data
traffic would not pass over the internet but over a private link between the
carrier and customer. The way this is done is by assigning a different APN
or Access Point Name. This APN was specific to this customer, and no-one
else had access to it.

When I was testing the equipment with the SIM cards and the custom APN, the
SIM cards would not work. So I tried it in my GPRS phone - and strangely it
worked using the standard APN. This did not surprise me as the carrier was
notorious for not correctly configuring the APN.

My customer then sent the list of SIM cards to the carrier for them to fix,
attaching the custom APN. This was the same list the carrier had provided to
them, but thanks to business processes it was easiest for my client to
e-mail the carrier the list back. The changed the APN on all 80 cards to the
custom APN, removing GPRS access through the default APN to all cards.

24 hours later I tried the equipment again, and it still did not work. So I
rang my client, and for a joke I told him the serial number of the SIM card,
and asked him if it was on his list. I was rather surprised when he could
find no reference of it. Comparing his list of serial numbers to my list of
serial numbers, we worked out that only 3 out of 80 of the SIM cards were on
his list.

So my client then contacted the carrier. After some discussions, the carrier
then transferred the 77 SIM cards to my client, and presumably restored the
correct APN to the other 77 SIM cards being used by other clients returning
GPRS functionality.

What had happened is that the carrier did not provide the correct SIM Serial
Numbers to my client in the first place. My client assumed that this list
was correct. I did not care what the serial numbers were, but I recorded
them on each piece of equipment anyway, copying the number from the cards
themselves, rather than copying from his list.

Then my client, assuming his list was accurate e-mailed the carrier, and the
carrier assumed that this list was correct. And then changed the SIM cards
to 'Fix Them', breaking many other services at the same time. Management in
the carrier took some time to be convinced that they had not issued the
correct serial numbers to the client - even wanting to speak to me directly
to verify that I physically had these SIM cards in my possession.

Right now my clients GPRS devices seem to be working, but I have no idea
about the 77 SIM cards being used by other clients. This is likely to be a
huge billing nightmare too. Thankfully we only used a few cents worth of
GPRS bandwidth on cards that did not (at the time) belong to my client.

The risk? Don't rely on information that a supplier gives you. Do not rely
on information a customer gives you without cross checking it. Do not rely
on mobile devices for critical purposes if there is any chance that someone
could re-configure your mobile device.

Darryl Smith, VK2TDS, POBox 169 Ingleburn NSW 2565 Australia +61 4 12 929 634

New 'Heathrow Connect' Trains - do not want to go to Heathrow!

<"SB" <>>
16 Jun 2005 05:47:38 -0700

A new electric train service has just started between Heathrow Airport and
Paddington Station in West London, UK. This uses brand new
multi-million-pound trains made by Siemens in Germany/France. They were
specially designed for the British Airports Authority (BAA) and First Great
Western Link (FGWL) who have the main franchise for services out of
Paddington (in West London). The emergency evacuation instructions engraved
on the windows are all in French - somewhat important since there have been
at least three very major fatal crashes on the line.

The trains are highly computerised but not so automated in that they still
need revenue protection officers (ticket inspectors) to check tickets in the
three carriages. They are short trains. The route is a short one but
ordinary tickets and Travel Cards (one day go anywhere 'seasons') are
available - EXCEPT for the one mile link between the last station on the
mainline and Heathrow Airport itself. This is priced at 6 UK pounds, making
it the most expensive train fare in the world for the distance. Fare more
expensive per mile or kilometre than even for Concord. The equivalent bus
fare is a mere one pound 20 pence.

However these multimillions trains have a fault. This doesn't bother regular
travelers on the line well used to the vicissitudes of the alternative
ex-Thames Trains and FGWL services. But it might bother travelers from
overseas. This is that the on-board announcements are computerised.
Unfortunately however the computer controlling them hasn't a clue where the
train is and keeps on announcing that the "next stop is Paddington where the
train terminates," and "please mind the step between the train and the
platform." And "please make sure you take all of your belongings with you
when you leave the train." On the way to Heathrow every next station is
announced as Ealing Broadway (an intermediate stop) even if Ealing Broadway
has long been called at. And other intermediate stations, e.g. Southall, are
announced as being Hanwell or somewhere else.

There is also a problem with the computerised braking system in that at
Hayes and Harlington Station the trains invariable pull up a LONG way from
the entrance. Other trains pull up near the entrance. This means that sans
announcements from station staff passengers have to run after the train in
order to board it.

The trains are soon to be extended to four carriages long. For this they
have to be shipped back to Siemens in Europe. Apparently it is not possible
to do this work in the UK.

And the Risks?

Emergency instructions do need to be in the majority language of the country
in which the trains are designed for.

Computerised announcement systems have been around for a long while,
passengers do need the correct information especially when there is a charge
of 6 pounds if they inadvertently stay on board for the extra very short
trip into Heathrow itself, and staff are there to make sure they pay up.

Adding an extra carriage should not have to entail shipping an entire train
unit back to the manufacturers in a different country.

At least these trains do not have the fault of earlier electric units that
were so computerised that the doors wouldn't open at stations to let
passengers on/off - because the sun had gone behind a cloud and there wasn't
enough power to operate the door release mechanism.

Re: Plane diverts after erroneous hijack alert (Kuenning, R-23.89)

<Dan Jacobson <>>
Sun, 19 Jun 2005 06:12:15 +0800

When making routine code changes, pilots should avoid inadvertent selection
of Codes 7500, 7600 or 7700 thereby causing momentary false alarms at
automated ground facilities. For example, when switching from Code 2700 to
Code 7200, switch first to 2200 then to 7200, NOT to 7700 and then
7200. This procedure applies to nondiscrete Code 7500 and all discrete codes
in the 7600 and 7700 series (i.e. 7600-7677, 7700-7777) which will trigger
special indicators in automated facilities. Only nondiscrete Code 7500 will
be decoded as the hijack code.

REVIEW: "Brute Force", Matt Curtin

<Rob Slade <>>
Thu, 16 Jun 2005 16:06:54 -0800

BKBRTFRC.RVW   20050531

"Brute Force", Matt Curtin, 2005, 0-387-20109-2, U$25.00/C$33.50
%A   Matt Curtin
%C   233 Spring St., New York, NY   10013
%D   2005
%G   0-387-20109-2
%I   Copernicus/Springer-Verlag
%O   U$25.00/C$33.50 800-842-3636, 212-460-1500, fax: +1-212-254-9499
%O   Audience i+ Tech 2 Writing 3 (see revfaq.htm for explanation)
%P   291 p.
%T   "Brute Force: Cracking the Data Encryption Standard"

As the subtitle states, this is the story of the assessment of the strength
(and weakness) of the Data Encryption Standard, particularly as computer
power increased over time.  Specifically, it is the tale of the formation
and development of the DESCHALL operation, one of the forerunners of  It is not just a story, though: Curtin tells the tale from
a specific social and political perspective.  An indication of this position
is given in the forward, where John Gilmore reiterates the somewhat
questionable assertion that DES was "deliberately ... flawed."  Although
this work does not address more technical aspects of cryptography, using
hyperbolic arguments such as this may weaken the overall case of the book in
regard to cryptographic censorship.

There are forty-one very short chapters to the book, the first describing
the particular machine that found the key for the first DESCHALL distributed
cracking attempt.  A brief history and background for cryptography is given
in chapter two.

Chapter three outlines the process of transforming Lucifer into DES.
However, there are numerous errors in the account.  Some are minor.  (The
Data Encryption Standard and the Data Encryption Algorithm are not
equivalent: the algorithm is the engine, while the standard includes
additional functions for real world operations.)  Other problems include
issues such as the fact that the modification of S-boxes (the substitution
function, which the book refers to as permutation) is mentioned, while that
of the P-boxes (permutation) is not.  Most references state that the Lucifer
version finally submitted for DES was 70 bit, rather than 112 bit.  It is
quite misleading to say that a 112 bit key is "fifty-six times" as strong as
a 56 bit key.  The Diffie-Hellman objections to the 56 bit key length are
not given in detail, which makes the arguments hard to assess.  Not all the
dates are given, which sometimes creates difficulty in following the thread.
(In response to a first draft of this review, Curtin has noted that he has
collected a fairly extensive errata for the book, and hopes to correct the
issues in a second edition.)

Chapter four is a rather mixed bag: despite the "Key Length" title, it
touches on various algorithms, cryptanalytic concepts, and other topics.
(There is a seeming confusion of the Vernam cipher with a one-time pad, and
triple DES is generally considered to have an effective 112 or 113 bit key,
rather than 168, due to the meet-in-the- middle attack.)  The author's
personal involvement with cryptology, and analysis of the feasibility of
cracking cryptosystems, is outlined in chapters five through eight,
culminating in a review of the possibilities of distributed computing.  The
technical, social, and political factors involved in creating and operating
the DESCHALL team are discussed in chapters nine to thirty-eight.  (It is
odd that explanations of IP addresses almost always use the non-routable
192.168.x.x range.  Specific IP addresses have a depressing tendency to
change and so non-routable addresses are often used in explanations, but it
seems particularly inappropriate when the subject deals with identification
and location of machines.)  The material is fascinating, instructive, and
even exciting at times.  Interspersed are mentions of legislative debates
and hearings into cryptographic policy during that time.  Two chapters cover
events subsequent to DES Challenge I, while analysis and lessons learned are
reviewed in forty- one.

The density of errors in the early chapters is unfortunate, since it is not
representative of the work as a whole, and yet it may lead readers to
distrust the facts in the book.  In reality, there are significant points to
be made, not only in terms of cryptography and public policy, but also in
regard to distributed computing itself.  The book is certainly useful for
those interested in the issue of brute force attacks against cryptographic
systems, and is an engaging read for anyone into technology.

copyright Robert M. Slade, 2005   BKBRTFRC.RVW   20050531    or

Please report problems with the web pages to the maintainer