It's very interesting to see an in-the-wild example of a security flaw in the wireless pairing of a class C medical device (i.e. a device that can severely injure or kill). Would love to see technical details about the specific flaw here.
It looks like it's implementing 802.15.4 (the basis for ZigBee among other protocols).
The user manual for the Contour Next Link 2.4 device (https://www.medtronicdiabetes.com/sites/default/files/librar...) shows that pairing can be initiated by the USB dongle and succeeds if the user confirms the request on the device. A serial number is displayed but that appears to be under the control of the hypothetical attacker. So the user must know to reject an unexpected request even if it has the right serial number, or the attacker will gain control of their pump and can issue a remote bolus command.
This example doesn't have to do with Bluetooth but there's an interesting connection there because most BLE pairing methods have been shown to be insecure to sniffing attacks. That imposes constraints on how medical devices that need Bluetooth connectivity are designed, because it may force a device to have a screen for showing a pairing code when it otherwise would not need one.
The FDA released a Draft of the new Cybersecurity Guidance document back in April and there was speculation that this draft was going to become active (an actual regulation) by the end of the year. I wonder if this news is going to speed that up in any way.
The new draft literally doesn't change anything. It just defines some of the things that FDA has been already asking for in the past 7 years for every device submission.
Just my opinion as someone who has worked on many infusion pumps; that FDA review division is the best at FDA. They probably ask more cybersecurity questions than any other group I've encountered.
> They probably ask more cybersecurity questions than any other group
And therein lies the problem. Ask lots of questions on paper, and you get something that is very secure on paper.
But if you want something actually secure, you need to do pentests, have a substantial bounty program, have the design+code inspected by security reviewers, etc.
That FDA review division does require that information and testing to be supplied with infusion pump testing. In fact, they are one of the few that routinely asks for substantial testing in repeated deficiency requests.
This makes me mad as a minimed user. I can't even get data out of my pump (a 754) because minimed does not sell the reader in my country. The 600 models are the top-off the line models that cost $$$.
Medtronic shouldn't be able to get away with just saying, turn off remote bolusing to be secure. I hope they get a class-action suit.
Background: Medtronic is a money-hungry company. I've been using their insulin pumps for 15 years. Over the years the quality of their infusion sets dropped, they no longer provide a cap (the thing you put on to close the catheter before you shower) with each infusion set, rather than they put only one cap in a 10x bag. The infusion sets started to fail after 2 days (the default timespan is 3 days), whereas it used to last 4-5 days before.
There are some Contour Next Link (non-2.4 version) listed on Ebay and other sites. Unless Medtronic locks the meter to one user account, maybe you could then pair it and get the data out, if they will ship to your country.
Here in Canada, the infusion sets Mio 30, Mio Advance, Sure T and Mio that I have used all came with a cap in each set. They also charge the government C$26 each, but still that cap cannot be worth more than a few cents, so it is a strange way to save money.
The sets have been failing early for me as well at the rate of about 1 in 10. I started with the Mio Advance and my nurse said to call Medtronic and report the failures. Medtronic sent a box of 10 Mio Advance plus boxes of 10 Mio and 10 Sure T (metal) to try for free. The Sure T failed less than the Mio Advance and Mio, but I just had one fail the first day so am trying the Mio 30 which goes in at an angle but uses plastic.
> ... CareLink™ USB device that communicate wirelessly. ...
> ... For unauthorized access to occur, a nearby person other than you or your care partner would need to gain access to your pump at the same time that the pump is being paired with other system components. This cannot be done over the internet. ...
>4. Disconnect the USB device from your computer when you’re not using it to download pump data. 5. DO NOT confirm remote connection requests or any other remote action on the pump screen unless it is initiated by you or your care partner. 6. DO NOT share your pump’s or devices’ serial numbers with anyone other than your healthcare provider, distributors, and Medtronic.
Hmm... You have a wireless dongle connected to a PC that appears to rely at least in part on the serial number as authZ/N, and can provide fully remote communications over the Internet and manipulation of the terminal device. But... "This cannot be done over the internet"? Seems to be at the time of pairing, but can the pairing be initiated & accepted remotely?
To be fair the earlier Medtronic pumps were also insecure, but it allowed for reverse engineers to get into them and create one of the first closed loop systems.
Yes open communication with insulin pump has historically been a feature not a bug. In the older minimed models you still needed the device serial number to “hack” it, not sure if that’s the same for the 530g, but if it is that’s enough security for me as a type-1 diabetic. The cynical part of me thinks that minimed is more concerned with playing defense against superior closed loop software alternatives than they are about safety.
Tandem recently released updated firmware and mobile app for their t:slim X2 pumps which includes a function to deliver insulin from the mobile app. To me, this seems like a dangerous idea, given that people can die from an insulin overdose. I'm perfectly happy keeping the function solely on the physical device. My wariness has not been shared by the majority (or even a small fraction) I've discussed this with online - pump users generally desire this convenience and are not at all concerned about potential security implications.
While I’m not a certified security professional, I have looked pretty closely at Tandem’s mobile pairing and remote bolus implementation and it seems to have been designed in the right way. After initializing a Bluetooth connection, the phone and pump complete a handshake wherein a 16 character alphanumeric key appears on the pump screen and you need to enter it on your phone, which then uses it as a shared HMAC symmetric key. Status information and responses then occur in cleartext once authenticated, while bolus operations require messages to be signed with the initial key.
That being said, on the chance that there is a security flaw here I’m willing to eat my words…
My partner uses a Tandem pump, and is annoyed that she can't actually use most of the features of the Tandem app because she uses an unapproved (Pixel 6 Pro) device.
Take a look at https://github.com/jwoglom/pumpx2, I’m working with the AndroidAPS folks currently to make it more broadly available. xDrip integration would happen via AAPS.
The whole setup is only secure if the phone is secure. One malicious keyboard app and the key is leaked, and now there is no security left at all.
I think such a design is only safe to human-life standards if all possible signed messages (ie. All possible messages the app could send) would be safe for the user.
My concern is that the phone could be compromised. Having a phone hacked would be bad enough without giving the attacker the option to easily hospitalize/kill you.
There was an entire data set released that had all the medical device injuries and malfunctions listed. Pretty interesting to dive into considering it wasn't previously public.
As a Type 1 diabetic, insulin pumps are a game changer for the entire population that needs to use them. But I think it's understated the risks that come with the devices. In my opinion the benefits outweigh the risks but that is still something you should be able to determine on your own as a user.
Side note: One of the things I see a lot of diabetics miss with insulin pumps is how changes in altitude and air pressure can cause unintended delivery of insulin if you have air bubbles in the cartridge. For those who travel with insulin pumps, make sure to disconnect during changes in altitude (take-off and landing).
Medtronic buys a lot of companies and rebrands their products under their name. Software quality is going to vary a lot, because it comes from a wide variety of sources.
I worked at another medical device manufacturer. Often, they will "buy" a company they actually staked in the first place. The medical device company wants to develop a new technology or device, so what they do is give money to a startup that barely has an idea, and sends management over there to keep track of things. They'll see if the device pans out, then "buy" the company and integrate the device's manufacturing and design into their own system once the FDA approves the device. Then, they just keep it on life support for several decades, making as few changes as possible to prevent the need to redo FDA certifications.
This fits well to the gaps and oddities in the user experience; I think I am actually “on record” saying to my fiancee that this or that issue must be because they’re munging the product to fit FDA regulations. In letter, not spirit.
There’s also a clear sense that software quality is absolutely not a priority. The sense that software quality is explicitly set as not a priority.
For instance, I think I can confidently say that lessons learned from previous software stacks are not accumulated and applied to improve subsequent ones.
I’d like to add that I believe the individual developer is doing their best. It’s in the decision-making layer.
Just spending a few minutes searching around I found this interesting reverse engineering work on the Contour Next Link 2.4 USB dongle: https://github.com/szpaku80/reverse-engineering-contour-next...
It looks like it's implementing 802.15.4 (the basis for ZigBee among other protocols).
The user manual for the Contour Next Link 2.4 device (https://www.medtronicdiabetes.com/sites/default/files/librar...) shows that pairing can be initiated by the USB dongle and succeeds if the user confirms the request on the device. A serial number is displayed but that appears to be under the control of the hypothetical attacker. So the user must know to reject an unexpected request even if it has the right serial number, or the attacker will gain control of their pump and can issue a remote bolus command.
This example doesn't have to do with Bluetooth but there's an interesting connection there because most BLE pairing methods have been shown to be insecure to sniffing attacks. That imposes constraints on how medical devices that need Bluetooth connectivity are designed, because it may force a device to have a screen for showing a pairing code when it otherwise would not need one.