MDhex vulnerabilities open GE Healthcare patient monitoring devices to attackers

Researchers have discovered six critical and high-risk vulnerabilities – collectively dubbed MDhex – affecting a number of patient monitoring devices manufactured by GE Healthcare.

The flaws may, according to GE Healthcare, allow an attacker to make changes at the device’s OS level that may render the device unusable or interfere with its function, make changes to alarm settings on connected patient monitors, and utilize services used for remote viewing and control of multiple devices on the network to access the clinical user interface and make changes to device settings and alarm limits, which could lead to missed, unnecessary, or silenced alarms.

In short, they may lead to patient harm or even death. Also, unfortunately, patches are yet to be issued.

About the MDhex vulnerabilities

Researcher Elad Luz of CyberMDX unearthed the flaws in September 2019 and notified GE Healthcare about them.

They are:

• CVE-2020-6961 – Unprotected storage of credentials (SSH private key exposed and is universally shared across an entire line of devices in the CARESCAPE and GE Healthcare family of products)
• CVE-2020-6962 – Improper input validation (the versions of the web-based system configuration tool in use is deprecated and opens the devices up to a number of vulnerabilities with known exploits in the wild)
• CVE-2020-6963 – Use of hardcoded credentials (SMB with hard-coded credentials allows remote file access)
• CVE-2020-6964 – Missing authentication for a critical function (MultiMouse / Kavoom KM software can be run to allow remote keyboard/mouse and clipboard control of a machine)
• CVE-2020-6965 – Unrestricted upload of dangerous file types (software update manager allows remote file upload)
• CVE-2020-6966 – Inadequate encryption strength (credentials for VNC remote desktop access are stored in an insecure manner AND can be found in publicly available product documentation)

Some of the affected devices present only some of these issues, others all. The list is as follows:

• ApexPro Telemetry Server, Versions 4.2 and prior
• Clinical Information Center (CIC), Versions 4.X and 5.X
• CARESCAPE Telemetry Server, Versions 4.3 and prior
• CARESCAPE Central Station (CSCS), Versions 1.X and 2.X
• Patient monitors B450, B650 and B850, Versions 1.X and 2.X

Mitigations and patches

“GE is developing software updates/patches including additional security enhancements that will be made available,” the manufacturer noted, but didn’t say when.

In the meantime, to mitigate the risk of exploitation, they advise users to properly configure the Mission Critical (MC) and Information Exchange (IX) networks to ensure the isolation of the vulnerable devices – instructions on how to do it can be found in the product configuration guides and technical and service manuals.

“Properly configured MC and IX networks greatly reduce but do not eliminate the ability to gain access to the networks. As a result, if the networks are properly isolated, for this issue to occur, the unauthorized person would need to gain physical access to the listed monitoring devices themselves individually or acquire direct access to the isolated MC or IX networks on-site at the hospital,” the company noted.

If possible, closing specific ports at the firewall level is also advised. More info on this and additional mitigation advice can be found here and here.

GE healthcare told ZDNet that they’ve been notifying customers about the issues and mitigations since November 2019 and that they are not aware “of any incidents where these vulnerabilities have been exploited in a clinical situation.”

“Finding vulnerabilities in medical devices is like hitting snooze on your alarm in the morning. This isn’t your drop-dead to get out of bed and it’s not a breach, but it’s your warning that attackers, who are sometimes closer on our tail than we’d like to admit, have a new pathway in,” commented Nadir Izrael, CTO and co-founder of Armis.

“Medical data and patient data is valuable, as is the life giving operation of the medical devices themselves, and it’s what attackers are looking to steal or disrupt. It’s why I’ve seen MRI machines talking to servers in Russia, a medical crash cart being used to access Facebook or phishing websites, and even an infusion pump infected by malware that was still connected to a patient. MDHex is a reminder that trust in the security of patient care devices can’t be given implicitly any more. Hospitals need to know that many medical devices are inherently insecure, built without security in mind and without an agent, and extremely difficult to patch, if at all.”