TL; DR
We bought a medical infusion pump device from eBay and from it, forensically retrieved the WPA key and server authentication credentials for a real-world hospital’s wireless network and medical pump management server. In the wrong hands, such capability could be life-threatening given the level of network-based access this information would present to attackers – in the worst case scenario, our findings might allow for manipulation or disruption of the hospital’s network of infusion pumps which could result in harm to the health of patients connected to the pumps or worse still, their fatality.
This is a true yet anonymised account of recent concerning findings from our Connected Health security research. This is not about vulnerabilities in the Connected Health device itself, but more on the paramount importance, particularly in the health sector, of changing default PINs and passwords and the need for accurate asset management and secure decommissioning processes – i.e. the security basics.
Our connected health research
As part of our Connected Health research theme we are currently engaged in a number of research activities, one of which is vulnerability research of medical infusion pumps. Mostly we are doing this to develop our understanding of systemic or inherent vulnerabilities in such device types and to build on our security testing capabilities against such devices through tooling, protocol fuzzing etc. We wanted to perform a hardware teardown of one of the devices that we had acquired, but in the interest of not wanting to potentially damage that particular device, we sought to procure another one that we could use to take apart and analyse its constituent components.
We took to eBay and slightly to our surprise, found a number of eBay sellers selling the exact device that we were after – sometimes just one unit, other times in job lots of 30 or more! Our surprise here was how easy it seemed to buy such equipment which isn’t readily available off the shelf and is usually quite expensive when bought new. Regardless, we found what we needed and for £118 (plus postage and packaging) it felt like a bargain.
Your package has arrived
About a week later and our spare infusion pump (actually to be clear, the main control unit rather than the actual pump) arrived. We unboxed it and powered it on just to check that it was operational – it was, and we noticed within seconds of it booting up some text at the top of its screen that read:
ACME-HOSP-HOLBY
This simple string of text seemed to identify a hospital name and the place of that hospital. A quick Google search took us straight to the ACME hospital, which seemed to be in the city of Holby.
We played around with the menus on the device and followed the network settings option which prompted us for a 5-digit PIN to view the settings. We already knew of a common/default PIN for this device type and disappointingly, the same default PIN was enabled on this device, allowing us to view its network settings and to see that the device was configured to connect to a wireless network with the SSID of HOLBY1.
With this information we checked the wigle [1] wireless network mapping website to see if the HOLBY1 wireless was indeed at or near the ACME hospital in Holby. It was. We felt confident that we knew exactly which hospital this infusion pump unit had come from, the wireless network to which it connected within that hospital and that the wireless network likely still exists. Our next phase of investigation was to try and recover the wireless network key for the HOLBY1 network.
Recovering the wireless (WPA) key
This was achieved. From our research on our original pump we had developed a capability to access it’s configuration over a serial connection. The same capability worked on our eBay purchase and with ease we dumped the following information in plaintext:
- The WPA key for the HOLBY1 network – it was a 15 character string, but mildly guessable as it related to the hospital and contained the substring ‘HOLBY’
- The hostname, IP address and port of the management server for the ACME-HOSP-HOLBY device
- Encryption keys to connected to the management server
At this point we had enough information that would likely allow us to connect to the ACME hospital wireless network with valid credentials and communicate with the management server for other pumps on the same hospital network. We would simply need to be within the vicinity of the hospital wireless network (such as the carpark) do to this.
To be clear, we have not in any way attempted to connect to the real hospital with the information from our findings (e.g. to validate that the network authentication credentials are valid).
Other information leakage of value to attackers
Having identified the ACME hospital and credentials to connect to one of its wireless networks, we briefly performed additional open source information gathering on the hospital to understand if we could gain further information that would be useful to attackers seeking to exploit the connectivity credentials that they might find, as we did, from the pump control unit.
We ran FOCA [2], a tool for finding metadata and information in documents, against the ACME hospital website. From 113 downloaded documents, FOCA extracted 35 internal network usernames at the hospital (the naming convention was HOLB
The striking realisation at this point was that we had amassed this wealth of attacker-useful information pertaining to a hospital network without having connected to the network in any way. Our exploitation path to date had purely been information leakage.
Worst case scenario
One can only begin to imagine the potential bad scenarios here should malicious threat actors follow similar investigation techniques. Worst case scenarios might include attackers connecting to victim hospital networks and deliberately disrupting or manipulating the connected pump infrastructure, possibly resulting in inaccurate or lethal dosages being administered to patients. If a hospital network were compromised in this way, so many questions arise, including:
- Can we trust the future integrity of connected medical devices of a known compromised hospital network?
- How do we assure future hospital network security in the wake of a known security breach?
- Who’s the risk owner for any impact on health or loss of life as a result of a hospital network compromise?
How do these devices end up on eBay?
We pondered how our newer device ended up on eBay in its non-wiped. We asked the eBay seller where they got their stock from, and whether they undertook any secure data wiping. We received a fairly quick response from the seller:
“These pumps were purchased in auction. We use a local computer company to wipe patient data.”
While there did indeed appear to be no patient data on the device (though we continue our forensics work to confirm this), a number of questions and observations arise from this response:
- The pumps were purchased at auction – this means that there has been at least one other intermediary between the hospital and the eBay seller – we wonder therefore how many other sources have handled (and had access to the device) between the hospital and ourselves?
- Assuming the ACME hospital did indeed put the device up for auction, is this a standard practice with hospitals for old/decommissioned kit?
- Use of a local company to wipe patient data – who is this company, are they authorised by the ACME hospital to do so, as in they will have access to patient data before the wiping process, so is there perhaps some data breach issue here?
- The belief that wiping patient data is sufficient – clearly there is an oversight on deletion of configuration data
- The elephant in the room – was this device stolen, if not by the eBay seller, then some other intermediary? We hope not, but it’s possible…
- Beyond security researchers, who is the market for used medical equipment? Who is actually buying this kit for legitimate purposes? Might other hospitals be buying used (and potentially compromised) medical devices from eBay?
Risk mitigation
We are of course responsibly disclosing our findings to the real-world affected hospital in this case. In the process we’re providing a number of recommendations for mitigating the risks in this domain, and we hope these recommendations are of use to other hospitals or medical entities who maintain connected medical devices, and to medical device manufacturers.
Asset Management
Asset management of medical devices is critical to the security of hospital networks. It is acknowledged that this can be difficult in say a hospital with potentially thousands of connected devices that move around a large site as patients are moved between wards etc. One can imagine how losing track of assets in such a dynamic environment can occur, however as seen in this blog, the consequence of not having a good handle on assets could be at the detriment to the security of the entire hospital.
All equipment should be asset tagged and logged and with suitable anti-tamper stickers (and other hardware mechanisms where possible). Default PINs or passwords should also be changed, while secure passwords should be chosen for wireless network access.
Most if not all connected equipment will communicate with one or more central servers – the logs of these communications should serve as a good guide on which devices are in use and thus are within the vicinity of the hospital (i.e. ideally the devices should poll or call home to central servers periodically to indicate their presence). If a medical device has not communicated with a central server in say a few days or a week, the inference here might be that it is permanently turned off or has been taken away from site – in these situations, ideally efforts should be made to confirm that the device is still present on site, and if it cannot be located or accounted for, then suitable incident response processes should be initiated.
Secure Decommissioning
Where connected medical devices are to be decommissioned, this must be done securely. This includes secure wiping of both patient data, *and* configuration data (security, network etc.). Hospitals should have clear guidance and processes for this, and if using 3rd parties for this task should ensure appropriate 3rd party due diligence has been performed on those organisations.
If there are deep concerns on the potential for data recovery despite secure wiping processes, then decommissioning processes should also consider secure destruction of hardware.
Connected medical device manufacturers should ensure that documentation has clear guidance on secure wiping and decommission of their devices, and that those secure wipe functions are implemented within the devices.
For hospitals that are concerned about their asset management (past and/or present), they might want to perform periodic online checks on websites such as eBay to check that their devices are not finding their way to those online markets without proper authorisation.
General Network Security Best Practices
General best practices in network security will also help mitigate issues from unauthorised network access, such as segregation (i.e. keeping connected pump networks separate from other critical networks in the hospital), patching, strong passwords and protective monitoring.
Information leakage before you buy
We decided to purchase yet another pump from eBay, for increasing the number available to our researchers and also to perform additional forensics activities to identify potentially other hospitals vulnerable to the findings in this blog post.
Without lie, the same eBay seller had another pump for sale for a similar price, but this time we spotted that the screenshot of the device on the eBay listing page showed the device in a powered-on state. At the top of the screen of the device, on the eBay image was the string:
ACME-HOSP-HOLBY
We can only conclude that either ACME hospital in Holby is legitimately auctioning off its connected health equipment (but being negligent in the process), or it is facing an asset management crisis and is a victim of theft.
Either way, this is at the detriment to the security of its hospital network and most alarmingly, the potential fatality of its patients.
References
