Shared SSH private-key exposure

1. Summary

The SSH server subsystem of GE HealthCare CARESCAPE, ApexPro, and Clinical Information Center patient-monitoring devices ships with a private key that is stored insecurely in the device’s configuration files and is identical across the entire affected product line [1][3]. Because the key is hardcoded and shared fleet-wide, it can be recovered from any single device (or from otherwise available material) and then reused to authenticate to any other reachable device [3][4]. A network-reachable, unauthenticated attacker who holds the key can open an SSH session to a monitor or telemetry/central-station server and obtain remote management and code execution on it [1][3][4]. This is one of six vulnerabilities collectively branded “MDhex” [3][5].

2. Affected products & versions

NVD lists CARESCAPE Central Station as both 1.X and 2.X in its affected-software configurations [1]. At disclosure (January 2020), GE was still developing software updates and named no fixed firmware version or timeline [5][6].

3. The vulnerability in detail

The defect lives in the SSH server subsystem of GE’s patient-monitoring devices — specifically in an SSH private key that the device stores in its configuration files [1]. Two things about that key turn an ordinary configuration artifact into a maximum-severity remote-access flaw. First, the key is insufficiently protected: it is stored in the SSH server configuration in a way that lets it be read off the device rather than being sealed in hardware or otherwise guarded [1][3]. Second, and more damaging, the same key is used on every device in the product line — it is hardcoded and universally shared across the CARESCAPE / GE HealthCare fleet rather than being unique per unit or per site [3][4]. These two properties compound: the weak protection means the key can be recovered from one box, and the shared nature means that single recovery unlocks SSH on all of them.

Root cause. The product line was built to trust a single embedded SSH private key for management access, and that key was neither protected against extraction nor diversified across devices. This is the classic anti-pattern of a hardcoded, fleet-wide secret. NVD classifies it as CWE-522 (Insufficiently Protected Credentials) — the credential that guards a security-relevant function is stored or transmitted without adequate protection so that an attacker can obtain it — combined with CWE-256 (Plaintext Storage of a Password), reflecting that the key material sits in configuration in a recoverable form rather than being encrypted, hashed, or bound to per-device hardware [1]. The system’s security depends on a secret staying secret, but the design guarantees the secret is both readable and identical everywhere, so it cannot stay secret once any one device is examined.

Why is a shared key so much worse than a merely weak one? Cryptographic authentication is only as strong as the secrecy and uniqueness of the credential. A per-device key that leaked would compromise exactly one device; a per-site key that leaked would compromise one hospital. A single fleet-wide key collapses that blast radius calculation entirely — the population of devices an attacker can reach with one recovered secret is the entire installed base of the product line rather than a single unit. There is also no meaningful revocation story: because the key is baked into the shipped configuration and is the same everywhere, an operator cannot rotate or revoke it in the field without a firmware-level change that re-provisions unique key material, which the sources do not confirm was delivered. The defect is therefore structural, not a transient credential leak.

The mechanism of exploitation follows directly. The SSH daemon on an affected device accepts key-based authentication using this shared key. An attacker who possesses the key can connect over the network to the device’s SSH service (TCP port 22) and authenticate with no password and no user interaction, because the key is the credential [1][3][4]. Public-key SSH authentication requires the client to prove possession of the private key matching an authorized public key on the server; here the attacker simply has that private key, so the proof succeeds and the server grants a session. Once authenticated, the attacker has remote management and can execute code on the device [3][4].

The preconditions are modest. The attacker needs (a) network reachability to the device’s SSH port, and (b) possession of the shared private key. The credentials in the MDhex set are described as publicly available or easily recoverable from a device, and consistent across the entire product line, so obtaining the key is characterized as low-effort [5]. No password beyond the key, no user interaction, and no physical or RF proximity are required when the device is network-reachable [1]. If the medical network is properly isolated, the attacker instead needs direct network access or physical access to a device — isolation reduces but does not eliminate the exposure [6].

A concrete step-by-step exploitation chain looks like this [3][4][5]:

1. Obtain the shared SSH private key — extract it from any affected device’s configuration files, or recover it from publicly available material; the same key is valid fleet-wide.
2. Identify a network-reachable affected device (a CARESCAPE/ApexPro telemetry server, Central Station, CIC, or a B450/B650/B850 monitor) with TCP 22 exposed — for example on a flat or poorly segmented hospital “Mission Critical” network.
3. Connect to that device’s SSH service and authenticate with the shared key. No password or user interaction is needed and attack complexity is low.
4. Obtain an interactive/management session and execute code on the device.
5. Leverage that access — optionally chaining the other MDhex issues — to manipulate the monitoring environment: set or alter alarm limits, admit or discharge patients, change the device date/time, disable alerts, exfiltrate PHI and monitoring data, or render monitoring unavailable, such that the equipment may fail to advise the nurse’s station of patient deterioration [5].

The severity comes from the trivial exploitability of a shared, recoverable key on life-critical clinical hardware.

4. Discovery & timeline

The flaw was discovered by Elad Luz, Head of Research at CyberMDX (now a Forescout company), as part of the six-CVE MDhex disclosure [3]. It was reported to GE on 2019-09-18 and publicly disclosed on 2020-01-23, coordinated with the CISA ICS-Medical advisory ICSMA-20-023-01 (dated 2020-01-23), which bundles all six MDhex CVEs and enumerates affected products and mitigations [2][3]. At disclosure GE was still developing patches and offered interim network-based mitigations rather than a released fixed version [5][6].

5. Technical reference

• CVE: CVE-2020-6961 (one of CVE-2020-6961 through CVE-2020-6966, collectively “MDhex”) [3].
• CWE: CWE-522 (Insufficiently Protected Credentials); CWE-256 (Plaintext Storage of a Password) [1].
• CVSS v3.1: 10.0 CRITICAL — vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H [1]. Reading the key metrics for this bug: AV:N — reachable over the network; AC:L — no special conditions, the key is easily recovered and low-complexity to use; PR:N — no privileges needed, the key alone authenticates; UI:N — no clinician interaction required; S:C — scope is Changed, per the NVD vector [1]; C:H/I:H/A:H — full loss of confidentiality (PHI/monitoring data), integrity (alarm limits, patient admit/discharge, date/time), and availability (monitoring can be rendered unavailable). (Author’s inference, not stated by a cited source: the Changed scope is consistent with compromise of the SSH service enabling the attacker to affect the broader monitoring environment beyond the SSH component itself; NVD publishes the S:C value but does not narrate this rationale.)
• Code/commit refs: none available. The exact filesystem path/filename of the configuration file holding the key is not given by the sources (described only as “configuration files” / “SSH server configuration”).
• Advisory refs: CISA ICSMA-20-023-01 [2]; NVD CVE-2020-6961 [1].

6. Consequence & CFSE path analysis

Real-world consequence: an attacker who reaches an affected device over the network and presents the shared key gets an interactive, unauthenticated session on hospital patient-monitoring equipment. From there they can falsify what clinicians see, silence or alter alarms, and take monitors offline — actions that bear directly on life-critical bedside surveillance — and can exfiltrate patient health information. The clinical failure mode explicitly documented is monitors failing to advise the nurse’s station of patient deterioration [5].

Why the CFSE Path Score differs from CVSS. CVSS gives this a flat 10.0: it correctly registers maximum technical impact but treats confidentiality, integrity, and availability as interchangeable “High” checkboxes and stops at the device. CFSE instead traces what the access lets you do to a clinical outcome, decomposing the single exposed, universally-shared SSH key into distinct consequence paths and scoring each on where it actually lands. That is why the CFSE verdict is EMERGENCY with direction UNDER relative to the NVD CVSS 10 baseline — CVSS’s ceiling of 10 cannot express that two independent consequence paths each reach a life-safety endpoint, which is the substance CFSE surfaces.

The CFSE analysis is as follows:

• Verdict: EMERGENCY (direction UNDER vs. the NVD CVSS 10 baseline).
• Dominant paths (co-dominant, both EMERGENCY):
• PERCEPTION_TO_ACTION — interactive access can falsify patient-monitoring and alarm state that clinicians act on for life-critical decisions.
• DEVICE_CONTROL_SAFETY — the attacker can silence alarms or render monitors unavailable, undermining life-critical surveillance.
• Supporting path: DATA_PRIVACY — scored CRITICAL, capped down from an EMERGENCY base because it only exposes PHI and monitoring data without independently reaching alarm-manipulation or safety consequences.
• Shared exposure across all paths: RE:4 (network-reachable), EC:4 (trivial SSH connect), SR:4 (shared fleet-wide key), SX:4 (remote, fleet-scale), OR:4 (recall-class recovery requiring key-rotating firmware and segmentation), EV:2 (report-backed), with a patch available.
• Summary: The entry decomposes the vulnerability into three consequence paths, all anchored on the same exposed, universally-shared SSH private key that grants network-reachable, unauthenticated SSH access across the affected CARESCAPE/ApexPro product line. Two co-dominant paths land at EMERGENCY (perception-to-action and device-control-safety); a supporting data-privacy path is CRITICAL. The overall path_verdict is EMERGENCY.

7. Remediation & mitigations

Grounded in the sources, the following apply specifically to this shared-SSH-key flaw and the MDhex set [2][4][5][6]:

• Vendor fix: At disclosure GE was developing software updates with additional security enhancements. No fixed version number or timeline was named in the available sources. A durable fix for this flaw necessarily requires rotating away from the shared key — re-provisioning unique per-device or per-site key material via firmware so that recovering one device’s key no longer authenticates to any other. The sources do not confirm such a key-rotating firmware release; treat the vendor fix as unconfirmed pending a named version.
• Block SSH at the network boundary: the direct mitigation for this CVE is to block/close TCP 22 (SSH) at the firewall so the vulnerable service is unreachable from untrusted networks.
• Segment and isolate: place affected devices on isolated Mission Critical (MC) and Information Exchange (IX) / medical networks behind firewalls; block inbound traffic except necessary clinical data flows. Isolation reduces but does not fully eliminate risk — an attacker with direct network or physical access can still reach the SSH service [6].
• Restrict physical access to central stations and telemetry servers, which limits an attacker’s ability to extract the shared key locally from a device’s configuration files.
• For the broader MDhex set (the other five CVEs, not this one specifically): block TCP/UDP 137/138/139 (NetBIOS), TCP 445 (SMB), and TCP 10000, 5225, 5800, 5900, 10001, and change default Webmin passwords. These address adjacent MDhex issues rather than the shared-SSH-key flaw itself, but are part of the same coordinated mitigation guidance.

8. Sources

[1] NVD — CVE-2020-6961 — NVD (NIST) — https://nvd.nist.gov/vuln/detail/CVE-2020-6961 — Authoritative CVE record: SSH private key in configuration files, CVSS v3.1 10.0 vector, CWE-522/CWE-256, and affected product/version list (CARESCAPE Central Station listed as both 1.X and 2.X). Credibility: primary-advisory.

[2] ICSMA-20-023-01: GE CARESCAPE, ApexPro, and Clinical Information Center systems — CISA (ICS-CERT medical advisory) — https://www.cisa.gov/news-events/ics-medical-advisories/icsma-20-023-01 — Official advisory bundling all six MDhex CVEs, affected products/versions, CVSS scores, discovery credit, and GE/CISA mitigation guidance. Credibility: primary-advisory.

[3] MDhex Vulnerability (CyberMDX research, now Forescout) — Forescout Research Labs (formerly CyberMDX) — https://www.forescout.com/research-labs/mdhex-vulnerability/ — Original researcher writeup confirming the universally-shared embedded SSH private key enabling remote access and code execution, discovery credit to Elad Luz, and the disclosure timeline. Credibility: researcher-primary.

[4] Critical MDhex Vulnerabilities Shake the Healthcare Sector — BleepingComputer — https://www.bleepingcomputer.com/news/security/critical-mdhex-vulnerabilities-shake-the-healthcare-sector/ — Technical press coverage: distributed SSH private key enabling remote SSH management/code execution, product matrix, concrete mitigation ports, and no known exploitation. Credibility: reputable-press.

[5] Critical, Unpatched ‘MDhex’ Bugs Threaten Hospital Devices — Threatpost — https://threatpost.com/critical-mdhex-bugs-ge-medical-devices/152163/ — Explains MDhex naming, clinical-safety impact (alarm modification, alerts disabled, failure to advise nurse’s station), low complexity, hardcoded/consistent credentials, and patch-in-development status. Credibility: reputable-press.

[6] MDhex vulnerabilities open GE Healthcare patient monitoring devices to attackers — Help Net Security — https://www.helpnetsecurity.com/2020/01/24/vulnerabilities-patient-monitoring-devices/ — Independent corroboration of affected devices (incl. B450/B650/B850), the shared-key nature, no named patched version, and that isolation reduces but does not eliminate risk. Credibility: reputable-press.

[7] Critical ‘MDHex’ Vulnerabilities Identified in GE Healthcare Patient Monitoring Products — HIPAA Journal — https://www.hipaajournal.com/critical-mdhex-vulnerabilities-identified-in-ge-healthcare-patient-monitoring-products/ — Compliance-focused coverage emphasizing PHI exposure and the six-CVE set; supports the data-privacy consequence path. Credibility: reputable-press.