Rios (2013) medical device vulns

394 views
310 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
394
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Rios (2013) medical device vulns

  1. 1. ISSA DEVELOPING AND CONNECTING CYBERSECURITY LEADERS GLOBALLY 12 – ISSA Journal | July 2013 Editor’s note: It is not the intention of the ISSA to expose new and unknown vulnerabilities. As this article indicates, the vulnerabilities noted have been conveyed to both the vendor and DHS ICS-CERT and have previously been published. Abstract Medical devices are designed to support human life. When you look at a medical device, do you think of how a security issue could affect it? Do you wonder what it would take to discover a critical security vulnerability in that device? Do you wonder what types of exploit mitigations are in place? These are the questions that a colleague and I asked ourselves when we purchased our first medical device for security re- search. This article chronicles some of the highlights of our investigation into medical device security and the industry that surrounds these devices. O n December 30, 2012, a large package was delivered to my personal residence. I quickly signed for it and carried the package to my home office. I hast- ily opened the box and took one second to admire the device (see figure 1). During the unpacking of the XPER, I noticed two hospital in- ventory tags of a well-known hospital in Utah. Knowing that the device had come from a real hospital, I cracked it open and made a forensically sound copy of the hard drive. I also made a separate copy of the drive so I could start my security research. After mounting the drive image, I was surprised to find that the XPER was running vanilla Windows XP – the XPER is simply a Windows application that runs on Windows XP! I conducted an extensive search for any patient data that might have been left on the device; luckily, I did not find any. Once I had convinced myself that the device had no patient data, I began to look for a potential attack surface. The listen- ing service on port 6000 immediately caught my attention. I launched a six-line python script that conducted a most ru- dimentary of fuzzing attempts against the XPER’s open port – the XPER process immediately crashed. My six-line python script just crashed a Philips XPER. A quick look at the proces- sor registers told me the complete story, I had discovered a heap overflow (see figure 2). I spent a few hours coding a Metasploit module that dem- onstrated the capability of this exploit. Writing an exploit like this is an exercise in massaging the computer memory so that my exploit code would run instead of the XPER’s This article chronicles some of the highlights of the author’s investigation into medical device security and the industry that surrounds these devices. His research discovered that a device used in hospitals throughout the world was incredibly easy to compromise. By Billy Rios Figure 1 - Device label for tested XPER VULNERABLE Pushing Medical Device Security Forward
  2. 2. connectivity gives practitioners the information they need to make split second decisions related to patient safety. This new found connectivity also opens up an entirely new attack surface. The Philips XPER (figure 3) is an information man- agement system,2 which connects to a variety of medical devices via protocols like HL7.3 This means anyone that com- promises the XPER system will gain direct access to other medical devices supporting critical healthcare opera- tions and services. Anyone who gains access to the XPER system will also gain access to XPER databases that con- tain patient data. The specific system we wrote our exploit for manages information related to cardiovascular procedures and labs (see figure 4). Disclosure and security engineering in the medical world With exploits in hand, I asked my colleague Terry McCorkle for some advice, “What should we do with these exploits?” Disclosure has always been a tricky proposition for security researchers. While I had worked with Philips before on vul- nerabilities affecting industrial control systems (ICS), I had never dealt with any issues affecting medical devices. After 2 http://www.healthcare.philips.com/us_en/products/cath_lab_exp/xper_info_mgt/ index.wpd. 3 http://www.healthcare.philips.com/main/products/cath_lab_exp/xper_info_mgt/ physiomonitoring5.wpd. code. My goal was to prove that I could turn this simple crash into a dangerous exploit that would give me the complete control over the entire XPER device. After several attempts, Metasploit gave me the familiar response that told me my ex- ploit had worked: [*] Meterpreter session 1 opened (192.168.1.100:4444 -> 192.168.1.101:6000) With that single line, the Philips XPER had been completely compromised. The custom-written Metasploit module made quick work of the heap overflow vulnerably discovered mere hours before. The lack of exploit mitigations like data execu- tion prevention (DEP) and address space layout randomiza- tion (ASLR) made writing this exploit more of an exercise in writing ruby as opposed to writing an advanced exploit. Total time from searching for vulnerabilities and having a complete exploit: about two hours. Equally as interesting are the three “technician” accounts on the Philips XPER. In the security industry, we refer to these accounts as “backdoors.” These are the passwords that Philips technicians use to access and up- date XPER systems, but in the wrong hands these passwords give unfettered access to the XPER on tens of thousands of hospitals worldwide. Our cracking cluster made quick work of the password hashes and gave us three clear-text passwords that will work on every single Philips XPER in the world. While I’d like to think that the exploit I wrote was special, the reality is that it was one of the easiest I’ve ever written. Finding the vulnerabilities and writing the exploit took less time than a single Lord of the Ring movie. Total code needed for a simple fuzzer and a reliable exploit module was less than 75 lines. Simple exploit mitigations like DEP and ASLR could have made this exercise much more difficult. Fundamental security engineering processes could have completely elimi- nated issues like this before the XPER ever hit the market. Deep down inside, I wished it were harder to write such a reliable set of exploits. What is an XPER? Modern hospitals are highly connected organizations.1 Clini- cal applications, clinical decision support systems, health information exchange software, and even payment entry or- der systems have revolutionized modern health care. Medi- cal devices are becoming increasingly connected, providing real-time signals and feedback to practitioners. This new 1 http://www.hhnmag.com/hhnmag/jsp/articledisplay.jsp?dcrpath=HHNMAG/ Article/data/07JUL2007/0707HHN_CoverStory_07Winners&domain=HHNMAG. Deep down inside, I wished it were harder to write such a reliable set of exploits. Figure 2 - Memory registers at the time of the XPER crash Figure 3 - The XPER front grill Figure 4 - An XPER connected to a variety of medical devices July | ISSA Journal – 13 Pushing Medical Device Security Forward | Billy Rios
  3. 3. exactly how patient safety could be affected by a medical de- vice security issue and clearly communicating these details to the public takes an experienced and tempered approach. The FDA helped me understand the issues they were deal- ing with and why it was important to be laser sharp with our communications. For example, understanding and commu- nicating exactly what impact these vulnerabilities could have on patient safety was extremely important. Medical practitio- ners all across the world receive these communications and make critical decisions about what is best for their patients given a particular situation. Equally important was the work in identifying the appropriate stakeholders at various medi- cal institutions and within the medical device vendors. These tasks sound simple, but given the complexity and the number of stakeholders, managing this effort can become unwieldy. They also explained some of the unique issues that surround medical device security that the FDA was concerned about and why it is important to present the right message to the public. Many of the patients who will encounter medical de- vices are already in a vulnerable position; spreading unneces- sary fear does not help the situation. This is one of the reasons Terry and I decided against publishing the proof of concept exploit code. The guidance from the FDA also influenced our decision not to publicly reveal specific vendors and products when we discovered over 300 backdoor passwords in various medical devices. I hope other researchers exploring medical devices security work with ICS-CERT or the FDA on their findings. I do not envy healthcare organizations that have to deal with security issues affecting medical devices and software. Net- works can be unwieldy and are notoriously difficult to secure. Dealing with devices and software that can only be updated by vendor technicians makes defending hospital networks virtually impossible.5 Medical device vendors must rethink how security patches are delivered to end users and security engineering practices, especially for critical devices that di- rectly affect patient safety. How do we move forward? Software and device security is not a new problem and the software security issues in the medical world are not special or new. This is not the first exploit against a medical device. Pioneers like Kevin Fu6 and Barnaby Jack7 have previously demonstrated numerous weaknesses in medical devices. Vi- sionaries like Michael Ahmadi8 and Dale Nordenberg9 have devoted themselves to advancing medical device security. Despite our efforts, researchers alone cannot shoulder the re- sponsibility for pushing forward medical device security. We 5 http://articles.washingtonpost.com/2013-06-13/national/39937799_1_passwords- medical-devices-cybersecurity. 6 http://secure-medicine.org/publications [2011]. 7 http://www.pepperlaw.com/publications_update.aspx?ArticleKey=2664 - see footnote 1; http://www.vice.com/read/i-worked-out-how-to-remotely-weaponise-a- pacemaker. 8 Mike Ahmadi, “Oh, Hackable You! What Science Fiction Seems To Have Missed,” ISSA Journal, December 2011. 9 http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2011-03/2_ISPAB- mdiss-DNordenberg.pdf. giving it some thought, Terry and I decided on a course of ac- tion. On January 13, 2013, I reported the vulnerabilities I had discovered to the Department of Homeland Security (DHS) Industrial Control Systems Cyber Emergency Response Team (ICS-CERT). ICS-CERT analyzed the vulnerabilities and contacted the vendor. I’ve reported a number of vulner- abilities affecting industrial control systems, but I found the disclosure and security engineering process in the medical world to be a lot different than other issues I had encountered in the past. First, unlike other industries, the medical indus- try has (somewhat) a centralized authority that has influence over all the major device manufacturers. The Food and Drug Administration (FDA) provides approvals and clearances for various medical devices and communicates various alerts, notices, and recalls. The FDA was heavily involved in this particular issue (as well as other medical device issues we have reported). Ultimately, organizations like the FDA will set the strategic direction for medical device security for the long term, set the foundation for medical device security, and be instrumen- tal in driving medical device security to a better place. I was extremely pleased to see that the FDA was very engaged in learning more about this particular vulnerability, even more so when ICS-CERT declared themselves the lead cyber emer- gency response team for medical devices.4 Looking back at the work Terry and I had done with ICS-CERT and the FDA, we felt we had helped define how our government deals with security issues in medical devices. Roles and responsibilities were better defined and processes were updated to keep up with the modern landscape. One of the most surprising aspects of this experience was learning about the security engineering processes for patch- ing medical device vulnerabilities. When we asked for time lines associated with releasing a patch for the vulnerabilities we reported, the vendor could not provide an answer. Unlike other software, many patches for medical devices can only be installed by an approved technician. This means a Philips technician must travel to each organization that has a Philips XPER device and update the device manually. This approach does not scale. It will be many months (possibly years) be- fore these issues are completely addressed in the field. With such practices, healthcare organizations must implement compensating controls to protect these devices. Information related to this process is captured in Philips Field Change Or- der (FCO) 83000171. The FCO details the fixes developed by Philips, but also details the plan Philips developed to deploy fixes to XPER systems across the world. Working with the FDA on this issue and other issues affect- ing medical devices taught me a lot about the medical in- dustry. Obviously, there are enormous technical problems that need to be overcome, but there are also delicate political and communication issues that have to be considered when dealing with medical device security issues. Understanding 4 http://ics-cert.us-cert.gov/sites/default/files/ICS-CERT_Monthly_Monitor_Oct- Dec2012_2.pdf. 14 – ISSA Journal | July 2013 Pushing Medical Device Security Forward | Billy Rios
  4. 4. BLACK HAT | BRIEFINGS | JULY 31-AUG 1, 2013 | 09:00-18:00 BLACK HAT | TRAININGS | JULY 27-30, 2013 | 09:00-18:00 WWW.BLACKHAT.COM USA 2013 Black Hat USA 2013 - The premiere conference on information security - returns to Caesars Palace on July 27 - August 1, 2013. This year’s event will feature more than 50 hands on training courses over the first four days, followed by two days of Briefings comprised of over 9 tracks and two full days of Arsenal. Register with the code lxGuIV98 to save $200 off Briefings!
  5. 5. software, and even signed games. Do not let the medical de- vice vendors convince you that such requirements are too expensive or too complicated to implement. This require- ment could be implemented at minimal costs for new devic- es, will be completely transparent to the practitioner/patient, and is easily verifiable by regulatory bodies like the FDA. We are by no means stating that requiring signed firmware will solve all medical device security issues. Even with signed firmware, vendors will still have to implement robust security mechanisms for authentication, authorization, and account- ability. However, given the current state of medical device security, we believe firmware signing for all medical devices created in 2014 and beyond is a necessary first step. About the Author Billy Rios is a Technical Director and the Di- rector of Consulting at Cylance. Billy studies emerging threats with a focus on embedded devices, industrial control systems, and criti- cal infrastructure. Before Cylance, Billy led the front line response for externally reported security issues and incidents at Google. Prior to Google, Billy was the Security Program Manager at Internet Explorer (Microsoft). Before Microsoft, Billy worked as a pen- etration tester, an intrusion detection analyst, and served as an active duty Marine Corps Officer. Billy currently holds an MBA and a Master of Science in Infor- mation Systems. He was a contributing author for several pub- lications including: Hacking, the Next Generation (O’Reilly), Inside Cyber Warfare (O’Reilly), and The Virtual Battle Field (IOS Press). Billy has also presented at such prestigious security conferences as Black Hat, RSA, NATO CCDCOE, Microsoft’s Blue Hat, DEFCON, ToorCon Seattle, and HITB Security con- ference. He may be reached at brios@cylance.com. could release security bugs in medical devices every day for the next five years, but such moves would be tactical. A more strategic approach is needed, one that requires both technical and political expertise to push forward a new set of standards and requirements for medical device security. One of the most fundamental security controls for hard- ware devices is firmware signing. Firmware is essentially the “brain” of the medical device. Firmware attacks allow for an attacker to reprogram a device, giving complete control over it. For example, if the firmware for an X-ray machine has been tampered, it could administer unusually high doses of radiation while at the same time reporting normal settings to the practitioner. Once a firmware has been compromised, it is nearly impos- sible for a practitioner to detect that the device has been modified. There is no antivirus software that can tell you whether a device’s firmware has been infected. In most cases, determin- ing whether firmware has been modified will require disas- sembly of the device. Many of the backdoor passwords we’ve discovered allow for the tampering of firmware. This is why firmware signing must be required for all medical devices. If done correctly, firmware signing provides assurance that the firmware has not been modified by an attacker. Even with a backdoor password for the device, an attacker would not be able to infect the firmware. Firmware signing sounds complicated, you might think. This problem has already been solved in numerous industries. Every iPhone requires signed firmware. Every iPad requires signed firmware. Every Xbox, PlayStation 3, and even the $199 Nintendo Wii requires signed firmware, signed system Many of the backdoor passwords we’ve discovered allow for the tampering 16 – ISSA Journal | July 2013 Pushing Medical Device Security Forward | Billy Rios

×