Empty passwords and cleartext storage in a home cardiac monitor

MedDevice Cyber Staff · Jul 24 · 3 min read · Via CISA

The Medtronic MyCareLink Patient Monitor drew ICSMA-25-205-01. Three findings: data on an unencrypted filesystem, a built-in account with an empty password, and an internal service that deserializes untrusted data. Top score around 6.8, all requiring physical access, and Medtronic reported no evidence of exploitation.

Each of the three weaknesses is elementary in its own way. Storing data in the clear leaves everything the device has recorded readable to anyone who holds the hardware. A built-in account with an empty password is an authentication control that verifies nothing. Deserializing untrusted data means rebuilding program objects from input an attacker can shape, a long-established route from a malformed message to unintended code.

The physical-access requirement caps the severity. It does not excuse the findings. An empty-password account and cleartext storage are what a first-year secure-design review is supposed to catch. And home cardiac monitors sit on a nightstand for years, then get resold, returned and refurbished, so physical access is not exotic for a device that lives in a bedroom.

Home cardiac monitors exist to relay readings from an implanted device back to a clinic, which makes the data they hold intimate and the confidence placed in them considerable. A weakness that lets a later holder of the hardware read that store or feed the device malformed input turns an intimate record into an exposure, and does so on equipment a patient was told to treat as routine household electronics.

Medtronic auto-deployed updates. Credit to Ethan Morchy of Somerset Recon and Carl Mann. If you make home devices, assume the attacker will eventually hold the hardware and design the storage and accounts for that day.

The wider signal is about where such devices are built and sold. Hardware that migrates from the clinic into the living room inherits a threat model the original medical setting never imposed, and the security review it received on the way to market does not always travel with it into the years it spends in a patient's home.

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

The Medtronic MyCareLink monitor stored data unencrypted, shipped a built-in account with an empty password, and deserialized untrusted data (ICSMA-25-205-01), all requiring physical access with no exploitation reported. Apply the update, and if you build home monitors, encrypt data at rest, remove default accounts, and never deserialize untrusted input.

Apply the vendor update. Install the remediated MyCareLink build from ICSMA-25-205-01.
Remove empty and default accounts. No shipped device should carry a built-in account with an empty or known password.
Encrypt data at rest. Protect stored patient data so physical access to the device does not hand over its contents.
Stop deserializing untrusted data. Replace unsafe deserialization with a parser that validates structure and type before building objects.

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.

Required

data_phi

Contributing

use_home app_user_accounts net_wireless app_database sys_firmware_update

EMB3D

PID-3121

Fix the class in your product

The product turns untrusted bytes into objects without constraint. As the maker, stop deserializing untrusted data into arbitrary types: move to a schema-validated format across trust boundaries, and set any framework type filter to its most restrictive value.

Allow-list types. Validate structure and allow-list expected types before constructing anything.
Restrict the framework. On .NET Remoting set TypeFilterLevel to Low, or replace remoting with an authenticated schema-checked API.
Block the endpoint. Firewall the deserialization port so untrusted hosts cannot reach it.

Mapped EMB3D mitigations

Questions & Answers

What did ICSMA-25-205-01 find in the Medtronic MyCareLink monitor?

Three issues: data stored on an unencrypted filesystem, a built-in account with an empty password, and an internal service that deserializes untrusted data. Top score around 6.8, all requiring physical access, with no evidence of exploitation.

If physical access is required, why does it matter?

Home cardiac monitors sit on a nightstand for years and then get resold, returned or refurbished. For a device that lives in a bedroom, physical access is a normal part of the lifecycle, and storage and accounts should be designed for that day.

Was a fix deployed for the MyCareLink findings?

Yes. Medtronic auto-deployed updates to fielded monitors. Ethan Morchy of Somerset Recon and Carl Mann were credited with the findings.

← Back to Vulnerabilities