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.
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.
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.
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.
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.
I think that’s enough for now. In the next post, we’ll crack open the machine so you can peer into its insides.
Catch you next time.