Security leaders in the healthcare industry know the common refrain about medical devices: legacy technology permeates, none of it was meant to be connected to the internet, and all of it is too expensive to replace. Underlying this dynamic is the reality that many medical devices contain serious vulnerabilities, some of which have known exploits in the wild. Replacing devices, meanwhile, hinges on component failures rather than cybersecurity concerns—even though some of these vulnerabilities could lead to negative patient outcomes.
This is the backdrop for Team82’s first healthcare cybersecurity report. Available now, the State of CPS Security Report: Healthcare 2023 puts real numbers behind the vulnerabilities and architectural weaknesses that are not only endangering the availability and reliability of life-saving medical equipment, but also patient safety.
We urge you to download the report and take time to examine our findings; we believe healthcare delivery organizations are at a pivotal point. Security leaders and medical device manufacturers can no longer be reactive about cybersecurity. Patient safety as it relates to cyber must be a core business consideration for HDOs, and security must inform decision-makers, policy-makers, and vendors alike.
Let’s examine some of our key findings:
One important data source for this report was CISA’s Known Exploitable Vulnerabilites (KEV) catalog, a database of vulnerabilities that have been publicly attacked. From our research, we discovered that 63% of KEVs tracked by CISA can be found on healthcare networks, 23% of medical devices (imaging systems, clinical IoT devices, surgical equipment) have at least one KEV, and 14% of electronic health record systems.
We break that down further, below.
Patching vulnerabilities in medical devices is complex; while many medical device manufacturers develop on Windows or Linux, for example, two platforms that are regularly updated, the same capabilities are often not built into medical devices. Patching is often an expensive add-on support contracts, according to HDOs we spoke to. HDOs must often rely on compensate controls to mitigate the exposure and potential impact of these vulnerabilities if they’re exploited. MDMs, for their part, argue that because of the Food and Drug Administration’s lengthy device certification process they are concerned about breaking FDA-certified functionality and maybe be hesitant about investing in complete security testing.
In addition to KEVs, we discovered devices containing vulnerabilities that have a high Exploit Prediction Scoring System (EPSS) score. These scores, as determined by FIRST, estimate the probability of a vulnerability being exploited within 30 days of public disclosure (EPSS scores do not present a complete picture of risk and should be a consideration along with other metrics when prioritizing vulnerability remediation and mitigation options).
We discovered high EPSS scores especially rampant in hospital systems and medical devices running on unsupported operating systems, those considered end-of-life by a MDM and no longer supported with feature or security updates.
We also found relatively high numbers of imaging devices (MRIs, CT scanning machines) to contain vulnerabilities with high EPSS score, and even surgical devices, and other patient support systems.
The proliferation of remotely controleld and monitored medical devices has introduced weaknesses in network architectures that put devices and patienst at risk. For example, our research shows a number of life-saving medical devices—including surgical equipment–accessible from networks labeled “guest networks” by hospitals. A skilled attacker can bridge the two networks and burrow deeper into the internal network.
Our research shows that legacy medical devices running on unsupported and/or unmanaged operating systems are prevalent on hospital networks. These systems are considered end-of-life by their respective vendors and are no longer supplied with security or feature updates. Below are some data points around legacy systems from our research.
CWE-257: Storing Passwords in a Recoverable Format
RND encrypts passwords with a hardcoded weak secret key and returns the passwords in plaintext. If the server were compromised, an attacker could gain all the plaintext passwords and decrypt them.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 5.3
CWE-321: Use of Hard-coded Cryptographic Key
A built-in user called sshuser, with root privileges, exists on the RND platform. Both public and private ssh keys exist in the sshuser home directory. Anyone with the private key can access an RND server as sshuser.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 10.0
CWE-259: Use of Hard-coded Password
RND includes a jailed environment to allow users to configure devices without complete shell access to the underlying operating system. The jailed environment includes a built-in jailbreak for technicians to elevate privileges. The jailbreak requires a weak password that is hardcoded into the environment. Anyone with this password can access an RND server with root permissions.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 8.2
CWE-321: Use of Hard-coded Cryptographic Key
RND uses a secret key on the backend web server to ensure that session JWTs are valid. This secret key is hardcoded into the web server. Anyone with knowledge of the secret key could create a valid JWT, thus bypassing the typical authentication to access the server with administrator privileges.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 9.8
CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
An authenticated vSZ user supplies an IP address as an argument to be run in an OS command, but this IP address is not sanitized. A user could supply other commands instead of an IP address to achieve RCE.
No patches have been supplied by the vendor at this time. To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
CVSS v3: 9.0
