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 27 Issue 86

Tuesday 29 April 2014

Contents

Health Care: Website Fails—Oracle Blamed
Stephanie M. Lee
It's Insanely Easy to Hack Hospital Equipment
Henry Baker
Critical Care Medicine: Gorilla my dreams?
UPMC
EHR hazards
from DKross
Mobile payment systems fail to take off with consumers
Brian X. Chen via Monty Solomon
FBI Needs to See *Enemy of the State*
Marc Rotenberg
Global Entry and Company: Worth the Price?
Seth Kugel via Monty Solomon
Remote bicycle brakes
Charles P. Lamb
"5 takeaways from Verizon's 2014 Data Breach Investigations Report"
Roger A. Grimes via Gene Wirchenko
Microsoft injects code into files backed up on their cloud
Mark Thorson
"US CERT and KB 2963983: Don't use drive-by-enabled Internet Explorer"
Woody Leonhard via Gene Wirchenko
Stanford's password policy
David Magda
Re: The sky is falling! Hackers target satellites
Erling Kristiansen
Re: heartbleed
Henry Baker
Dimitri Maziuk
Book: Vulnerability in Technological Cultures
MIT Press
Info on RISKS (comp.risks)

Health Care: Website Fails—Oracle Blamed (Stephanie M. Lee)

"Peter G. Neumann" <neumann@csl.sri.com>
Tue, 29 Apr 2014 15:20:21 PDT
Stephanie M. Lee
Website fails—Oracle blamed
*San Francisco Chronicle* and SFGate.com
Front page of the Business Report: D1, 29 Apr 2014 (PGN-ed)

Oregon embraced the Affordable Care Act early on, and hired Oracle to lead
its state health insurance exchange Cover Oregon.  (The overall project cost
nearly $250 million in federal funds.)  The website "ended up an utter
failure by all measures.  Customers could not sign up without using paper
applications.  Last week Oregon ditched its website, and is switching to the
federal exchange (which will cost another $5 million).

The *Chronicle* article notes that Oracle also received another $50 million
to modernize the Oregon Department of Health Services, allowing online
applications for certain services.

Oregon and Oracle are blaming each other.

“Despite the technical glitches, about 65,000 residents have obtained
private insurance plans through Cover Oregon.''


It's Insanely Easy to Hack Hospital Equipment

Henry Baker <hbaker1@pipeline.com>
Sat, 26 Apr 2014 15:25:08 -0700
   [FYI—"Insane" is the right word...]
      [Long item truncated for RISKS.  PGN]

Kim Zetter, *WiReD*, 25 Apr 2014
http://www.wired.com/2014/04/hospital-equipment-vulnerable/

When Scott Erven was given free rein to roam through all of the medical
equipment used at a large chain of Midwest health care facilities, he knew
he would find security problems—but he wasn't prepared for just how bad
it would be.  In a study spanning two years, Erven and his team found drug
infusion pumps—for delivering morphine drips, chemotherapy and
antibiotics—that can be remotely manipulated to change the dosage doled
out to patients; Bluetooth-enabled defibrillators that can be manipulated to
deliver random shocks to a patient's heart or prevent a medically needed
shock from occurring; X-rays that can be accessed by outsiders lurking on a
hospital's network; temperature settings on refrigerators storing blood and
drugs that can be reset, causing spoilage; and digital medical records that
can be altered to cause physicians to misdiagnose, prescribe the wrong drugs
or administer unwarranted care.

Erven's team also found that, in some cases, they could blue-screen devices
and restart or reboot them to wipe out the configuration settings, allowing
an attacker to take critical equipment down during emergencies or crash all
of the testing equipment in a lab and reset the configuration to factory
settings.  Erven: “Many hospitals are unaware of the high risk associated
with these devices, Even though research has been done to show the risks,
health care organizations haven't taken notice.  They aren't doing the
testing they need to do and need to focus on assessing their risks.''

Erven works as head of information security for Essentia Health, which
operates about 100 facilities—including clinics, hospitals and pharmacies
-- in Minnesota, North Dakota, Wisconsin and Idaho.  Essentia decided to
open its facilities to a full-scale evaluation in 2012, and in a remarkable
and laudable move, allowed Erven to publicly reveal some of his findings.

Erven won't identify specific product brands that are vulnerable because
he's still trying to get some of the problems fixed.  But he said a wide
cross-section of devices shared a handful of common security holes,
including lack of authentication to access or manipulate the equipment; weak
passwords or default and hardcoded vendor passwords like `admin' or
`1234'; and embedded web servers and administrative interfaces that make
it easy to identify and manipulate devices once an attacker finds them on a
network.

Although Erven and his team don't know whether any of these devices are
connected directly to the Internet—they plan a subsequent test to
determine this—many of them are connected to internal networks accessible
via the internet.  Hackers could gain access to the devices by infecting an
employee's computer via a phishing attack, then exploring the internal
network to find vulnerable systems.  A hacker who happens to be in the
hospital could also simply plug his laptop into the network to discover and
attack vulnerable systems.

“There are very few [devices] that are truly firewalled off from the rest
of the organization.  Once you get a foothold into the network, you can scan
and find almost all of these devices, and it's fairly easy to get on these
networks.''

Everything Was Tested, And Most Of It Was Hackable [...]

The Worst Problems [...]

Hospitals Are Unaware of the Dangers [...]

  [Also noted by Matthew Kruk.  PGN]


Critical Care Medicine: Gorilla my dreams?

<UPMC>
Sat, 26 Apr 2014 9:11:15 PDT
  [Per request, the name of the RISKS submitter is omitted here, although
  that person added:
  “UPMC is the biggest employer in Pittsburgh and behaves like a gorilla.''
  PGN]

In the why-care-about-software-assurance, e-health records breaches or legal
compliance file,

University of Pittsburgh Medical School, Critical Care Medicine [has posted]
the following job opening:

  Position Description:

  We're looking for a full-time individual to design, build and maintain
  high-volume, real-time clinical data acquisition systems, including
  developing hardware and software solutions to interface with existing
  hospital systems. Operating within a multidisciplinary research team,
  tasks will additionally involve implementing analytics in the context of
  clinical decision support system.

  Experience:
  - Data modeling
  - Designing high-availability and high-performance systems
  - Documenting and communicating processes and systems
  - Emergency Planning
  - Working under minimal supervision

  3 years of experience in at least some of the above areas; Minimum
  bachelor's degree in relevant fields.

Solo designing with "minimal supervision" a software system to have
privileged interface with other hospital data systems—that doesn't
present any risks!

Note, while this system is to be designed to obtain "real-time clinical
data," which presumably will include some e-personal health records, not a
word is mentioned about credentials in security or privacy engineering or
software assurance.  Do they know of the minimum mandatory Federal software
requirements for e-PHI security and privacy?  Not mentioned here.

Meanwhile, UPMC is facing a class action for thousands of people affected by
a data breach, including several hundred employees whose tax refunds were
fraudulently filed and re-directed post-breach.


EHR hazards (from DKross)

"Peter G. Neumann" <neumann@csl.sri.com>
Sun, 27 Apr 2014 13:24:34 PDT
https://www.ecri.org/Forms/Pages/PSRQ_Top10.aspx?rF=7mkfdys
https://www.ecri.org/EmailResources/PSRQ/Top10/Top10PSRQ.pdf


Mobile payment systems fail to take off with consumers (Brian X. Chen)

Monty Solomon <monty@roscom.com>
Tue, 29 Apr 2014 00:02:05 -0400
Brian X. Chen, *The New York Times*, 28 Apr 2014

SAN FRANCISCO - Millions of Americans use smartphones for tasks like hailing
a taxi or checking in for a flight. But for buying something in a store?
That mostly remains a tech entrepreneur's dream.

For years now, the promise of a mobile wallet - in which paying in person
can be as simple as hitting a button on a phone - has led to a host of US
startups trying to cash in.

Those companies, though, have faced nearly as many hurdles as they have
competitors, including the most basic ones: Many people are not aware of the
new payment systems, others are confused by the many choices, and some see
no benefit in the mobile option over using cash or credit cards.

The hurdles have left all the payment companies scrambling to find the code
for a profitable business model. And now, a feeling is growing that mobile
payments systems will not replace traditional wallets, at least anytime
soon. ...

http://www.bostonglobe.com/business/2014/04/27/mobile-payment-systems-fail-take-off/LTYGTCqyzkZ9dOkmeTNpGN/story.html


FBI Needs to See *Enemy of the State*

Marc Rotenberg <rotenberg@epic.org>
Tue, 29 Apr 2014 17:39:09 -0400
I noted that in the cell phone privacy case today the FBI revealed that they
did not know how to build a decent Tempest tested room.

> MR. DREEBEN: I have anecdotal reports from the F.B.I. that that has
> happened, that they have looked into the question of to what extent can
> you protect a phone through the use of things like Faraday bags. I think
> one of the important things to notice, if you throw a phone into a Faraday
> bag, which is supposedly going to be able to block network signals, when
> you open it up, it has to be similarly shielded or it will pick up a
> signal from a cell tower, and that will wipe the phone. And the
> F.B.I. tried to build a Faraday room in a building that they later
> discovered Verizon had put up a cell tower on it, and that cell tower put
> out a strong enough signal to go right through the Faraday room.

At the very least, someone at the FBI should see the movie *Enemy of the
State* (1998): Gene Hackman managed to construct a perfectly workable
Tempest cage to inspect electronic devices without fear of disruption.


Global Entry and Company: Worth the Price? (Seth Kugel)

Monty Solomon <monty@roscom.com>
Mon, 28 Apr 2014 23:47:37 -0400
Global Entry and Company: Worth the Price?
Seth Kugel, Frugal Traveler, *The New York Times*, 24 Apr 2014

Time versus money - there's no more fundamental trade-off in budget
travel. Nonstop or layover, taxi or public bus? Stand in line for half-price
theater tickets or buy full-price at the click of a mouse?

Airports, you may have noticed, have some lines of their own. Some you can't
avoid - the one forming at Starbucks at 6 a.m., for example - but others,
you can, for a price. In January 2013, I decided to pay $100 for five years
of immigration-line exemption through the government's Global Entry
program. Instead of waiting with the masses, I could plop my passport and
fingerprints onto a fast-working kiosk, and be on my way.

Until I couldn't. In February, I entered the immigration area at Kennedy
Airport, and, with an air of superiority that is the exact opposite of
walking through business class into coach, I left my fellow passengers to
the long lines and waltzed up to the kiosk. As expected, the machine quickly
recognized my fingerprints. But this time it didn't like them nearly as
much. It spit out a notice: My Global Entry membership had been "revoked."
...

  [Trying to determine *why* it was revoked, Seth checked with the JFK
  Global Entry office (“to no avail'') and has been waiting nearly two
  months (“and counting'') for an answer from the `trusted traveler
  ombudsman' of the U.S. Custom and Border Protection.  The article
  continues with Seth doing a detailed comparative analysis of whether it is
  worth the $100 overall.  PGN]

http://www.nytimes.com/2014/04/24/travel/global-entry-and-company-worth-the-price.html


Remote bicycle brakes

"Charles P. Lamb" <CLamb@acm.org>
Fri, 25 Apr 2014 18:10:25 -0400
Here is another poorly thought-out product--a remote bicycle brake. It is
intended for parents to control children's bicycle riding. The idea is to
allow someone to, via a radio signal, apply a brake to a bicycle on remote
command or when the bicycle ventures out of range. Even if it works only as
intended the ability of a rider to control the bicycle by an unexpected
sudden application of the break. But suppose someone other than the
authorized user figures out how to block the don't brake signal to the
bicycle? It could be applied purposefully when the bicycle is in the process
of crossing a busy intersection or other dangerous circumstance or
accidentally by EMI. Surprisingly, the inventor considers this a feature,
"also, as an extra safety measure, *when anything blocks the signal* between
the remote controller and the bike, *the brake is automatically applied*."


"5 takeaways from Verizon's 2014 Data Breach Investigations Report" (Roger A. Grimes)

Gene Wirchenko <genew@telus.net>
Tue, 29 Apr 2014 10:30:52 -0700
Roger A. Grimes | InfoWorld, 29 Apr 2014
If there's one security report you should read every year, this is
it. Trends include rising corporate espionage, more frequent ATM
compromises, and improved hack detection
http://www.infoworld.com/d/security/5-takeaways-verizons-2014-data-breach-investigations-report-241488


Microsoft injects code into files backed up on their cloud

Mark Thorson <eee@sonic.net>
Sat, 26 Apr 2014 16:55:13 -0700
Certain type of files (including .htm, .docx, .xlsx, .php) are injected with
code when restored from Microsoft's cloud.  Doing this without notification
seems like an enormous breach of trust.  Certainly extremely risky.

http://www.myce.com/news/microsoft-onedrive-for-business-modifies-files-as-it-syncs-71168/


"US CERT and KB 2963983: Don't use drive-by-enabled Internet Explorer" (Woody Leonhard)

Gene Wirchenko <genew@telus.net>
Tue, 29 Apr 2014 10:02:42 -0700
Woody Leonhard | InfoWorld, 28 Apr 2014
US CERT and KB 2963983: Don't use drive-by-enabled Internet Explorer
Department of Homeland Security recommends avoiding Microsoft browser
until vulnerability in IE6 to IE11 is fixed
http://www.infoworld.com/t/microsoft-windows/us-cert-and-kb-2963983-dont-use-drive-enabled-internet-explorer-241467


Stanford's password policy

David Magda <dmagda@ee.ryerson.ca>
Fri, 25 Apr 2014 19:18:10 -0400
A new password policy has been released by Stanford that introduces a
"sliding scale" when it comes to complexity and needed 'special characters':

  Students, faculty, and staff can use passwords as short as eight
  characters, but only if they contain a mix of upper- and lower-case
  letters, numbers, and symbols, according to the policy, which was
  published last week on Stanford's IT Services website. […] The standards
  gradually reduce the character complexity requirements when lengths reach
  12, 16, or 20 characters. At the other end of the spectrum, passcodes that
  have a length of 20 or more can contain any character type an end user
  wants, including all lower case.

http://tinyurl.com/lfndwrv
http://arstechnica.com/security/2014/04/stanfords-password-policy-shuns-one-size-fits-all-security/

According to my math, a 20-character all-lowercase password is potentially
more secure (log2(26^20) = 94 bits of information entropy) than a
10-character funny-character password (log2(95^10) = 65.7b).  Even a
14-character all-lower password is slightly better (log2(26^14) = 65.8b).

Stanford's recommendation is at least 16-characters mixed-case
(log2(52^16) = 91.2b).

Now if only all systems actually accepted arbitrary strings.

[Please feel free to correct me--it's been a while since I did log2()s. =) ]

  [Of course, some passcodes in excess of 20 characters may have very
  little entropy for the attacker.  For example, suppose you chose
     To be or not to be, that is the question.
  or
     The quick brown fox jumped over the lazy dog.

  The only question for the attacker might be did you truncate somewhere
  along the way to avoid so much typing?  Combine that with the old TENEX
  timing attack, being able to align passwords across page-fault boundaries
  to iteratively detect the correctness of the nth character, reducing the
  challenge to a linear search, and the attacker can have a linear field
  day.  PGN]


Re: The sky is falling! Hackers target satellites (Grimes, R-27.85)

Erling Kristiansen <erling.kristiansen@xs4all.nl>
Sat, 26 Apr 2014 12:30:46 +0200
The article is not very clear about what exactly is targeted, but it seems
to be services run over communication satellites, not the satellites as
such. If so, the title is rather misleading.

Hacking a satellite-based communication service comes in two flavours:

 1. Hacking ground equipment and/or terrestrial "tail" networks.  This is
    no different in principle from hacking other modems, routers etc. I
    think this is what the article is talking about.

 2. Hacking the radio link. Some systems can be jammed or even spoofed with
    rather simple equipment, and it is true that many systems have little or
    no protection against this. Jamming ( transmitting a high-enough-power
    signal to drown out the legitimate signal), in particular, is quite hard
    to protect against.

Hacking the satellites themselves is a different story. Most satellite
systems are designed such that you need a powerful transmitter and a large
antenna to send commands to the satellite, and you need intimate knowledge
of the satellite and its telecommands to do any real harm. So it is out of
reach of the amateur hacker. But certainly within reach of nation states and
maybe other resourceful organizations.


Re: heartbleed (Maziuk, RISKS-27.85)

Henry Baker <hbaker1@pipeline.com>
Fri, 25 Apr 2014 12:29:16 -0700
You'll have to forgive me for sounding like an old fart, but there hasn't
been any excuse for unpredictable GC performance since 1978, 36 _years_ ago:

List Processing in Real Time on a Serial Computer

http://home.pipeline.com/~hbaker1/RealTimeGC.html
http://home.pipeline.com/~hbaker1/RealTimeGC.ps.gz

Re sockets & other resources: reference counting (properly done) can be both
safe and real-time, so there is once again no excuse for using an unsafe
language.

Unsafe programming isn't a profession, it's a sport—much like sky diving,
rock climbing, motor racing, etc.  It provides lots of fun, thrills &
excitement, but it shouldn't be an insurable risk.


Re: heartbleed (Baker, RISKS-27.86)

Dimitri Maziuk <dmaziuk@bmrb.wisc.edu>
Fri, 25 Apr 2014 15:03:16 -0500
> You'll have to forgive me for sounding like an old fart, but there hasn't
> been any excuse for unpredictable GC performance since 1978, 36 _years_
> ago ...

1. You'll have to forgive me for sounding blunt but tell this to Gosling and
Van Rossum. I get work with tools that are actually available. The best they
do is the upper bound on when, and that's "when the vm terminates". Which in
the case of always-on servers is "never".

> Re sockets & other resources: reference counting (properly done) can be
> both safe and real-time,

2.a. Not universally true: they may exist outside of your reference-counted
sandbox and therefore aren't safe to delete.

2.b. The fundamental problem is
- at line 10 garbage collector decides that an object is garbage, e.g.
its reference counter reaches 0,
- at line 20 garbage collector deletes the object and collects its
resources,
- somewhere in between, say, at line 15. the object's finalizer (they
don't call them destructors) runs and changes the object's reference
count to 1. Or makes it "accessible" if you're using java's multi-level
mark-and-sweep queue.
- At line 30 the whole thing crashes and burns. Or at line 20 the
garbage collector sees the ovbject's not collectable and doesn't delete
it—resulting in the exact memory leak we were trying to prevent in
the first place.

I.e. this is not about gc *performance* even though that is a factor
that isn't helping any (#1). It's about the fact that you can either
have "no dangling pointers" or "place to free up resources" but not both
(#2.b). You're free to choose the less "unsafe" option.

> there is once again no excuse for using an unsafe language

... other than users asking for code that does what they need.


Vulnerability in Technological Cultures (Hommels et al.)

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 28 Apr 2014 14:36:50 PDT
  Anique Hommels, Jessica Messman, and Wiebe E. Bijker (editors)
  Vulnerability in Technological Cultures:
    New Directions in Research and Governanace
  MIT Press, 2014
  xi+382 (+4 pages of other books in Bijker's Inside Technology series)

The back cover says that “The book explores case studies that range from
agricultural practices in India to neonatal intensive care medicine in
Western hospitals; these cases ... illustrate what vulnerability is and
does.  ...  [and] elucidate its ambiguity, context dependence, and
constructed nature.  Finally, the book addresses the implications of these
analyses for the governance of vulnerability, proposing a more reflexive way
of dealing with vulnerability in technological cultures.''

The book has 15 chapters from 23 contributors.  “The contributors argue
that viewing risk in terms of vulnerability offers a novel approach to
understanding the risks and benefits of science and technology.  Such an
approach broadens conventional risk analysis by connecting to issues of
justice, solidarity, and livelihood, and enabling comparisons between the
global north and south.''

Particularly for RISKS readers who think primarily in terms of computers and
their diverse applications, I believe there is much that can be learned from
this book.  It is remarkably holistic (e.g., total-system oriented) and
far-sighted in its treatment of the concepts and the elaborated case
studies.  Even though the words `computer' and `vulnerability' are not
included in the index, there are copious discussions of `trust', `safety',
`security', `reliability', `robustness', `resilience', and even
`interdependencies'.  I have a hunch that many of us will have much to learn
from the collected wisdom contained in this book.  Indeed, there is much
that is directly applicable to computer-related risks.

Please report problems with the web pages to the maintainer

Top