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.

DHS Funding for IoT Security!

We’re proud to announce that we’ve been awarded funding through Department of Homeland Security Silicon Valley Innovation Program.  The security of IoT is a concern for organizations in many different industries; we’re excited and happy to do our part to help solve this problem at scale.  Over the last five years, we’ve looked at a variety of IoT and embedded devices.  The fragmentation of processor architectures, hardware components, and real-time operating systems introduces some real challenges to making security impact at scale for IoT.  One common denominator amongst many of the IoT devices we’ve seen is the usage of wireless protocols (specifically 802.11), so we’re focusing on the technology that will allow us to impact the widest range of devices.  We’re excited at the chance to show off our prototypes and research over the next few months,  but first we wanted to mention the Silicon Valley Innovation Program itself.

The Silicon Valley Innovation Program, conceived and operated by the DHS Science and Technology Directorate, is pretty special.  Working with the federal government can be daunting, especially for startups.  The Silicon Valley Innovation Program is trying to change that.  They’re specifically interested in engaging start-ups, incubators, and those organizations who typically don’t work with government.  If you are an IoT startup or cyber security startup with some IoT skills, you should definitely take a look at the program!  You can find a link to the IoT security challenge here and you can learn more about the Silicon Valley Innovation program here.

Worldwide Building Automation System Enumeration - October 2015

Here at WhiteScope, we periodically scour the Internet in search of exposed buildings.  We make use of a variety of data sources (including Shodan and Scans.io) for our initial enumeration.  We're excited to see how the newly launched Censys is going to change the Internet enumeration game! While these enumeration services are invaluable in the detection in devices on the Internet, these services only provide so much data specific to building automation devices.  To supplement the great work done by these enumeration services, we've developed a custom set of enumeration tools which utilizes Shodan and Scans.io data and provides us additional information related to buildings on the Internet.  For example, instead of knowing there is a building at IP address 1.1.1.1, we now know that there is a bank branch or a hospital at 1.1.1.1.  In partnership with QED Secure Solutions, we're making some of the data we've captured available in this report.  We plan on releasing a similar report twice a year, once in April and again in October.  We hope you find it informative and useful.

You can download the document here:

Billy