Rios (2013) medical device vulns

ISSA DEVELOPING AND CONNECTING CYBERSECURITY LEADERS GLOBALLY

Pushing Medical Device

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.

AbstractMedical devices are designed to support human life. When you look at a medical device, do you think of how a security issue could a!ect 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? "ese are the questions that a colleague and I asked ourselves when we purchased our #rst medical device for security re-search. "is article chronicles some of the highlights of our investigation into medical device security and the industry that surrounds these devices.

On December 30, 2012, a large package was delivered to my personal residence. I quickly signed for it and carried the package to my home o$ce. I hast-

ily opened the box and took one second to admire the device (see #gure 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. A%er mounting the drive image, I was surprised to #nd 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 le% on the device; luckily, I did not #nd any. Once I had convinced myself that the device had no patient data, I began to look for a potential attack surface. "e 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 over&ow (see #gure 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

VULNERABLEPushing Medical Device Security Forward

connectivity gives practitioners the information they need to make split second decisions related to patient safety. "is new found connectivity also opens up an entirely new attack surface. "e Philips XPER (#gure 3) is an information man-agement system,2 which connects to a variety of medical devices via protocols like HL7.3 "is 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. "e speci#c system we wrote our exploit for manages information related to cardiovascular procedures and labs (see #gure 4).

Disclosure and security engineering in the medical worldWith 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 a!ecting industrial control systems (ICS), I had never dealt with any issues a!ecting medical devices. A%er

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. A%er 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. "e custom-written Metasploit module made quick work of the heap over&ow vulnerably discovered mere hours before. "e 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.” "ese 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 di$cult. 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 so%ware, 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. "is 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

exactly how patient safety could be a!ected by a medical de-vice security issue and clearly communicating these details to the public takes an experienced and tempered approach. "e 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. "ese tasks sound simple, but given the complexity and the number of stakeholders, managing this e!ort can become unwieldy. "ey 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. "is is one of the reasons Terry and I decided against publishing the proof of concept exploit code. "e guidance from the FDA also in&uenced our decision not to publicly reveal speci#c 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 #ndings.I do not envy healthcare organizations that have to deal with security issues a!ecting medical devices and so%ware. Net-works can be unwieldy and are notoriously di$cult to secure. Dealing with devices and so%ware 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 a!ect patient safety.

How do we move forward?So%ware and device security is not a new problem and the so%ware security issues in the medical world are not special or new. "is is not the #rst 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 e!orts, 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 a!ecting industrial control systems, but I found the disclosure and security engineering process in the medical world to be a lot di!erent than other issues I had encountered in the past. First, unlike other industries, the medical indus-try has (somewhat) a centralized authority that has in&uence over all the major device manufacturers. "e Food and Drug Administration (FDA) provides approvals and clearances for various medical devices and communicates various alerts, notices, and recalls. "e 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 de#ne how our government deals with security issues in medical devices. Roles and responsibilities were better de#ned 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 so%ware, many patches for medical devices can only be installed by an approved technician. "is means a Philips technician must travel to each organization that has a Philips XPER device and update the device manually. "is approach does not scale. It will be many months (possibly years) be-fore these issues are completely addressed in the #eld. 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. "e FCO details the #xes developed by Philips, but also details the plan Philips developed to deploy #xes to XPER systems across the world.Working with the FDA on this issue and other issues a!ect-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/#les/ICS-CERT_Monthly_Monitor_Oct-Dec2012_2.pdf.

v

14 – ISSA Journal | July 2013

Pushing Medical Device Security Forward | Billy Rios

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 2013Black 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!

so%ware, 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. "is require-ment could be implemented at minimal costs for new devic-es, will be completely transparent to the practitioner/patient, and is easily veri#able by regulatory bodies like the FDA.We are by no means stating that requiring signed #rmware will solve all medical device security issues. Even with signed #rmware, 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 #rmware signing for all medical devices created in 2014 and beyond is a necessary #rst step.

About the AuthorBilly 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 (Microso!). Before Microso!, Billy worked as a pen-etration tester, an intrusion detection analyst, and served as an active duty Marine Corps O"cer.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 "e Virtual Battle Field (IOS Press). Billy has also presented at such prestigious security conferences as Black Hat, RSA, NATO CCDCOE, Microso!’s Blue Hat, DEFCON, ToorCon Seattle, and HITB Security con-ference. He may be reached at [email protected].

could release security bugs in medical devices every day for the next #ve 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 #rmware 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 #rmware 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 #rmware has been compromised, it is nearly impos-sible for a practitioner to detect that the device has been modi#ed. "ere is no antivirus so%ware that can tell you whether a device’s #rmware has been infected. In most cases, determin-

ing whether #rmware has been modi#ed will require disas-sembly of the device. Many of the backdoor passwords we’ve discovered allow for the tampering of #rmware. "is is why #rmware signing must be required for all medical devices. If done correctly, #rmware signing provides assurance that the #rmware has not been modi#ed by an attacker. Even with a backdoor password for the device, an attacker would not be able to infect the #rmware.Firmware signing sounds complicated, you might think. "is problem has already been solved in numerous industries. Every iPhone requires signed #rmware. Every iPad requires signed #rmware. Every Xbox, PlayStation 3, and even the $199 Nintendo Wii requires signed #rmware, 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