Introduction

The terms “Hacker” and “Malware” are part of our daily vocabulary due to its significant impact on society, enterprises, and individuals alike. There is a good chance you or someone you know has been impacted by cyberattacks. These attacks come in many shapes and forms. It could be as subtle as your laptop slowing down to being locked out of your online accounts. In severe cases, you may get a message demanding you pay ransom to regain access to critical files.

Despite the wide range of cyberattacks, these traditional attacks have one thing in common: they target digital assets. You may lose your personal information stored in digital form, but there is no physical harm to your person as a direct result of such an attack. However, what if an attack could cause bodily harm? Hacking a pacemaker remotely and administering untimely shock can cause heart attacks. Remotely changing the configured dosage of an infusion pump can cause complications and even death. Unfortunately, these scenarios are not the plot of the next Hollywood movie. With the initiatives to connect purpose-built devices and making them Internet of Things (IoT) devices never designed to be online or accessible via Internet, these devices are being retrofitted to do just that.

One particular IoT device we’ll analyze is the infusion pump. The infusion pump market is expected to grow to more than $10 billion USD by 2021[1] and they are one of the most abundantly available connected medical devices in any hospital environment. As such, infusion pumps can easily be found in patient rooms, hospital hallways, storage closet, etc. Such physical access is unavoidable in healthcare settings focused on delivering timely care. Due to the unique accessibility to these devices, the ZingBox security team focused on answering the following question in this report:

If a hacker has an opportunity to be in the same room as an infusion pump, what type of attacks can he/she launch?

[1] Research and Markets

Executive Summary

Here is the summary of findings identified in this report:

• User interface of the infusion pump can be altered, causing inaccurate dosage to be entered
• Hackers can gain access to the centralized server the pump connects to and potentially access Protected Health Information (PHI) or Electronic Health Records (EHR)
• Decryption of traffic in-transit between infusion pump and pump server
• Infusion pump can be used as a conduit into the hospital’s infrastructure
• Internal flash memory (chip) can be altered, preventing reboot, replacement of compact flash card, and other measures ineffective

Scope & Limitations

• The assessment focused on the BD Alaris 8015 pump (PC unit version 9.12.40.4)
• Only the vulnerabilities based on physical access to the infusion pump was documented. Remote access/hack of the pump server is beyond the scope of this report.
• Physical tool used for this exercise consisted of a screwdriver

Vendor Collaboration

All vulnerabilities uncovered as part of this exercise were reported to the vendor prior to public disclosure. An updated ICS-CERT advisory including findings from ZingBox is available here:
https://ics-cert.us-cert.gov/advisories/ICSMA-17-017-02A

Updated Advisory from BD is available here:
https://www.bd.com/en-us/support/product-security-and-privacy/product-security-bulletin-for-alaris-pc-unit-model-8015-update

Infusion Pump Overview

Before diving into the details of our research, we’ll review the various characteristics of the infusion pump. Figure 1 illustrates the pin pad user interface of the pump. The pump interfaces with the Alaris system referred to as Guardrails Application. To the right of the pin pad is the units designed to infuse the medication to patients.

Figure 2  illustrates the internal view of the pump exposing its circuit board. Please note the compact flash card inserted into the circuit board. This was the point of entry leveraged by the attacks outlined in this research. Another accessible device, but not illustrated in Figure 2, is the Wifi card used to connect to the hospital network.

It’s worthwhile to note that the pump was not designed for its configurations to be altered in the field without the use of specialized tools or software. Our research did not leverage any such tools or procedures designed for field maintenance.

Exploiting Infusion Pump Vulnerabilities

Lack of Secure Boot Protection

Once the pump front bezel was removed by undoing screws from the back, it was possible to replace the existing compact flash with our own. There is no physical or digital safeguards to prevent such action. Commonly found secure-boot or encryption strategies were not employed. Our first step was to create our own scripts to be executed when the compact flash was replaced to start exploring the device internals.

Weak System Integrity Protection

By simply removing the compact flash from the pump and using a card reader, we first explored the device content to identify various attack vectors. As illustrated in Figure 3, the file, AUTORUN.CMD caught our attention.

Examining the AUTORUN.CMD file revealed:

boot -crc -cache /ata0/app/medley/0/ose.elf

The boot file “ose.elf” is a Linux RTOS ARM system created by a Swedish software vendor ENEA.

There are two methods to bypass this integrity check. You can remove the “-crc -cache” parameters from the command line in AUTORUN.CDM or recalculate the CRC of the modified “ose.elf” image and update file “MANIFEST.XML” where the value is stored and in the attacker’s control.

There are several alterations we can implement as proof of concept including:

• Overwrite the PIN numbers (to access Network settings)
• Replace the boot up image with a custom message (i.e., “Your device has been locked until ransom is paid”)
• Alter the front-end forms of Guardrail to cause unexpected dosage to be administered

We elected to change the infusion settings in the Guardrail application where the RATE (mililiters infused per hour) and volume to be infused (VTBI) are configured. Figure 4 illustrates the infusion pump before and after the alteration. Note the change in location of the RATE and VTB entry. The title has also been changed from PRIMARY to PRIMERA to easily illustrate the alteration.

Figure 5 illustrates the consequences of this alteration. We entered the RATE of 273 mL/h and VTBI of 27.3 ml. However, once activated the pump reported a RATE of 27.3 mL/h and VTBI or 273 ml. This equates to 10 times the intended dosage.

Hardcoded Credentials

According to the maintenance manual (See Figure 6), a PIN is needed to access the pump’s network configuration. The default value of 32221 is hardcoded, and we were able to identify the specific offset inside the ose.elf file, allowing us to overwrite the PIN with any value we want. As expected, many organizations use this value unchanged.

Figure 7 illustrates other hardcoded credentials found in the ose.elf image. The same credentials were also found in the internal flash memory.

Figure 8 illustrates potential shell-based credentials.

Lacking Encryption of Sensitive Data-At-Rest

Upon detailed examination of the compact flash card, we discovered other shell commands in addition to the “boot”. Among other insights, this capability allowed us to identify the list of processes running in the pump as illustrated in Figure 9.

With access to the filesystem, we noticed a partition related to the FlashFx generic block device driver that links the system and the hardware. This link allowed access to the internal flash memory in similar fashion as a traditional hard drive or RAM disk. To make matters worse, the link provided both read and write access.

Sensitive Data Disclosure

By analyzing the internal flash memory, we identified a configuration file housing sensitive information as shown in Figure 10.

   
Figure 10. Configuration File with Sensitive Data

Here are the details of the data exposed in the configuration file:

• Hostname, Port and Credentials to access the Pump Server
• AES Encryption key to protect the traffic between infusion pump and Pump Server
• Wireless configuration including RADIUS credentials to access the Hospital Local Network

Once a hacker obtains details of the Wireless configuration, he/she can wirelessly gain access to the hospital network. Any device on the network including connected medical devices as well as traditional PCs and laptops are now vulnerable to attacks. Furthermore, the credentials to the pump servers are exposed which can lead to unauthorized access and/or loss of PHI or EHR data.

Another attack vector is the injection of rogue/malicious access point impersonating a legitimate one. Combined with the encryption key already attained, the attacker can decrypt the network traffic. As an exercise, we reconfigured the pump to connect to a rogue access point. Figure 11 illustrates the connection to a rogue access point with the SSID of “ZINGBOX_INSIDE”. It’s important to note that any changes made to the internal memory were written back to the non-volatile chip making the changes persistent through reboots. The CRC check to prevent changes to internal flash memory was easily bypassed since the file housing the value was writeable.

Conclusion

IoT devices represent new attack vectors to various industries. Consequences to industries such as healthcare can be disastrous. Healthcare environments require physical interaction between patients and many medical devices. Such close interaction is unavoidable and, therefore, physical security is a mandatory protection on those devices. Security controls must be implemented based on the assumption an attacker will have physical access with sensitive and critical devices.