One AES key, shared across every install of a cardiovascular system

MedDevice Cyber Staff · Mar 13 · 3 min read · Via CISA

Philips IntelliSpace Cardiovascular, versions 4.1 and 5.1 and prior, drew ICSMA-25-072-01. Two CVEs, both 7.7. The auth token is built from a fixed AES-128 key that ships identical across every installation, and separately the Windows login token can be replayed to bypass authentication.

A cryptographic key embedded in shipped software is a secret that is not truly secret. Because the same value is compiled into every copy, anyone able to obtain a single installation can recover the key by examining the program, and authentication tokens minted from that key can then be forged. The mechanism meant to prove a token genuine instead proves only that its holder possessed a value everyone received.

The replay weakness compounds the key problem. When a login token can be captured and presented again in place of a fresh authentication, the system is trusting possession of a string rather than proof of identity. Set beside a forgeable token scheme, it leaves the path to a valid-looking session openable in more than one way, and neither route requires guessing a password.

A shared static key means breaking one install breaks all of them. There is no per-customer secret isolating the blast radius, so recover the key once and you can forge tokens against any site running the software. What that buys an attacker is patient cardiovascular records and active sessions. Joe Dillon reported it.

The records behind a cardiovascular information system document imaging, procedures and the clinical history that guides treatment. Access won through a forged or replayed token looks like an ordinary session to the software, which makes an intrusion hard to separate from legitimate use and the resulting exposure of patient data hard to bound afterward.

Generate keys per install, store them properly, rotate them. Shipping the same secret to every customer keeps landing on this advisory page because it is convenient to build and impossible to fix after the fact.

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

Philips IntelliSpace Cardiovascular built its auth tokens on a fixed AES-128 key identical across every install and let the login token be replayed to bypass authentication (ICSMA-25-072-01). Apply the fix and, going forward, derive keys per install and bind tokens so they cannot be replayed.

Apply the vendor fix. Update IntelliSpace Cardiovascular to the remediated version from ICSMA-25-072-01.
Use per-install keys. A key shared across every deployment means one recovered key breaks them all; derive a unique key per installation.
Bind tokens against replay. Tie session tokens to time, nonce and session context so a captured token cannot be replayed to bypass login.

For Device ManufacturersAm I affected, and how to fix the class

Am I affected?

This class applies to devices with the properties below. Check them against your product to gauge exposure.

Contributing

app_user_accounts net_remote_access net_cloud app_database data_phi use_hospital_net sys_named_os app_roles

EMB3D

PID-3321 PID-3322 PID-4113

Fix the class in your product

Passwords are reversible or one key is shared across every install. As the maker, hash credentials with a purpose-built password algorithm, derive keys uniquely per installation, and bind tokens so a captured one cannot be replayed.

Hash, do not encode. Store credentials with a salted, memory-hard algorithm (argon2id or scrypt).
Derive keys per install. Never compile a shared key into the image; back it with a secure element.
Bind tokens against replay. Tie tokens to expiry, a nonce, and session context.

Mapped EMB3D mitigations

Questions & Answers

What is wrong with authentication in Philips IntelliSpace Cardiovascular?

ICSMA-25-072-01 covers two flaws, both 7.7, in versions 4.1 and 5.1 and prior. The auth token is built from a fixed AES-128 key that ships identical across every installation, and the Windows login token can be replayed to bypass authentication.

Why is one shared AES key across installs a problem?

Recover the key once and you can forge tokens against any site running the software. There is no per-customer secret to contain the blast radius, and the fix, per-install key generation, cannot be retrofitted quietly.

← Back to Vulnerabilities