Possible attack scenario Link to heading

In the previous parts, we analyzed different scopes of the Home Monitoring Unit and managed to extract and decrypt data out of the device by exploiting the lack of mutual authentication and the hard-coded credentials. In this last post we will see how we can chain the different vulnerabilities found up to this point to modify the data sent by the pacemaker to the backend server.

It is important to note that the attack described in this post is technically feasible but not practical. That means that even if the attack can be performed, it cannot be used to harm a patient or put their safety at risk. I will come back to this point at the end of the post. Also, the attack presented is only feasible on the CardioMessenger II which, even if it is still in use, is not the latest version of the manufacturer’s HMU and is not for sale on the market anymore. Healthcare providers and patients should follow BIOTRONIK’s recommendation, which is:

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

Please refer to BIOTRONIK Statement on CardioMessenger II Cybersecurity for more information.

Attack Idea Link to heading

The idea for an attacker is to modify the data sent by the pacemaker to the backend server without triggering any alert/warning system. Modifying the data in such a way that they don’t trigger any alert is a challenge in itself, and as I had no access to a working pacemaker, I can only assume that someone with bio-medical knowledge can figure out how to do it. To be able to modify these data, there are several methods, that have different requirements. Figure 1 summarizes the idea of the attack in the simplest manner: the goal of the attacker is to modify a Boolean’s value from “true” to “false.”

Method 1: JTAG access Link to heading

The first method an attacker could use to achieve her goal is to take advantage of having JTAG access to the device, and thus control over the memory, to change the data before it gets packed and encrypted. If we consider the simplest case, where the attacker only wants to perform a bit flip in the data, she would put a breakpoint before the data gets packed, modify it, resume the execution and that will do.

This method obviously requires the attacker having physical access to the device (more specifically to the JTAG pins) for the whole time of the attack and is thus not very practical.

A possible solution for this is to insert the Raspberry Pi setup as both a JTAG connector and an Access Point inside the HMU, which gives a “remote physical access” (one can connect to the RPi and then interact with the MCU via JTAG).

Method 2: Network access Link to heading

The second method also requires the attacker to have had physical access to the HMU at least once. The idea is for the attacker to dump enough of the memory to get the device’s key. Once the attacker has this material, the attack can be performed anywhere between the HMU and the backend server, as long as the attacker can intercept the traffic. A typical example here could be an insider attacker at the mobile operator.

This time, the attacker can intercept the communication, decrypt it using the key gathered previously and the same script as in the previous post, modify the data, encrypt and pack it again and forward it to the backend server.

Method 3: Spoofing the HMU completely Link to heading

Lastly, an attacker might want to completely spoof the HMU. This also requires physical access to the device in order to collect the credentials and the keys. In addition to this, the attacker needs access to the VPN, which requires a valid SIM card or access to a Telephone line (I’m unsure if that version of the device is still in use). With that, the attacker can connect to the VPN and then to the backend service. She can then send data to the server using the HMU’s key to encrypt the messages. The difficulty here is that the whole message needs to be faked, which might be a challenge if the attacker does not know what it looks like in a first place. So this would need some “monitoring” time to gather valid messages in order to create valid-looking fake messages later.

On the practicality of the attack Link to heading

Now let’s review why this attack is not practical. The first and probably best argument is that this attack can only render the home monitoring useless, i.e. like if there was no home monitoring at all but making the patients and the doctors believe there is. In order for the attack to harm a patient in a targeted way (one specific person is targeted), the attacker would need to perform the attack for a very long time, and rely on “luck” for the patient to have his condition deteriorated quickly enough so that it is not detected by the regular doctor’s appointments.

The second point is that the attack requires physical access to the device, good knowledge of the data sent to the backend in order to spoof it without triggering an alert and preforming the attack for a long time to have a potential impact. This increases the difficulty and effectiveness of the attack, and thus decreases the likelihood that someone would even try it apart from in a security research perspective.

Indeed, even if this attack cannot result in any harm to the patient, it highlights the need of being able to trust the data coming from a medical device. This is not an easy problem and it is even less when facing low power devices such as the pacemaker.

Conclusion and take-aways Link to heading

This post concludes the series. As mentioned in the introduction, the idea here was to present what could be done using the different vulnerabilities that have been found and presented in the previous posts. More specifically, the goal was to show that several vulnerabilities which, on their own do not have a big impact, can be chained to perform an attack. We decided to publish our findings after discussion with the manufacturer that made it clear that they cannot be used to harm any patient, which is of course the top priority.

Working on this project was a great learning experience for me, which I hope is well presented in this blog series. As already mentioned, I was a complete beginner in hardware and embedded security (and still am), so almost every part of the work was new for me. In addition, I had the opportunity to take part in the coordinated disclosure process along with CISA and the BSI, which was also a first time for me. I am glad that BIOTRONIK took our findings seriously and was open to discussion: they provided us with a detailed response to our report, in which they explained the improvements made to mitigate the reported issues. The objective of the “Pacemaker Hacking Project” is to contribute to the security of the pacemaker ecosystem, and in that sense, it was a success.