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…
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.''
[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]
[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.
https://www.ecri.org/Forms/Pages/PSRQ_Top10.aspx?rF=7mkfdys https://www.ecri.org/EmailResources/PSRQ/Top10/Top10PSRQ.pdf
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
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, 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
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*."
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
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/
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
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]
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.
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.
> 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.
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