the harsh reality of slow movers
TRANSCRIPT
☤TM
Not So Fast!
The Harsh Reality of Slow Movers
Ben Ransford, Ph.D. Virta Laboratories, Inc. [email protected]
@secthings 2015
Not So Fast! @secthings 2015 © [email protected] TM
–George Santayana, The Life of Reason vol. 1
“Those who cannot remember the past are condemned to repeat it.”
2
Not So Fast! @secthings 2015 © [email protected] TM
Outline
• Medical-device security: a cautionary tale
• Lessons for IoT
• Outside-the-box anomaly/malware detection
3
Not So Fast! @secthings 2015 © [email protected] TM
Amazing devices!
4
1957
Photos: Medtronic, Computer History Museum
Not So Fast! @secthings 2015 © [email protected] TM
Amazing devices!
5
Therac-25 (ca. 1980s)
Photo: SIUE
Not So Fast! @secthings 2015 © [email protected] TM
Amazing devices!
6
II. AUTOMATED EXTERNAL DEFIBRILLATOR (AED)OVERVIEW
In this section, we introduce automated external defibrillatorsand discuss why they represent a quintessential software-basedmedical device to investigate security. The term defibrillatorrefers to a broad class of devices that use large electricalshocks to treat cardiac arrhythmias that might otherwise leadto a fatal outcome. Defibrillators are divided into two types:implantable or external. While both types of defibrillators treatcardiac arrhythmias, the devices are radically different in designand purpose. One could draw the following analogy: implanteddefibrillators are to mobile phones as external defibrillators areto public phone call boxes. The former are prescribed and tunedto a particular person whereas the latter are available for generaluse when you can find one. There are two further classificationsof external defibrillators: manual or automated. Trained healthcare professionals may use manual external defibrillators totreat a wide range of arrhythmias. Our work analyzes thesecond class: automated external defibrillators (AEDs) that aperson with limited medical training may use to treat a morelimited (but common) number of cardiac arrhythmias such asventricular fibrillation.
AEDs are significantly different from implantable cardiac de-fibrillators, both physically in terms of their hardware, softwareand connectivity, and in terms of risk. An AED is typicallyattached to the chest of the individual using two pads, and itdelivers an electric shock to reestablish a normal heart rhythm.The conditions that can be treated through defibrillation, forexample cardiac arrhythmias of ventricular fibrillation and ven-tricular tachycardia, generally require prompt attention in orderto prevent severe brain damage or death. Studies have shownthat the chances of survival improve if an individual receivesdefibrillation within 3-5 minutes of collapse [1]. For this reason,AEDs are widely available in airports, community centers,schools, government buildings, and other public locations. Asof 2009, an estimated 1.5 million AEDs are in circulationworldwide [13], and industry expects an annual growth in salesof 9-12% [11], [8]. In 2005, over 192,400 AED units were soldin the U.S. marketplace; this represents approximately a ten-fold increase in AED sales from 1996–2005 [18].
The FDA has received more than 28,000 adverse eventreports for external defibrillators between January 2005 andMay 2010, including malfunctions, patient injuries, and deaths.As a result, the FDA has issued 68 recalls, 17 alone in 2009.In 2010, the FDA reported that 280,000 external defibrillatorsacross 14 different models were susceptible to malfunction [9].16.2% of AED advisories were confirmed as resulting fromsoftware-related issues, with 6 advisories affecting 12,311 in-dividual devices [18]. Only one category had a higher incidence(electrical issues at 21.6% of the causes of a recall) [18].Given the importance of these devices in saving lives, the FDAbegan an initiative to promote the development of safer externaldefibrillators in 2010 [2].
In this paper, we study one particular model of AED, theCardiac Science G3 Plus with model number 9390A-501. Wedecided to examine an Automated External Defibrillator (AED)because of its reliance on software updates to address an FDArecall. Depending on how the device is configured, the shock
Fig. 1. The Cardiac Science G3 Plus exploited to install our customfirmware. The AED displays DEVICE COMPROMISED.
administered can be 150-300 Joules, which can be administeredmultiple times on one battery before the device requires arecharge. The G3 Plus is pictured in Figure 1.
III. CASE STUDY
In this section, we analyze the Cardiac Science G3 PlusAutomated External Defibrillator. In order to analyze the de-vice, we used IDA Pro 5.6—an inexpensive, commerciallyavailable software package—to statically reverse engineer thedevice’s update and diagnostic software, communication pro-tocol, and firmware [3]. Our analysis was conducted usingCOTS hardware and software, and took upwards of 100 hours.During our analysis, we discovered that 4 vulnerabilities werereadily prevalent from reversing the device and its software.We verify our analysis and show the gravity of softwareexploits on medical devices by executing concrete attacks anddemonstrating their potential impact. Both the FDA and themanufacturer of the studied device were notified of our findings.One thing to note is that we explicitly chose not to provide adetailed set of steps for reproducing the attack; instead, weprovide the minimal evidence for a security expert to verifyour results.
A. Analyzing the G3 PlusPerforming a security analysis of the G3 Plus necessitated
reverse engineering device operation and controlling softwarebecause it is a closed-platform device, with proprietary hard-ware, firmware and software.
We discovered that the AED’s CPU implements a 16-bit x86ISA by examining the internals of the AED with CPU processormanuals. From this, we applied static reverse engineeringtechniques to the firmware.
The device comes with three software packages: MDLink,RescueLink and AEDUpdate, responsible for programmingdevice parameters (like shock value), collecting post-cardiacarrest reports, and updating the AED, respectively. We focusour analysis on the device firmware (252 KB), AEDUpdate(8 MB), and MDLink (680 KB) because of their potential
2
External Defibrillator (1985–)
Photo: Steve Hanna et al., “Take Two Software Updates and See Me in the Morning…”, USENIX HealthTech 2011
Not So Fast! @secthings 2015 © [email protected] TM
Amazing devices!
7
Patient monitor
Infusion pump
Photos: Philips, Hospira, The Register/Medtronic
Insulin pump
Not So Fast! @secthings 2015 © [email protected] TM
Amazing devices!
8
2003pacemaker
2013pacemaker prototype
Photos: Ben Ransford; Medtronic
Not So Fast! @secthings 2015 © [email protected] TM
What Could Go Wrong?• Increasing software dependence
• Increasing software complexity
• Deeper integration with medical records, hospital IT, patients’ homes & bodies
• 1980s: 6% of recalls due to software*
• 2005–9: 18% of recalls due to software*
9
* Hanna et al., HealthTech 2011
Not So Fast! @secthings 2015 © [email protected] TM
Amazing harmful devices!
10
Therac-25 (ca. 1980s, recalled 1987)
Photo: SIUE
Not So Fast! @secthings 2015 © [email protected] TM
Amazing open devices!
11
II. AUTOMATED EXTERNAL DEFIBRILLATOR (AED)OVERVIEW
In this section, we introduce automated external defibrillatorsand discuss why they represent a quintessential software-basedmedical device to investigate security. The term defibrillatorrefers to a broad class of devices that use large electricalshocks to treat cardiac arrhythmias that might otherwise leadto a fatal outcome. Defibrillators are divided into two types:implantable or external. While both types of defibrillators treatcardiac arrhythmias, the devices are radically different in designand purpose. One could draw the following analogy: implanteddefibrillators are to mobile phones as external defibrillators areto public phone call boxes. The former are prescribed and tunedto a particular person whereas the latter are available for generaluse when you can find one. There are two further classificationsof external defibrillators: manual or automated. Trained healthcare professionals may use manual external defibrillators totreat a wide range of arrhythmias. Our work analyzes thesecond class: automated external defibrillators (AEDs) that aperson with limited medical training may use to treat a morelimited (but common) number of cardiac arrhythmias such asventricular fibrillation.
AEDs are significantly different from implantable cardiac de-fibrillators, both physically in terms of their hardware, softwareand connectivity, and in terms of risk. An AED is typicallyattached to the chest of the individual using two pads, and itdelivers an electric shock to reestablish a normal heart rhythm.The conditions that can be treated through defibrillation, forexample cardiac arrhythmias of ventricular fibrillation and ven-tricular tachycardia, generally require prompt attention in orderto prevent severe brain damage or death. Studies have shownthat the chances of survival improve if an individual receivesdefibrillation within 3-5 minutes of collapse [1]. For this reason,AEDs are widely available in airports, community centers,schools, government buildings, and other public locations. Asof 2009, an estimated 1.5 million AEDs are in circulationworldwide [13], and industry expects an annual growth in salesof 9-12% [11], [8]. In 2005, over 192,400 AED units were soldin the U.S. marketplace; this represents approximately a ten-fold increase in AED sales from 1996–2005 [18].
The FDA has received more than 28,000 adverse eventreports for external defibrillators between January 2005 andMay 2010, including malfunctions, patient injuries, and deaths.As a result, the FDA has issued 68 recalls, 17 alone in 2009.In 2010, the FDA reported that 280,000 external defibrillatorsacross 14 different models were susceptible to malfunction [9].16.2% of AED advisories were confirmed as resulting fromsoftware-related issues, with 6 advisories affecting 12,311 in-dividual devices [18]. Only one category had a higher incidence(electrical issues at 21.6% of the causes of a recall) [18].Given the importance of these devices in saving lives, the FDAbegan an initiative to promote the development of safer externaldefibrillators in 2010 [2].
In this paper, we study one particular model of AED, theCardiac Science G3 Plus with model number 9390A-501. Wedecided to examine an Automated External Defibrillator (AED)because of its reliance on software updates to address an FDArecall. Depending on how the device is configured, the shock
Fig. 1. The Cardiac Science G3 Plus exploited to install our customfirmware. The AED displays DEVICE COMPROMISED.
administered can be 150-300 Joules, which can be administeredmultiple times on one battery before the device requires arecharge. The G3 Plus is pictured in Figure 1.
III. CASE STUDY
In this section, we analyze the Cardiac Science G3 PlusAutomated External Defibrillator. In order to analyze the de-vice, we used IDA Pro 5.6—an inexpensive, commerciallyavailable software package—to statically reverse engineer thedevice’s update and diagnostic software, communication pro-tocol, and firmware [3]. Our analysis was conducted usingCOTS hardware and software, and took upwards of 100 hours.During our analysis, we discovered that 4 vulnerabilities werereadily prevalent from reversing the device and its software.We verify our analysis and show the gravity of softwareexploits on medical devices by executing concrete attacks anddemonstrating their potential impact. Both the FDA and themanufacturer of the studied device were notified of our findings.One thing to note is that we explicitly chose not to provide adetailed set of steps for reproducing the attack; instead, weprovide the minimal evidence for a security expert to verifyour results.
A. Analyzing the G3 PlusPerforming a security analysis of the G3 Plus necessitated
reverse engineering device operation and controlling softwarebecause it is a closed-platform device, with proprietary hard-ware, firmware and software.
We discovered that the AED’s CPU implements a 16-bit x86ISA by examining the internals of the AED with CPU processormanuals. From this, we applied static reverse engineeringtechniques to the firmware.
The device comes with three software packages: MDLink,RescueLink and AEDUpdate, responsible for programmingdevice parameters (like shock value), collecting post-cardiacarrest reports, and updating the AED, respectively. We focusour analysis on the device firmware (252 KB), AEDUpdate(8 MB), and MDLink (680 KB) because of their potential
2
External Defibrillator (1985–)
Photos: Hanna et al., “Take Two Software Updates and See Me in the Morning…”, USENIX HealthTech 2011
II. AUTOMATED EXTERNAL DEFIBRILLATOR (AED)OVERVIEW
In this section, we introduce automated external defibrillatorsand discuss why they represent a quintessential software-basedmedical device to investigate security. The term defibrillatorrefers to a broad class of devices that use large electricalshocks to treat cardiac arrhythmias that might otherwise leadto a fatal outcome. Defibrillators are divided into two types:implantable or external. While both types of defibrillators treatcardiac arrhythmias, the devices are radically different in designand purpose. One could draw the following analogy: implanteddefibrillators are to mobile phones as external defibrillators areto public phone call boxes. The former are prescribed and tunedto a particular person whereas the latter are available for generaluse when you can find one. There are two further classificationsof external defibrillators: manual or automated. Trained healthcare professionals may use manual external defibrillators totreat a wide range of arrhythmias. Our work analyzes thesecond class: automated external defibrillators (AEDs) that aperson with limited medical training may use to treat a morelimited (but common) number of cardiac arrhythmias such asventricular fibrillation.
AEDs are significantly different from implantable cardiac de-fibrillators, both physically in terms of their hardware, softwareand connectivity, and in terms of risk. An AED is typicallyattached to the chest of the individual using two pads, and itdelivers an electric shock to reestablish a normal heart rhythm.The conditions that can be treated through defibrillation, forexample cardiac arrhythmias of ventricular fibrillation and ven-tricular tachycardia, generally require prompt attention in orderto prevent severe brain damage or death. Studies have shownthat the chances of survival improve if an individual receivesdefibrillation within 3-5 minutes of collapse [1]. For this reason,AEDs are widely available in airports, community centers,schools, government buildings, and other public locations. Asof 2009, an estimated 1.5 million AEDs are in circulationworldwide [13], and industry expects an annual growth in salesof 9-12% [11], [8]. In 2005, over 192,400 AED units were soldin the U.S. marketplace; this represents approximately a ten-fold increase in AED sales from 1996–2005 [18].
The FDA has received more than 28,000 adverse eventreports for external defibrillators between January 2005 andMay 2010, including malfunctions, patient injuries, and deaths.As a result, the FDA has issued 68 recalls, 17 alone in 2009.In 2010, the FDA reported that 280,000 external defibrillatorsacross 14 different models were susceptible to malfunction [9].16.2% of AED advisories were confirmed as resulting fromsoftware-related issues, with 6 advisories affecting 12,311 in-dividual devices [18]. Only one category had a higher incidence(electrical issues at 21.6% of the causes of a recall) [18].Given the importance of these devices in saving lives, the FDAbegan an initiative to promote the development of safer externaldefibrillators in 2010 [2].
In this paper, we study one particular model of AED, theCardiac Science G3 Plus with model number 9390A-501. Wedecided to examine an Automated External Defibrillator (AED)because of its reliance on software updates to address an FDArecall. Depending on how the device is configured, the shock
Fig. 1. The Cardiac Science G3 Plus exploited to install our customfirmware. The AED displays DEVICE COMPROMISED.
administered can be 150-300 Joules, which can be administeredmultiple times on one battery before the device requires arecharge. The G3 Plus is pictured in Figure 1.
III. CASE STUDY
In this section, we analyze the Cardiac Science G3 PlusAutomated External Defibrillator. In order to analyze the de-vice, we used IDA Pro 5.6—an inexpensive, commerciallyavailable software package—to statically reverse engineer thedevice’s update and diagnostic software, communication pro-tocol, and firmware [3]. Our analysis was conducted usingCOTS hardware and software, and took upwards of 100 hours.During our analysis, we discovered that 4 vulnerabilities werereadily prevalent from reversing the device and its software.We verify our analysis and show the gravity of softwareexploits on medical devices by executing concrete attacks anddemonstrating their potential impact. Both the FDA and themanufacturer of the studied device were notified of our findings.One thing to note is that we explicitly chose not to provide adetailed set of steps for reproducing the attack; instead, weprovide the minimal evidence for a security expert to verifyour results.
A. Analyzing the G3 PlusPerforming a security analysis of the G3 Plus necessitated
reverse engineering device operation and controlling softwarebecause it is a closed-platform device, with proprietary hard-ware, firmware and software.
We discovered that the AED’s CPU implements a 16-bit x86ISA by examining the internals of the AED with CPU processormanuals. From this, we applied static reverse engineeringtechniques to the firmware.
The device comes with three software packages: MDLink,RescueLink and AEDUpdate, responsible for programmingdevice parameters (like shock value), collecting post-cardiacarrest reports, and updating the AED, respectively. We focusour analysis on the device firmware (252 KB), AEDUpdate(8 MB), and MDLink (680 KB) because of their potential
2
impact on correct device operation; they are responsible forcommunicating with the host computer, updating firmware,and programming device parameters.
B. Vulnerabilities in the Cardiac Science G3 AEDBelow we detail the key findings of our investigation into
the security of the AED and its software. First, we discussthe bugs and vulnerabilities we found in the MDLink andAEDUpdate software. Following that, we discuss how we canarbitrarily change the G3 Plus’s firmware.
Vulnerability 1: AEDUpdate integer/buffer overflow. Initially,AEDUpdate sends a packet over the COM port to the AED andthen receives a response. In order to verify the vulnerability,we spoofed packets coming from the COM port such that wewere able to control the data that AEDUpdate received fromthe device; we thereby triggered the vulnerability and achievedarbitrary code execution.
The AEDUpdate program counts the number of ‘0’-characters in the response and then performs a memcpy basedon the number of zeros found. Specifically, the program expectsto find no more than 8 zeros, so it uses the expression8-num_zeros to calculate the size of the buffer to copy.However, if there are more than 8 zeros, the size parameterunderflows and results in attempting to copy around 4.3 billionbytes of data into a 16-byte buffer, causing the program to throwan exception. In order to exploit this vulnerability, we need tooverwrite the most recently registered exception handler withour own and cause this exception to occur before the corruptedreturn address is checked, which allows us to redirect programflow into arbitrary code.
Fig. 2. AEDUpdate buffer overflow. Executed code includes a message boxshowing the potential flow of the vulnerability from the AED (if the firmwarewere replaced) to the software.
In Windows XP SP2, nearly every module linked into abinary uses Safe Structured Exception Handling (SSEH). Thismeans that the exception handler must be registered with theoperating system, and if during execution it is discovered thatit is not registered, the process is terminated by the OS [4].oledlg.dll was the only DLL imported into the binarythat did not employ SSEH. Using this, we overwrote theexception handler on the stack with a subverted one, forcing
the program to execute our payload when an exception wasthrown3. Figure 2 shows AEDUpdate being exploited.
Automatic Vulnerability Discovery. Although the AEDUpdateinteger/buffer overflow vulnerability was initially found throughmanual analysis, we later verified that, given appropriateprogram entry points obtained through reverse engineering,it could also be automatically found within minutes usingour vulnerability discovery tool called BitFuzz [7], [19], [6].BitFuzz applies dynamic symbolic execution [7], [14] togenerate test inputs that explore different paths in the program,including paths that contain a crash. When a crash is found,the tool provides a crash report that consists of a crashingexecution trace and a crashing input. We run BitFuzz inLinux on a 3.0Ghz Dual Core Intel CPU with 4GB of RAM.After running for 16 minutes and 18 seconds, it successfullygenerates a crash report that confirms the existence of theinteger/buffer overflow vulnerability in AEDUpdate.
Vulnerability 2: Weak password authentication scheme. TheMDLink software has individual user profiles protected by apassword. However, the password file is stored on the localhard drive, and anyone with privileges can simply delete it inorder to circumvent the protection mechanisms or circumventit completely by installing the software fresh on a machinethat does not have access restrictions. Furthermore, after wereverse engineered the MDLink authentication mechanism, wediscovered that the password was obfuscated using a simpleXOR scheme. From there, we extracted the scheme and wrotea small utility to arbitrarily change or recover a user’s password.
Vulnerability 3: Credentials stored in plaintext. Whileexamining AEDUpdate, we came across functionality thatseemed to upload a file to a remote FTP server. Upon furtherinvestigation, we found that the AEDUpdate stores the addressof the FTP server, username, and password in plain textwithin the update software. When warranted, due either toa failed upgrade or to some other diagnostic problem, thediagnostic file is sent to Cardiac Science. This private userinformation is collected when a firmware upgrade is started byAEDUpdate and includes contact information, serial number,and the firmware version—all potentially available to anyonewho accesses the login credentials.
Vulnerability 4: Improper use of weak CRC as digital sig-nature. We discovered that the software begins the updateprocess by sending a cyclic redundancy check (CRC) value ofthe new firmware. Once transferred, the device calculates theCRC of the received firmware and allows the current firmwareto be replaced only if the values match. In order to installcustom firmware, we populated its CRC verification table withnew values calculated over the entirety of our custom image.To obtain the precise integrity check employed by the AED,we extracted the code responsible for CRC calculation andverification from AEDUpdate, which we used to generate anew CRC to convince the AED that our image was legitimate.
This vulnerability allows malicious modifications that couldlead to device failure, patient harm, and financial burden. Theseattacks include: (1) disabling or falsifying integrity checking so
3For instance, by corrupting a pointer on the stack.
3
Not So Fast! @secthings 2015 © [email protected] TM
2008: 😺⇠👜
• Academic study of an implantable defibrillator (IEEE S&P ‘08)
• Focused security community on medical devices… oopsie!
12Photos: Medtronic, Ben Ransford
Not So Fast! @secthings 2015 © [email protected] TM13
• No authentication
• No encryption
• Unauthorized shocksPhotos: Ben Ransford
Not So Fast! @secthings 2015 © [email protected] TM
2009–2011
• Insulin pump & defibrillator hacks (Barnaby Jack, J. Radcliffe, others)
• No authentication
• Unauthorized bolus
14Photo: The Register/Medtronic
Not So Fast! @secthings 2015 © [email protected] TM
Wall Street Journal, June 2013, on a catheterization lab shut down by malware
“...records show that malware had infected computer equipment needed for procedures to
open blocked arteries after heart attacks.”
15
2013
Not So Fast! @secthings 2015 © [email protected] TM
2013
• Pharmaceutical compounder (HealthTech ’13)
• Must be on network, patching forbidden
16Photo: Ben Ransford
Not So Fast! @secthings 2015 © [email protected] TM17Photo: Ohemaa's MD
Major hospitals say: 3–5 years: >90% of medical devices will be on the network
Not So Fast! @secthings 2015 © [email protected] TM
Don’t Patch the OS
• Microsoft has figured out Windows security by now
• The Linux kernel is perfect, always works
• “Alternative” OSes won’t be targeted
20
Not So Fast! @secthings 2015 © [email protected] TM
Don’t Patch Libraries
• You wrote all of the device’s code & libraries
• No need to update OpenSSL, PHP, Apache, etc.
21
Not So Fast! @secthings 2015 © [email protected] TM
Use Default Secrets
• Use default passwords whenever possible
• Make passwords difficult to change
• Ship master keys w/ devices
• Hard-code credentials
22
Not So Fast! @secthings 2015 © [email protected] TM
Be Very Liberal in What You Accept
• Download software via insecure channels
• Don’t cryptographically sign software
• It’s probably fine
• Who would tamper with firmware?
• Anyway tampering is illegal
23
II. AUTOMATED EXTERNAL DEFIBRILLATOR (AED)OVERVIEW
In this section, we introduce automated external defibrillatorsand discuss why they represent a quintessential software-basedmedical device to investigate security. The term defibrillatorrefers to a broad class of devices that use large electricalshocks to treat cardiac arrhythmias that might otherwise leadto a fatal outcome. Defibrillators are divided into two types:implantable or external. While both types of defibrillators treatcardiac arrhythmias, the devices are radically different in designand purpose. One could draw the following analogy: implanteddefibrillators are to mobile phones as external defibrillators areto public phone call boxes. The former are prescribed and tunedto a particular person whereas the latter are available for generaluse when you can find one. There are two further classificationsof external defibrillators: manual or automated. Trained healthcare professionals may use manual external defibrillators totreat a wide range of arrhythmias. Our work analyzes thesecond class: automated external defibrillators (AEDs) that aperson with limited medical training may use to treat a morelimited (but common) number of cardiac arrhythmias such asventricular fibrillation.
AEDs are significantly different from implantable cardiac de-fibrillators, both physically in terms of their hardware, softwareand connectivity, and in terms of risk. An AED is typicallyattached to the chest of the individual using two pads, and itdelivers an electric shock to reestablish a normal heart rhythm.The conditions that can be treated through defibrillation, forexample cardiac arrhythmias of ventricular fibrillation and ven-tricular tachycardia, generally require prompt attention in orderto prevent severe brain damage or death. Studies have shownthat the chances of survival improve if an individual receivesdefibrillation within 3-5 minutes of collapse [1]. For this reason,AEDs are widely available in airports, community centers,schools, government buildings, and other public locations. Asof 2009, an estimated 1.5 million AEDs are in circulationworldwide [13], and industry expects an annual growth in salesof 9-12% [11], [8]. In 2005, over 192,400 AED units were soldin the U.S. marketplace; this represents approximately a ten-fold increase in AED sales from 1996–2005 [18].
The FDA has received more than 28,000 adverse eventreports for external defibrillators between January 2005 andMay 2010, including malfunctions, patient injuries, and deaths.As a result, the FDA has issued 68 recalls, 17 alone in 2009.In 2010, the FDA reported that 280,000 external defibrillatorsacross 14 different models were susceptible to malfunction [9].16.2% of AED advisories were confirmed as resulting fromsoftware-related issues, with 6 advisories affecting 12,311 in-dividual devices [18]. Only one category had a higher incidence(electrical issues at 21.6% of the causes of a recall) [18].Given the importance of these devices in saving lives, the FDAbegan an initiative to promote the development of safer externaldefibrillators in 2010 [2].
In this paper, we study one particular model of AED, theCardiac Science G3 Plus with model number 9390A-501. Wedecided to examine an Automated External Defibrillator (AED)because of its reliance on software updates to address an FDArecall. Depending on how the device is configured, the shock
Fig. 1. The Cardiac Science G3 Plus exploited to install our customfirmware. The AED displays DEVICE COMPROMISED.
administered can be 150-300 Joules, which can be administeredmultiple times on one battery before the device requires arecharge. The G3 Plus is pictured in Figure 1.
III. CASE STUDY
In this section, we analyze the Cardiac Science G3 PlusAutomated External Defibrillator. In order to analyze the de-vice, we used IDA Pro 5.6—an inexpensive, commerciallyavailable software package—to statically reverse engineer thedevice’s update and diagnostic software, communication pro-tocol, and firmware [3]. Our analysis was conducted usingCOTS hardware and software, and took upwards of 100 hours.During our analysis, we discovered that 4 vulnerabilities werereadily prevalent from reversing the device and its software.We verify our analysis and show the gravity of softwareexploits on medical devices by executing concrete attacks anddemonstrating their potential impact. Both the FDA and themanufacturer of the studied device were notified of our findings.One thing to note is that we explicitly chose not to provide adetailed set of steps for reproducing the attack; instead, weprovide the minimal evidence for a security expert to verifyour results.
A. Analyzing the G3 PlusPerforming a security analysis of the G3 Plus necessitated
reverse engineering device operation and controlling softwarebecause it is a closed-platform device, with proprietary hard-ware, firmware and software.
We discovered that the AED’s CPU implements a 16-bit x86ISA by examining the internals of the AED with CPU processormanuals. From this, we applied static reverse engineeringtechniques to the firmware.
The device comes with three software packages: MDLink,RescueLink and AEDUpdate, responsible for programmingdevice parameters (like shock value), collecting post-cardiacarrest reports, and updating the AED, respectively. We focusour analysis on the device firmware (252 KB), AEDUpdate(8 MB), and MDLink (680 KB) because of their potential
2
Photo: Steve Hanna et al., “Take Two Software Updates and See Me in the Morning…”, USENIX HealthTech 2011
Not So Fast! @secthings 2015 © [email protected] TM
Obscurity == Security• Nobody will scan your
devices
• Nobody will obtain your firmware via JTAG
• Compilation is the same as encryption
• Leave a network port open for “debugging”
24Photo: Dotmed
Not So Fast! @secthings 2015 © [email protected] TM
Deep Integration → Fixity
• Once something works, don’t want to touch it
• Sometimes replacement is really hard
• Environment changes → threats change too
26
Major surgery,~10yr battery
Photo: Ben Ransford
Not So Fast! @secthings 2015 © [email protected] TM
IoT and Slow Movers• You want integration + customer dependence?
• All bets are off once a Thing is deployed
• Customers will depend on your old/stale code
• Customers will depend on your old URLs
• You think you know how customers will use your product, but you don’t
• Optimize products & processes for patchability
27
Not So Fast! @secthings 2015 © [email protected] TM
The Mess We’re In• Major healthcare breaches afoot (Anthem: 80M!)
• Attackers roost on systems that won’t get patched (TrapX “Medjack” report)
• Backward thinking about patching
• Perimeter security is not a solution
• “Endpoint security” vendors ignore medical devices (as they ignore Things)
28
Not So Fast! @secthings 2015 © [email protected] TM29
Not So Fast! @secthings 2015 © [email protected] TM
Outside the Box• Nonintrusive monitoring
• No software installation
• Devices stay in service
• Use the power side channel to infer tasks, detect unusual behavior incl. malware
30
(In beta!)
Photo: Ben Ransford/Virta Labs
Not So Fast! @secthings 2015 © [email protected] TM31Photo: Atomic Toasters
Not So Fast! @secthings 2015 © [email protected] TM32
Not So Fast! @secthings 2015 © [email protected] TM
Current Consumption Varies• Today’s CPUs and software are careful to use
power management!
• Modern systems exhibit high dynamic range
• Workloads ➞ patterns of high/low
• CPU busy ➞ more current
• Peripherals busy ➞ more current
• Idle time ➞ less current
33Image: Apple
Not So Fast! @secthings 2015 © [email protected] TM
Learning from Analog Data
• Collect data during representative activity
• Constantly collect power signals
• Featurize signals, feed features to machine learning
• Feed analysis results back to customers
• Crowdsource problems across customers
34
Not So Fast! @secthings 2015 © [email protected] TM
Q’s We Can A• What state is the device in? Have we seen this
state before?
• Does the device have certain kinds of malware?
• How fast is it doing its work?
35
Not So Fast! @secthings 2015 © [email protected] TM
Takeaways• For IoT manufacturers: Recognize security debt,
plan for long lifecycle
• For users: Insist on coherent patching strategies that have a time dimension
• For security researchers: Roll up sleevesTwitter: @virtalabs / @br_Beta program: https://www.virtalabs.com/
37