I have been involved in a number of healthcare penetration tests here at Coalfire and in my previous roles. I have hacked electronic medical records, medical devices, and most importantly, humans. From my time as a systems engineer at a medical device and systems vendor to my current role at Coalfire as a penetration tester, I have seen a few healthcare organizations grow from highly insecure to cyber-fortresses. In this blog, I will highlight the most common issues my teammates and I come across while penetration testing healthcare environments.
Healthcare organizations are quite prone to using default and easy-to-guess credentials. This is partly due to the lack of vendor risk management. However, the responsibility still lies with the organization itself. We see default credentials used for electronic medical records (EMRs), radiology applications, ventilators, labs medical devices, operating systems, and other applications. Often, we come across default credentials for medical devices that lead to unchecked access to the Active Directory.
One common way we exploit this vulnerability is by going through an internally developed default credentials list. Once a username and password combination prove useful, the penetration tester moves laterally to check how far those credentials can take the tester. For example, a commonly used cardiology information system is known to have two default users and passwords. Most of the clients we interacted with gave these default users local administrator privileges on an Active Directory-connected system. The result of this was domain admin access within two hours.
click to enlarge image
These users often have system and database access across the environment. This can result in access to patient data, system shell, and web applications inside the network. In the screenshot below, we show an environment where the default application users had access to all EMR databases inside the network.
Security researchers Scott Erven and Mark Collao released a list of default medical device passwords at DEF CON 23. The presentation was titled “Medical Devices: Pwnage and Honeypots” and is available here https://www.youtube.com/watch?v=ZusL2BY6_XU.
We have found that healthcare environments have a relatively high number of misconfigured or unconfigured systems and applications. In this instance, the client used VNC Server to manage a large number of Windows systems. Since VNC uses its own authentication, and that authentication is often disabled by default, Coalfire was able to access most of the VNC-enabled Windows systems without the need for any authentication.
One of the systems we exploited through an unauthenticated VNC session was a medication dispensing station. Now, Coalfire had access to electronic protected health information (ePHI) and medication inventory.
In another penetration test, we gained access to a cardiology data management server with default application and system credentials. Here, we were surprised to see a very outdated version of the web application running without the need for authentication. This app contained ePHI such as patient names, patient IDs, and dates of birth.
As surprising as it may be, in 2017 we came across a paging system that had not been updated since 2005. Without any authentication requirements, this application allowed us to page any clinical staff including those with critical roles in the emergency room.
During our testing, we often find ePHI and other sensitive data stored in plaintext. This data is often found in user shares, department shares, and users' home directories. Once armed with Active Directory credentials, we go scavenging these directories for patient data, passwords, and financial data.
click to enlarge image
In another instance, the IT helpdesk had saved their passwords in a plaintext Excel file named "passwords.xlsx." Access to this file gave us further reach into the EMR and other critical systems inside the client's organization.
Coalfire often comes across unencrypted clinical systems, including the servers hosting electronic medical records. Since the disk is not encrypted, we can just reboot the system using a Linux flash drive and go scavenging.
As a result, we gained access to all patient data stored on this system.
While researchers and vendors are working toward WPA3, we still find wired equivalent privacy (WEP)-enabled medical devices and wireless access points in healthcare environments. In the screenshot below, you see us cracking a WEP shared-key. The access point in question was connecting two medical devices in the ICU to the rest of the network. Since these devices were located in the middle of the ICU, we had to walk the hallways outside the ICU to ensure good connectivity. In the end, we cracked the key in a few minutes.
click to enlarge image
Now that I have you afraid of going to hospitals, what can we do to fix the issues highlighted above? There is no straight answer. The purpose of the federally mandated Health Insurance Portability and Accountability Act (HIPAA) of 1996 is to establish national standards for the protection of ePHI. The goal of HIPAA is to ensure a patient’s access to care, while at the same time requiring covered entities and business associates protect the confidentiality, integrity, and availability (CIA) of ePHI. The Security Rule requires covered entities and their business associates implement reasonable and appropriate safeguards to protect ePHI. In addition to general security controls, such as access controls, termination procedures, and security awareness training, HIPAA requires organizations to conduct periodic information security risk analysis on all assets that create, receive, maintain, or transmit ePHI. Organizations should also conduct non-technical evaluations, such as compliance and gap assessments, and technical evaluations, such as penetration tests. A thorough and comprehensive security risk analysis is an important first step in identifying risks to patient data and patient safety due to cyber risk and determining mitigating controls. This should be augmented by a well-rounded risk management program with periodic risk analysis, including penetration testing, as the environment changes.
Also, the industry has developed the HITRUST CSF framework. This framework is based on ISO 27002 and incorporates other relevant information security assessment frameworks such as NIST RMF, FedRAMP, and PCI-DSS. HITRUST CSF assesses the organization on policy, procedure, implementation, measurement, and management related to specific requirements. There are business requirements such as the development of information security teams and very technical requirements about the implementation of DNSSEC, full disk encryption, and penetration testing. This level of granularity means a HITRUST certification could bring the healthcare information security program maturity level to par with other industries. HITRUST certification may also help healthcare organizations demonstrate compliance with the HIPAA Security Rule. See the following link for more: https://hitrustalliance.net/frequently-asked/1/en/topic/if-i-m-hitrust-csf-certified-does-that-mean-i-m-hipaa-compliant.
So, does a penetration tester with a healthcare background like me believe HITRUST certification alone is sufficient? Of course, my answer is 'no.' Regulatory and industry compliance frameworks are the bare minimum and rarely account for new threats. However, I believe HIPAA and HITRUST are good starting points for both the business and technical aspects. They help healthcare organizations satisfy their compliance needs while improving their overall security posture. I do however believe that information security is a dynamic field. Organizations must continue to identify their weak points while improving the existing security organization. Information Security, IT, and Development departments alike need to take security training (Security+, CISSP, OSCP, etc.) and test their security posture through penetration testing, and the enterprise should assess the users' security awareness with periodic assessments like phishing testing, red team/blue team exercises, etc. Assess your vendors for third-party risks and implement common-sense third-party security controls, such as requiring that all default passwords be changed before EMRs like Cerner, Epic, NextGen, etc. are introduced to the organization. Prevent the vendors from creating their own IT organization within the hospital's IT organization. We once identified an unmanaged Active Directory domain deployed by an EMR vendor, nested within the hospital's Active Directory domain. Risks like this are not uncommon and can be thwarted with sound information security policies that require assessment for any new technology or process being introduced to the organization.