Internet-connected hospital drug pumps vulnerable to remote lethal-dose attacks


#1

[Read the post]


#2

Why would a bedside drug pump need to be on the internet? By all means, have the capability to connect to a net enabled computer to deliver firmware updates when needed, but i can’t fathom why you would think it’s a good idea to have these things online when they are plugged into patients.


#3

It would slightly comforting to be reading this after I’ve finished chemo, but I worry about others.


#4

That is a HUGE assumption. I worked as Director of IT at two different hospital systems. In both cases, the medical equipment network was separated from the general LAN. The medical equipment LAN had no connection to the LAN used by PCs which had an internet gateway. It was connected to a Meditech cluster which did not route traffic between the two. Any attacker would first have to gain control of the Meditech systems running MUMPS on DEC Alpha machines and good luck with that. To even have admin access to that cluster you had to have a dumb terminal directly connected to a terminal port on the cluster.

Some systems may be setup by idiots… who knows? Just not the ones I had to manage.


#5

We’re in a bit of a pickle with IoT devices, and our electronics in general… on one hand we complain loudly when our PC’s BIOS won’t load an unsigned OS, or we can’t record an HDMI video stream, but we also complain when a medication pump is allowed to ba hackable, even if it is by utter negligence by the manufacturer.

The Internet of Things will be dismal if everything is signed and only upgradable by the manufacturer, there will be un-patched security holes galore that really can’t be fixed. In the same way, someone could maliciously hack a more “open” device…

Designers of IoT devices are going to have to get smarter, and really analyze each applicatoin and think about consequences…

In this case the manufacturer should not have allowed the core dosing firmware to be upgradable, in fact if you wanted to be safe the dosing firmware should be on a one-time-programmable device. If you really need it to be internet enabled (for monitoring), then separate that functionality out into a separate module that can report data and status, but cannot affect dosage settings…

If you are having to roll out firmware updates over the internet for an interface this simple, you should hire new firmware programmers…


#6

Yeah, exactly, I used to work at a company that integrated operating rooms (added all the A/V equipment in) and it was very very rare for a hospital to provide internet access, and if they did, it was under extremely controlled conditions.

We had a device that could send diagnostics through the web but we almost never got to set up that feature.


#7

So it sounds like the separation between the boards that makes them unhackable is just like the separation between my computer and my wireless router, which of course means it can’t get a virus.


#8

Don’t these questions come down to who “owns” the device? I have no problem with a Hospital owning a drug pump that I use, just as long as it accepts liability for allowing a malicious third party to control said drug pump.


#9

How much difficult is this from the capability of an adversary coming into the supposedly secure hospital area and twiddling the equipment’s knobs?

It’d be silly to address one rare vulnerability and miss a glaring larger another one.

…also, can the remote control attempt be made obvious on the equipment, enabled with a physical switch (e.g. reed contact in an implanted device, needs a fairly strong magnet)? That itself will reduce the vulnerability a lot.


#10

When are these guys going to wise up? It’s a Global War on White Hats. They will be much better off when they join Project Mayhem.


#11

-Why are so many patients at this hospital insured by a Russian cartel?


#12

In both cases, the medical equipment network was separated from the general LAN.

I’ve unfortunately seen a few hospitals where they don’t segregate their traffic or have weird vendor-required compromises that render the separation useless.


#13

I’d almost want to blame the JCAHO auditor for not catching that.


#14

That’s probably on the list of assassination methods from the top spy agencies.


#15

Do you suppose that some intelligence agency is keeping knowledge of these type of vulnerabilities to itself-- following in the footsteps of the NSA, for instance?


#16

All of them, I’d guess.
Bastards.

Somebody should break into them and spill their techno-secrets into the public domain. Yesterday was too late.

The short period of chaos that will follow will be worth it.


#17

This topic was automatically closed after 5 days. New replies are no longer allowed.