Understanding Pacemaker Systems Cybersecurity

Highlights:

• A paper capturing a comparison of pacemaker systems can be found here
• While potential vulnerabilities were discovered in all pacemaker systems, the specifics of those issues will not be discussed in this post.  All potential vulnerabilities discovered in this study have been/will be reported to DHS ICS-CERT.  
• We examined seven different pacemaker programmers from four different manufacturers.  Most of our efforts were focused on 4 programmers that had RF capabilities.
• We discovered over 8,000 known vulnerabilities in third party libraries across four different pacemaker programmer from four different manufacturers.  This highlights an industry wide issue associated with software security updates.
• Pacemaker programmers do not authenticate to pacemaker devices.  Any pacemaker programmer can reprogram any pacemaker from the same manufacturer.  This shows one of the areas where patient care influenced cybersecurity posture.
• Pacemaker programmers do not require physicians to authenticate to the programmer.  Another area where patient care influenced cybersecurity posture.
• All pacemaker systems had unencrypted filesystems on removeable media, making initial analysis relatively straightforward.

Part I – Introductions and Pacemaker Programmers:

In October of 2016 exceptions to the DMCA related to medical device cybersecurity research went into effect.  The EFF and several notable infosec organizations championed amendments to the DMCA to allow for more open exchange of Medical Device cyber security research.  We’d like to thank  those organizations that championed the changes to the DMCA. 

This post is provided in spirit of those DMCA exceptions.  Specifically, this post (and follow-on posts) provide insight into technical details as to how pacemaker systems work and some of the cybersecurity challenges manufacturers face when implementing these systems.  When this document references “pacemaker systems”, we are referring to pacemakers, Implantable Cardioverter Defibrillators (ICD), Pulse Generators, and Cardiac Rhythm Management (CRM).  Surprisingly, the architecture and even technical implementation of pacemaker systems across manufacturers is very similar.  We suspect that some of this similarity is due to the technical restraints associated with implanted technologies.  Other similarities, however, indicate that there is some cross-pollination between pacemaker manufacturers.  Given the similarities between systems, we hope that pacemaker manufacturers work together to share innovative cyber security designs and compete on user experience and health benefits as opposed to competing on cybersecurity.

Discussions associated with the cybersecurity of pacemaker systems can be an emotionally charged topic.  Our approach is to keep this discussion focused on technical data (“more research, less drama”), but we hope this data is used to spur civilized discussions about how we can improve implantable medical device cybersecurity.  When possible, technical data is presented in a vendor neutral manner.  A document describing our research has been provided to the NH-ISAC, you can find that document here.  In the spirit of coordinated disclosure, any potential vulnerabilities discovered during this project was/will be reported through DHS ICS-CERT.  Specific vulnerabilities, weaknesses associated with specific vendors, and exploits will not be discussed in these blogposts.

As shown in previous research efforts, cybersecurity researchers can obtaining a variety of medical devices, including “big iron” medical devices. 

Imaging Device in Billy's Garage

Pacemaker systems are no exception.  For this project, we acquired pacemaker programmers, home monitors, and pacemaker devices made by four different manufacturers.  These devices are supposed to be “controlled”, as in they are supposed to be returned to the manufacturer after use by a hospital, but all manufacturers have devices that are available on auction websites.  Programmers can cost anywhere from $500-$3000, home monitoring equipment from $15-$300, and pacemaker devices $200-$3000.

Pacemaker Programmers on Ebay

Pacemaker systems are “system-of-systems”.  Looking at all four manufacturers, there are essentially four components to modern pacemaker system deployments: the pacemaker devices, pacemaker programmers, home monitoring systems, and the supporting/update infrastructure.  All components are vital to the safe functioning of the pacemaker system.  The figure below shows how these components interact with each other. 

Pacemaker System Ecosystem

As seen in other medical device verticals (https://ics-cert.us-cert.gov/advisories/ICSMA-16-089-01), keeping devices fully patched and updated continues to be a challenge.  Despite efforts from the FDA to streamline routine cybersecurity updates, all programmers we examined had outdated software with known vulnerabilities.  Across the 4 programmers built by 4 different vendors, we discovered over 8,000 vulnerabilities associated with outdated libraries and software in pacemaker programmers.  

Outdated Third Party Components

We believe that this statistic shows that the pacemaker ecosystem has some serious challenges when it comes to keeping systems up-to-date.  No one vendor really stood out as having a better/worse update story when compared to their competitors.  In two instances, we were able to confirm that patient data was stored unencrypted on the programmer.  In one instance, we discovered actual unencrypted patient data (SSNs, names, phone numbers, medical data…etc) on a pacemaker programmer.  The patient data belonged to a well-known hospital on the east coast and has been reported to the appropriate agency.  These types of issues highlight the need for strong device disposal policies from hospitals.

How do Pacemaker Programmers Work?

Of all the components in pacemaker systems, pacemaker programmers provide the most insight into how pacemaker systems actually work.  In total, we examined seven different pacemaker programmers from four different manufacturers.  Six pacemaker programmer utilized unencrypted IDE hard drives.  One pacemaker programmer utilized an unencrypted PCMICA flash drive.  We saw a variety of operating systems such as the familiar Windows XP, Real Time Operating Systems (RTOS) like MonteVista, old operating systems like DOS, we even encountered one programmer using OS2! 

All of the programmers we examined booted directly into the programming software without first requiring any type of login or password.  Pacemaker programmers do not authenticate to pacemaker devices.  Any pacemaker programmer can program any pacemaker from that specific vendor.  This is true for all programmers we examined.  Proximity is the primary criteria for pacemaker programming.  This is an area where is appears that patient care has influenced the cybersecurity posture of the pacemaker programmer.  While older pacemaker programmers only utilize a close proximity “telemetry wand”, newer programmers from all vendors utilize longer range RF communications in addition to the close proximity telemetry wand.  Our research focused on programmers that supported the use RF communications.  By intended design, all the pacemaker programmers we examined first required the use of a telemetry wand in order to communicate with the pacemaker.  This is the intended design; situations where devices can communicate with a pacemaker without first requiring a telemetry wand is more complicated and will be addressed in a later post.  In all implementations we observed, the telemetry wand would retrieve a token from the pacemaker device itself.  In some cases, the token is the device serial number/ID.  In one case, the token value retrieved from the pacemaker device was a static AES key.  This token value is then used to derive a session value/key and communications is passed from the telemetry wand to longer range, higher bandwidth radio signal.  The method/algorithms used to derive the session token/key values is different amongst different manufacturers.  

These session token generation algorithms are stored within the programmer logic and software.  Once a proper session is established, the programmer can perform a variety of functions over radio, including the alteration of therapy.  This is by-design and is the case for all pacemaker programmers we examined.  Obviously, compromise of a pacemaker programmer is a serious matter.  The by-design capabilities of pacemaker programmers is significant and compromise of a pacemaker programmer would result in situations where alteration of therapy is possible.

The software implementation of pacemaker programmers shows an area where cross-pollination between vendors has likely already occurred.  All of the modern programmers we examined use a core application to initialize the programmer hardware and interfaces.  Communications to pacemakers is done through “apps”.  Each pacemaker device model has its own app on the programmer.  The app contains the specific commands supported by that specific pacemaker.  The pacemaker app also contains the telemetry structure used to retrieve data, program, and reprogram the pacemaker device.  Most of the implementations we observed allowed programmers to both update pacemaker therapy settings and pacemaker firmware.  We did not observe any cryptographically signed pacemaker firmware.  Given pacemaker firmware are not cryptographically signed, it would be possible update the pacemaker device with a custom firmware.  Once interaction with a pacemaker is complete, the pacemaker app passes control back to the main application and the main application will await an another inductive telemetry wand action.

Steps for RF Programming

(1)   Pacemaker programmer system starts the main application (no password required)

(2)   A close proximity telemetry wand is used to interrogate a pacemaker

(3)   The pacemaker device provides a token and identifying information

(4)   The pacemaker token and identifying data is received by the main application

(5)   The main application launches the pacemaker app for the identified pacemaker

(6)   The pacemaker programmer switches to RF communications

Pacemaker programmers represent a significant part of the pacemaker ecosystem.  From a security research perspective, access to programmers can be extremely helpful in understanding how pacemaker systems work.  In the next part, we’ll talk about the home monitoring systems and how they work.