Hacking these medical pumps is as easy as copying a booby-trapped file over the network Two security vulnerabilities in medical workstations can exploited by scumbags to hijack the devices and connected infusion pumps, potentially causing harm to patients, the US government revealed today. The flaws, CVE-2019-10959, rated critical (specifically, 10 out 10 in severity), and CVE-2019-10962, rated medium (7.5), were …
At least the latest firmware is not subject to this particular threat, apparently.
How to upgrade something that is embedded in a person's body is something else though, and given that I already fear upgrading my motherboard firmware*, I shudder to think of me having one of those things inside me that needs upgrading.
* : somehow I never can bring myself to trust those things - I always fear that, after the update, the board just dies and never starts up again
Not sure how prevalent it is but my motherboard has "dual BIOS" . When you update, it only installs over one of the BIOS, keeping the other untouched as a backup. If the installation fails/results in a corrupted installation, it falls back to the second BIOS so you can still successfully boot and try again.
... who in the fuck thinks that critical care medical equipment like infusion and syringe pumps need network connectivity in the first place? This kind of equipment is monitored IN REAL TIME BY HUMANS, 24/7! That's what "critical care" means, for gawd/ess's sake! A network connection is completely and utterly meaningless in this kind of situation ... unless you're a marketing "genius", of course.
You think nurses are in the room with the patient 24x7? They need some sort of connectivity back to the desk at minimum so the duty nurses can monitor stuff, check alarms and so forth.
I don't see any reason why they need a full network connection though. What's wrong with serial, or some other protocol that doesn't involve a full networking stack?
We do have a properly secured network with VPN and SMB is blocked where appropriate. I'm not saying we're perfect but we do better than most of the banks I previously worked for (I'm not in the network team but sit next to them).
However, we do read the data off these devices and store it centrally. Doctors may then review the data to look for patterns in the data which may indicate the effectiveness of a particular treatment.
I agree however that there's no need to allow write access over the network. While it could be convenient to update over the network it's just not worth the risk.
"Reading remote sensors..."
I would much rather the device push out any data that's read than be responsive to any manner of polling, lest a DoS situation be created. And, remote control of a device should only be possible with very, very strong justification--if at all, and then hardened to the nines.
Can we get a security standard that actually enforces such things, please? Or, is this one of those things that government spooks want for assassination opportunities?
You have obviously never had a catheter stuck in your arm. Sometimes, they hurt like hell and when you are in a drugged up haze your natural reaction is to pull them out. They can even fall out when you roll over if you have previously been tugging at the sticky tape first. Sometimes the nurse punctures the otherside of the intended vein and the injected fluid wells up inside your body. This is why the nurse has to come and check. Just having a pump saying that X milliliters of drug have left its output orifice is no guarantee that they have arrived in the appropriate vein.
They have connectivity back to the desk in the form of a longitudinal pressure wave notification device-not to over-simplify but in layman's terms, broadly, a,"beep." When these,"beeps," emanate from a patient room the healthcare provider is expected to direct their innate optical scanning devices ("eyes") at the patient.
I know it sounds absurdly complicated but somehow, believe it or not, it works.
I am a nurse and we have many devices that are network connected, mainly to allow data from the various devices and monitors to be automatically populated into the patient electronic record.
They also serve to parrot alarms from the bedside device to the central station monitoring computer so we can ignore them from the comfort of the nice chairs rather than the small bed side stools....
Well, it seems at least some of this kit is at least 13 years old and bearing in mind how long medical approval and certification takes (and costs, not to mention possible re-certification for patched systems), it was probably designed and developed in a much more naive world. In the modern world, they should still be pretty safe because the suggested mitigations are that the medical establishment should already be a pretty secure network with critical stuff vlanned off with even more internal security like firewalls.
Bit then we don't live in a perfect world where hospitals have unlimited network security budgets.
In my experience a lot of medical kit is designed by medical bods with very little understanding of IT. They see a problem and devise a solution based on their limited knowledge. Hospitals then buy it because the medical bods speak the same language and it's very hard for hospital IT to object as we tend to get overridden and the department in question holds the budget so we have to live with whatever gets dumped in our laps.
>In my experience a lot of medical kit is designed by medical bods with very little understanding of IT.
That also happens in IT: I as the design authority specify the use of iPads supported by a WiFi infrastructure, leaving the details of getting iOS and bonjour working in an enterprise environment to the 'experts' - who naturally curse the idiot who thought using iPads in the enterprise was a good idea...
...and bearing in mind how long medical approval and certification takes (and costs, not to mention possible re-certification for patched systems)...
I realise that it's a hot topic (for those in the niche. Hello people!), not liked by many manufacturers, but I dare to say that's why it maybe isn't a bad thing that, with the now new incoming Medical Device Regulation (2017/745), stuff becomes much more tight. For a start, software in medical devices is no longer regarded as an insignificant cog to make stuff work, but a medical device on itself with all the bells, whistles, obligations, and attention it deserves. Also, manufacturers are now forced to follow up on their devices (thus software) in practice, do continuous risk management, evaluation, and trend reporting and evaluation. As said, many don't like it; it means more hassle for them, more cost, more transparency, more scrutiny, more investment on their side. But then again, I can't suppress the feeling that it isn't all bad. And yes, before some of you (Hello again people!) start throwing a fit, I agree, MDR isn't perfect, and god, are there holes in there. But take a pint, breathe, and you'll probably agree that we have to start somewhere, especially if tech moves soooooooooooo much faster than regulation...
>“At least the latest firmware is not subject to this particular threat, apparently.”
Wouldn't be so sure... it is not clear whether this is an SMBv1, v2 and/or v3 vulnerability.
Also does the latest firmware need SMB v1 etc. disabled to make it secure.
"Next, the intruder crafts a Windows Cabinet file (CAB)..."
The intruder is far more likely to be a bored teenager who has downloaded the required malicious CAB file from somewhere.
It's a very common mistake, when evaluating the odds of such attacks, to mindlessly overlook the very existence of script kiddies.
Considering that script kiddies dominate, it's really a monumentally stupid error. But it's an error that I've seen explicitly performed several times in various situations.
... and once copied, it should sit there, like any other file copied to a remote system's windows share - but that does not mean that the software should actually randomly execute it - unless the app came with some sort of update routine that did no checking on the validity of the file that it received. Blindly trusting user inputs is always a bad thing...
I can tell you there's a hell of a lot of security by obscurity going on here. Which is a direct failure of the process of oversight which should have mandated a set of standards and protocols to use across the industry, rather than allowing a free for all of hand-rolled APIs.
In fact, naively, I rather assumed that would be one of the main roles of a regulator. Otherwise WTF are we paying them for ?????????
The only saving grace for my wifes pump (intrathecal baclofen, so there's a feed straight into her spine) is the controller seems to be NFC based. You need to hold it over the pump to connect.
Having just returned from an unwilling stay in an NHS hospital, my concern at this exploit is pretty much zero.
There are plenty of patient monitors, IV pumps etc. with an option for network connectivity. And absolutely zero actually connected ones.
The vast majority sit there on a stand next to the patient with an uncancelled alarm bleeping its life out. An earache for the patients but I don't think the staff even hear them : they bleep so much they just block them out.
This makes me very unhappy. It's like a compiler warning : if you habitually ignore it, how will you see the one that matters ? The blame belongs equally between overworked medical staff and unthinking manufacturers who make their systems bleep by default at every little whimsy, but good system design it is NOT. And danger from unprotected network ports irrelevant.
Perhaps in some big american hospital that can afford a monitor for every bed (only a few % need one) they do plug them in. I suspect not. And maybe wifi versions are coming, but if notification over wifi to a central monitoring console is their thing, I won't be a customer.
Maybe so on a general ward, but a very different picture on intensive care. There is a lot of data collected into ICU electronic records and I have no problem with that being done electronically. But the system should be designed from the perspective of a bad actor, not left wide open for updates over the network.
Alarm / alert fatigue is a massive issue in hospitals. One case I am aware of involved 27 people clicking through an alert about a critical missing medication.
Central notification is not all bad. ICU nursing is 1 nurse: 1 patient. But sometimes they need to help each other out with rolling patients or dealing with a deteriorating patient or checking drugs. Having alarms centrally monitored as well gives a degree of redundancy that is entirely appropriate.
Most murders are committed by people who know the victim.
Hacking a pump would be the perfect crime.
Mad at your wife/husband? Mad at your boss? Got fired?
Ransomware to get some extra cash?
Are they on pacemakers?
Can you attack an entire population?
Questions that every security guy has to worry about.
Pretty bad... but I would really hope the actual equipment and monitoring is on it's own network. Hospitals I've been too, public wifi is on it's own network, regular hospital computers (these are the ones that keep getting ransomware at various hospitals...) are on a second, and the actual medical equipment is on a third. (The ransomware still cripples the hospital since they can't get to patient records -- and more important in the good ol' USA can't keep track of billing -- but the medical equipment keeps running on it's own network.)
It is very hard to truly isolate systems. Information needs to be transferred between LIS and HIS systems; your lab results from some remote lab, your vitals, your EMR, your nurse’ notes, etc. need to be all looked at by your physician.
The pharmacist downstairs may need to verify the actual drug dosage.
Connected systems improve patient outcomes.
Unless they get hacked.
Problems with insulin pumps are old news - try searching for One Touch Ping.. As IoT and security cross over into industrial control and all sorts of things I've spent 40 years working with, the breathtaking stupidity of running windows in an embedded device still beggars belief. It took 30 years of pain before windows became almost secure.
. . . .you CAN'T secure medical kit. Changing the software requires a vendor to TOTALLY re-accredit the kit and any software.
. . .which is why, at the hospital my eldest daughter worked at, the password for EVERY SINGLE MEDICAL DEVICE was. . . "password" . . .
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
