The RISKS Digest
Volume 24 Issue 44

Tuesday, 26th September 2006

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…

Contents

German driverless Transrapid maglev train crashes, killing 23
Debora Weber-Wulff
Martin Virtel
Peter B. Ladkin
SCADA Hacks
Al Macintyre
Vancouver Int'l Airport locked down due to software glitch
Karl Klashinsky
TIAA-CREF Payment Delays Because of New Computer System
Peter D. Junger
DVD player, designed for usability?
Daniel P.B. Smith
1,100 Laptops Missing From Commerce Department
Alan Sipress via PGN
Home security system snafu
Ron Garret
RISKS readers as election officials
Peter-Lawrence Montgomery
Ron Rivest's ThreeBallot
PGN
Identities lost in phishing
Gadi Evron
22nd Annual Computer Security Applications Conference
Christoph Schuba
Info on RISKS (comp.risks)

German driverless Transrapid maglev train crashes, killing 23

<Debora Weber-Wulff <D.Weber-Wulff@fhtw-berlin.de>>
Sat, 23 Sep 2006 09:01:57 +0200

On Friday, Sept. 22, 2006, the German magnetic levitation train Transrapid
(running along a 31,8 km long test loop in Emsland) slammed into a
maintenance car on the track while traveling at approx. 200 km/h.

Officials have been quick to assure that this was not a technical error --
although how they can know this before even all of the 23 dead had been
retrieved from the wreckage is an open question.  The cause was quickly put
down to "human failure" — but has not been elaborated on, probably because
Germany was in the process of trying to sell a second Transrapid to China.

Since the test loop is built on 4-meter high stilts and runs through a
wooded area, a maintenence car runs once in the morning to clean off leaves
and twigs that have gathered overnight and have detrimental effects on
magnetic levitation.

The local fire departments did appear to have extra long ladders in order to
reach the track, but cranes were necessary in order to lift the maintenance
car off the flattened front part of the Transrapid train.

The train does not have a driver, who might have noticed something on the
track and hit the brakes. Officials say that it is impossible to detect
something like this, although I know that for rail-bound trains there are
actually detectors that will not signal a train to proceed unless the track
portion ahead is clear. [Perhaps they don't have signals, since only one
train runs on this track?  My speculation - dww]

The train does not offer regular service, but rather takes tourists for a
fast trip. The passengers at the time of the accident are said to have been
workers for a subcontractor.

From the pictures it seems that some sort of slide construction helped
people get out of the (intact) back of the train (the blue things in one of
the pictures).

The Transrapid has been sold as a collision-free system, because it cannot
fall off the track (it wraps around), nothing can cross its path, and two
mag lev trains cannot physically use the same piece of track. The
maintenance car, however, was *not* maglev equipment. So we again have the
case of the system being logically fine if you stay inside the system, but
introducing one piece that is from a different context completely changes
the situation.

Article (in German):
http://www1.ndr.de/ndr_pages_std/0,2570,OID3129340_SPC3131186,00.html
Pictures of the wreck:
http://www1.ndr.de/ndrde_slideshow/0,2964,OID3132196_SIX0,00.html
Diagram of the track loop:
http://www.tagesschau.de/aktuell/meldungen/0,1185,OID5938672_REF1_NAV_BAB,00.html
Pictures (with captions in German) explaining how maglev works:
http://www.spiegel.de/fotostrecke/0,5538,PB64-SUQ9MTYzNTMmbnI9MQ_3_3,00.html

Prof.Dr. Debora Weber-Wulff, FHTW Berlin, FB 4, Treskowallee 8, 10313 Berlin
+49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/

  [Two other reports follow, and provide some diversity of views, although
  I have trimmed some of the duplications.  PGN]


German driverless Transrapid maglev train crashes, killing 23

<"Martin Virtel" <virtel.martin@ftd.de>>
Sat, 23 Sep 2006 11:11:35 +0200

The two workers on the maintenance vehicle saw things coming and jumped,
saving their lives.

The test track, which is used as a technology showcase and transports
curious tourists and potential customers of the technology, had been
approved for driverless operation only last year.

Right now after the accident, engineers assure us that In theory, maglev
technology is the safest transport in the world, because the propulsion is
done by magnets in the rail - two maglev vehicles on the same part of the
track would run in the same direction, so a crash between them is indeed
impossible.

Apparently, nobody thought about non-maglev vehicles on the same track,
although these vehicles stick around for routine maintenance. Which is
really tragic, because railways, a 19th century technology, normally do have
the technology to ensure that only one vehicle is on a given part of the
track, and they used to have drivers on board as a fall-back.

And, of course, unspecified "human error" is cited as the most probable
cause for the accident, the second theory being a disruption of an
unspecified wireless communication system.

http://www.spiegel.de/wissenschaft/mensch/0,1518,438706,00.html

Martin Virtel, Redakteur Forschen & Entwickeln, FINANCIAL TIMES DEUTSCHLAND
Stubbenhuk 3, 20459 Hamburg   +49/40/319 90 469  http://www.ftd.de


German driverless Transrapid maglev train crashes, killing 23

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Sat, 23 Sep 2006 09:06:58 +0200

The International Herald Tribune (IHT) has a story by Mark Landler of the
NYT.  Our local paper, the Neue Westfälische (NW) is running a story from
the Associated Press (AP).

The IHT says it was traveling about 200kph. The NW says about 180kph.

The IHT is reporting 25 dead and 10 seriously injured. The NW is reporting
23 dead and 10 seriously injured.

The IHT says that "The authorities declined to speculate on the cause,
though experts on maglev technology said it appeared to have been caused by
a communications breakdown rather than a flaw in the technology."  The AP
quotes the state lawyer involved saying "it is probably the result of human
error." The AP also says that the state justice department and the operating
company IABG are assuming it is human error.

It astonishes me that some authorities are willing to speculate in public on
the root cause of the crash only a day after it has happened.

The NW said that [my translation] "according to the state legal department,
the Transrapid can only travel [on its test track] when the maintenance
vehicle has left the track. The maintenance workers confirm this by
telephone.  it is open [that is, it has not been determined PBL] why the
train controller gave permission for the train to proceed."

So let me join in, but without speculating. Any collision between two rail
vehicles demonstrates that the means of ensuring that two vehicles are not
in the same place at the same time is inadequate. The reason I can say this
is because it is an analytic statement: a collision happened, therefore the
means of hindering collisions was inadequate.  (The classic example of an
analytic statement is that a bachelor is an unmarried man.)

On a single-vehicle short track, one imagines there are lots of economical
ways of checking that the track is free which do not involve merely
telephone calls. People obviously thought that what they had was
adequate. Turns out it wasn't.  (Remember: this is an analytic statement.)

Peter B. Ladkin, Faculty of Technology, University of Bielefeld, 33594
Bielefeld, Germany Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de


SCADA Hacks

<Al Macintyre <macwheel99@sigecom.net>>
Wed, 13 Sep 2006 23:44:20 -0500

Infoworld interviewed:
* Alan Paller, director of research at the SANS Institute, and
* Eric Byres, director of industrial cyber security at Symantec,
  on some topics of interest to us.

SCADA (supervisory control and data acquisition) systems, essential to the
nation's critical infrastructure, have been hacked.

What's happening today is that terrorists are using cybercrime to get the
money to buy the bombs to blow people up.  They are not using cyberattacks
against physical things.  There have been cases where SCADA systems that run
power plants, were taken over, but the crime was about financial extortion.

SCADA systems are becoming more vulnerable to cyber attack because obscure
operating systems are being replaced with Windows connected to corporate
networks, that are vulnerable to breaches.  The GAO did a great report on
this in 2004. http://www.gao.gov/new.items/d04354.pdf

Then there is the military statement that the Chinese downloaded 10-20
terabytes of sensitive information from NIPRNet.

What the government is doing is producing mountains to reports whose only
function is to gather dust.  The best thing that can be done with them is
pile in front of government buildings as protection against a car bomb.

http://www.infoworld.com/article/06/09/11/37NMmain_1.html


Vancouver Int'l Airport locked down due to software glitch

<Karl Klashinsky <klash@cisco.com>>
Mon, 25 Sep 2006 10:01:42 -0700

On 17 Sep 2006, Vancouver International Airport was locked down for several
hours because a security guard noticed what appeared to be an explosive on
an X-ray screen.  The bag in question could not be located in the screening
area, so the decision was made to re-screen all passengers in the waiting
areas.

The "lock down" procedure also required many flights that had just taken off
to return to Vancouver so that all passengers could be re-screened.

As it turns out, the bag was not found because it did not exist.  The image
seen by the guard was from training software installed on the screening
machine.  The image in question should have appeared only during a training
exercise, according to a spokesperson from Canadian Air Transport Security
Authority (CATSA).  Furthermore:

"They're investigating how that feature of the tool got inadvertently
activated.  And while they're doing that investigation, they've deactivated
the tool itself."

None of the basic facts here will be a surprise to RISKers.  However, one
thought crossing my mind is whether the training software was executed as a
prank, and if so, how (i.e., I have no idea whether it's possible to
interact with the screening machines remotely).  But if a "false positive"
image could be inserted into a live, in-service screening machine, then it's
possible that a "false negative" could also be inserted.

The CBC story shortly after the incident, describing the lock down:

http://www.cbc.ca/canada/british-columbia/story/2006/09/17/vancouver-airport.html

And the recent story describing the cause:

http://www.cbc.ca/canada/british-columbia/story/2006/09/22/bc-airport-screening.html

  [Also noted by Robert Israel, UBC, Vancouver]
http://www.ctv.ca/servlet/ArticleNews/story/CTVNews/20060921/yvr_security_060921/20060921


TIAA-CREF Payment Delays Because of New Computer System

<"Peter D. Junger" <junger@samsara.law.cwru.edu>>
Mon, 25 Sep 2006 14:34:00 -0400

On 6 Sep I faxed the paperwork to TIAA-CREF requesting a withdrawal from my
retirement account expecting that it might take as long as a week before the
money was wired to my account.  It is now 25 Sep and I am still waiting.

I have spoken to several consultants about this problem.  The first just
said that it should not have taken that long and that he would see if he
could get it expedited.  The next consultant was more forthcoming and said
that the delay was caused by the fact that TIAA-CREF was installing a new
computer system.  (I had earlier been told in another context that the old
system was written in COBOL back in the 1960s.)

Later consultants told me that as a University's account is transferred to
the new system, withdrawal applications from retirees from that University
have to be processed manually, rather than by the computer system.  That
strongly suggests that as more and more accounts are transferred to the new
system the delays will get longer and longer.

There apparently has been no public announcement of this problem.  (At least
I found nothing in a Google search.)  When I mentioned this to one of the
consultants, she said that information that there was going to be a
switch-over to a new system was sent to account holders last year, but, when
I pointed out to her that that announcement said nothing about delays, she
said that she did not believe that they had been anticipated.

When I asked what happened to people who couldn't make a mortgage payment or
something like that I was told by one of the consultants that TIAA-CREF was
reimbursing people who had to pay late charges because of the delay.  He
didn't say what they did for people whose credit reports were damaged or
those who lost a deal because they could not come up with a down payment in
time or something like that.

One of consultants also told me that it might be six months before the
switch-over to the new system was complete.

The consultants, who were all very considerate, all said that they had no
contact the people responsible for the actual processing of the withdrawal
applications.

Peter D. Junger, Case Western Reserve University Law School, Cleveland, OH
junger@samsara.law.cwru.edu  http://samsara.law.cwru.edu


DVD player, designed for usability?

<"Daniel P. B. Smith" <usenet2006@dpbsmith.com>>
Mon, 25 Sep 2006 21:06:13 -0400

Look at the button layout on this portable DVD player.

http://www.dpbsmith.com/buttons.jpg

In case it still isn't clear--it sure wasn't clear to me--the northeast
button navigates east; the southeast button navigates south; the southwest
button navigates west; and the northwest button navigates north. The
silkscreened little arrows _next to_ each button are apparently intended to
convey this, and to help you ignore the engraved little arrows in the
buttons themselves.

An awful lot of modern user interface design seems to me to amount to
printing little silkscreened arrows next to buttons that were hopelessly
misplaced to begin with.

  [This of course might reminds us of John Denver's final flight, in which
  he thought he had run out of gas on one tank and tried to switch tanks.
  The lever positions were UP for both tanks off, RIGHT for the left tank,
  and DOWN for the right tank.  PGN]


1,100 Laptops Missing From Commerce Department

<"Peter G. Neumann" <neumann@csl.sri.com>>
Fri, 22 Sep 2006 16:11:04 PDT

More than 1,100 laptop computers have vanished from the Department of
Commerce since 2001, including nearly 250 from the Census Bureau containing
personal information.  This was revealed in response to a request from the
U.S. House Committee on Government Reform, which is surveying 17 federal
departments about such losses.  Of the 10 thus far responding, Commerce is
"by far the most egregious."  This leaves questions about the 7 departments
that have not responded!  [Source: Alan Sipress, *The Washington Post*, 22
Sep 2006; PGN-ed]
http://www.washingtonpost.com/wp-dyn/content/article/2006/09/21/AR2006092101602.html


Home security system snafu

<Ron Garret <ron@flownet.com>>
Sun, 24 Sep 2006 11:26:22 -0700

I swear I am not making this up.

Today I got a call from the company that monitors our home security system.
They said that they had received a trouble report from our system.  But our
panel said everything was hunky-dory.  All the self- tests were normal, and
the sensor in question was operating properly.

This is not the first time this has happened, so I decided to escalate.
Long story short: the only plausible theory that anyone has been able to
come up with is that somewhere in the country another security system has
mistakenly been programmed with our ID code (the ID codes are assigned and
programmed manually) and it is THAT system that is calling in the trouble
reports.  The central monitoring system uses the self-reported ID codes to
identify the system calling in, not caller-id.  Therefore (assuming this
theory is correct) there is no way to know where the system with the
duplicate ID actually is.

I pointed out to them that if this theory is correct then the system with
the duplicate ID code is essentially useless, and that if and when the
owners of that system learn this they may not be too happy about having paid
their monthly fees for essentially no value whatsoever.  If a burglar ever
breaks into that house (wherever it is) it will appear to the monitoring
office that someone has broken into OUR house.  The police will be
dispatched to our house and we'll be charged for a false alarm.  Meanwhile
the real burglars will be happily unmolested in some unknown and unknowable
location.  Furthermore, if a burglar ever breaks into OUR house through the
location corresponding to the (evidently) faulty sensor on the house with
the duplicate ID they might be tempted to write this off as just the faulty
sensor acting up and not call the police.

Even the possibility that such events might result in (it seems to me,
IANAL) easily winnable lawsuits now that the company has been made aware of
the problem has not motivated them to find a solution as far as I can tell.


RISKS readers as election officials (Re: Lesher, RISKS-24.43)

<Peter-Lawrence.Montgomery@cwi.nl>
Fri, 22 Sep 2006 06:48:33 +0200 (MEST)

I'm a mathematician in Microsoft's Cryptography group.  On September 19,
during the Washington State primary, I was a King County (Seattle area)
election judge.  This seemed a good use of my expiring vacation hours.

The pay is about $115 for working about 6 am - 9:30 pm, with a one-hour
lunch break and two 15-minute breaks.  A four-hour pre-election training
session is also reimbursed.  This is more than I've received for equivalent
jury duty.

The polling station where I was assigned is supposed to have 14 workers, but
only 9 had been recruited.  Some of us doubled up to do two precincts.  I
brought a copy of Avi Rubin's report, but most other judges weren't
interested.

For those voting in person, this was the first time they could choose
electronic voting (AVU, Accessible Voting Unit) or paper ballots.  I was
across the room from the (one) AVU but understood you touched the screen to
pick a candidate.  Supposedly it could (slowly) read the ballot aloud in
English or Chinese, for those who are visually disabled.  A printed copy of
your ballot passed under a glass — you had to affirm that the choices
printed there are correct before casting your ballot.

If a voter chose AVU, I (as judge) needed to fill in a form with the voter's
name and precinct information.  Another judge types this precinct
information into the AVU so the voter gets a proper ballot.

Paper ballots could be marked (fill in an oval) and dropped in an Accuvote
machine, which checked for consistency (e.g., don't vote for two candidates
for same office) and tallied the votes.  Before opening the polls, we needed
to check that all tallies were zero.  The end-of-day counts were printed on
the same roll of adding-machine tape.  Ballots with a write-in candidate
automatically went into a separate cannister beneath the Accuvote machine,
so they could be separated at days' end.  The County will recount all paper
ballots by hand in 4% of the polling places.

The Accuvote machine also checked that a political party (Democratic or
Republican) had been declared.  Some voters deliberately declined this, not
voting for partisan offices.  The inspector (= chief judge) had to unlock
the Accuvote machine and tell it to allow this ballot.

Many King County voters vote absentee, and there are plans to go fully
absentee around 2008.  The voter lists supplied To election judges omit
absentee voters.  The precincts at this polling place had a combined 1500 or
so registered non-absentee voters, of which about 250 chose paper ballots
and 30 chose AVU (30% turnout.  I heard those who used the AVU liked it.
There were about 60 absentee ballots dropped off at this polling place.

Occasionally multiple members of a neighborhood would show up together, and
there would be a wait in the line for that precinct.  But delays were short
-- having only nine workers wasn't so bad after all).

My usual polling place is elsewhere, and I could not access it during voting
hours.  I cast a provisional ballot, where my name is outside an envelope
and the ballot inside.  Provisional ballots must be paper.  I was able to
cast a vote on many judges as well as state legislators, US Senator, and a
county tax, but not for US Representative, because my residence is in
another congressional district.  Several voters who walked in, claiming they
had not received their absentee ballot (and were not on our lists), were
allowed to vote provisionally.

At the end of the day, many items to be returned to the county were
delivered by the inspector, who needed an accomplice of the opposite
political party.  There were three bags supplied for these items, but it was
hard to fit everything in.  Some items, such as the privacy booths used by
paper voters, were left behind for the county to pick up later.

King County election procedures came under criticism in 2004-2005, while the
2004 gubernatorial election results were being challenged.  I saw no severe
anomalies Tuesday.  A technician stopped by during the morning, to check
that things were going well.


Ron Rivest's ThreeBallot

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 25 Sep 2006 15:25:01 PDT

If you have not yet seen Ron Rivest's latest offering, this one is essential
reading: a three-part paper ballot that satisfies privacy and integrity
while avoiding vote selling and eschewing cryptography.  Very clever, very
cute.  Cheers!  PGN
  http://theory.csail.mit.edu/~rivest/Rivest-TheThreeBallotVotingSystem.pdf


Identities lost in phishing

<Gadi Evron <ge@linuxbox.org>>
Mon, 18 Sep 2006 06:57:16 -0500 (CDT)

As I often comment, it is funny to me (not really but hold on) when people
scream about this or that organization losing a laptop with 20K
identities. What's 20K?

Obviously that is important, and speaks volumes of corporate security and of
privacy issues. Still, it is insignificant in a laughable fashion when
compared to what's being stolen daily online.

Every day, millions of online identities and website credentials are
lost. Millions. Every day.

This is done through trojan horses which are spread (bots, worm fashion)
among an immense online population.  There are thousands of new variants to
these bots coming out every month dedicated specifically as a targeted
attack on online financial institutions.

These attacks target the financial online sites (banking, eCommerce, etc.)
not by attacking them directly on the macro level, but rather by multiple
micro-level attacks against their users, en-masse.

These trojan horses (bots) are so advanced, the utilize rootkit technology,
and when the user surfs to an HTTPS site, use man-in-the-middle attacks on
the machine itself to steal his or her credentials.

These credentials in turn are sent to the remote attackers for further
processing.

A lot of money is lost this way. This is a world-wide problem, but it is
especially apparent (as the bad guys utilize the data more and more) in, but
not limited to, the UK and Europe.  In the US this is a growing trend, but
it is mostly ignored by the defenders (most are not aware of it) as regular
primitive "e-mail phishing" is still the most apparent threat there. This is
largely due to US banks still mostly using username and password
authentication.

E-mail phishing is important and a large threat, but it is doomed to death
(it will still be here 10 years from now, like Nigerian scams are here
today, but as a specific threat it will diminish into obscurity.

Phishing today should become the root in a tree called Online Financial
Fraud or eFraud. That, friends, is not going away whether in blogs, trojan
horses, e-mail or your cell phone.

These trojan horse attacks, as they are located on the user's machine
itself, are not stopped by 2-factor authentication, etc. There are things
that can be done, but when the security problem is on a remote machine not
under the, say, bank's control, there is not much they can do with their
current confidence risk assessment systems.

There are solutions, but these are to be discussed another time. It is
obvious that one of the biggest problems facing banks, and ESPECIALLY
eCommerce sites (without the physical-space presence) is how to establish
reputation systems that will provide with a technological risk assesment
confidence decision as to how safe it is to work with a remote user.

The web channel is the cheapest and most effective in banking today, and
banks will not want to lose it.

We (Alan Solomon and myself) cover some of the market involving this
technology and how it works in a recent paper we published in the Virus
Bulletin September edition:
http://www.beyondsecurity.com/whitepapers/SolomonEvronSept06.pdf


22nd Annual Computer Security Applications Conference

<ACSAC Distribution Manager <distribution@acsac.org>>
Sat, 23 Sep 2006 16:32:25 -0400

  22nd Annual Computer Security Applications Conference (ACSAC 2006)
            December 11-15, 2006 - Miami Beach, FL
                     http://www.acsac.org

We would like to invite you to attend this year's ACSAC conference in Miami
Beach, FL. We have again created an exciting program organized in three
tracks, featuring invited speakers, peer-reviewed technical papers, case
studies, tutorials, a workshop, a works in progress session, panels, and
plenty opportunity to mingle and network with your colleagues from around
the globe.

The advance program is posted and registration is now open:

   http://www.acsac.org/2006/advance_program.html
   http://www.regmaster.com/conf/acsac2006.html

The deadline for securing the early registration discount and hotel room
discounts is November 13, 2006.

Dr. Christoph Schuba, 2006 ACSAC program chair Christoph.Schuba@GMail.COM

Please report problems with the web pages to the maintainer

x
Top