HL7Magic: A tool for testing medical devices using the HL7 protocol

At DEFCON 2023 I presented some research in which I discussed an easier method of testing the Health Level Seven (HL7) medical protocol. This included a demonstration of a new tool I created named ‘HL7Magic’, which enables testers to proxy, parse and amend messages to demonstrate the impact of manipulating data sent to a medical device. This blog post has been released alongside the open-sourcing of this tool and will discuss the key concepts mentioned within my talk.

HL7Magic can be downloaded here.

In the 21^st century, we have become reliant on the use of technology in the healthcare sector, not just as a means to communicate data, but as a way of providing care to patients. One of the earliest uses of technology in healthcare was when X-rays were first adopted in 1895. Since then, systems and devices found in hospital environments range from the infusion pumps used to deliver medication, to the conferencing systems used in meeting rooms. From an attacker’s perspective, each one of these devices is considered a potential access vector when targeting a hospital network.

Recent reports have highlighted the importance of testing medical devices and networks, as attacks on healthcare systems have continued to rise, particularly throughout 2023 during the course of this research project . The impact of these attacks could not only cause financial and reputational damage, but also result in physical harm to patients. Therefore, it’s important that security does not continue as an afterthought for those researching, developing and using medical technologies.

There are several mechanisms that have been designed to communicate different types of patient data, such as patient records and medical imaging. The protocol Health Level Seven (HL7) – named after the organisation -  is considered the most widespread when it comes to communicating patient data between medical systems. With this in mind, I decided that this would be a good candidate for a research topic. We will dive into this protocol more shortly.

Another protocol within the family of standards developed by Health Level 7 UK, is Fast Healthcare Interoperability Resources (FHIR – pronounced Fire!). FHIR was designed in response to the changes in approach to healthcare data exchange and aimed to simplify the communication of patient data by utilising widely used internet standards such as REST. As a result, this lowered the bar for developers to implement the basic mechanisms and the appropriate security controls to secure data. However, research carried out into this protocol found that if API’s built around FHIR were misconfigured, millions of patient records could be exposed.

Other healthcare protocols include DICOM (Digital Imaging and Communications in Medicine), LIS (Laboratory Information System) and POCT (Point-of-Care Connectivity). For the rest of this article, we will dive into my research into the HL7 protocol.

Health Level Seven (HL7) is currently the most commonly used protocol in the healthcare industry and its main purpose is to communicate patient data. Version 1 was first deployed in 1979, but the version in use across most medical devices used in the modern day is version 2. HL7 version 3 was released in 2005 in an attempt to implement a new standard which included a more secure mechanism of data delivery. However, this version is not backwards compatible and therefore has been less widely adopted across the industry. As a result, this research was focused on version 2 only.

As the HL7 protocol does not use TLS natively, message contents are communicated in cleartext. Each message is made up of several segments, each segment starting on a new line. Segments contain fields that are separated by pipe and caret characters depending on whether the field entry is a new component (|) or a sub-component (^). We can see this below:

The ‘Message’ segment (MSH) will appear at the start of most HL7 messages, and will contain information about the message itself, such as the sending application, date and time and HL7 version. This segment will also contain the ‘Message Type’, which will explain the intention for which the message was sent. An example of a Message Type is ADT^A01, which tells us that the message being sent is an Admission, Discharge or Transfer (ADT), and the event is a Patient Admission (A01) – a patient being admitted into the hospital. We can see this in the example below:

Other commonly seen message types include Observation Results (ORU) which will be used to periodically update vital signs readings, Orders (ORM) which are used for pharmacy orders and treatments, and Medical Document Management (MDM).

The next segment commonly found in HL7 messages is the ‘Event’ segment (EVN). This also provides specific information about the events mentioned above. Following this, it’s common to see the ‘Patient Identifier’ segment (PID). This will contain key information relating to the patient, such as their name, address and phone number. Additional segments that might be present in HL7 messages are ‘Next of Kin’ (NK1) and ‘Allergy Information’ (AL1), which are self-explanatory.

Let’s see the complete message containing all segments mentioned above:

It’s key to note that specific segments are required for specific message types and specific fields are required for specific segments. If these required entries are not present, the message will not parse correctly at the point it enters the application or system.

OK, that’s the general protocol structure. But how is it transmitted?

There are several ways to deliver HL7 messages, the most common being via Minimal Lower Layer Protocol (MLLP) through TCP/IP. This protocol ensures that HL7 messages are wrapped in a start block, an end block, and a closing carriage return. This way, applications and servers expecting HL7 messages will know when the message starts and ends. This is important as there is no defined length, some messages can be lengthy and can contain multiple segments.

Here we can see an example of a HL7 message wrapped by MLLP ready for transmission:

Whilst this is the most common method of transport, HL7 messages can also be communicated via other TCP/IP protocols such as SOAP, SMTP and FTP.

There are several known vulnerabilities affecting HL7 v2, most of which are a result of misconfigurations or legacy development. In this particular version, there are very few security mechanisms that can be introduced at the protocol level.

When the HL7 standard was initially created, developers relied upon the idea that security would be implemented on the application or devices themselves. However, this has since opened up a number of opportunities for attackers to exploit issues that could potentially cause harm to patients. Let’s review a few.

Lack of Authentication

The HL7 protocol does not require any kind of authentication prior to sending messages. This means that any device can freely send messages to any server or application, given both hosts are on the same network. This might lead to the exploitation of other vulnerabilities such as a Denial of Service which could cause a medical device to crash, or simply access to patient data. In HL7 v2, a segment named ‘User Authentication Credential’ was introduced that allowed for the implementation of authentication mechanisms such as Kerberos or SAML. However, this segment is optional within the standard definition, and unlikely to be implemented due to its complexity.

No Tamper Detection

It's also possible to amend HL7 messages due to the absence of tamper detection mechanisms. Therefore, if an attacker is positioned suitably on a hospital network, they may be able to intercept and change the messages being communicated between devices. Putting this into perspective, this could result in a number of possible impactful actions. Allergen information contained within records may be changed which may result in the prescription of drugs that the patient may be allergic to, therefore causing a severe impact to that individual. Other medical protocols such as LIS and the more bespoke Philips Data Export will generate a checksum when sending data to a Central Management System, to make it more difficult for attackers to tamper with the data.

Denial-of-Service

When configuring middleware applications and servers to accept HL7 messages, it common for a maximum number of connections to be set. This number is often quite low and as a result, can leave the application susceptible to a Denial-of-Service attack if the number of connections is exceeded. To make matters worse, most middleware applications are set to keep connections open once established. Therefore, if an attacker were to initiate a high number of connections within the intention to cause a Denial of Service, these connections would also remain open, preventing any legitimate traffic from reaching the application.

Person-in-the-Middle and ARP Spoofing

As mentioned previously, HL7 messages are communicated in cleartext. This means that if traffic to or from medical devices is intercepted, an attacker could easily retrieve sensitive information contained within that message, such as patient details. This is also possible due to the fact there is no authentication mechanism in place. An attacker positioned within a hospital network could perform techniques such as ARP (Address Resolution Protocol) spoofing to masquerade as a legitimate device on the network by linking their MAC address with an IP address of a device already on the network. This would allow them to listen to the traffic between two devices and retrieve patient information.

There are a number of challenges that come with testing the HL7 protocol, the first associated with fingerprinting its use. HL7 typically does not run on a specific port, therefore it’s difficult to identify through port scanning tools or fingerprinting modules. One way in which it is possible to fingerprint its use, is where medical devices are using default ports to communicate. It should be noted that some medical devices do not have the ability to deal with a large amount of incoming traffic that may be associated with port scanning. Therefore, it is likely they will crash if port scanning is attempted.

As mentioned above, HL7 messages are sent in cleartext unless SSL has been manually configured on the device or through a wrapper application. On some medical devices, there will be an option in the device administration menu that will allow encryption to be turned on for device communication. However, in most cases this option is disabled by default, meaning all traffic will be unencrypted and easily readable if intercepted. Intercepting traffic can be challenging as medical devices usually communicate through non-standard protocols that cannot be proxied through existing tools. An alternate method would be to observe traffic on the network through packet capture tools such as Wireshark or through ARP spoofing. This would also reveal which ports are being used to communicate patient data, a key piece of information needed in attack attempts.

HL7 version 2 messages can be very difficult to read due to their complex format and even more so the larger they become. Messages are sent in human-readable (ASCII) format, with a defined field structure within each segment. However, in version 3 message format changed to XML in an attempt to make messages easier to read. As mentioned above, HL7v3 is not backwards compatible, therefore this format is not widely adopted.

So how exactly can we overcome these challenges?

There are very few tools that have been developed to test medical devices and protocols such as HL7, primarily due to the lack of research carried out in this area. A tool named ‘Pestilence’ was developed as part of a research project by Christian Dameff, Maxwell Bland, Kirill Levchenko and Jeff Tully. The project explored the impact of exploiting insecure HL7 messages through sending potentially life-threatening payloads. This tool was not publicly released on ethical grounds, given the impact it could cause should it fall into the wrong hands. Anirudh Duggal also released a tool named MedAudit, which was demoed at BlackHat in 2017. This tool provides a nice graphical interface for testing devices using HL7, including fuzzing capabilities and integration with Postman.

After getting familiar with various tools and building my own test server, I decided that there were some things missing based on the challenges mentioned above. With that being said, I decided to utilise existing security testing frameworks to build out tooling for HL7. Burp Suite offers functionality to build extensions, which in this instance allowed me to build a tool to proxy HL7 traffic and amend on the fly, in addition to other features that would make testing simpler. Let’s talk about the tool – named HL7Magic – in more detail.

HL7Magic was designed as a Burp Suite Extension, written in Python using the HL7apy library. This library parses HL7 messages of differing versions and types, and allows each segment and field to be accessed within the message. This library proved to be quite difficult to work with further on down the line, and the documentation did not include some functions which I found to be useful when debugging.
E.g. the ‘validate()’ function allows you to piece back together a HL7 message and enables you to identify which fields are missing. However, it requires knowledge of the segments and fields needed for that message type.

To begin the process of using the tool at a high level, a HL7 message is sent from a medical device to a server and intercepted by a security tester positioned on the network. This can be achieved by configuring a tool like Mitm_relay to allow non-HTTP traffic to be intercepted through Burp Suite. Mitm_relay can be downloaded here . The initial command looks something like this:

-l – this is the address we are listening on

-r tcp:8880 – our relay sending data from our client on port TCP/8880

127.0.0.1:8888 – our server listening on 127.0.0.1 on port TCP/8888

-p http://127.0.0.1:8081 – our Burp Proxy configuration, listening for traffic on port TCP/8081

Once the traffic has been proxied and intercepted in Burp, the HL7 message is parsed and the contents are dynamically stored. This allows any message of any length, type and version to be parsed. The HL7 message is then converted to JSON, a human-readable format that is easier to amend from a security testers perspective. Once the relevant fields and segments have been changed, the message is converted back into HL7 format with the new contents and forwarded onto the server.

Lets see this in action!

1. Firstly, a HL7 message is sent from a medical device, through mitm_relay and intercepted by Burp:
   

2. The HL7Magic plugin converts the message into JSON format, far easier to read!

3. Next we can amend patient details within this JSON format, such as the patient's name:

4. HL7Magic converts the JSON back into a HL7 message with the new patient name:

5. Lastly, the new message is forwarded onto the server:

This process would allow a security tester to identify whether it’s possible to manipulate the fields within a HL7 message, or whether the server accepts a changed medical record.

HL7Magic should be imported as a Burp Suite Extension. This is done through the ‘Extender’ tab, by clicking ‘Add’. The extension type should be set to ‘Python’, and the extension file is the hl7magic.py file. Once added, the check box in the UI will confirm the extension is loaded and ready to go. More information on setup can be found in the repository.

In conclusion, the development of this tool will help security testers tasked with identifying flaws in medical devices. HL7 is still the most commonly used protocol in the healthcare industry and if misconfigured, the protocol is left vulnerable to a number of potentially harmful issues. During this research, I identified that HL7 is difficult to test from a security perspective. It’s difficult to fingerprint with no real reliable methodology, messages are difficult to read and there are currently no easy ways to proxy HL7 traffic through security tools. As a result, HL7Magic will provide security testers with an easier method of testing devices using HL7 to communicate.

You can watch my DEFCON talk on HL7Magic here.

• Health Level Seven: https://www.hl7.org.uk/
• CheckPoint - After Ransomware Disruption, Hospital Turns to Check Point Infinity Global Services to Recover and Build Cyber Resilience: https://blog.checkpoint.com/customer-stories/after-ransomware-disruption-hospital-turns-to-check-point-infinity-global-services-to-recover-and-build-cyber-resilience/
• Approov, Alissa Knight - Hacking and Securing FHIR API Implementations: https://approov.io/info/hacking-and-securing-fhir-api-implementations
• Christian Dameff MD, Maxwell Bland, Kirill Levchenko PhD, Jeff Tully MD - Pestilential Protocol: How Unsecure HL7 Messages Threaten Patient Lives: https://i.blackhat.com/us-18/Thu-August-9/us-18-Dameff-Pestilential-Protocol-How-Unsecure-HL7-Messages-Threaten-Patient-Lives-wp.pdf
• Anirudh Duggal - MedAudit: https://github.com/anirudhduggal/medaudit
• Saurabh Harit - Breaking Bad: Stealing Patient Data Through Medical Devices: https://www.blackhat.com/docs/eu-17/materials/eu-17-Harit-Breaking-Bad-Stealing-Patient-Data-Through-Medical-Devices.pdf
• NHS Data Security and Protection Toolkit: https://www.dsptoolkit.nhs.uk/
• OWASP - Secure Medical Device Deployment Standard: https://s36779.pcdn.co/wp-content/uploads/2021/03/OWASP-SecureMedicalDeviceDeployment7.pdf
• Forescout - Connected Medical Device Security: https://www.forescout.com/resources/connected-medical- device-security-a-deep-dive-into-healthcare-networks/
• Dallas Haselhorst - HL7 Medical Attacking and Defending: https://linuxincluded.com/hl7-medical-attacking- defending/
• HL7apy: https://crs4.github.io/hl7apy/tutorial/index.html