Hacking Insulin Pumps

The ethics of hacking insulin pumps … in this blog post, I would like to discuss a few thoughts about the pros, cons, and risks, of “playing” with a medical device!

Introduction

Recently Medtronic Diabetes released an advisory for its MiniMed 508 and MiniMed Paradigm insulin pumps.  This advisory warned consumers that a new vulnerability had been identified whereby Radio Frequency (RF) signals could be sent remotely to at-risk models of its MiniMed product range, allowing for changes of settings, and even insulin delivery.


… the Good

There are some really innovative pieces of work being done that are only possible through the research being done into remotely accessing insulin pumps.

This ranges from retrieving diagnostic and treatment history information – as provided by Nightscout, to groundbreaking OpenSource projects that are aimed at developing Closed Loop insulin delivery systems – such as OpenAPS


… the Bad

For all the exciting innovation that is happening, a.k.a. “the Good”, such research opens our collective eyes to the behaviours of our devices, creating opportunities to discover unexpected risks and even security risks – as we have seen in the recent announcement.

In this case, it’s pretty bad … a medical device company has been made aware of a remotely exploitable security vulnerability that cannot be prevented, cannot be worked around (508 models cannot have their firmware upgraded) and can very well go undetected until it’s too late.

As such, they are notifying anyone they believe to be using the device, of the risk. (Though interestingly, they aren’t yet calling it a recall)


… the Ugly

The part that, frankly, sickens me is that the team that found the vulnerability then went one step further and released a tool to exploit it.

Yes – they published an app that could be used to kill someone !!!
https://www.wired.com/story/medtronic-insulin-pump-hack-app/


The Risks

I too love the work done by groups such as NightScout and OpenAPS, but it does come with risks.

Think of it this way. What happens if the source code for OpenAPS is compromised, introducing a back door that allows a threat actor to remotely connect to a looping device and execute the (literal) “kill switch”?

How many “loopers” read the source code to be sure that it is integral and doesn’t introduce such a risk?

I’d love to say that this is beyond the realms of possibility, that no one in their right kind would do such a thing… but remember … someone wrote a piece of code that does exactly that …


Playing with Fire

I’m on a FaceBook group related to NightScout.  A while back, one of the members posted a new plugin he had created that allowed him to deliver insulin remotely via his child’s pump.

There was a catch, when I enquired, there was no protection to verify that the person triggering the delivery was in fact authorised to do so.  Anyone who perhaps saw a screen shot of the tool “in action”, maybe with the mobile phone number associated with the insulin pump, and who knew (maybe from the photos) the command sequence to delivery insulin, could in fact send  a potentially fatal insulin dose to the diabetic using the pump.

Now we have a scenario where a “perfectly valid”, unmodified, plugin, which has become a life-threatening vector for compromising a diabetic patient’s health, except unlike the recently announced vulnerability – you can do it from “anywhere”


What to do?

Having presented a couple of horrific scenarios, and plausible (albeit reduced) risk … what can we do about it?

In the first instance, contact Medtronic if you think you are at risk.  I’m hearing wonderful stories of pumpers having their old, End of Life, devices being replaced “for free”.  I’m not saying it’ll happen for everyone, but surely it’s worth looking into?!

We are lucky, here in Ireland our devices are refreshed every 4 years, at no cost to us.  So the number of people who are using an at-risk device should be low.  But other countries are not so lucky, where diabetics continue to use pumps well past their EOL / End of Warranty date(s).

I’d recommend using this information to talk with your diabetic care team, ask them for their support to move to a non-affected model such as the Medtronic MiniMed 640G. Even without using the integrated CGM, the pump is far superior (IMHO) than any other option available ***

*** Note- this is a point-in-time Ireland-specific statement … there is a 670G available which is AWESOME – not only does it do predictive suspend, it also auto-corrects (boluses insulin) for high sugars.

If your pump supports the “remote bolus” feature, think … do you really need this feature?  If the answer is “no” … then disable it!  Accessing your data is one thing … but allowing for remote bolus delivery is another thing completely!


Where this post began

Some of this content is taken from my recent responses to a FaceBook post in an Irish Type-1 Diabetic Parent’s support group – a closed group (no, I have not used any text other than my own!).

I responded when a parent posted a photo of a letter they received from Medtronic.  They were frustrated by the message, unsure why Medtronic would send such a letter, scaring parents when (in their view) no-one would be hacking into pumps anyway.

In my response, I indicated that I see the warnings from Medtronic as “responsible manufacturing” – I applaud them for this pro-active notification.

I understand that the risk is arguably low.  But, as demonstrated above, no only is it possible, but someone went out of their way to release code that actively exploits this vulnerability. And then, even when someone has good intentions, without proper consideration to the risks, it is possible to introduce potentially lethal vulnerabilities


Final thought

Hacking insulin pumps need not be “evil”, but it requires a clear understanding of the risks associated with the activity you are engaged in.  It opens up incredible opportunities but can have disastrous consequences.

If you are going to “play” – do so carefully, and at the very least, disable “remote bolus”

#WeAreNotWaiting