
CVE-2015-3459 – Hospira Lifecare PCA Infusion Pump - aburan28
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3459
======
dlnovell
I worked for Hospira last year on the Plum A+ and 360 infusion pumps but not
the PCA. I'm a little surprised such a blatant security hole wasn't caught,
considering the magnitude of the regulatory environment we worked under. I'd
never worked in that kind of environment before, and I left shortly after a
successfully defended audit of our software development and tracking process
and systems. (Although how successful is the development and tracking process
if a year later this "bug" comes out?) My guess is that because we were beaten
over the head day in and day out focusing on "if this software delivers the
wrong medication the patient is probably going to die", and "if you make a
mistake in the development process and in change tracking we can lose the
ability to make these devices" that the idea of defending against malicious
intent was de-emphasized/overlooked.

~~~
voidlogic
Question unrelated to the stupidity of supporting telnet as protocol on these
devices- Did you guys use formal verification techniques?
[http://en.wikipedia.org/wiki/Formal_verification](http://en.wikipedia.org/wiki/Formal_verification)

~~~
voidlogic
If some one would explain the down-voting to me, I'd love to understand...
honestly

1\. My question was unrelated to the poor decision the OPs former employer
made to use telnet.

2\. Formal verification the the gold standard in correctness often used for
can't fail things like missiles and satellites.

~~~
toyg
Probably your tone. Half your post is you telling them they're stupid, and the
other half is a patronizing link to very well-known concepts (implying they'd
be stupid not to use them, except there are reasons why very few people
actually do). It can read like the average know-it-all post plus gratuitous
insults.

~~~
voidlogic
>Half your post is you telling them they're stupid

No I was saying my question was unrelated to a stupid decision their former
employer made....

>and the other half is a patronizing link to very well-known concepts

The link was NOT for the benefit of the OP to whom I was asking a question, it
was for reader here that might not know what I was referring too in the
question.

~~~
toyg
_> I was saying my question was unrelated to a stupid decision their former
employer made_

"Former employers" don't usually make decisions in a vacuum -- chances are
that engineers were involved at some point, and if it wasn't OP maybe it was a
colleague or even a friend. Engineers are as lazy as anyone else, and telnet
is an easy protocol to support. Also "let's not talk about my opinion of X" is
just a passive-aggressive way of stating your opinion without accepting a
possible critique of it, which in itself is off-putting. If you really didn't
want to talk about the subject, you wouldn't have mentioned it right away. The
only safe use of "let's not talk about X" is as a way to move on _after_ a
topic has been discussed and agreement could not be reached.

 _> The link was NOT for the benefit of the OP to whom I was asking a
question, it was for reader_

that might as well be, but 1) both OP and HN readers will likely be familiar
with the concept and/or can google it themselves, and 2) playing to the peanut
gallery is patronizing in itself.

Note I'm not criticizing your positions, I'm just describing how your tone
might come across as patronizing. And that's more than enough meta for a week,
I think :)

------
teuobk
Here's the bad news: after spending a decade working in the medical device
industry, I can say that security is not always a high priority in medical
device designs.

I don't think the situation is likely to get better until the FDA starts
requiring security audits as a condition of approval -- and for 510(k)s too,
not just for PMAs.

~~~
wyldfire
> I can say that security is not always a high priority in medical device
> designs.

Agreed. But it's because generally it's not (yet?) a problem.

------
smutticus
Is anyone else dissatisfied with the amount of information we get in many sec
bug reports? Almost everytime I read a CVE or other vulnerability I find
myself with more questions than answers. There's so little information given.

Is telnet on by default? Is this device normally plugged into a network, for
how long? How common is this device? Has it been on the market for long?

Without this kind of information it's very difficult to assess risk, or
otherwise form an opinion.

~~~
adt2bt
On the other hand, for potentially significant security holes, answering those
questions would make attacking the devices easy. I imagine more detail will
come out in a postmortem once the affected devices are updated. I may be
overly optimistic, though..

~~~
dyngnosis
I've got a full advisory written up. It is unclear if the vendor will patching
the device. When I get that cleared up I'll have a full advisory for everyone.
In the meantime if you need something answered urgently you can contact me
directly.

------
sspiff
I was thinking this is bad, but this thing is running a 2.4 kernel, so it's
probably just a wired ethernet port on the back of the device. Limited but
dangerous potential here.

Nope, it's a thousands times worse. This devices has WiFi. You don't even need
to plug a cable in the back.

I can't find how the wireless is configured in their manual[1], but they
clearly mention Wireless LAN.

[1]: [http://www.meql.com/Manuals/Abbott-Hospira-PCA-III-Mednet-
Us...](http://www.meql.com/Manuals/Abbott-Hospira-PCA-III-Mednet-User-
Manual.pdf)

------
lifeisstillgood
tl;dr - drug pump has no authentication on telnet port

This is the brochure page for this family of products
([http://www.hospira.com/en/products_and_services/infusion_pum...](http://www.hospira.com/en/products_and_services/infusion_pumps/Lifecare/))
and the one that stands out a mile is

\- Robust wireless capabilities enable remote drug library updates

the product itself (let's assume it's top notch medical hardware, I am afraid
I cannot comment usefully) works fine, and has been battle tested and built by
veterans. But the second they add network access they are hit by a double
whammy ... Actually I have rewritten this three times, and really I can find
no excuse for this. Selling to moronic sysadmins - "hey easy to use web front
end with passwords or even client certs). I can only assume the argument runs
like this

\- if we make it hard to do X over the network, and X does not happen, chances
of someone dying are y%. If we bollox security, then X is sooo easy to do, and
we just save y% of lives.

Now that is "tragedy of the commons" in sheeps clothing, but I can see it may
be the only excuse you have

------
xooxies
This is completely unacceptable. There really should be more pentesting of
medical gear and industrial control systems in general.

~~~
TheLoneWolfling
I'd argue that the very fact that it's physically possible to hack these sort
of devices is a huge red flag.

There shouldn't be pentesting, because there shouldn't be anything to pentest.

Something like a medical device, you keep the outside communication part
airgapped from anything that could cause harm. If that means you have to
duplicate things, then it means you have to duplicate things.

~~~
moyix
Implantable devices typically _have_ to have a wireless interface of some
sort. The alternative is to put a physical port on someone's body, which is a
great way to cause infections.

~~~
TheLoneWolfling
So you have a wireless interface for the non-able-to-kill-you stuff.

But if you're having to change the code of something that's been implanted,
you've _already_ done something horribly wrong.

~~~
mkehrt
For example, I _think_ pacemakers can set the range of acceptable heart rates
by radio. So now, you have to have logic checking that it doesn't get set to
0. But what happens if there's a buffer overflow in that checking?

Edit: here's a paper demonstrating similar attacks: [http://www.secure-
medicine.org/public/publications/icd-study...](http://www.secure-
medicine.org/public/publications/icd-study.pdf)

~~~
TheLoneWolfling
See, that's an example of something that I do not think should be settable via
radio. _Maybe_ inductive or sonic communication.

Alternatively, you have the software check the set range, but the hardware (or
a second non-connected processor) also checks it separately to make sure it's
sane anyways.

------
NamTaf
"Robust wireless capabilities enable remote drug library updates" [1]

What do they mean by 'robust'? You can rely on it to be there whenever you
want to hack someone to death?

[1]
[http://www.hospira.com/en/products_and_services/infusion_pum...](http://www.hospira.com/en/products_and_services/infusion_pumps/Lifecare/)

~~~
abecedarius
I mentally translate 'robust' to 'fancy' \-- the dictionary meaning I grew up
with being so rarely used correctly now.

------
zurn
So is the procurement process in medical organizations so feeble that nobody
notices these, or is there such widespread apathy about this state of affairs
that it all gets ignored, or is there some kind of culture of secrecy that
results in even these life threatening cases to be kept quiet between the
hospital and the equipment salesman?

------
mherdeg
I wonder how long it's going to be before we see state-level actors exploit
these kinds of security holes.

To be sure, there are already a lot of ways to incapacitate or hurt someone.
But abusing software bugs in a person's medical devices might be a less
traceable way to disrupt their activity.

~~~
TheLoneWolfling
Why bother with medical devices? Just lock on their driver-side brakes when
they're on the highway. Bonus: car accidents are common enough that it'd be
unlikely to be noticed.

~~~
flashman
You'll have to be more subtle than that. A crash investigator is going to
notice asymmetric skid patterns and brake disc damage.

~~~
r00fus
For plausible deniability on extrajudicial actions, I thought "drug overdose"
and "murder/suicide" were the preferred means.

That's assuming the agency committing the act doesn't have readily handy
poisons that degrade within hours and are thus untraceable. Combine with car
accident and you have a large mess to uncover, further decreasing likelihood
of discovery.

------
vesinisa
It's essentially a device for automatic delivery of pain killers when the
patient presses a button. Why on earth would such device even require network
connectivity? They advertise "wireless capabilities for remote drug library
update". But "wireless capability" is a whole new engineering domain, and the
manufacturer seems to have failed to even begin to address it properly.

~~~
ryanmarsh
Just because you cannot envision a particular use case does not mean that it
is not a valuable one. Fist off a large hospital will have drugs that are
"formulary", meaning drugs doctors are allowed to prescribe and the in-house
pharmacy fill. These lists need to be updated, imagine you have thousands of
these pumps on premises. Now imagine you also have to do inventory management.
Now imagine you have these pumps wired in with your nurse calling system (for
when infusion is complete or the device is empty).

Edit: usually you pick the drug from a list on the interface when programming
it. I'm not familiar with this pump but I've used many like it.

------
totallynotcool
I don't think we have any of our equipment in the OR networked other than
commo devices; phones, video, et. al. I do know of some dental tools that use
bluetooth to sync drills with a nurses cell so they can change the settings
for the docs but 'hacking' that wouldn't lead to any unrecoverable harm...
unless, of course, you could turn the drill on via blue tooth

------
theskyisfalling
Of all the bad things that can happen to a patient connected to an infusion
pump, being hacked is way way down the list.

------
Zikes
Not that this isn't a nasty security hole, but I should hope that this sort of
equipment is firewalled at least.

~~~
ceejayoz
> Not that this isn't a nasty security hole, but I should hope that this sort
> of equipment is firewalled at least.

Won't do you much good if an attacker makes an open Wifi point with the same
SSID as the hospital's network.

~~~
hueving
>Won't do you much good if an attacker makes an open Wifi point with the same
SSID as the hospital's network.

For that to work the hospital's SSID would have to be open as well. And if
that were the case, faking the SSID would be a complete waste of time because
you could just connect to it yourself.

~~~
zurn
You vastly overestimate the difficulty of spoofing a password-protected wifi
network.

Even without that, acquiring access credentials is hardly rocket science. (eg.
grab one of these pumps or any other wifi device lying around and read the
password over the ethernet/serial port)

~~~
hueving
I don't think you understand how wpa works. It's not like the client just
sends a password. A shared key is mutual authentication. If putting up a
network with a target ssid leaked data, WiFi would be completely broken.

~~~
zurn
[http://www.renderlab.net/projects/WPA-
tables/](http://www.renderlab.net/projects/WPA-tables/)

wifi security is a pretty soft layer of additional security and definitely
should be considered cheaply penetrable for purpouses of defense.

But like I said you can just harvest the PSK off a device without cracking
anything. An unprotected shared secret on all nodes is not very secret at all.

~~~
hueving
A link to some precomputed tables doesn't mean anything. Wpa2 AES CCMP with a
long shared secret is effectively unbreakable. I have not seen any research on
academia or industry that comes close.

Care to share some? If not, please stop spreading misinformation.

------
moe
Was anyone else reminded of that 'Homeland' episode?

