Medical Device Security

One of our guiding principles at ERNW is “Make the World a Safer Place”. There could not be a topic that matches this principle more than the security or insecurity of medical devices. This is why we started a research project that is looking at how vulnerable those devices are that might be deployed in hospitals around the world. Recently the U.S. Food and Drug Administration (FDA) has put out a recommendation concerning the security of medical devices. It recommends that “manufacturers and health care facilities take steps to assure that appropriate safeguards are in place to reduce the risk of failure due to cyberattack, which could be initiated by the introduction of malware into the medical equipment or unauthorized access to configuration settings in medical devices and hospital networks”. We thought that we should take a look at how manufacturers deal with security for these devices.

If you look at modern medical devices, especially devices that are used for monitoring vital signs, one main feature is networking capability. Hospitals want to monitor multiple patients without a hassle from one central workstation where one nurse is able to see alarms and live data. Many vendors offer the possibility to integrate their devices into the network via LAN, but WiFi is also possible. The protocols used are highly proprietary, which is good in terms of insecurity J. Taking a deeper look we realized that authenticity and integrity of the transported data obviously was not an important requirement. Good old attacks like ARP spoofing and man-in-the-middle attacks work like a charm. Considering that these devices need to have a high availability in case of emergency situations, the impact would be very high. Not to mention the fact that tampering with the data may result in erroneous vital signs being displayed to the doctor.

Getting a hand on these devices is the hardest part. In our experience, vendors are not really responsive when it comes to testing their devices on security. One could buy used medical devices but interesting targets are either not affordable or it’s simply not legal to possess or operate them, think of MRIs or X-Ray machines. So we started with devices that every hospital needs and which are not going to threaten your health while gaining a root shell. 🙂 The technical details in this blog post might be a little bit unspecific, this is due to the critical nature of the vulnerabilities that we discovered. As we want to make sure that there is no threat to the safety of patients or hospital staff the disclosure process is critical and some of the findings are not patched yet by the vendors. Furthermore the patching process itself might be cumbersome for those devices; we’ll discuss this in a later post.

The first thing that we looked at was an EEG which is used to measure brain waves. It is split up into two parts, a box that gathers the signals from the patient’s brain and a workstation, which displays the data for the doctor. The communication protocol between the workstation and the box is simply UDP with a proprietary data format via the local network. By reversing the protocol we found out that it basically allows extensive control over the box, even during a measurement when the doctor is staring at the workstation screen. There are no checks for integrity or authenticity of the data that passes the network.

While this case might not pose a risk on the health of a patient, we found out that similar issues exist in medical devices that will guide a doctor or a nurse in the process of making life critical decisions: Patient monitors. These devices are also capable of communicating over the network and the firmware of many of them can be configured over the network. They might even have wireless capabilities. We found out that the configuration process can be abused to set a configuration on a device that makes no sense at all. It even might be dangerous because it might influence the decision making process of medical personnel. For example take a look at this screenshot:

The picture shows alarm boundaries of an ECG.

The ECG measures the electrical activity of the heart. Obviously 😉 one of the parameters that is essential to monitor is the heart rate. To set off an alarm when the heart rate of a patient is too low or too high is an essential feature for a patient monitor. These alarm boundaries are to be configured in a reasonable way and the user should not be able to define boundaries that can’t even be measured by the device. In the picture above you see the upper alarm boundary of the heart rate alarm set to 30583 and the lower boundary set to -30584. These are values that even a severely sick or perfectly healthy heart would never even get close to. The upper boundary might be somewhere around 220 beats per minute! It is not possible to set these unreasonable limits on the device itself, we had to abuse the configuration process for this to work. This is especially critical when you think of how these devices are used in hospitals. Many patients get connected to a device like this every day, the staff using these monitors can be changing multiple times within minutes. Setting unreasonable alarm boundaries on a device might lead to a failure in detecting dangerous heart rates in an emergency situation.

The devices we have seen so far fail to provide an acceptable level of security. No matter how much you spend on safety, if you can’t provide security, your safety considerations are basically gone, too! There will be more to come on this topic as we are in the process of starting cooperations with hospitals to get our hands on devices. So stay tuned!

I will be holding a talk on this year’s DeepSec conference in Vienna on Thursday, 21st of November with some more details and demos. If you get a chance to visit the con: pay me a visit! 🙂