Insecure Design Choice Puts Patient Safety, Data at Risk

Late last week, the U.S. Food and Drug Administration (FDA) and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) warned in dual bulletins regarding security vulnerabilities within the Contec CMS8000 and white-labeled Epsimed MN-120 remote patient monitors. The firmware vulnerabilities place patients at risk of leakage of personally identifiable protected health information (PHI), disruption of the device, or corruption and manipulation of data.

The FDA's Safety Communication and the CISA's Fact Sheet refer to the vulnerability as a "backdoor." Still, other cybersecurity researchers and medical device experts aren't convinced it's malicious; instead, it's likely the result of poor design and quality control, they said.   

What Vulnerabilities did the Researcher Uncover?

According to CISA's analysis—triggered by information provided by an unnamed security researcher—CISA researchers identified what the agency labeled an embedded “backdoor,” with a hard-coded internet address in the firmware versions within the Contec CMS8000 that CISA analyzed. According to the agency’s analysis, the vulnerability creates the risk of patient data spillage through unauthorized patient data transmission, and possibly unauthorized remote code execution and device modification.

However, Claroty's Team82 concluded in its analysis that the "backdoor" is an "insecure design issue, creating potential security risks to patient data." Team82 published its detailed findings, which include considerable prior research into the CMS8000. Practitioners Nexus interviewed agree.

Essentially, CISA found upon startup that affected devices attempt to connect to a remote, hard-coded IP address and stream patient data via port 5151. That patient information is transmitted using the Line Printer Daemon (LPD) protocol instead of the more common Health Level 7 (HL7) protocol.

Further, files from a remote share are copied to the device's local filesystem, potentially overwriting existing files, because of how the firmware's update function works, such as lacking integrity, verification, or version tracking, and because the backdoor persists even in the most recent pre-release firmware, which is firmware version 2.0.8.

Root Cause? Poor Design, Quality Control Likely

Martin Fisher, an experienced healthcare CISO and managing partner at Kiraso Partners LLC, a cybersecurity services and consulting firm, said he wasn't surprised by the findings. 

"This is not, ‘Oh my gosh!’ like this has never happened before, especially with clinical devices that are getting older and older, and were built in a time when there was such a concept as threat modeling in that industry," Fisher said.

Still, this firmware vulnerability poses significant risk, particularly to smaller healthcare facilities that must apply mitigations such as blocking outbound connections from the firewall to the IP in question until an FDA-approved firmware update is made available from the vendor.

Bill Pelletier, an embedded systems security architect at a medical device and software maker based in the northeast U.S., said that while the vulnerability is quite serious, the remote firmware function was likely created during the device's manufacturing process. The inclusion of remote access capabilities, for example, was likely a support function, or it aided the device maker in some other way during the manufacturing process.

"[Why the backdoor is present] Occam's Razor almost always applies in situations like this, and the simplest explanation for the existence of highly functional ‘backdoors’ is intentional, and the external accessibility is by design,” he said. 

Such capabilities are standard for certain manufacturer services [such as troubleshooting or design] to be performed for data collection by other devices, including clinical data collections.

Such capabilities are rarely included in the user guides. "Lots of devices have back-end infrastructures that they talk to for customers and mobile device managers to aggregate data about a fleet of devices," he said. "Having a hard-coded destination can be both malicious, as in command and control nodes, or for device fleet aggregation for the ubiquitous ‘dashboard" display,’" he added.

The FDA recommends that patients and caregivers consult healthcare providers about whether the devices require remote monitoring. If so, the FDA advises stopping the use of the devices and finding an alternative. For devices limited to local monitoring, the FDA recommends maintaining that posture and turning off network connectivity. For larger healthcare providers, Team82 provides additional analysis of the flaw and recommendations on risk mitigation here.