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 26 Issue 10

Saturday 10 July 2010

Contents

Con-Ed Nerve Center Fights to Keep Lights On
Gabe Goldberg
Cal payroll data system cannot be changed to cut all employees' pay
Spinoza
Loophole May Have Aided Theft of Classified Data
Gabe Goldberg
What Does Microsoft Know About You?
Lee Pender via Monty Solomon
NY bank IT tech pleads guilty to data theft, fraud
Robert McMillan via Monty Solomon
To Stop Cheats, Colleges Learn Their Trickery
Trip Gabriel via Monty Solomon
Healthcare data risks
PGN
Bank fishes phishing
Diomidis Spinellis
Apple Acknowledges Flaw in iPhone Signal Meter
Miguel Helft via Monty Solomon
Re: Previous user's data on my "new" GPS device
Thomas Russ
Re: Software auto-updaters
Merlyn Kline
Paul Schreiber
REVIEW: "SSL and TLS: Theory and Practice", Rolf Oppliger
Rob Slade
Re: Jumping the Walrus: When Risk Management Goes Bad
Richard I. Cook
Info on RISKS (comp.risks)

Con-Ed Nerve Center Fights to Keep Lights On

Gabe Goldberg <gabe@gabegold.com>
Thu, 08 Jul 2010 14:33:51 -0400

It's not demonstrating a risk here, but how secure is that Carrier protocol?
Has a third-party evaluated it? Can it do anything besides telling
thermostats to cycle every half hour? Can it be misused?

Con-Ed Nerve Center Fights to Keep Lights On

"In times of unusually high demand for electricity, Con Ed tells Carrier,
the maker of heating and cooling systems, to send a radio signal that causes
those thermostats to cycle on and off every 30 minutes. Doing so shaved
about 25 megawatts off the peak demand this week, Con Ed officials said."

https://www.nytimes.com/2010/07/08/nyregion/08heat.html
or http://tinyurl.com/2e8s69p


Cal payroll data system cannot be changed to cut all employees' pay

spinoza1111 <spinoza1111@yahoo.com>
Sun, 4 Jul 2010 02:08:25 -0700 (PDT)

  http://news.yahoo.com/s/ap/us_california_budget_minimum_wage

Absolutely pathetic. One reason America is in decline: major computer
systems such as California's payroll were designed for computers like the
one I first worked on in 1971: it had 8000 "bytes" of RAM.

The information California needs to change is probably scattered through
"sequential" files such that to find any record, you have to read all the
records before it. And because there was no such thing as data base
technology in the 1950s, the "knowledge" of how to find pieces of data (such
as employee salaries) and interpret their contents (which could be a binary
number, a "binary coded decimal number" or some wack's Own Idea encapsulated
in said wack's code) much less change them, is lost and inside
incomprehensible computer code.

Probably, up to now, you submitted a "change" request to change an
employee's salary, possibly still as a punched card. These change requests
are probably combined or "batched" and then run together once a day or week.

This means you'd have to create a change request for every single employee
to implement Arnold's plan and match every record in a single whopper
run. My guess is that the "change" software, assuming there aren't different
versions for different classes of state employees (a distinct possibility)
is "NP complete", meaning that it is "fast" on modern computers for the
expected number of changes (a couple of orders of magnitude less than the
total file size) but ramps up exponentially for the unexpected case of
"change all employees".

Whereas in developing countries the payroll was automated recently using
best of breed database technology.

Matching two sets of data was rocket science in the 1950s. Today, most
ordinary computer programmers don't know how to do it, but databases
programmed by good programmers do so as fast as possible.

And I really don't want a job cutting state employee pay in sunny California
by reviving my mainframe skills. I will pass this job lead on to some of my
geezer friends.

Remember when you were a hotshot if you could program, and could fund your
California lifestyle with a part time coding job for the state?  Welcome to
the future, hotshot.


Loophole May Have Aided Theft of Classified Data

Gabe Goldberg <gabe@gabegold.com>
Fri, 09 Jul 2010 01:09:30 -0400

The soldier accused of downloading a huge trove of secret data from military
computers in Iraq appears to have exploited a loophole in Defense Department
security to copy thousands of files onto compact discs over a six-month
period. In at least one instance, according to those familiar with the
inquiry, the soldier smuggled highly classified data out of his intelligence
unit on a disc disguised as a music CD by Lady Gaga.

https://www.nytimes.com/2010/07/09/world/09breach.html?hp


What Does Microsoft Know About You? (Lee Pender)

Monty Solomon <monty@roscom.com>
Wed, 30 Jun 2010 23:42:36 -0400

We take a look at all the various sources of data Microsoft collects from
customers, how it stores and uses that data, and how its use of it stacks up
against Google and other competitors.

Lee Pender, *Redmond Magazine*, 1 Jul 2010

Just about every software vendor or Web service collects information about
its users. Some do it with more subtlety than others, but the fact is that
there's hardly an application or Web site that doesn't gather some sort of
intelligence about you every time you use it.  Microsoft, of course, is no
exception. From Windows Activation Technologies (WAT) to Bing, Microsoft
stockpiles information on you even when you don't sign up for services such
as Hotmail. But what does Microsoft know about you?

Actually, a more appropriate question might be: What kind of information
about you can Microsoft see? It could see a lot, but there are some things
that the company chooses not to view or store.  For example, the unpopular
WAT, formerly known as Windows Genuine Advantage, is perhaps the least
intrusive of the Microsoft information-gathering tools. Bing and Hotmail get
a little more personal, but experts and IT professionals say that they're
less worried about Microsoft regarding privacy than they are about some
other high-profile vendors.

What Microsoft Knows

Microsoft starts collecting information on you and your system within
minutes of you starting up a brand-new system. We asked Brendon Lynch,
senior director of privacy strategy at Microsoft, to help us compile a
step-by-step explanation of what Microsoft knows and when it knows it.  The
flow begins when you first start your system, log on to Windows and go
through the WAT validation process. ...
  http://redmondmag.com/Articles/2010/07/01/What-Does-Microsoft-Know-About-You.aspx


NY bank IT tech pleads guilty to data theft, fraud (Robert McMillan)

Monty Solomon <monty@roscom.com>
Sat, 3 Jul 2010 21:05:38 -0400

Robert McMillan, *Business Week*, 2 Jul 2010

A former IT staffer with the Bank of New York Mellon pleaded guilty Thursday
to stealing sensitive information belonging to 2,000 bank employees and then
using that data to steal more than US$1 million from charities. ...

http://www.businessweek.com/idg/2010-07-02/ny-bank-it-tech-pleads-guilty-to-data-theft-fraud.html


To Stop Cheats, Colleges Learn Their Trickery (Trip Gabriel)

Monty Solomon <monty@roscom.com>
Wed, 7 Jul 2010 23:02:18 -0400

Trip Gabriel, *The New York Times*, 5 Jul 2010
https://www.nytimes.com/2010/07/06/education/06cheat.html

The frontier in the battle to defeat student cheating may be here at the
testing center of the University of Central Florida.

* No gum is allowed during an exam: chewing could disguise a student's
speaking into a hands-free cellphone to an accomplice outside.

* The 228 computers that students use are recessed into desk tops so that
anyone trying to photograph the screen - using, say, a pen with a hidden
camera, in order to help a friend who will take the test later - is easy to
spot.

* Scratch paper is allowed - but it is stamped with the date and must be
turned in later.

* When a proctor sees something suspicious, he records the student's real-time
work at the computer and directs an overhead camera to zoom in, and both
sets of images are burned onto a CD for evidence. ...


Healthcare data risks

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 5 Jul 2010 14:13:12 PDT

  [Thanks to Deborah Peel, Founder and Chair, Patient Privacy Rights
  (http://www.patientprivacyrights.org) for these items; starkly PGN-ed]

1. Steve Green, *Lawsuit filed over UMC patient records' leak, *Las Vegas
   Sun*, 3 Jul 2010
  http://www.lasvegassun.com/news/2010/jul/03/lawsuit-filed-over-umc-patient-records-leak/
  University Medical Center in Clark County NV is being sued for leaking
  confidential patient information.  But the hook in the story seems to be
  the way in which patients were informed of the leak: they were offered a
  one-year free subscription to a credit-monitoring system knowledge of
  whose expiration became public,  The *Sun* was also investigating a UMC
  employee who was tipping lawyers off on traffic accident victims.

2. ACLU sues over R.I. Health Information Exchange

  Claiming that not enough has been done to protect the privacy rights of
  patients, the Rhode Island chapter of the American Civil Liberties Union
  (ACLU) filed suit against the R.I. Department of Health (DOH), challenging
  the rules the agency has adopted to implement a centralized database of
  patient healthcare records in the state for its statewide health
  information exchange (HIE).
  http://www.cmio.net/index.php?option=com_articles&view=article&id=22971


Bank fishes phishing

Diomidis Spinellis <dds@aueb.gr>
Sun, 04 Jul 2010 00:19:01 +0300

Earlier today I called my bank's helpdesk to obtain an electronic
certificate that was needed to transfer money to another account.  After
they verified my credentials the customer representative asked me:

* Did you respond to that email we sent you asking for your username and
  password?

Up to that point I was mechanically answering all their questions, but this
one made me pause.  In this forum we often criticize incompetent banks and
silly security procedures, so my first thought was about the cluelessness of
sending out such emails.  However, a second later I realized that *they*
were fishing, trying to find out if *I* had been the victim of a phishing
attack and replied negatively.  I was surprised by the question's
originality and cleverness, so I asked if they were indeed looking for
victims of phishing attacks and they acknowledged that this was their
intention.  Bravo!

Diomidis Spinellis - http://www.spinellis.gr


Apple Acknowledges Flaw in iPhone Signal Meter (Miguel Helft)

Monty Solomon <monty@roscom.com>
Sat, 3 Jul 2010 15:54:07 -0400

Miguel Helft, 2 Jul 2010

Apple customers love to complain about the reception on their iPhones.  And
the problem may be worse than it looks.

Apple said on Friday that for years its phones had been exaggerating signal
strength by displaying too many bars - indicating stronger reception than
there ever was. The problem, Apple said, is a bug in the software, which it
promised to fix soon.

Once it does, it seems, customers will be able to see just how bad reception
really is.

The company said it discovered the problem while trying to explain the
mystery of the disappearing bars on its new iPhone 4, a week after some
users began complaining that when they held the phone a certain way, the
bars indicating signal strength dropped off sharply.  But Apple said the
flaw, which it promised to fix shortly, existed with older versions of the
iPhone, too.

For a company that obsesses over every detail of its products, the failure
to detect this longstanding problem earlier is astonishing.

Some customers say they are skeptical of Apple's explanation of the
vanishing bars. "I don't buy it that it is just a simple matter of the meter
not showing the right amount of signal strength," said Bryan Hurst, of
Hackettstown, N.J., who upgraded last week to an iPhone 4 from an iPhone
3GS. Mr. Hurst said he had had more problems with dropped calls with the new
handset than the old one. "It doesn't make any sense," he said.

But Apple disagrees and says there is plenty to like about the iPhone 4. The
much-vaunted antenna - designed specially for the new phone - works just
fine, the company said. In fact, Apple said, the iPhone 4 is the best ever
on several fronts, including wireless reception. ...

http://www.nytimes.com/2010/07/03/technology/03apple.html


Re: Previous user's data on my "new" GPS device

Thomas Russ <taruss2000@gmail.com>
Tue, 6 Jul 2010 11:55:59 -0700

It seems to me that this is just a high-tech twist on a risk that is
typically already present.  Unless one has taken the precaution of
establishing a separate mailing address for car registration information,
the automobile registration in the glove box of the car will typically
already have your home address on it.  Add in the attached garage and
automatic garage door opener, and the bad guys won't even need to jimmy the
lock.

  [Besides, putting in a bogus address does not help if the historical
  record shows your actual coordinates!  PGN]


Re: Software auto-updaters (Tyson, RISKS-26.09)

Merlyn Kline <merlyn@zynet.net>
Mon, 05 Jul 2010 10:53:33 +0100

> I'd like to see a campaign to change the nature of auto-updaters (such as MS
> Word or Adobe).  [...]

Me too! I see several other problems here:

* The frequency of updates. With only a few common applications (and
  one OS) installed, I sometimes feel there is not ever a time when I'm
  not being nagged for an update.
* The need for reboots. I'm sure that many updates requesting a reboot
  don't (or shouldn't) really need it.
* An interaction between the last two points: many updaters don't
  check for updates until a reboot, which I generally only do if an
  updater has requested it. So one update can lead to another...

It seems to me that at least some of this ought to be in the hands of the
OS. It already needs a secure method of providing updates, which we must
trust. This uses, or could use, sensible protocols to ensure authentic
provenance as well as providing decent UI for update management, including
managing the risks inherent in such updates. If the back end were open to
third parties to add their updates to the stream, this could be all managed
far more effectively. This would still be open to abuse but less so, and
such abuse would be more easily controlled. While it smacks of the single
basket, it is a basket we already must trust.


Re: Software auto-updaters (Tyson, RISKS-26.09)

Paul Schreiber <paulschreiber@gmail.com>
Mon, 5 Jul 2010 12:45:27 -0400

However, when a bug in the application (or operating system) causes your =
program to crash on launch (or crash during updating), you are left with =
an unusable application.

This happened with World of Warcraft for Mac OS X a few years ago.


REVIEW: "SSL and TLS: Theory and Practice", Rolf Oppliger

Rob Slade <rMslade@shaw.ca>
Wed, 7 Jul 2010 16:51:22 -0800

BKSSLTTP.RVW   20091129

"SSL and TLS: Theory and Practice", Rolf Oppliger, 2009,
978-1-59693-447-4
%A   Rolf Oppliger rolf.oppliger@esecurity.ch
%C   685 Canton St., Norwood, MA   02062
%D   2009
%G   978-1-59693-447-4 1-59693-447-6
%I   Artech House/Horizon
%O   617-769-9750 800-225-9977 artech@artech-house.com
%O   http://books.esecurity.ch/ssltls.html
%O  http://www.amazon.com/exec/obidos/ASIN/1596934476/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1596934476/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1596934476/robsladesin03-20
%O   Audience i+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   257 p.
%T   "SSL and TLS: Theory and Practice"

The preface states that the book is intended to update the existing
literature on SSL (Secure Sockets Layer) and TLS (Transport Layer Security),
and to provide a design level understanding of the protocols.  (Oppliger
does not address issues of implementation or specific products.)  The work
assumes a basic understanding of TCP/IP, the Internet standards process, and
cryptography, although some fundamental cryptographic principles are given.

Chapter one is a basic introduction to security and some related concepts.
The author uses the definition of security architecture from RFC 2828 to
provide a useful starting point and analogy.  The five security services
listed in ISO 7498-2 and X.800 (authentication, access control,
confidentiality, integrity, and nonrepudiation) are clearly defined, and the
resultant specific and pervasive security mechanisms are mentioned.  In
chapter two, Oppliger gives a brief overview of a number of cryptologic
terms and concepts, but some (such as steganography) may not be relevant to
examination of the SSL and TLS protocols.  (There is also a slight conflict:
in chapter one, a secure system is defined as one that is proof against a
specific and defined threat, whereas, in chapter two, this is seen as
conditional security.)  The author's commentary is, as in all his works,
clear and insightful, but the cryptographic theory provided does go well
beyond what is required for this topic.

Chapter three, although entitled "Transport Layer Security," is basically a
history of both SSL and TLS.  SSL is examined in terms of the protocols,
structures, and messages, in chapter four.  There is also a quick analysis
of the structural strength of the specification.  Since TLS is derived from
SSL, the material in chapter five concentrates on the differences between
SSL 3.0 and TLS 1.0, and then looks at algorithmic options for TLS 1.1 and
1.2.  DTLS (Datagram Transport Layer Security), for UDP (User Datagram
Protocol), is described briefly in chapter six, and seems to simply add
sequence numbers to UDP, with some additional provision for security cookie
exchanges.  Chapter seven notes the use of SSL for VPN (virtual private
network) tunneling.  Chapter eight reviews some aspects of public key
certificates, but provides little background for full implementation of PKI
(Public Key Infrastructure).  As a finishing touch, chapter nine notes the
sidejacking attacks, concerns about man- in-the-middle (MITM) attacks (quite
germane, at the moment), and notes that we should move from certificate
based PKI to a trust and privilege management infrastructure (PMI).

In relatively few pages, Oppliger has provided background, introduction, and
technical details of the SSL and TLS variants you are likely to encounter.
The material is clear, well structured, and easily accessible.  He has
definitely enhanced the literature. not only of TLS, but also of security in
general.

copyright Robert M. Slade, 2009    BKSSLTTP.RVW   20091129
rslade@vcn.bc.ca     slade@victoria.tc.ca     rslade@computercrime.org
victoria.tc.ca/techrev/rms.htm blog.isc2.org/isc2_blog/slade/index.html
http://blogs.securiteam.com/index.php/archives/author/p1/


Re: Jumping the Walrus: When Risk Management Goes Bad (RISKS-26.09)

"Richard I. Cook" <ri-cook@uchicago.edu>
Sat, 03 Jul 2010 18:16:22 -0500

This subject examined in detail by Lee Clarke in his book "Mission
Improbable: Using Fantasy Documents to Tame Disaster"—which details
Exxon's disaster "plan" for spills around Valdez, Alaska. (University Of
Chicago Press, 2001, ISBN-10: 0226109429).

It is no surprise that companies develop fantasy documents for disaster
management. What is surprising is that regulators and agencies continue to
accept these documents as written.

Please report problems with the web pages to the maintainer

Top