Security Testing of the Pacemaker Ecosystem

In 2015, Marie Moe (now working at mnemonic) started a small research project on the pacemaker ecosystem security, more specifically, on the BIOTRONIK pacemaker ecosystem. Five years later,  four master’s theses have been written and several talks have been given on the topic. In this article we present our latest results, disclosed after one year of embargo due to the coordinated vulnerability disclosure process.

The pacemaker ecosystem

The pacemaker is not a standalone device that is installed inside a patient’s body and left there for years without any interaction with the outside world. With the introduction of telemedicine in the form of remote monitoring it actually relies on a whole ecosystem to work correctly and efficiently. This ecosystem is composed of multiple devices. Figure 1 shows the ecosystem of the vendor we have been studying, this is similar for other pacemaker brands.

Pacemaker Ecosystem
Figure 1: Diagram of the pacemaker ecosystem (source [2])

Here is a description of the different components of the ecosystem:

  • The pacemaker: Implanted in the patient’s body, this is the main device of the ecosystem. It generates an electric impulse that helps regulate the heart rate. Programmable pacemakers allow practitioners to select the appropriate pacing for every patient.
  • The programmer: The programmer is an external computer used by a practitioner at the hospital to program the pacemaker. This device requires proximity with the pacemaker, which is achieved thanks to the programming head. The communication remains wireless though.
  • The Home Monitoring Unit: The HMU is a device aiming at easing the patient’s life by preventing them from visiting their practitioners too often. Indeed, placed in the patient’s home, this device is in charge of downloading the log data from the pacemaker and sending to the vendor’s servers for the practitioner to access them remotely.
  • The Operator Network: The HMU needs a way to access the internet in order to communicate with the vendor’s servers. Depending on the HMU (see below), the internet can be accessed using a mobile network such as GSM or 3G but also using a regular telephone line.
  • Vendor’s Servers: These are the servers the HMU connects to in order to export the patient’s data. This is achieved using the operator network. The patient data stored on the servers can be accessed by the practitioner through an online platform.

Results

As previously mentioned, four master’s theses (three published so far) have emerged from this project.

In 2018, Kristiansen et al. Focused on the security of the BIOTRONIK pacemaker programmer. They performed a thorough analysis of the programmer, running on Windows XP Embedded and found several outdated software components containing vulnerabilities. They created a Virtual Machine out of the programmer which can be used to perform more analysis on it, without risking bricking the actual device. Finally, they managed to reverse engineer the code used to encrypt patient data (when exported from the programmer to a USB stick for instance) and to figure out that the same hard-coded key is used amongst all programmers of the same type.

In 2019, Lie and Bour took a closer look at the security of the Home Monitoring Unit. This device is indeed interesting as it communicates with both the pacemaker and the vendor’s server, and thus “sees” the data going through it. Lie focused on the network side of the HMU: she set up a fake base station and analyzed the network configuration of the HMU. Using an old device’ SIM card and a more recent device’ credentials, she found out that the devices are not properly decommissioned and can be used as way to contact the backend servers, which should not be possible without a device in use.

Figure 2: An overview of how an illegitimate BTS works (Source: [1])

Bour focused on the hardware security of the device. He used the debug interfaces to obtain the firmware of the HMU and to reverse engineer the proprietary protocol used by the HMU to communicate with the backend server. In addition, he showed that the lack of mutual authentication and the cleartext transmission of credentials, linked with the unencrypted storage of the cryptographic keys can be used to mount a Man-in-the-Middle (MitM) attack between the HMU and the backend server. However, we want to highlight that even if this attack has been shown to be feasible, it is not practical and cannot be used to harm a patient (see the statement related to the coordinated responsible disclosure below).

Figure 3: Details of the connector that was added to the HMU (Source: [2])

The theses are available here:

A more detailed technical write up is available here.

Coordinated Responsible Disclosure

These research findings were shared with BIOTRONIK in the form of a vulnerability report. BIOTRONIK cooperated according to a Coordinated Vulnerability Disclosure process and appropriately analyzed and validated our report. They then shared their responses to each reported vulnerability, and we discussed each point in detail. During these discussions, BIOTRONIK provided sufficient information to confirm that patient harm arising from the vulnerabilities is very unlikely.

BIOTRONIK recommends that healthcare providers and patients continue to use the investigated devices as intended and follow device labelling.

The CISA advisory is available on the US CERT website.

The following CVEs have been assigned to the reported vulnerabilities:

  • CVE-2020-18246: Improper Authentication CWE-287 (CVSS v3 base score of 4.3)
  • CVE-2020-18248: Cleartext Transmission of Sensitive Information CWE-319 (CVSS v3 base score of 4.3)
  • CVE-2020-18252: Improper Authentication CWE-287 (CVSS v3 base score of 4.3)
  • CVE-2020-18254: Missing Encryption of Sensitive Data CWE-311 (CVSS v3 base score of 4.6)
  • CVE-2020-18256: Storing Passwords in a Recoverable Format CWE-257 (CVSS v3 base score of 4.6)

Timeline of the responsible disclosure:

  • October 2019: Vulnerability report is sent to BIOTRONIK
  • November 2019: Discussion between SINTEF, CISA and the FDA
  • April 2020: BIOTRONIK response is received by SINTEF
  • April/May 2020: Discussion between BIOTRONIK, BSI, CISA and SINTEF
  • 18th June 2020: CISA’s advisory and disclosure of CVEs.

Conclusion

Securing IoT devices is difficult and securing medical IoT devices is even harder. The trade-off between strong security and low power is not an easy one to deal with. Moreover, as it was shown in our research, one cannot underestimate the threat of an IoT device “in the wild” to an ecosystem. We are glad to see that our work has been taken seriously by BIOTRONIK and lead to improvements in the latest version of the Cardio Messenger, contributing to a more secure pacemaker ecosystem.