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 couple of posts, I would like to take you through in the nuts and bolts of the analysis itself through the inspection of a genuine, real-life medical device. Starting with an examination of the device itself, we’ll take a look at the physical design and menus before getting into the analysis of the functionality.
Below is an image of the machine. It’s a Philips, SureSigns, VS2 Plus Patient Monitor with connections for a temperature probe, pressure cuff, and a pulse-oximeter (pulse-ox) sensor.
We purchased it from a used medical device vendor specifically to do some testing. This device was not given to us by the manufacturer or a hospital.
I mentioned in a previous post that we found repair manuals for the device. A repair manual is very helpful, as it can provide an inside view of a device without having to physically crack it open. In addition, we found information on the manufacturer’s website, though having the device in hand is a much simpler way to find vulnerabilities and test exploits than trying to do it remotely or from a patient bedside.
Start ‘er Up
On the left: The device starting up. Notice the splash screen helpfully provides the software version installed.
On the right: The back of the machine with ports for the nurse call connector and device sensors. Most relevant to a security assessment, though, are the USB and ethernet ports due to the wide array of potential connectivity (and thus, potential threat vectors). This machine also comes in a Wi-Fi version, which in that case that would be another port to consider.
Below is a view of the main screen. Obviously, it’s not hooked up to a patient, so the heartrate, oxygenation, and other monitors are blank and not generating any visualizations.
In the inset to the right, you can see the user interface options at the bottom of the screen to access the patient records, print, settings, and alarms. Enticing.
With this device, we first looked for what we could do without a password. At the same time, we kept in mind how long things took, say if there might be enough time for someone to tailgate into a room and modify something quickly.
Without an admin access password, we were able to access this screen (below, top left). From here, we were able to see the patient information, make a new patient record, and save it to a USB stick we stuck into the machine.
We were also able to see system information (above, top right) with hardware ID, IP address, and MAC address. With this information in hand, it’s possible a bad actor wouldn’t even need to be in the room when they wanted to launch an attack on the device.
Surprisingly, we were able to also modify the alarms settings (above, bottom). What would happen if the alarms were turned off without staff knowing?
Wow, there were a lot of actions available and settings we could futz with without authenticating access. Many patient-related information actions and settings like records, alarms, and data saving can be modified without any authentication.
Now what can be done without a password might be scary, but that might be a design decision to make it easier to work with the device in the clinic. Therefore, device users would need security controls to compensate for the design.
Though, we should be concerned that USB seems like an easy path in and out of the machine. As we’ll see later, in addition to data saving and recovery, it’s also used for machine saving and recovering configuration settings and software updates. How might this be hacked? Could we spoof an upgrade?
Keeping in mind you’d need be at the machine, perhaps it’s not the easiest of exploits, but who would know if you did?
Now that we’ve seen what you could do just walking up to the device, in the next segment, we’ll try to get into the authenticated access and the administrative functions that lie beneath.
See you next time.