Why Do A Medical Device Assessment, Part 4: Access Granted

Why Do A Medical Device Assessment, Part 4: Access Granted

In the last post, we got up close and personal with the device, and now it was time to really try to dig into the administrative functions. While the unauthenticated (non-password-protected) menus had some potentially problematic features available, things became more interesting as we moved into the service screens.

Authenticated Access

We were concerned that since this was a used device, the password had been lost, meaning we might have had to crack it.

Maybe we didn’t look hard enough, but in the manual, we didn’t find anything about changing any of the passwords. It’s possible the password is hardcoded, which would make it fairly easy to get into these devices whenever you want. Indeed, the manual listed the default password (next image), which was all we needed to log in.

Once we were logged in, this gave us access to the service menu (next image) where we could upgrade software, export and import settings, and modify LAN addresses.

We found out that there was no additional authentication required for exporting or importing the settings configuration. What’s more, when importing settings, the system automatically reboots. So someone could come in, access a machine, get into the service menu, upload a new setting, and leave as the machine rebooted, all within a matter of a minute or so (with some practice).

The settings configuration file seemed to be in a special format, which would require further research or some reverse engineering to figure out. We’d also be curious how deep the settings affect the machine – basically, what can be set from the configuration file.

As I mentioned, the USB port is used to update the firmware of the device, as well. What if someone updated it with modified software? Of course, you’re thinking of the patient, but think of modified software that does everything it is supposed to do, but also provides a base for a botnet or APTs lurking around the network. That kind of hidden threat could leave a backdoor open for all kinds of attacks at any time the bad actor sees fit.

Also, because certificates are involved, we would need to investigate how the machine responds to malformed or expired certificates and how easy it is to upload fraudulent certificates.

Data Export

The net screen (below) sets how the machine communicates with the HL7 server or EMR. We’d want to investigate this further to understand how the machine communicates to the server, what’s in those messages, and if there are any vulnerabilities.

We’d also investigate how robust the connections are and how resilient to man-in-the-middle attacks, or other forms of connection spoofing.

Diagnostic Menu

Interestingly, there was another password required to get into the diagnostics (and yes, it was a default password, and listed in service manual).

That password gets you into this system diagnostics menu (next image).

What’s interesting in this menu is that one can reset the error logs and the serial number. Might a threat actor cover their tracks by resetting the logs? Or might the threat actor reset or change the serial number to cover a rogue device they might be using to spoof the original?

There’s also an option to clear the data and restart the system. Might this be also a way someone could cover their tracks?


We were wondering about these simple passwords. Maybe it’s not so much that the machine needs a hyper-secure password; perhaps the first password might be for folks on the clinic floor, as a sort of speedbump to remind them they are entering a more serious part of the machine. And the diagnostics password might be reserved for the biomedical technicians.

Data Flow

Since the device has an ethernet port, we can do queries to see what it’s doing.

The device is visible on the network and responds to pings. And a scan for open ports didn’t reveal anything open. We’d want to connect the machine to a server so that we might inspect the ports under that use.

If we find open ports, we want to know why they are open and how to secure them.

Also, we want to understand the protocols that the device uses and how. That’s important information for securing a device. For example, building security controls that are fine-tuned to the device protocol, so that if there is improper traffic or protocols, we can flag or shutdown the device.

We also do vulnerability scans to learn more about the device, and if any CVEs have been reported. For this device, a vulnerability scan didn’t find anything interesting to report. We normally would then employ some heavier weaponry, such as a toolset like Metasploit, but in the interest of time we went straight for the innards of the device.

As part of our research for this device, we found an interesting article warning about vulnerabilities in another line of Philips patient monitors. The warning seemed to echo what we were seeing in this patient monitor. Basically, those monitors were called out because of hard-coded passwords, and lack of verification of the origin or integrity of code. In line with the idea of compensatory security controls, the DHS recommended that until a patch was provided, users should restrict system access to authorized personnel and follow a least privilege approach, apply defense-in-depth strategies, and disable unnecessary accounts and services.

Yeah, sounds like what we’d recommend for this monitor as well.

Next Episode

I think that’s enough for now. In the next post, we’ll crack open the machine so you can peer into its insides.

Cool stuff.

Catch you next time.


Insights to your Inbox

Stay informed with the latest cybersecurity news and resources.

Charlie Schick Healthcare Consultant

Why Do A Medical Device Assessment, Part 3: The Device

In the previous two posts in this series, I talked about the reasons cybersecurity analysis on medical devices is necessary and some processes behind device analysis. In the next coupl...
October 21, 2020
Board inspection
Charlie Schick Healthcare Consultant

Why Do A Medical Device Assessment, Part 2: How We Do It

In my last post, I talked a bit about the cybersecurity challenges around medical devices. In this post, I want to tell you a bit about the process of device cybersecurity analysis, wi...
October 15, 2020
Device Assessment
Charlie Schick Healthcare Consultant

Why Do A Medical Device Assessment, Part 1: “It’s Not a Good Situation”

Relevant to this series, Owl’s Device Inspection and Analysis Lab focuses on security analysis of all sorts of devices, ranging from laptops, servers, and mobile devices; to securing op...
October 7, 2020