Medical devices are found in modern hospitals, medical practices and laboratories. These specialized devices are used by qualified personnel to gather, evaluate, display and send medical data. This article describes the methodical approach a security analysis for medical devices. In the broadest sense this is also applicable to other specialist equipment.

Actual usage

As with any security check, it is a good idea to gain an understanding of how a system works in real life, as soon as possible. This knowledge is available in the form of manuals and instructions, or by having a qualified specialist demonstrate day-to-day usage of the system. In the case of medical devices, it is best to talk to the nursing staff who use these devices every day. This can help answer these basic questions:

• What does the device do?
• Where is it typically used?
• What data does it gather?
• How is information displayed?
• What other interfaces are there?

You should then try to operate the device yourself and run it in normal operation. It can be helpful to look through the menus and settings to gain an understanding of the underlying processes as well as the technical options. Medical technology personnel can help here as you examine administrative aspects and technical details of the devices.

Local analysis

When first attempting to use the device you will gain an initial understanding of the ways in which it may be vulnerable to attack. For instance, is it possible to overwrite the parameters on an infusion pump, in turn having negative consequences for the patient?

Here it is important to bear in mind that all medical devices are controlled by computer systems of varying complexity. Some of them include proprietary platforms with superior isolation. However, Linux or Windows solutions are often used as the underlying foundation upon which the actual medical functionality is built. In the development phase, there is usually greater focus on these other functions than on the fundamental security architecture of the operating system and software. Maintenance of the non-specialist components, including the operating system, is ignored in most cases. Along with the configuration-based hardening, patching in particular is neglected.

Some medical devices are run in kiosk mode, meaning that the user can only use the functions required to operate the medical device. For an ECG, for example, the data is always displayed in full-screen mode. Clicking away or closing this modal display is prevented by selectively hardening the operating system and the developed software.

The solution in this case is one that has been around for over ten years in the Citrix environment. By design, opening certain functions results in the granting of additional rights. A classic example is initiating a help or print dialog. Here the system searches for websites to find clickable links, which can then be clicked and opened in the standard browser. Most browsers in Windows environments can be used as local file explorers by entering C: in the address bar. This enables mapping of disk drives and the opening of other files and programs.

Once someone has made it this far into a system, they can attempt to disable the installed components (including version numbers) as well as installed patches. This allows them to gather critical information on other potential avenues of attack. Local exploits are usually available in various forms, making it possible to acquire further rights at will.

External interfaces

Most medical devices have one or more external interfaces. These are used either for initialization or programming, or they are a fixed component of data processing, enabling the input or output of data.

Today’s devices typically have RJ45 interfaces for network access (covered in a separate chapter). However, RS232, PS2 and USB interfaces are also common. In addition, a number of manufacturers use proprietary connectors that are often built on serial mechanisms. With a bit of tinkering and reverse engineering it is possible to discover other access points.

These interfaces can serve to carry out analyses, attacks or to use additional functions. For instance, USB interfaces can be used to implement new code. Particularly in Windows environments, this makes it relatively easy to introduce attack tools, exploits and malware in file form. Where this isn’t possible, input devices can be emulated with Teensy for example to attempt an attack (e.g., brute force, generation of malware on-the-fly).

This overlaying of key displays can enable surreptitious attacks that are a risk to life and limb. When medical devices are linked to a medical network or other internal network in the hospital, attacks can also be carried out on other systems. Once overtaken, equipment can cause considerable damage to patients, the hospital, operators and external partners.

Network analysis

Modern medical devices are networked. This is to simplify access through, for instance, a proprietary client or web interface. Or, taking it one step further, it can allow data to be exchanged between various devices, the backend or a centralized monitoring system.

This interconnectivity often introduces a large number of additional potential targets for attack. Reading incoming and outgoing communications can allow services and protocols to be identified. This can be done with a network tap, which has no further impact on network operations, thus making it easy to carry out passive monitoring.

Additionally, external parties can actively look for attack targets at the network level, including vulnerabilities in the TCP/IP stack. Classic flooding, fragmentation and spoofing attacks have a high chance of succeeding here. Sometimes old attack techniques can be revived, or there are additional opportunities offered by TCP and UDP services. These and other attack targets can be identified using a port scan and application mapping.

Obsolete services and components often turn up and typically include web server implementations, SSL components and additional modules. Once this kind of versioning is identified, it is relatively easy to exploit known vulnerabilities.

However, this should not disguise the fact that previously undiscovered 0-day vulnerabilities may be hidden in network components. Either the components are so outdated that they are not equipped to deal with newer attack techniques, or proprietary or modified modules are applied which were not developed with security as a priority. A concrete penetration test can bring solid results to light.

Hardware analysis

With some systems it is not possible to easily eliminate potential avenues of attack. Yet there are, without a doubt, attack possibilities lurking within the devices.

Hardware analysis can be made a priority to identify these risks as well. Here data carriers and chips are removed and examined separately.

Once a data carrier can be removed and controlled, it can be mirrored and viewed at the file system level. If the file system is unknown because it is proprietary, you can attempt file carving. If there is no encryption of the data carrier or data, it is possible to extract the existing data.

Examining configurations can offer up valuable information, sometimes even established passwords. And with reverse engineering of binaries, you can identify specific vulnerabilities in individual software components.

Typical measures

Once medical devices are tested, the list of measures to be taken can be comprehensive and multi-layered. The fundamental problem is often that the systems are not developed, integrated and operated with a focus on security. In many cases, no thorough hardening has been performed. For various reasons it is often impossible for hospital administrators to fill this gap on their own. Not only does it void the manufacturer’s guarantee, but rather the product’s expensive certification as well. Furthermore, the access rights that would even allow such technical modifications are often missing.

For these reasons it is advisable in each case to contact the manufacturer directly to close vulnerabilities. Few manufacturers, however, see themselves as obligated to do so, which is why even known vulnerabilities can persist for years. Manufacturers are often only willing to relent when advisories are published, thus increasing public pressure.

Directly minimizing the number of possible attack targets requires undertaking measures in the local network – zoning, VLAN, firewalling, NAC, IDS and IPS are the operative words here. Implementing these methods is often associated with a large amount of effort, as the exact technical functioning of the devices is often unknown and discovering it is laborious. This analysis and flanking is particularly worthwhile in cases when large numbers of the same device are used (e.g. infusion pumps and ECGs).

Summary

Medical devices are a permanent fixture of modern patient care. This equipment usually takes the form of specially configured computer systems that are meant to perform a specific task. It is important for any security test that this task be understood, through consulting manuals or qualified personnel.

Attack targets can appear at various levels. Local attacks can be carried out during use of the device, while attacks may also be deployed over the network. Where the isolation of the system prevents further attacks, hardware components can be removed and tested separately.

Once a vulnerability is found, the manufacturer should be contacted with the request for a correction. For political and economic reasons, however, many manufacturers feel no obligation to act, thus requiring flanking measures at the network level. Securing medical devices is no easy matter. Despite – or perhaps precisely because of this – it is therefore imperative.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://www.npr.org/sections/alltechconsidered/2016/04/01/472693703/malware-attacks-on-hospitals-put-patients-at-risk
• http://www.npr.org/sections/thetwo-way/2016/02/17/467149625/la-hospital-pays-hackers-nearly-17-000-to-restore-computer-network
• https://vuldb.com
• https://vuldb.com/?id.75158
• https://vuldb.com/?id.76315
• https://www.computec.ch/download.php?view.747
• https://www.pjrc.com/teensy/