1 Introduction

Healthcare Delivery Organizations (HDO) are complex infrastructures where a broad range of information technology, operational technology, and Internet of Things (IoT) devices are increasingly interconnected [1]. Specialized IoT devices, often referred to as Internet of Medical Things (IoMT) [2], are used to support clinical care. They can, for example, deliver treatment (e.g., infusion pumps), track patients’ vital signs (e.g., patient monitors), or perform analysis on samples (e.g., blood analyzers). These IoMT devices can communicate with other systems within the HDO by sending and receiving data over healthcare network protocols.

While these technologies and increased connectivity improve the efficiency and quality of care, they can also introduce threats. A growing body of security research conducted on healthcare network protocols and medical devices demonstrates the risks of attacks which can have critical consequences for patients (e.g., [3,4,5,6,7,8]). Examples include the ability to manipulate the amount of drug delivered by infusion pumps [9, 10], or the interception and modification of patients’ medical data such as real-time vital signs [3] and even CT scans [11].

The network analysis we performed in [12] reveals the usage of other healthcare protocols for which, to the best of our knowledge, no security research has been performed. This represents an issue for HDO and patients as these protocols could potentially be abused in similar ways mentioned above. This situation calls for security research to be conducted on these protocols in order to gain a greater understanding of the risks these technologies may introduce.

This knowledge can contribute to enhancement of the security posture of HDO as it can be leveraged to implement and/or fine-tune security controls. More specifically, protocol security research can enable the improvement of network security monitoring solutions such as intrusion detection systems (IDS) for HDO in multiple ways. For example, new signatures for IDS can be created, giving them the ability to detect malicious activities. Additionally, one can create network traffic datasets relevant to HDO, which can be used for the testing of novel environment-specific IDS and other security tools. In fact, as shown in [13], current datasets available are often limited or ill-suited to reflect the modern threat landscape (e.g., lack of real-network attacks, or large number of deprecated threats).

Performing security research in HDO can be challenging for two reasons. First, experimentation in “live environments” may be not feasible, as it can introduce risks for HDO’s operations by altering the functioning of devices. Common security testing procedures such as port scanning can crash systems that are connected to patients and deliver care [14]. Second, obtaining network traffic data to conduct research offline can be difficult since such data is likely to contain patients’ information and therefore cannot be shared due to regulations. Consequently, it is essential to have dedicated labs to perform security research in safe and controlled environments, yet realistic enough to guarantee the validity and accuracy of the experimentation.

In this paper we conduct security research on three healthcare protocols and investigate how they can be abused. These protocols are the POCT1-A and LIS02-A standards used to connect point-of-care and laboratory devices with laboratory information systems (LIS), and the proprietary protocol Data Export which can be used to collect data from Philips patient monitors. After introducing previous work done on healthcare protocols in Sect. 2, we start by detailing our experimental setup in Sect. 3, including the objectives, methodology, the selection of targets, and explain how to build a lab containing medical devices and other systems required for our research. We then introduce in Sect. 4 our attacker model and demonstrate four attacks targeting these protocols, highlighting the potential impact to HDO’s operations and patients’ safety and privacy. The contribution of our work is three-fold: 1) the lab setup we present can be used as a blueprint to pursue security research on medical devices in a safe environment, 2) the demonstration of attacks highlights how attackers could exploit weaknesses in healthcare networks, and 3) security measures in HDO can be improved with the creation of new signatures and datasets to assist the development and testing of HDO-specific IDS (Data sharing not applicable to this article as no datasets were generated).

2 Related work

Some of the literature focuses on certain healthcare network protocols, including non-proprietary protocols such as Health Life Seven (HL7) or Digital Imaging and COmmunications in Medicine (DICOM), and proprietary ones like RWHAT. HL7 standards are used to exchange patient data between systems, and is considered to be “the most widely implemented standard for healthcare in the world” [15]. Several studies have shown how it can be abused in hospitals due to insecure implementation. Duggal explains in [16] how to attack HL7 2.x standards. He outlines the critical parts of HL7 messages, and demonstrates ways to abuse HL7 interfaces, including how to perform denial of service (DoS) attacks and how to fuzz HL7 services running on machines in hospitals. Haselhorst proposes similar attacks in [7]. He shows how to execute DoS attacks by exhausting the number of simultaneous connections supported by an HL7 interface in order to block further legitimate connections. Additionally, he points out the lack of authentication by default, allowing anyone on the network to craft and send HL7 messages. Dameff et al. [17] developed a tool that exploits the lack of authentication and encryption in most HL7 deployments. Their tool automates the process of performing a man-in-the-middle attack and changes laboratory results from healthy values to those indicating serious illness.

DICOM is the international standard involved in medical imaging processes, and is used for the exchange and storage of images captured by imaging modalities (e.g., CT scanners) [18]. Chantzis et al. explain in [4] how to create a custom protocol parser in Wireshark,Footnote 1 and how to develop a DICOM Service scanner for the Nmap Scripting Engine.Footnote 2 This scanner can identify DICOM Service Providers on the network, test their configuration and launch attacks. Mirsky et al. developed in [11] a tool which can intercept patients’ CT scans over the network and modify them by adding or removing tumors.

McKee investigates in [3] the RWHAT proprietary protocol used by some bedside patient monitors. He demonstrates the feasibility of modifying patient’s vital signs recorded by a patient monitor while being transmitted to a central monitoring system (CMS). Tampering with vital signs can lead to serious consequences for a patient, including “extended hospitalization, additional testing, and side effects from medications prescribed to control heart rhythm and/or prevent clots” [3].

3 Experimental setup

We explain in this section the objectives of our research and the selection of protocols and medical devices. Finally, we present the design and setup of our testing lab.

3.1 Objectives & methodology

We aim at discovering vulnerabilities in a selection of healthcare protocols and medical devices, and demonstrating attacks exploiting them. More specifically, our objective is to create a number of novel network attacks which could impact HDO’s operations, patients’ safety and data privacy. The purpose of these attacks is to enable the creation of new IDS signatures and datasets relevant to this environment, ultimately improving network monitoring capabilities [13]. While this work follows the examples of previous healthcare security research, we focus on different protocols.

Based on our research conducted on HDO networks in [12] we identify and select healthcare protocols for which no attack has been yet published (to the best of our knowledge). We then acquire devices using those protocols. Our objective is to first understand the communication patterns between the devices and how the protocols operate. We specifically look at how the packets are formed, and what kind of data they convey, among other things. We then investigate whether these communications can be abused by, for instance, spoofing devices, intercepting packets and tampering values on the fly. Furthermore, we also want to identify if the medical devices can be remotely controlled by sending commands via these protocols, similarly to other protocols like BACnet [19].

While it is important to understand how the devices and protocols work to find weaknesses, we limit the explanation of their functioning and specifications to the amount necessary for our study. We focus here on the demonstration and consequences of the novel attacks we found, and refer the curious readers to the specifications of the devices and protocols for deeper understanding.

3.2 Targets

The protocols selected for this study are POCT1-A2 [20], LIS02-A [21] and Data Export [22]. The two first protocols are used for interconnecting point-of-care and laboratory devices with information systems such as laboratory information systems (LIS) or data management system (DMS) [20, 21]. These protocols enable the exchange of clinical results and patient data between laboratory instruments and information systems [21]. Additionally, they can be used by clinical staff to issue test orders and remote requests to devices. Data Export is a proprietary protocol which can be used by Philips bedside patient monitors to connect them to a computer [22]. It provides a means for clinical researchers to collect data such as measurements (e.g., heart rate, arterial oxygen saturation), electrocardiogram waves, patient demographic information and patient monitors’ system data.

We acquire several devices that use the selected protocols. Obtaining these devices enables us to generate real data and observe “live” communications. This situation helps greatly in understanding how the protocols operate, and also to test attacks. We choose a Siemens DCA Vantage blood analyzer for the analysis of both POCT1-A2 and LIS02-A, and a Philips IntelliVue MP50 patient monitor for Data Export. The blood analyzer measures the glycaemia in patients with diabetes and detects early kidney disease, while the patient monitor is used to track in real-time vital signs of a patient.

Note: The LIS02-A standard is a revision of the former ASTM E1394-97 standard [21]. While the specifications of the Siemens DCA Vantage cover the usage of ASTM, this information applies to LIS02-A.

3.3 Healthcare lab design

We start our security research by setting up a test lab containing the aforementioned medical devices and other systems required. It enables us to experiment with attacks in a controlled and safe environment. We present below our lab by first introducing its architecture, then the tooling installed on the devices, and finally the basic functioning of the devices and protocols.

3.3.1 Architecture

The lab we build is depicted in Fig. 1. It consists of the aforementioned medical devices, as well as a collection of computers, interconnected all together via a network switch.

Fig. 1
figure 1

Network layout of our healthcare lab

Full size image

The devices require to be provisioned an IPv4 address upon boot before being able to communicate. To fulfill this requirement we add a Raspberry Pi 3 to the network and configure it as a DHCP server. For the purpose of analyzing protocols, it is important to be able to observe real-time network traffic as it is generated by the devices. For this reason, we configure one port of the switch as a SPAN port on which all network traffic is mirrored, and we connect a computer to it which will be used as a network tap.

Regarding the protocols of interest, we can generate and analyze POCT1-A2 and LIS02-A traffic by deploying a LIS server which communicates with the blood analyzer and stores test results. For Data Export, we consider in our research a scenario where this protocol is used to interconnect the patient monitor with a computer acting as a central monitoring station (this computer is further referred to as the CMS). Such monitoring stations are commonly used in hospitals to remotely display the patients’ vitals coming from several monitors, allowing nurses to watch over multiple patients from a single location [3]. However, as stated in the protocol’s specifications, the protocol is designed to enable data collection for clinical research purposes, and must not be used as real-time alarming system due to the risk of data loss [22] (p. 10). Moreover, the specifications also state that the Data Export interface “cannot be accessed via the Local Area Network when the monitor is connected to the Philips LAN” [22] (p. 10).

Although our architecture goes against the intended protocol design, we do so in our lab to highlight two things. First, the methodology we present can still be replicated to analyze other protocols used in HDO to interconnect patient monitors and CMS. Second, as data collected for clinical research can be used for the development of machine learning models [23], it is relevant to consider how protocol abuse could be leveraged by threat actors to perform machine learning-specific attacks such as model poisoning attacks [24]. With this in mind, we deploy in our lab a computer configured to act as a CMS on which we can observe the real-time readings sent by the patient monitor.

Finally, we connect a laptop (referred to as Attacking Machine in Fig. 1) to the switch to represent an attacker on the network. We elaborate on the capabilities of the attacker later in Sect. 4.

3.3.2 Software & tooling

For the lab, as depicted in Fig. 1 to be operational, we need to configure the devices and install or simulate related software and services. While the medical devices are deployed with their default configuration and the network switch is configured as described above, we install/develop the necessary tools on the other devices as follow:

  • LIS: Since no suitable open-source solution for LIS can be found, we implement a simple LIS02 server using Python ASTM and a POCT01 server according to the communication specifications of the Siemens DCA Vantage analyzer [25]. This setup is for proof of concept only in our lab, and is not used in HDO nor recommended by Siemens.

  • CMS: We install the IxTrend Express softwareFootnote 3 on the computer acting as a CMS. The program records medical signals from patient monitors for clinical research, and is selected for its support of the Data Export protocol. As mentioned above, this deployment goes against Philips’ recommendations, and is only meant for proof of concept in our lab.

  • Network tap: We install the software WiresharkFootnote 4 to capture and analyze network traffic. This tool is a powerful protocol analyzer, enabling us to inspect packets as they are passing on the network.

  • DHCP server: We configure the Raspberry Pi 3 as DHCP server by installing Bind9.Footnote 5 The device answers to the DHCPDISCOVER messages broadcasted by the devices on the network and provides IPv4 addresses to them.

  • Attacking machine: We install the tool EttercapFootnote 6 for traffic redirection and packet modification, and ScapyFootnote 7 for packet crafting. Additionally, we deploy on this machine a copy of our custom LIS02 server which is used as a rogue LIS server. We elaborate further on how these tools are used when presenting the attacks and proofs of concept. Note: In a real situation, an attacker would likely use a broader collection of tools to guarantee the success of her objectives. However, we consider for our scenario only the tools required for the execution of the attacks we present in Sect. 4.

3.3.3 Basic functioning of the selected medical devices

We describe below how the devices in the lab interact with each other over the healthcare communication protocols we are interested in. In particular, we look at how the devices are configured to operate on the network, then how communications are established and how data is exchanged.

Siemens DCA Vantage blood analyzer:

The configuration of the device is done manually by adjusting the settings directly on the device. The relevant configuration options for our study can be found in the Ethernet port settings menu. Particularly, the IP address of the blood analyzer can be set to be either automatic (provided by the DHCP server), or static (entered manually on the device). Next, we specify the IP address and port number of the LIS server we want to connect to. Finally, we select which protocol to use: the Siemens DCA Vantage can communicate with the LIS server over the LIS02-A and POCT1-A2 protocols. Below we describe the basic functioning of both these protocols.

Fig. 2
figure 2

Communications between the Siemens DCA Vantage and the LIS over LIS02-A protocol

Full size image

LIS02-A: When using LIS02-A, a session is created every time an operator wants to transmit data from the Siemens DCA to the LIS server, according to the procedure depicted in Fig. 2. As described in the Siemens DCA’s specifications [25] (p. 6), a session consists of three distinctive phases: Establishment, Transfer and Termination phase. In the Establishment phase, the Siemens DCA Vantage requests to establish the direction of communication by sending an inquiry character <ENC>, which is acknowledged by the LIS if it is ready to receive data. In the Transfer phase, the laboratory instrument can send messages as follow: it sends a Start of Text character <STX>, followed by the frame number FN (value from 0 to 7) and the Text corresponding to the content of the message to send. Finally, it finishes the transmission by sending a End of Text character <ETX>, a Checksum and the end of frame characters <CR><LF>. The LIS replies back with an <ACK> if the checksum value is correct. Finally, in the termination phase, the blood analyzer sends an End of transmission character <EOT> to the server, after which both devices return to their initial state.

Fig. 3
figure 3

Example of a LIS02-A message containing the result of a HbA1c test (example inspired from [21])

Full size image

Various information can be carried in LIS02-A messages: data about the laboratory instrument and the information system, patient (e.g., name, birth date, address, phone number, known diagnosis, etc.), test order (e.g., specimen ID, priority, ordering physician, etc.), and results (e.g., measurement value, unit, reference ranges, result abnormal flags). Figure 3 depicts an example of a LIS2-A message containing the result of Hemoglobin A1C test (or HbA1c test): by measuring the amount of glucose in the blood, these tests may be used to diagnose diabetes in adults [26]. LIS02-A messages consist of multiple records (each line represents a different record), which carry specific information.

In Fig. 3, some information of interest for our study is indicated by red boxes. The first record is the Message Header Record (H) and contains sender information including the product-code, software-version and serial number (box 1 on the figure), as well as the timestamp of message transmission following the format YYYYMMDDHHmmSS (box 2). The second record is the Patient Information Record (P), specifying the patient ID and name (box 3). The fifth record is the Result Record (R), displaying the universal test ID (“HbA1c”), the measurement (“2.5”), the unit (“%”), the reference range (“4.0 to 6.0”), and the timestamp of the beginning of the test analysis (box 4). A complete overview of LIS02-A messages can be found in [21].

POCT1-A2: The Siemens DCA Vantage can communicate with the LIS over flows of POCT1-A2 messages referred to as conversations, which consist of a number of topics exchanged. As described in the Siemens DCA’s specifications [25] (p.36), two types of conversations are supported: Basic profile, where a conversation is initialized, data is transmitted and the conversation is terminated, and Continuous Mode, where the conversation remains open after initialization, allowing the blood analyzer to send status change, device events and observations (i.e., test results) as they occur.

Fig. 4
figure 4

Communication between the Siemens DCA Vantage and the LIS over POCT1-A2 protocol

Full size image

As depicted in Fig. 4, a Basic profile conversation starts with the Hello topic, in which the Siemens DCA Vantage informs the LIS that it is ready to communicate. After receiving an acknowledgment of the LIS, the blood analyzer sends a Device status message indicating its current level of readiness (e.g., ready, busy, locked). After acknowledgment, the conversation goes to the Observations topic where the LIS requests observations (i.e., test results). The Siemens DCA Vantage sends them back, the LIS acknowledges the reception, and the blood analyzer finishes the transmission by sending an End of Topic message. The LIS then sends a directive to the device to enter the Continuous Mode: according to the device’s specifications, the Siemens blood analyzer requires a Basic profile conversion to be followed by a Continuous Mode conversation [25]. From there on, the communication is maintained and a number of other topics can be used [25] (p. 37). For our study, understanding the functioning of the Basic Profile conversation is sufficient. The details of the Continuous Mode conversation can be found in [25].

In the Observations topic, there is a number of message types that are supported by the Siemens DCA Vantage, such as Request Observation Message (REQ.R01, as shown in Fig. 4), Patient Observations (OBS.R01), Device Status (DST.R01) or even Remote Command Directive (DTV.SIEM.DVCMD). The exhaustive list along with descriptions can be found in [25] (p. 34). Patient Observation messages contain the results of a patient test. Such results are retrieved from the blood analyzer at the end of a test, or when a device operator performs a test recall. An example of an HbA1c result formatted according the POCT1-A standard is depicted in Fig. 5. It represents the POCT1-A equivalent of the LIS02-A test result shown previously in Fig. 3. The POCT1-A standard uses the XML format for the exchange of messages. The relevant parts of the message for our study are highlighted in red boxes on the figure. The first box contains the Service (SVC) information, indicating that the message is a patient test results (“OBS”), and it also includes the measurement timestamp and the sample sequence number. The second box displays the patient data (PT), which are the patient ID and name. The third box contains the actual observation results (OBS): the unique test identifier (“HbA1c”), the test value and unit (“2.5%”), as well as the reference range (“[4.0;6.0]”) among other things.

Fig. 5
figure 5

Example of a POCT1-A2 message containing the result of a HbA1c test (similar to the test presented in Fig. 3)

Full size image

Philips MP50 patient monitor:

For the purpose of our study, we first need to configure the patient monitor to communicate with the computer acting as a CMS (referred to as “the computer” in this section) over the Data Export protocol. Data Export is a message-based request/response protocol, and uses the Local Area Network (LAN) interface and the standard UDP/IP transport protocol [22]. The configuration is completed as follow. After being connected to the switch and booted up, the Philips MP50 begins by requesting an IP address on the network using the BOOTP protocol. The DHCP server answers to that request by supplying an address. The patient monitor then starts multicasting Connect Indication Event messages in a Data Export packet over UDP to port 24005, signaling its presence on the network. These messages contain information about the patient monitor such as the serial number, product number, hardware revision, appliance software, and software revision. The Philips MP50 keeps on sending these messages until an association is established with a computer.

The computer on the network can establish an association with the patient monitor as described in detail in [22] (p.25). The association is created (and terminated) according to a certain sequence of messages depicted in Fig. 6.

Fig. 6
figure 6

Communication sequence between the Philips MP50 patient monitor and a computer to establish an association, transfer data and close the connection

Full size image

When the computer receives a Connect Indication message, it can send an Association Request message. The Philips MP50 receives it and sends back an Association Result message, to either accept or refuse the association. If the association is accepted, the patient monitor sends next an MDS Create Event Report message, containing information about its system and its configuration. This message must be acknowledged by the computer with an MDS Create Event Result message. From this moment on, the computer can send Poll Data Request messages to the patient monitor to retrieve information such as vitals measurements, alerts (e.g., patient alarms), patient demographics or system attributes (e.g., version numbers). The Philips MP50 replies to these requests by sending Poll Data Response messages containing the data queried. The computer can chose to close an association by sending an Association Release Request message to the patient monitor, which will be acknowledged in return with an Association Release Result message from the patient monitor. In case of a communication issue, the Philips MP50 can send an Association Abort message to the computer, indicating that the association has been stopped (not shown in Fig. 6).

3.4 Remarks and communication with manufacturers

Before deploying the devices in the lab as described above, we first performed a vulnerability assessment on the two pre-owned medical devices which were obtained via an online auction site. We leveraged various sources detailing IoT device assessments such as [27] to structure our work. Starting with a function evaluation, we set up and configured the devices to operate according to their “normal specifications” in order to understand how they work. We then performed a physical inspection to evaluate the physical attack surface of the devices. Based on the results, we then attacked the exposed interfaces identified.

We spotted several issues with the DCA Vantage blood analyzer which were reported to Siemens and we worked together through the responsible disclosure process to address the following findings. The DCA Vantage is operated by the users via the restrictive user interface called the kiosk app [4]. This application limits the actions that can be executed by a regular user (e.g., a nurse), and provides an authentication mechanism to allow a privileged user (e.g., technician) to perform maintenance operations and change the system configuration. While users should not be capable of escaping from the kiosk app, we found that it is possible to break out from this application by connecting a keyboard to the exposed USB port and using specific key-stroke combinations. This allows us to gain access to the underlying OS and file system, granting us the possibility to run arbitrary code and retrieve files stored on the system. This Improper Access Control vulnerability was reported to Siemens and assigned the number CVE-2020-15797. We also found that the DCA Vantage contains several pieces of sensitive and confidential information. For instance, we extracted a database in the system in which we found data such as administrator password, test results and device logs. The password corresponds to the four-digit pin required to authenticate a privileged user (for the authentication mechanism mentioned above). This vulnerability, commonly referred to as Use of Hard-coded Password, was reported to Siemens and assigned the number CVE-2020-7590.

Table 1 Attacks on medical device protocols implemented in the lab
Full size table

No vulnerability was found in the Philips IntelliVue MP50 patient monitor in the time allotted for the assessment. While the attacks on the Data Export protocol presented in this paper demonstrate the risk of (semi-)plain text protocols in general, they do not constitute an attack on the Philips device per se (i.e., they do not exploit a vulnerability present in the device). Therefore the device is not considered “vulnerable” and there is no specific vulnerability disclosure related to these attacks. Our results were not formally discussed with contacts at Philips. The attacks in this paper have limited impact, especially if the device’s interface and protocol are used as intended and documented by the manufacturer [22].

Finally, our findings also reveal potential privacy issues. The test results stored in the database we retrieved are presumably from a previous owner. Although we did not investigate further the prevalence of sensitive data in second-hand medical devices, this shows that special care should be taken to data confidentiality when disposing of medical devices. There should be a process in place to securely decommission devices, as well as functions implemented in medical devices to allow for the secure erasure of data.

4 Experimentation

In this section we demonstrate in our lab four attacks on the selected protocols.

4.1 Attacker model

The attacker model we choose for our analysis is one of an attacker who wants to interfere and disrupt HDO’s operations and patient care by launching cyber attacks against medical devices and HDO infrastructure. The attacker can be driven by various motivations, such as social and economical destabilization, profit through ransom, or sheer “amusement”.

This attacker model assumes the threat actor to be already inside the network, and can interact with the targeted devices. We discussed in our previous work [12] how networks in HDO can be found improperly segmented, making our model tangible. The consequence is that sensitive devices (and data) can be reachable not only by legitimate systems used by medical staff, but also by adversaries who have access to the network [11]. We consider an attacker having access to the network in one of the two following ways: via remote access or via physical access. Remote access to an HDO’s network can be established, for example, through the compromise of a device reachable over the Internet or via phishing [28]. Physical access can be obtained by connecting a rogue device to an exposed network socket [11]. The ease of obtaining such access is common in hospitals since sockets are often used in patient rooms to connect medical devices that interface directly with patients [29].

An attacker having access to the network can leverage a man-in-the-middle (MITM) position. This consists in the attacker’s ability to redirect communication flows to her, and therefore allowing her to be logically in between devices. Such position enables her to intercept, read and/or modify packets on the network. Additionally, we consider an attacker who has already performed network reconnaissance activities [30] and identified the target devices and their respective IP addresses and ports.

4.2 Attacks

We implement four attacks using the protocols POCT1-A, LIS02-A and Philips Data Export, as described in Table 1. For each attack, we outline in the table its type and impact on the confidentiality, integrity and availability (CIA) of assets according to the STRIDE threat classification model [31]. This popular model is commonly used to identify weaknesses in technology [4] and has also been successfully applied to cyber physical systems [32, 33]. Following the STRIDE framework, the four attacks we demonstrate in this section are classified along the following three types:

  • Spoofing: The attacker pretends to be a legitimate system.

  • Tampering: The attacker violates the integrity of data by modifying it.

  • Denial of service (DOS): The attacker violates the availability of data and system by disrupting system operation.

We present each attack below. We first outline the goal and impact, and then introduce the technical background relevant to the understanding of the attack before explaining the scenario of the attack. We finish with a demonstration of our proof of concept where we implement the aforementioned scenario and execute the attack in our lab.

4.2.1 Attack 1: retrieving test results

Goal and impact: This attack consists in the interception of blood test results from the DCA Vantage analyzer. It impacts the confidentiality of patient data, where the attacker obtains a number of sensitive information contained in the POCT1-A packet. This attack highlights the risks to patients’ data privacy, and can be reproduced with any two devices communicating over an unencrypted and unauthenticated POCT1-A channel.

Technical background:

Let us first consider an example of a blood test result stored in the Siemens DCA Vantage as shown in Fig. 7.

Fig. 7
figure 7

HbA1c test result displayed on the screen of the Siemens DCA Vantage

Full size image

It displays the result of a Hemoglobin A1C test (or HbA1c test) of 66 mmol/mol, which could be indicative of diabetes. This result, dating from the 26th of July 2018, was already stored in the device when we received it (see Remarks above). We use this test result throughout our experimentation and attacks below. For sanitary reasons, we did not conduct blood tests ourselves in our lab. The interested reader can refer to the DCA Vantage Operator’s manual [34] to learn how these tests are practically performed in an HDO setting.

When the operator (e.g., a nurse or a lab analyst) chooses to send a test result to the LIS, a POCT01-A packet containing the result is generated and sent over an established connection between the DCA Vantage and LIS.

Fig. 8
figure 8

Details of the POCT1-A packet containing the HbA1c test results sent from the Siemens DCA Vantage to the LIS. The relevant parts of the message for our study are highlighted in red boxes. Box 1 is the header of the message which specifies, among other things, the message type (“OBS.R01” for Patient Observations message), a control ID which uniquely identifies the message, and a timestamp corresponding to the date and time at which the message was sent. Box 2 highlights the Service section of the message, as introduced before. Box 3 contains the patient ID and the result value for the HbA1c test

Full size image

We execute the transmission of the aforementioned test (pressing the “Send” button on the Siemens DCA’s screen shown in Fig. 7). By using our network tap, we capture the packet and retrieve the payload in which we find the XML-formatted test result, as shown in Fig. 8. The content of the payload is somewhat similar to the example shown in Fig. 5. As expected, the data and test results contained in the payload are the same as the ones displayed on the blood analyzer (see Fig. 7).

Attack scenario: An attacker can retrieve test results in one of these two ways. The first way consists in passively intercepting POCT1-A packets as they are transmitted on the network. Since the packets are sent in clear text, the attacker can simply sniff the network traffic and examine the content. The limitation of this approach is that the attacker has to wait for an operator to manually initiate the transmission of the results to the LIS.

The second way an attacker can retrieve the test results is by sending a specific command via POCT1-A to the blood analyzer (or any other POCT1-A devices). Knowing that a LIS server can send commands via POCT1-A to a device, an attacker can hijack the communications between a POCT1-A device and a legitimate LIS server (e.g., via ARP cache poisoning) and spoof the server. She can then send a limited set of remote commands to the target device. Depending on the commands supported by the device, the attacker will be able to, for example, force the device to send all pending test results to the LIS server (which she will intercept), or update the list of device administrators for example. These commands can be useful for the attacker depending on the motivations and/or objectives.

A malicious actor can easily perform such an attack in a hospital by connecting a small device like a Raspberry Pi embedding a rogue LIS server to the network via an exposed network socket. A similar attack targeting the DICOM protocol has been successfully demonstrated in a real hospital setting in [11].

Fig. 9
figure 9

Details of the LIS02 packet containing the HbA1c test result sent from the Siemens DCA Vantage to the LIS. The format of the packet is somewhat similar to the example given above in Fig. 3. We find relevant information for our study highlighted in red such as the Message Header record, the result value, and the checksum (“02”) (Color figure online)

Full size image

Proof of concept: We demonstrate in our lab the second scenario described above by performing the following steps. From the attacking machine, we first run our rogue LIS server and perform an ARP cache poisoning attack with Ettercap to spoof the legitimate LIS server. This forces the DCA Vantage to communicate with our rogue server. Following the device’s specifications [25], our server is configured to respond to the blood analyzer’s “Hello message” (HEL.R01) with an acknowledgment message (ACK.R01). Our server then requests pending tests results by sending a “Request message” (REQ.R01) to the target device. The DCA vantage replies by sending the test results. After a short conversation sequence (detailed in [25]) a continuous conversation mode is established between the DCA Vantage and our rogue device. In this mode, all further test results will be sent directly to our rogue LIS server. Moreover, the DCA Vantage will accept a limited set of commands from the server, such as to update the list of the device’s operators (OPL.R01).

4.2.2 Attack 2: changing test results

Goal and impact: The goal of this attack is to tamper with a test result being sent from the DCA Vantage analyzer to the LIS over the LIS02-A protocol. With such ability, an attacker can modify healthy results to abnormal ones, or the other way around. This impacts the integrity of the patient data, which could ultimately affect the patient’s health. This attack can be reproduced with any two devices communicating over unencrypted and unauthenticated LIS02-A.

Technical background: When the operator chooses to send a test result to the LIS via the LIS02-A protocol, a packet such as the one shown in Fig. 9 is generated and sent over the network. When the LIS server receives the packet, it displays the results, as shown in Fig. 10 and stores them internally.

Fig. 10
figure 10

The test result containing a value of 66 mmol/mol is received by the LIS server

Full size image

Attack scenario: Let us consider a scenario where the attacker wants to tamper with this data flow and send incorrect test results to the LIS. The procedure to implement this attack consists in the following steps. The attacker first executes a MITM attack to redirect the communication flow to her. When the test result is being sent by the laboratory device, she can intercept and drop the original packet. The attacker then crafts a new packet with a modified test result, and adjusts the checksum value by computing a new one before sending the packet. Finally, the crafted packet is received and stored by the LIS.

Proof of concept: We demonstrate the aforementioned scenario by implementing an attack in which we change the result of an HbA1c test which could be indicative of diabetes (66 mmol/mol) to a normal result (41 mmol/mol). We use the test result depicted in Fig. 7.

We follow the procedure outlined above by using Ettercap to establish a MITM position and create a custom filter that modifies test results and checksum accordingly. An example of filter creation is provided on the Ettercap’s GitHub repository.Footnote 8

We begin the attack by running Ettercap from the attacking machine and hijacking the connection between the DCA Vantage and the LIS server. Next, we execute the test result transmission from the blood analyzer using the test result already stored in the device (depicted in Fig. 7). In a normal situation, when the analyzer sends the test result (value of 66 mmol/mol), the LIS would receive the packet as shown in Fig. 10. However, after launching our attack, the Ettercap filter we developed intercepts and modifies the packet by setting the test result to the value of our choice (41 mmol/mol) and adjusts the checksum. The crafted packet is then sent to the LIS server and we can observe the success of the attack upon reception, as displayed in Fig. 11.

Fig. 11
figure 11

Due to the tampering attack, the test result value received by the LIS server is 41 mmol/mol, instead of the 66 mmol/mol value sent by the blood analyzer

Full size image

4.2.3 Attack 3: disconnecting a patient monitor

Goal and impact: The goal of this attack is to close an ongoing Data Export association between the patient monitor and the computer acting as a CMS (recall that this setup is for proof of concept only, as explained in Sect. 3.3). In a (hypothetical) hospital environment, the staff remotely monitoring a patient loses the real-time information about vital readings. As a DoS attack, the availability of the patient monitor’s data is impacted. This attack could be launched on multiple patient monitors which could result in the disruption of HDO operations, ultimately leading to delays in care with potential consequences to patients’ health.

Technical background: The Data Export protocol supports the transmission of commands. As described in its specifications [22], there is a number of commands that can be sent, allowing the monitor and a computer to interact with each other in various ways. One of the commands is the Association Abort command. A patient monitor can send this message in the case of communication problems to close the association [22].

Attack scenario: An attacker can leverage this command to terminate the association between a patient monitor and the CMS, effectively causing a denial of service. She can spoof the targeted monitor and send an Association Abort message to the CMS. To do so, the attacker crafts a packet containing the Association Abort message as payload according to the specifications [22] (p.337). The payload consists of the following bytes:

figure a

The attacker can then set the source IP address to the one of the targeted patient monitor and can finally send the packet to the right port of the CMS (24105 by default). In case of another port being used instead, the attacker would first have to sniff the traffic to observe over which port the CMS and the monitor are communicating. Upon reception of this packet, the association between the CMS and the patient monitor will be closed until manually re-established. By repeatedly sending Association Abort commands, the attacker can prevent effective use of the Data Export protocol.

Proof of concept: We implement this attack in our lab by performing the following steps. Using Scapy, we create a UDP packet containing the aforementioned payload. We then set the packet’s source IP address and source port to the patient monitor’s values in order to spoof it. Finally, we set the destination IP address to the CMS’s, and the destination port to 24105, the default port for Data Export protocol.

We send the packet from the attacking machine and we observe the result on the screen of the CMS, as shown in Fig. 12. Upon packet reception, the CMS displays an error message informing that the patient monitor has closed the association. No data can be received any longer by the CMS, and the association has to be manually re-established.

Fig. 12
figure 12

CMS displaying the result of an Association Abort message

Full size image

4.2.4 Attack 4: changing a patient’s vital readings

Goal and impact: The goal of this attack is to tamper with the vital readings sent from the patient monitor to the computer acting as a CMS over the Data Export protocol (recall that this setup is for proof of concept only, as explained in Sect. 3.3). In a (hypothetical) hospital environment, the personnel monitoring a patient remotely sees incorrect readings, unbeknownst to her. Similarly to Attack 2, tampering with the data conveyed in healthcare protocol packets violates the integrity of a patient’s health information, which could ultimately lead to adverse effects on the patient’s health.

Technical background: The patient monitor captures patient’s vitals such as pulse, blood pressure and oxygen saturation through sensors connected to the patient’s body. This information is displayed on the device’s screen (see Fig. 15 as example), and can be exported over the Data Export protocol for clinical research purposes. As outlined in Sect. 3.3, we use in our lab this protocol to interconnect the patient monitor with a computer acting as a CMS. The patient monitor encodes the data according to the protocol specifications [22]. An example of a Data Export packet sent by the monitor to the CMS is depicted in Fig. 13.

Fig. 13
figure 13

Example of a Data Export packet sent by the Philips MP50 patient monitor to the CMS captured with Wireshark. Box 1 (in red) represents the Ethernet envelop, box 2 (in blue) the IPv4 envelop, box 3 (in green) the UDP envelop, and the remaining of the packet corresponds to the payload in the Data Export format. The packet is 888 bytes long (the remaining of the payload is truncated) (Color figure online)

Full size image

While certain clear-text key words can give an idea about the type of data present in the packet, one cannot directly understand the information in the payload. The protocol being a binary protocol, understanding the payload format requires a bit of reverse-engineering. The publication of the protocol specifications makes this task easier, as we show below.

Attack scenario: An attacker wants to modify the pulse rate of a patient to 0 beat per minute to simulate a patient “flat-lining”. Such attack could trigger an immediate emergency response from the staff and, when executed on multiple patient monitors, could be disruptive. This attack is achieved by modifying specific bytes of the Data Export packets as they are sent from the monitor to the CMS.

To execute this scenario, an attacker can follow a similar procedure as shown with Attack 2: she can use Ettercap to establish a MITM position after having created a filter that captures and replaces the real-time vital readings in Data Export packets to a value of 0 beat per minute. The challenge in this context is to first identify where and how the pulse rate is encoded in a packet, which requires some reverse engineering.

Note that, depending on the motivations, the attacker could also change the pulse rate values to any arbitrary values, or even change other vital readings with the same procedure, such as blood pressure and oxygen saturation, as listed in the Data Export specifications [22].

Proof of concept: To demonstrate this attack, we proceed with the three following steps. In the first step, we want to identify at which offset the pulse readings are located in the packets. To do so, we need to understand how the pulse rate is collected and processed by the patient monitor. In our lab setting, the pulse rate is measured via a finger plethysmograph connected to the monitor. We find in the Data Export documentation the information related to the pulse rate recorded by the plethysmograph and how this information is encoded [22] (p.118). In particular, we see the encoding of the label (0x00024822), the observed value (0x4822) and the unit (0x0AA0). With this information at hand, we can search in Data Export traffic for packets with these byte values in the payload.

We generate and capture traffic by using our patient monitor’s plethysmograph connected to one of our fingers. Using Wireshark, we find the packets sent by the patient monitor containing bytes with the values related to the pulse data (see the bytes highlighted in Fig. 14) as identified in the protocol specifications.

Fig. 14
figure 14

Data Export packet transmitted from the patient monitor and captured with Wireshark. It shows the patient’s pulse rate in the payload of the packet. The bytes related to the pulse rate as found in the protocol specifications are highlighted in red (boxes 1, 2 and 3). The actual encoded patient’s pulse rate can be seen in green (box 4) (Color figure online)

Full size image

Moreover, by comparing the pulse value displayed on the patient monitor with the values displayed on the CMS, we identify the two bytes encoding the actual pulse rate value measured by the monitor, which are located 6 bytes after the pulse’s unit (0x0a 0xa0). In the example given in Fig. 14, the value is 0x61 in hexadecimal, which translates in decimal into a pulse rate of 97 beats per minute. Having identified where the pulse value is located in the packet, we can now calculate the offset of the byte we want to change: offset 0x323.

In the second step, we create an Ettercap filter to capture and modify the packets containing patients’ pulse readings. Similarly to Attack 2 presented before, Ettercap is used to establish a MITM position and intercept the packets of interest: the ones having a payload containing the values 0x00 0x02 0x48 0x22 (the pulse label), 0x48 0x22 (the observed value) and 0x0A 0xA0 (the unit). We then modify the pulse value to the desired value and forward it to the CMS to display this information.

We can then execute the attack as follow. First, we attach the plethysmograph to one of our fingers to generate data and simulate a patient being monitored. In Fig. 15 is depicted the reading displayed on the patient monitor, which is a normal pulse of 80 beats per minute. We then execute the attack. The result can be observed in Fig. 16, as seen by hospital staff on the CMS. After the execution of the attack, the pulse suddenly drops from a legitimate range oscillating between 70 and 80 beats per minute to 0 until the attack is stopped.

Fig. 15
figure 15

Patient vitals and other information shown on the display of the Philips MP50 patient monitor. The pulse rate reading (80 beats per minute) is displayed on the right-hand side of the screen. The pulse is measured by the finger plethysmograph that is attached to one of our fingers, simulating an actual patient being monitored. Some vitals are missing (value set to -?-) because the sensors are not connected to the patient monitor

Full size image
Fig. 16
figure 16

Flat-lining spoofing attack observed on the CMS: before the attack execution, the pulse values oscillate between 70 and 80 beats per minute, corresponding to the actual pulse readings. After execution, the pulse value drops to 0 beat per minutes as long as the attack is executed

Full size image

5 Conclusion

In this article we investigate three healthcare protocols found in HDO. A number of weaknesses are found and we demonstrate four attacks exploiting them in our lab. These practical scenarios highlight new risks to HDO and patients by violating the confidentiality, the integrity and the availability of data transmitted between medical devices and other systems. The state of the network segmentation in healthcare networks that we observed in our previous analysis [12] lets us assume that many HDO would be exposed to such threats. It is therefore necessary to protect these environments by designing network monitoring tools suited to address the threats specific to HDO, as they can impact greatly hospital’s operations and patients’ safety and privacy.

The research presented in this article contributes to such design. It can improve security measures such as IDS by issuing signatures for newly found vulnerabilities. Additionally, new attack datasets can be assembled to test the signatures and support the implementation of novel IDS tailor-made for HDO. Finally, our methodology and blueprint for designing a healthcare lab allows researchers to pursue vulnerability research efforts for the healthcare industry in a safe environment.