Digital networking is already widespread in many areas of life. In the healthcare industry, a clear trend towards networked devices is noticeable, so that the number of high-tech medical devices in hospitals is steadily increasing.
In this blog post, we want to elucidate a vulnerability we identified during the security assessment of a patient monitor. The device sends HL7 v2.x messages, such as observation results to HL7 v2.x capable electronic medical record (EMR) systems. A user with malicious intent can tamper these messages. As HL7 v2.x is a common medical communication standard, we also want to present how this kind of vulnerability may be mitigated. The assessment was part of the BSI project ManiMed, which we would like to present in the following section.
Manipulation of Medical Devices (ManiMed)
The BSI, in its role as the central cybersecurity authority in Germany, aims to sensitize manufacturers and the public regarding security risks of networked medical devices. In response to the often-fatal security reports of medical devices within the last years, the BSI initiated the research project Manipulation of Medical Devices (ManiMed). In this project, the analysis and the security assessments of various medical devices are carried out by ERNW. Apart from elucidating the current state of medical device cybersecurity, this project is intended to demonstrate the importance of actively practiced cooperation, collaboration, and trust among all stakeholders (vendors/manufacturers, security researchers, and authorities). The project aims to have an exemplary function towards more cybersecurity and transparent communication in the field of medical devices.
Background on HL7 v2.x
The HL7 v2.x standard is a common, text-based interoperability standard for health and medical transactions between medical systems and devices to support hospital workflows [1]. Since its release in 1989, the standard defines a series of electronic messages to support administrative, logistical, financial as well as clinical processes, therefore enabling interoperability of heterogeneous medical systems such as patient administration systems (PAS), electronic medical record systems (EMR), billing, radiology or laboratory systems, and active medical devices such as patient monitors. As a result, the majority of manufacturers integrate HL7 v2.x interfaces into their products. Consequently, agreements on the message structure and content representations are required to parse and process the messages’ contents.
HL7 v2.x messages make use of an encoding syntax based on segments (lines) and one-character delimiters. Each segment starts with a 3-character string that identifies the segment type. Every message’s first segment represents the message header segment (MSH). The MSH segment includes the message’s type, which determines the expected message segments. The segment types are specified by the segment grammar notation used in the HL7 standards.
Injecting Message Segments
The target of evaluation, a patient monitor, uses the message type ORU^R01^ORU_R01 (hereinafter called ORU), which means Unsolicited Observation Message. The HL7 v2.x ORU message transmits observations and results from production to ordering systems. Additionally, it can transmit result data to medical record archival systems, or systems not part of the primary ordering process.
Encoding characters are special characters that constitute the structure of HL7 v2.x messages. An attacker with physical access to the device can inject valid HL7 v2.x segments into the HL7 v2.x ORU messages with a connected barcode reader as encoding characters in untrustworthy inputs are processed. Hence, attackers can tamper data transmitted to further network-connected systems. As a consequence, the scope of the attack expands from the patient monitor to network-connected systems.
The following figure shows the payload ernw\rDG1|1||S61.80^ernw^icd10gm19|||BD|||||||||1|\r in its representation as code128 barcode. This barcode is needed because it circumvents the restrictions of special characters in input fields. The intended use of such barcode readers is to scan a patient’s personally identifiable information (PII) in the means of barcodes to speed up clinical processes.
This payload adds an HL7 v2.x DG1 segment that represents the diagnosis code S61.80 [2] according to the medical diagnosis code coding system International Statistical Classification of Diseases and Related Health Problems 10th Revision German Modification Version 2019 (ICD-10-GM-2019) [3] as the primary diagnosis. Injecting the prepared payload in the patient name causes the following HL7 v2.x communication between the device (red) and an HL7 v2.x – capable system (blue).
The payload inserts a line break after the string ernw that started a new DG1 segment. This segment itself ends with a final line break. The following figure demonstrates the dissected message in Wireshark.
Impact and Limitations
Attackers cannot inject complete HL7 v2.x messages because batched message processing, which needs to be enabled on connected systems, requires messages to be wrapped in batch segments. Further, attackers cannot control the messages’ destinations. It must be noted that HL7 v2.x ORU messages are specified to only contain a limited subset of all available HL7 v2.x message segments. Attackers may only be able to inject these selected segments [4] into messages when network-connected systems strictly validate messages received from the patient monitor.
In this way, attackers can inject arbitrary observation results (not limited to the selected patient) that could lead to misdiagnosis or medical errors and, therefore, may cause patient harm. These results do not need to represent the modalities provided by the patient monitor as an attacker may also inject OBX segments containing results coded by using interoperable coding systems such as LOINC [5].
Mitigations
The following countermeasures are possible to mitigate the HL7 v2.x injection:
- Input validation: Filtering and validation of untrusted data
- Output encoding: Escaping of special characters and symbols (preferred)
Characters usually used in HL7 v2.x messages that need to be encoded in the user input are:
- Field separator (default:
|) - Component separator (default:
^) - Subcomponent separator (default:
&) - Field Repeat separator (default:
~) - Escape character (default:
\) - Line break character (default:
\r)
It must be noted that the line break character may be platform dependent. Therefore, it is recommended to encode all representations of line breaks.
Take care and stay healthy.
Cheers!
Julian
References
[1] https://hl7.org/implement/standards/product_brief.cfm?product_id=185
[2] https://www.icd-code.de/icd/code/S61.-.html
[3] https://www.dimdi.de/static/de/klassifikationen/icd/icd-10-gm/kode-suche/htmlgm2019/