Scan For Security Vulnerabilities in Medical Devices

Security Testing, Fuzzing, and Certification of Medical Devices

Security testing for networked medical devices should be one of the top priorities, to ensure safety and privacy.  Medical devices, fully self-sufficient appliances, aim to revolutionize the healthcare industry. They educate and empower patients to keep a check on their health, aid doctors and patients detect disease(s), assist in medical processes, let patients control and manage their health and make personal fitness more exciting.  

Modern medical devices are often categorized into:

  • Wearable – Health monitors, portable devices such as insulin pumps
  • Embedded device – Pacemakers
  • Onsite device – Medical x-ray scanners, MRI machines

Healthcare information systems, on the other hand, are designed to comprehend, store, manage and communicate information related to patient health or activities of healthcare service providers and assist them in delivery of healthcare services. To comply with various federal stipulations and regulations and to ensure seamless, automated healthcare service delivery, it is imperative that any medical device not only functions as intended by its manufacturer, but also stays secured from system malfunctions largely driven by system design failure or forced manipulation by “man in the middle” attack, especially during interconnect phases, from malicious actors.

Medical Devices – Network and Accessibility

A state-of-the-art clinic is a complex system. It consists of sophisticated medical equipment that operate through fully functional computers with an operating system and required applications installed on them. Connecting medical devices to EHR systems has considerably brought down the time it takes to keep a check on the vital patient data. Not only do physicians depend on digital information stored in the computers, but also most of the healthcare technologies are connected to the Internet. Ranging from monitors, infusion pumps, CT scanners to ventilators, each device contains critical patient information.

Networked Medical Devices

A typical hospital network consists of VLANs (virtual network segments) based on their type, function or profile. These segments are setup to plug onto the LAN of the hospital network, either directly or via tunneling. Usually, most modern hospitals use the Computerized Maintenance Management Systems (CMMS) to manage their medical device inventory. Many of these systems are connected to the network and allow communication with the medical devices for maintenance purposes. Often these systems are complemented or integrated with Real-Time Location Systems (RTLS) to support locating and managing devices. Other sections of the network such as Clinical, Business and Administrative sections also feed on to the same LAN.

  • Clinical and Business – Networked medical devices are linked with other IT modules in the hospital, like the EHR, HIS (Hospital Information System) as well as administrative systems for inventory management, billing, etc.
  • Administrative – From an enterprise IT angle, medical devices and their allied components should be accessible and managed by Enterprise IT functions, be it a Configuration Management Database (CMDB) or a single-sign-on (SSO) system.
  • RTLS – In case of wireless technology, RTLS is employed to instantly look for usable equipment for treatments. Advanced monitors can keep a check on patient movements and warn staff as soon as there is an issue.

One of the most important components of this network is the security module which plugs onto both the LAN setup as well as WAN setup. These VLAN configurations provide an additional degree of protection from network-based attacks and most importantly, should an attack occur, they help to contain an outbreak. Security testing for these network medical devices is imperative.

Accessibility of networked medical devices

Imagine you are recuperating from a surgery. A few wireless body sensors that help you remain mobile on the hospital bed or around the room with ease are fitted on you. Once the initial recovery stage is over, you are allowed to return home early, provided you carry the body sensors with you. At home, your physician remotely keeps a check on your vital statistics transmitted through a wireless hub connected to your residential network. Due to advancements in connectivity and accessibility to networked medical devices, such a development is likely to become the regular norm for post-operative care.

Wireless technologies are significantly improving the quality of healthcare by offering exceptional mobility to patients while providing healthcare professionals an easy and real-time access to patient data. Most medical devices attached to hospital networks are remotely accessible from other points on the network, or even the public Internet.

A hacker may get an unauthorized access to the hospital network because of weak access control measures, thereby resulting in compromised confidentiality.  This is where security testing for network medical devices is incredible important. The generic method by which a hacker seeks to attack can broadly be placed under any one of the following:

  • Where the hacker has physical access to the networked device in the hospital
  • Where a deliberate attempt to hack the system is taken by an insider who attacks the network, which may be remote or local
  • When an insider unintentionally inserts an infected USB stick or any other malware-affected device

According to guidelines from FDA, the manufacturers must try and limit unauthorized access to medical devices and implement policies and practices for adequate data security. They must limit network access to trusted users only and must maintain a device’s critical functionality. Apart from restricting unauthorized access to the network and networked medical devices, health care centers must ensure use of antivirus software and firewalls, and should conduct periodic evaluation to keep track of individual network components.

Security testing for networked medical devices; vulnerabilities and causes

A year ago, the researchers at the University of Washington conducted an experiment on tele-surgery, where a surgeon in one location controlled a robot in another location and let the robot perform a surgery on the patient. The results of this experiment highlighted that using the Interoperable Telesurgery Protocol, which is publicly available, hackers can easily interrupt the commands sent by the surgeon to the robot by deleting or changing the commands, modify the intention of signals from the operator to the robotic arm by changing the robotic arm movements and take complete control over the robot and therefore the surgery procedure.

This explains how in an endeavor to improve interoperability of health care networks and devices, medical device security becomes a secondary priority for most manufacturers, whereas technological innovation holds maximum importance. As a result, patient care gets compromised as medical devices connected to the Internet pose substantial risks in being hacked by unauthorized users. In fact, according to a recent report from SANS Institute, 94% of health care centers have faced the perils of a cyber attack.

Of late, a number of medical device manufacturers are migrating their data processing activities to the cloud, thereby unknowingly adding another security threat vector. Manufacturers are also often indifferent to ensuring adequate security testing on networked medical devices, primarily because of a conflict of interest. They work with a profit objective in mind and compromise on the security of medical devices.

Manufacturers are progressively using Commercial off-the-shelf Software (COTS). As systems are becoming more multifaceted and feature-rich, COTS becomes a preferred design choice for a number of software architects. However, the major shortcoming of this approach is that the device automatically takes over the vulnerabilities of COTS. Additionally manufacturers use chipsets, applications and code libraries that are outdated and inexpensive so that they are able to maintain a higher profit margin. As such, these pose increased number of vulnerabilities and are incompatible to the modern day gadgets.

Any commercial software application makes a device vulnerable to malware or attack vectors and it is of key prominence that manufacturers strengthen the device using security best practices such as disabling unnecessary ports or components of the commercial software, which are not in use and including the component in the device’s security notification and patching process.

Vulnerabilities in networked medical devices may include, but is not restricted to, device flaws in terms of hardware, software or technical security controls and physical security controls. Some of the most common vulnerabilities present in wired and wireless networked medical devices include the following:

  • Use of open communication networks which are easy targets for hackers to seize or hijack signals being sent to a device
  • Electromagnetic interference which results in disruption of regular working of a networked medical device
  • Embedded web services with illegal and unencrypted communication which have the capability to affect devices remotely from anywhere in the world.
  • Untested or defective software and firmware which leads to higher probabilities of exploiting an existing bug in the system
  • Lack of basic security features in medical devices, resulting in life-threatening patient safety issues (Often security features are added post the design stage or even during implementation, which disrupts clinical workflow and are implemented poorly.)
  • Unapproved applications and destructive devices operating on the hospital network that either permit unauthorized access or interfere with other devices.
  • Security vulnerabilities in off-the-shelf software designed to prevent unauthorized device or network access, such as zero authentication, poor coding, SQL injection.
  • Threats related to security and privacy factors
    • Wrongly configured networks or poor security practices which allow easy access to hackers
    • Failure on the part of the manufacturer to install security software updates and patches in a timely manner to medical devices
    • Lack of security efforts taken to dispose of patient information, including test results or health records
    • Failure in observing security details related to passwords for software made to access privileged medical device. Often employee negligence results in usage of weak passwords, unchanged default passwords, or passwords left unattended. Also there are instances of uncontrolled distribution of passwords, disabled passwords and hard-coded passwords for software installed for privileged device access.
    • Use of obsolete operating systems which might have unpatched vulnerabilities for Internet connected medical devices including a radioactive medical equipment
    • Ability of cybercriminals to access administrative links through non-administrative portals such as a user interface, which in turn might result in compromising the safety of a device controlled with this application
  • Gaps which can be exploited through reverse engineering based on device information available in public forums such as certification agencies, device manuals and patent databases

Vulnerability management

Addressing security testing networked on medical devices threats and preventing information security risks is a big challenge. Since it is practically impossible to eliminate cyber security threats completely, manufacturers and health care centers must put in efforts to minimize them. It is very important to maintain a proper balance between safeguarding patient information and supporting the use of innovative technologies for enhanced device performance.

Currently, in most cases, under pre-meditated cyberattacks, health care centers face complete breakdown in regular operations as they lack the ability to detect such an attack. IT, risk and compliance staff in hospitals and clinics should anticipate future medical device security risks and address them along with the existing risks to provide patient safety and protected health information. Moreover, it is extremely important that manufacturers and companies dealing with medical devices begin to implement security strategies right from the inception of a device up to its commercialization.

It is vital to reduce the risk of exploitation of vulnerabilities by limiting access to networked medical devices to specific user groups and implementing layered network protections, including endpoint and network activity monitoring, firewall and antivirus software.  Typical risk mitigation approaches include isolating medical devices that do not meet security standards, sampling devices randomly to gauge compliance and constantly monitoring and taking appropriate measures to maintain device security. Some recommended security standards to address the risks intrinsic to security testing networked medical devices include the following:

  • Medical device manufacturers must emphasize on device security at the initial stage, than as an afterthought to avoid unnecessary costs and last minute shortcuts that developers take to push in some form of security factor.
  • Use strong passwords to protect all external connection points.
  • Develop on-time patch management, update IT security policies and vulnerability assessments.
  • Increase awareness among all stakeholders including physicians, Chief Medical Information Officers (CMIOs) and clinical engineering teams about current and potential medical device vulnerabilities.
  • Protect infrastructure from threats like malware and hacking attacks with a reliable security solution.
  • Take a backup of critical information at regular intervals and keep a copy of it offline.

QA testing for networked hardware and web applications

Given the numerous ways programmers can make mistakes, looking for security vulnerabilities in a piece of software should be an integral part of the development process. That is not always the case as security testing on networked medical devices of a particular product can be an expensive proposition and developers often weigh expense against cost of other factors involved in releasing the product to its customers. Also their knowledge about security threats is restricted. As such, when it comes to ensuring device security, it loses priority over the delivery of the product. Because of this, even software developed in an environment stringently cognizant of security risks is most likely released without full testing.

Naturally when the application is released, hackers will bash away at it with every possible corrupted form of the protocol to create an error in the application. By pushing at the edges of the envelope of the protocol, they may find a way to trip up the application and create a buffer overflow, the most frequently leveraged design error.

How are hackers finding buffer overflow opportunities missed during development and standard pre-release QA? A wide range of tools have been developed by the hacker community to enable the rank and file to find new exploits. These tools, fuzzers, work by creating and feeding a wide range of unexpected or corrupted inputs looking for a combination that will break the application. The production of these tools has become a small industry of its own. The QA world has attempted to adapt these rough and ready hacker tools into their test processes with some success, but also with many headaches. Most of these hacker-developed fuzzers are focused on a single type of code weakness or just on a single protocol or even on a single application.

Even after all the QA testing being done, buffer overflow error tests, protocol breach tests, and black-box testing should be done to further reduce the scope of adding vulnerabilities to the devices.

Buffer overflow errors – vulnerabilities generated during application development

Translation of requirements during application development is the first cause of most programming errors. For instance, during the development of an application for a pacemaker, a project manager translates the requirements from the desired end to the programming team, which members translate to individual programming assignments. The programmers then translate the assignment into a proper syntax for the programming language. All these translations are sources of potential programming errors during the design stage.

Off-by-one errors, programming language use errors, integer overflows are all examples of errors generated by a programmer while translating a concept to a proper algorithm. For example, to hold ‘n’ items that are each ‘m’ bytes long, the programmer may tell the program to allocate n*m bytes. If m*n is larger than the biggest number that can be represented, less memory will be allocated than intended. This may lead to a buffer overflow.

However, not all programming errors are created equally. Some allow attackers to gain something or to get an ability they didn’t already have. They may be able to deny other users’ access to the program by crashing it, or access information they shouldn’t be able to. In some cases, they may be able to cause the program to execute any command they tell it. These errors are vulnerabilities. Other errors, while they may have the same causes, won’t give attackers any access they didn’t already have. So, the first task for a vulnerability researcher is to determine if the programming error is merely a bug or if it can lead to exploitation. If a bug can lead to exploitation, either by itself or when used in concert with other bugs, it is indeed vulnerability

Also insecure coding practices occur when software developers do not take into account the introduction of logical security vulnerabilities. Software defects (software errors) and logic flaws can be exploited to compromise medical devices. Insecure coding practices are very dangerous because it may enable an attacker to take over the device’s functionality, acquire its data, or prevent the device’s software from working at all.

Multi-protocol, environment-variable ‘Smart’ fuzzers like beSTORM, which has been formally approved by the ISA Security Compliance Institute (ISCI) as a communication robustness testing (CRT) tool for use in ISASecure® Industrial Automation and Control System (IACS) certification, are vital for finding buffer overflow weaknesses, not only because they automate and document the process of delivering corrupted input, but also because they closely watch for unexpected response from the application. For example, beSTORM will try packets with malformed headers, by manipulating packet content and providing the kind of data that the application may be looking for, using &, <, >, full stops and commas within email applications, or typical URL symbols for HTTP servers. This is simply unviable if done manually.

Protocol breaches – vulnerabilities generated when APIs communicate with devices

Device protocol APIs allow applications to talk to a device over industry standard protocols. Developers need to simply identify the device and then open a communication channel to it. Opening a channel prompts for access authorization. This is a critical step to help prevent programs from accidentally or maliciously communicate with one or more devices without the user’s awareness. Once access is granted, the program can communicate with a device, including starting long data transfers.

Being able to attack the actual implementation of the protocol by generating attack vectors that target basic coding errors such as mishandling of input validation or boundary checking (defensive programming errors), design flaws (logical, design specification, and similar), and the implementation of the protocol itself, is how hackers achieve better results.

The use of more advanced manipulations based on the basic two types (value manipulation and protocol manipulation) also considerably impacts the capability of today’s fuzzers to provide results. For example, trying to exploit a logical flaw in the program by sending a login request twice and then combining it into the melting pot of attacks increases the number of combinations required, and the success rate. Being able to work with more advanced protocols, requiring the fuzzer to wait for a response before sending the next request (basically establishing sessions with the attacked application-session-based fuzzing) is another step in fuzzing.

beSTORM, perhaps the only multi-protocol, environment-variable ‘Smart’ fuzzer, officially recognized by the ISA Security Compliance Institute (ISCI) as a communication robustness testing (CRT) tool for use in ISASecure® Industrial Automation and Control System (IACS) certification, addresses protocol breaches by testing over 50 protocols and ‘auto learns’ new or proprietary protocols while providing automated binary and textual analysis, advanced debugging and stack tracing.

Black box testing – protocol-based fuzzing for application and device testing

This is a technique that works by automatically feeding a program multiple input iterations that are specially constructed in a way to trigger an internal error indicative of a bug, and potentially crash it. Commonly referred to as “fault injection” technique, black box testing can be applied to a network service as much as to a CPU, a cell phone, program parameters, an API, a Web browser, or a file type.

Testers with no knowledge of the internal working of the application being tested go about their work by first sniffing traffic at target protocols, generate input iterations from what they observe, and then drive ‘Random’ or ‘Garbled’ messages or ‘Legal’ mouse and keyboard events at the application until vulnerabilities emerge. Application monitoring can vary from a watchdog that sees if the program is still running to a remote check to see if the service is still available and responding or all the way to more advanced techniques like watching with a debugger for an anticipated exception. By value manipulation, only a specific data set is tested for specific value changes and through protocol manipulation, the entire protocol structure implementation can be tested or both.

The solution is to catch application flaws during development using the best fuzzer you can get – when correction is relatively easy and far less expensive.

By applying automated protocol based fuzzing techniques, beSTORM, a powerful automated black box auditing tool, tries virtually every attack combination, intelligently starting with the most likely scenarios and detects application anomalies, which indicate a successful attack. This way security holes can be found in the application far faster, without brute force testing and almost without any user intervention. Easily scalable, beSTORM is equipped with the ability to use multiple processors or multiple machines to parallelize the audit and substantially reduce the testing duration.

beSTORM – an automated fuzzer

Beyond Security’s beSTORM is an exhaustive fuzzer. A powerful black box auditing tool, it is designed to find security weaknesses in protocol implementations and uses formal RFC definitions to create an attack language which in turn is used to identify vulnerabilities in the tested application. It supports testing for predetermined test cases and tries to exploit more likely vulnerabilities before continuing with the full test, its main objective is to allow for the most complete testing that will cover as much of the protocol space as possible. With beSTORM, it is also possible to write custom modules for proprietary protocols using XML.  It can be a great tool to use for security testing on networked medical devices, keeping these devices safe for patients and adhere to privacy standards to protect that information.