Editor’s Note: Sven Krewitt is the Senior Vulnerability Researcher for Risk Based Security, a detailed information and analysis on data breaches and vulnerability intelligence. Krewitt brings 11 years of experience as a security specialist and vulnerability researcher. He has previously worked as a Senior Security Specialist focusing on vulnerability analysis, quality assurance, and training of new employees.
The first known medical vulnerability currently on record is from June 1985 and was in a radiation therapy machine, Therac-25, produced by Atomic Energy of Canada Limited (AECL). Due to a race condition the vulnerability lead to fatal radiation overdoses in patients.
Since some of the initial reports in 2011 about vulnerabilities in medical devices, research into this area has noticeably gained popularity. Some of the more widely published research includes vulnerabilities discovered in insulin pumps and defibrillators. The risks of vulnerabilities in medical devices was further underlined when Dick Cheney revealed in a 60 Minutes interview that he feared his pacemaker being hacked and specifically had asked for the wireless functions to be turned off by his doctors.
In fact, there have lately been several high profile medical cases including the release of a firmware update for an implantable cardiac pacemaker to fix a vulnerability affecting hundreds of thousands of patients carrying affected devices. We have also seen involvement of the FDA and even security professionals creating groups such as I Am The Cavalry, trying to increase visibility and encourage more effort being put into securing medical products.
These security risks are not limited to medical devices themselves, but any software used in the medical sector to collect, organize, or transfer PII such as medical records. To be clear, we are not just talking about expensive commercial software products either. While processing a vulnerability report, one widely used open-source medical product, OpenEMR, gained our interest, as it is stated to be “a leader in healthcare open source software“. Further researchshowed that in the USA, it has been estimated that there are more than 5,000 installations of OpenEMR in physician offices and other small healthcare facilities serving more than 30 million patients. Internationally, estimates are that OpenEMR is installed in over 15,000 healthcare facilities with more than 45,000 practitioners using the system supporting over 90 million patients. Any security issue in OpenEMR has the potential for widespread impact.
OpenEMR is written in PHP and according to our own Vulnerability Intelligence solution, VulnDB, there has been reported 118 vulnerabilities in the product since 2006, including four code execution and 42 SQL injection issues.
While reviewing the issues, one particular vulnerability stood out: A SQL injection vulnerability in the setup.php script. On the surface this primarily sounds like a misconfiguration by a system administrator, as best security practices generally dictate that setup scripts should be removed after the installation routine has finished. In this case, however, the setup scripts are not removed automatically and the support wiki only appeared to contain a suggestion to “consider removing (or ensuring no access to)” the setup script.
“We believe that this phrasing is far too vague to convince a customer to remove the setup scripts. It also fails to properly warn about the risks of not doing so.”, said Sven Krewitt, Senior Vulnerability Researcher for Risk Based Security, who conducted the OpenEMR research.
Based on the widespread usage and potential serious impact, this lead the RBS Research team to focus on two important and unanswered questions:
1. What percentage of OpenEMR customers have removed the setup scripts or restricted access as suggested in the support wiki?
2. What is the risk to OpenEMR customers, who have not followed this suggestion?
Open Installations With Setup Scripts Accessible
Admittedly, considering typical use-cases of this product at physician offices and other small healthcare facilities, we knew that most installations would not be publicly accessible, but running within internal networks. However, between August and November of 2017, using publicly available search engines Shodan and Censys, we were able to identify 188 unique IP addresses with an accessible OpenEMR-based installation. 141 of the 188 (75%) actually have the setup.php script accessible.
This clearly confirmed our suspicion that the recommendation is too vague or that system administrators simply aren’t aware that they have to take further actions once setup is completed. It is even more troubling considering these installations are Internet-accessible. While the sample size is small, we can make a decent assumption that a substantial percentage of the over 20,000 installations of OpenEMR are in a similar state.
But what is the potential impact of attackers having access to this setup script?
Prepare To Be Probed and Potentially Worse
As previously mentioned, in April of 2017 an SQL injection vulnerability was reported in the setup.php script. Having access to a setup script typically means that the functionality, which handles the initial configuration of the application, is within reach. Considering initial configuration usually requires administrative access, this is immediately a concern.
After our RBS research team conducted a brief analysis, it revealed that the already known SQL injection vulnerability is the least of users’ worries. Unauthorized access to this OpenEMR setup script allows gaining administrative access to the application, including the ability to execute arbitrary PHP code on the system.
Immediately one would make that assumption that an attacker could trivially just change the administrator password of the current OpenEMR installation. However, our research showed that unauthenticated access to the script actually does not allow any reconfiguring of the existing installation. What we were able to determine is that it does allow instantiating additional sites in OpenEMR (see Multiple Sites Module), each using a separate configuration.
The settings of each new site include MySQL database parameters, which can arbitrarily be chosen by an attacker. Specifying a remote, attacker-controlled MySQL database during a new site-setup would, therefore, create an additional OpenEMR instance connecting to a remote MySQL server. In addition, the administrator account can be specified during a rogue multi-site installation, causing authentication for the new site to now use the remote database.
This approach allows an unauthenticated, remote attacker to gain administrative access to the current and original OpenEMR installation.
This is the first step of the attack, but it doesn’t stop here. Having access with administrator privileges to an OpenEMR instance is considered critical, but the site databases are separated from each other. However, the administrator can edit local PHP files via the ‘Administration/Files’ menu. This allows inserting arbitrary PHP code, which is executed in context of the web server. This ultimately allows getting full control of the installation and e.g. disclose all stored patient data in the database or the file system.
Exploitation does require directory permissions allowing the configuration of a new site, but our research shows that around 54% of the open installations we uncovered are vulnerable to this sort of attack.
Cleanup and Conclusion
Even with all the attention the medical industry has received over the years with security issues, our research shows there is still a long way to go. At the end of our research, we decided to check geolocation and ISP-related information of the Internet-accessible OpenEMR installations.
| Top Countries | |
| United States | 143 |
| Canada | 10 |
| Germany | 5 |
| India | 4 |
| Ireland | 4 |
While most of the IP addresses are located in the United States, we found an interesting, but not that surprising statistic about the hosting providers used by the organizations using OpenEMR on the Internet.
| Internet Service Provider / ASN (Autonomous System Number) | |
| Amazon.com, Inc. | 67 |
| Google Inc. | 13 |
| Microsoft Corporation | 12 |
| Digital Ocean, Inc. | 9 |
| Comcast Cable Communications, LLC | 6 |
This further supports the concern of software being installed in the cloud and improperly locked down. While we still believe that other installations on private networks are affected, the fact that these cloud installations are impacted means that many organizations’ and patients’ data is quite likely currently exposed.
The potential impact to medical data is highly concerning to RBS. We were able to track down 78 of the 141 organizations that had an OpenEMR installation with the setup script accessible. However, finding the proper contact information proved difficult and time consuming. It is a stark reminder of the importance of having an easy to find security contact email address on your website. We have attempted to reach out to the organizations for which we were able to find contact information and alerted them to the risk, suggesting actions be taken immediately.
RBS contacted the OpenEMR project team prior to publishing this blog to work with them on improving the security and protect their customers. We received a prompt reply from the project lead. An official patch was released four days later, including an announcement to the community. In addition, the wiki was changed to recommend the removal of the setup.php script.
“We appreciate the OpenEMR developers quick turnaround and highly recommend that their users follow the suggestion to remove all unnecessary files and apply the latest patch”, added Krewitt.
12/21: The OpenEMR community released a patch to fix this exploit. Details can be found at http://open-emr.org/wiki/index.php/OpenEMR_Patches
