Tag: medical device security

INSIGHTS | August 20, 2013

FDA Medical Device Guidance

By Gunter Ollmann

Last week the US Food and Drug Administration (FDA) finally released a couple of important documents. The first being their guidance on using radio frequency wireless technology in medical devices (replacing a draft from January 3,2007), and a second being their new (draft) guidance on premarket submission for management of cybersecurity in medical devices.

The wireless technology guidance document seeks to address many of the risks and vulnerabilities that have been disclosed in medical devices (embedded or otherwise) in recent years – in particular those with embedded RF wireless functionality…

The recommendations in this guidance are intended for RF wireless medical devices including those that are implanted, worn on the body or other external wireless medical devices intended for use in hospitals, homes, clinics, clinical laboratories, and blood establishments.  Both wireless induction-based devices and radiated RF technology device systems are within the scope of this guidance.

The FDA wishes medical device manufacturers to consider the design, testing and use of wireless medical devices…

In the design, testing, and use of wireless medical devices, the correct, timely, and secure transmission of medical data and information is important for the safe and effective use of both wired and wireless medical devices and device systems. This is especially important for medical devices that perform critical functions such as those that are life-supporting or life-sustaining. For wirelessly enabled medical devices, risk management should include considerations for robust RF wireless design, testing, deployment, and maintenance throughout the life cycle of the product.

For most of you reading the IOActive Labs blog, the most important parts of the guidance document are the advice on security and securing “wireless signals and data”. Section 3.d covers this…

Security of RF wireless technology is a means to prevent unauthorized access to patient data or hospital networks and to ensure that information and data received by a device are intended for that device. Authentication and wireless encryption play vital roles in an effective wireless security scheme. While most wireless technologies have encryption schemes available, wireless encryption might need to be enabled and assessed for adequacy for the medical device’s intended use. In addition, the security measures should be well coordinated among the medical device components, accessories, and system, and as needed, with a host wireless network. Security management should also consider that certain wireless technologies incorporate sensing of like technologies and attempt to make automatic connections to quickly assemble and use a network (e.g., a discovery mode such as that available in Bluetooth™ communications). For certain types of wireless medical devices, this kind of discovery mode could pose safety and effectiveness concerns, for example, where automatic connections might allow unintended remote control of the medical device. 

FDA recommends that wireless medical devices utilize wireless protection (e.g., wireless encryption,6 data access controls, secrecy of the “keys” used to secure messages) at a level appropriate for the risks presented by the medical device, its environment of use, the type and probability of the risks to which it is exposed, and the probable risks to patients from a security breach. FDA recommends that the following factors be considered during your device design and development: 

* Protection against unauthorized wireless access to device data and control. This should include protocols that maintain the security of the communications while avoiding known shortcomings of existing older protocols (such as Wired Equivalent Privacy (WEP)). 

* Software protections for control of the wireless data transmission and protection against unauthorized access. 

Use of the latest up-to-date wireless encryption is encouraged. Any potential issues should be addressed either through appropriate justification of the risks based on your device’s intended use or through appropriate design verification and validation.

Based upon the parts I’ve highlighted above, you’ll probably be feeling a little foreboding. From a “guidance” perspective, it’s less useful than a teenager with a CISSP qualification. The instructions are so general as to be useless.

If I was the geek charged with waving the security batton at some medical device manufacturer I wouldn’t be happy at all. Effectively the FDA are saying “there are a number of security risks with wireless technologies, here are some things you could think about doing, hope that helps.” Even if you followed all this advice, the FDA could turn around later during your submission for certification and say you did it wrong…

The second document the FDA released last week (Content of Premarket Submissions for Management of Cybersecurity in Medical Devices – Draft Guidance for Industry and Food and Drug Administration Staff) is a little more helpful – at the very least they’re talking about “cybersecurity” and there’s a little more meat for your CISSP folks to chew upon (in fact parts of it read like they’ve been copy-pasted right out of a CISSP training manual).

This guidance has been developed by the FDA to assist industry by identifying issues related to cybersecurity that manufacturers should consider in preparing premarket submissions for medical devices. The need for effective cybersecurity to assure medical device functionality has become more important with the increasing use of wireless, Internet- and network-connected devices, and the frequent electronic exchange of medical device-related health information.

Again, it doesn’t go in to any real detail of what device manufacturers should or shouldn’t be doing, but it does set the scene for understanding the scope of part of the threat.

If I was an executive at one of the medical device manufacturers confronted with these FDA Guidance documents for the first time, I wouldn’t feel particularly comforted by them – in fact I’d be more worried about the increased exposure I would have in the future. If a future product of mine was to get hacked, regardless of how close I thought I was following the FDA guidance, I’d be pretty sure that the FDA could turn around and say that I wasn’t really in compliance.

With that in mind, let me slip on my IOActive CTO hat and clearly state that I’d recommend any medical device manufacturer that doesn’t want to get bitten in the future for failing to follow this FDA “guidance” reach out to a qualified security consulting company to get advice on (and to assess) the security of current and future product lines prior to release.

Engaging with a bunch of third-party experts isn’t just a CYA proposition for your company. Bringing to bear an external (impartial) security authority would obviously add extra weight to the approval process; proving the companies technical diligence, and working “above and beyond” the security checkbox of the FDA guidelines. Just as importantly though, securing wireless technologies against today’s and tomorrow’s threats isn’t something that can be done by an internal team (or a flock of CISSP’s) – you really do need to call in the experts with a hackers-eye for security… Ideally a company with a pedigree in cutting-edge security research, and I know just who to call…

INSIGHTS | July 25, 2013

Las Vegas 2013

By IOActive
Again, that time of the year is approaching; thousands of people from the security community are preparing to head to Las Vegas for the most important hacking events: Black Hat USA and DefCon. IOActive will (as we do every year) have an important presence at these conferences.

We have some great researchers from our team presenting at Black Hat USA and DefCon. At Black Hat USA, Barnaby Jack will be presenting “Implantable medical devices: hacking humans”, and Lucas Apa and Carlos Mario Panagos will be presenting “Compromising industrial facilities from 40 miles away”. At DefCon, Chris Valasek will be presenting “Adventures in automotive networks and control units”.
These will be probably the most commented on talks, so don’t miss them!
During Black Hat USA, IOActive will also be hosting IOAsis. This event gives you an opportunity to meet our researchers, listen to some interesting presentations, participate in a hacking hardware workshop, and more—all while enjoying great drinks, food, and a massage.

 

Also back by popular demand and for the third time in a row, IOActive will be sponsoring and hosting Barcon. This is an invitation-only event where our top, l33t, sexy (maybe not ) researchers meet to drink and talk.

 

Lastly (but not least important), we are once again hosting “Freakshow”, our popular and greatest DefCon party, on Saturday, August 3rd at 9am at The Rio pools.

 

For your convenience, here are the details on our talks at Black Hat USA and DefCon:

 

IMPLANTABLE MEDICAL DEVICES: HACKING HUMANS
Who: Barnaby Jack
Where & When: Black Hat USA, August 1st, 2:15pm

 

In 2006, approximately 350,000 pacemakers and 173,000 ICD’s (Implantable Cardioverter Defibrillators) were implanted in the US alone. 2006 was an important year; this is when the FDA began approving fully wireless-based devices. Today there are well over 3 million pacemakers and over 1.7 million ICDs in use.
In this talk, I will focus on the security of wireless implantable medical devices and discuss how these devices operate and communicate and the security shortcomings of the current protocols. I will reveal IOActive’s internal research software that uses a common bedside transmitter to scan for and interrogate individual medical implants. Finally, I will discuss techniques that manufacturers can implement to improve the security of these devices.

 

COMPROMISING INDUSTRIAL FACILITIES FROM 40 MILES AWAY
Who: Lucas Apa and Carlos Mario Panagos
Where & When: Black Hat USA, August 1st, 3:30pm

 

The evolution of wireless technologies has allowed industrial automation and control systems (IACS) to become strategic assets for companies that rely on processing plants and facilities in industries such as energy production, oil, gas, water, utilities, refining, and petrochemical distribution and processing. Effective wireless sensor networks have enabled these companies to reduce implementation, maintenance, and equipment costs and enhance personal safety by enabling new topologies for remote monitoring and administration in hazardous locations.
However, the manner in which sensor networks handle and control cryptographic keys is very different from the way in which they are handled in traditional business networks. Sensor networks involve large numbers of sensor nodes with limited hardware capabilities, so the distribution and revocation of keys is not a trivial task.
In this presentation, we will review the most commonly implemented key distribution schemes, their weaknesses, and how vendors can more effectively align their designs with key distribution solutions. We will also demonstrate some attacks that exploit key distribution vulnerabilities, which we recently discovered in every wireless device developed over the past few years by three leading industrial wireless automation solution providers. These devices are widely used by many energy, oil, water, nuclear, natural gas, and refined petroleum companies.
An untrusted user or group within a 40-mile range could read from and inject data into these devices using radio frequency (RF) transceivers. A remotely and wirelessly exploitable memory corruption bug could disable all the sensor nodes and forever shut down an entire facility. When sensors and transmitters are attacked, remote sensor measurements on which critical decisions are made can be modified. This can lead to unexpected, harmful, and dangerous consequences.

 

Adventures in Automotive Networks and Control Units
Who: Chris Valasek
Where & When: DefCon, August 2nd, 10:00am
Automotive computers, or Electronic Control Units (ECU), were originally introduced to help with fuel efficiency and emissions problems of the 1970s but evolved into integral parts of in-car entertainment, safety controls, and enhanced automotive functionality.
In this presentation, I will examine some controls in two modern automobiles from a security researcher’s point of view. I will first cover the requisite tools and software needed to analyze a Controller Area Network (CAN) bus. I will also demo software to show how data can be read and written to the CAN bus. Then I will show how certain proprietary messages can be replayed by a device hooked up to an ODB-II connection to perform critical car functionality, such as braking and steering. Finally, I will discuss aspects of reading and modifying the firmware of ECUs installed in today’s modern automobile.

 

INSIGHTS | June 20, 2013

FDA Safety Communication for Medical Devices

By Gunter Ollmann
The US Food and Drug Agency (FDA) released an important safety communication targeted at medical device manufacturers, hospitals, medical device user facilities, health care IT and procurements staff, along with biomedical engineers in which they warn of risk of failure due to cyberattack – such as through malware or unauthorized access to configuration settings in medical devices and hospital networks.
Have you ever been to view a much anticipated movie based upon an exciting book you happened to have read when you were younger, only to be sorely disappointed by what the director finally pulled together on the big screen? Well that’s how I feel when I read this newest alert from the FDA. Actually it’s not even called an alert… it’s a “Safety Communication”… it’s analogous to Peter Jackson deciding that his own interpretation of JRR Tolkien’s ‘The Hobbit’ wasn’t really worthy of the title so to forestall criticism he named the movie ‘Some Dwarves and a Hobbit do Stuff’.
This particular alert (and I’m calling it an alert because I can’t lower myself to call it a safety communication any longer) is a long time coming. Almost a decade ago me and my teams at the time raised the red flag over the woeful security of hospital networks, then back in 2005 my then research teams raised new red flags related to the encroachment of unsecured WiFi in to medical equipment, for the last couple of years IOActive’s research team have been raising new red flags over the absence of security within implantable medical devices, and then on June 13th 2013 the FDA releases a much watered down alert where the primary recommendations and actions section simply states “[m]any medical devices contain configurable embedded computer systems that can be vulnerable to cybersecurity breaches”. It’s as if the hobbit has been interpreted as a midget with hairy feet.
Yes I joke a little, but I am very disappointed with the status of this alert covering an important topic.
The vulnerabilities being uncovered on a daily basis within hospital networks, medical equipment and implantable devices by professional security teams and researchers are generally more serious than what outsiders give credit. Much of the public cybersecurity discussion as it relates to the medical field to date has been about people hacking hospital data systems for patient records and, most recently, the threat of targeted slayings of people who happen to have vulnerable implanted insulin pumps and heart defibrillators. While both are certainly possible, they’re what I would associate with fringe events.
I believe that the biggest and most likely threats lie in non-malicious actors – the tinkerers, the cyber-crooks, and the “in the wrong place at the wrong time” events. These medical systems are so brittle that even the slightest knock or tire-kicking can cause them to fail. I’ll give you some examples:
  • Wireless heart and drug monitoring stations within emergency wards that have open WiFi connections; where anyone with an iPhone searching for an Internet connection can make an unauthenticated connection and have their web browser bring up the admin portal of the station.
  • Remote surgeon support and web camera interfaces used for emergency operations brought down by everyday botnet malware because someone happened to surf the web one day and hit the wrong site.
  • Internet auditing and scanning services run internationally and encountering medical devices connected directly to the Internet through routable IP addresses – being used as drop-boxes for file sharing groups (oblivious to the fact that it’s a medical device under their control).
  • Common WiFi and Bluetooth auditing tools (available for android smartphones and tablets) identifying medical devices during simple “war driving” exercises and leaving the discovered devices in a hung state.
  • Medial staff’s iPads without authentication or GeoIP-locking of hospital applications that “go missing” or are borrowed by kids and have applications (and games) installed from vendor markets that conflict with the use of the authorized applications.
  • NFC from smartphone’s and payment systems that can record, playback and interfere with the communications of implanted medical devices.
These are really just the day-to-day noise of an Internet connected life – but one that much of the medical industry is currently ill prepared to defend against. Against an experienced attacker or someone determined to cause harm – well, it’s as one sided as a lone hobbit versus the combined armies of Middle Earth.
I will give the alert some credit though, that did clarify a rather important point that may have been a stumbling block for many device vendors in the past:
“The FDA typically does not need to review or approve medical device software changes made solely to strengthen cybersecurity.”
IOActive’s experience when dealing with a multitude of vulnerable medical device manufacturers had often been disheartening in the past. A handful of manufacturers have made great strides in securing their devices and controlling software recently – and there has been a change in the hearts and minds over the last 6 months (pun intended) as more publicity has been drawn to the topic. The medical clients we’ve been working most closely with over recent months have made huge leaps in making their latest devices more secure, and their next generation of devices will be setting the standard for the industry for years to come.
In the meantime though, there’s a tremendous amount of work to be done. The FDA’s alert is significant. It is a formal recognition of the poor state of security within the industry – providing some preliminary guidance. It’s just not quite a call to arms I’d have liked to see after so many years – but I guess they don’t want to raise too much fear, nor the ire of vendors that could face long and costly FDA re‑evaluations of their technologies. Gandalf would be disappointed.
(BTW I actually liked Peter Jackson’s rendition of The Hobbit).
INSIGHTS | February 26, 2013

“Broken Hearts”: How plausible was the Homeland pacemaker hack?

By Barnaby Jack
[1]
I watched the TV show Homeland for the first time a few months ago. This particular episode had a plot twist that involved a terrorist remotely hacking into the pacemaker of the Vice President of the United States.

People follow this show religiously, and there were articles questioning the plausibility of the pacemaker hack. Physicians were questioned as to the validity of the hack and were quoted saying that this is not possible in the real world [2].

In my professional opinion, the episode was not too far off the mark.


In the episode, a terrorist finds out that the Vice President has a bad heart and his pacemaker can be remotely accessed with the correct serial number. The terrorist convinces a congressman to retrieve the serial number, and then his hacker accomplice uses the serial to remotely interrogate the pacemaker. Once the hacker has connected to the pacemaker, he instructs the implantable device to deliver a lethal jolt of electricity. The Vice President keels over, clutches his chest, and dies.
My first thought after watching this episode was “TV is so ridiculous! You don’t need a serial number!”
In all seriousness, the episode really wasn’t too implausible. Let’s dissect the Hollywood pacemaker hack and see how close to reality they were. First, some background on the implantable medical technology:
The two most common implantable devices for treating cardiac conditions are the ““`pacemaker and the implantable cardioverter-defibrillator (ICD).
The primary function of the pacemaker is to monitor the heart rhythm of a patient and to ensure that the heart is beating regularly. If the pacemaker detects certain arrhythmia (an irregular heartbeat or abnormal heart rhythm), the pacemaker sends a low voltage pulse to the heart to resynchronize the electrical rhythm. A pacemaker does not have the capability to deliver a high voltage electrical shock.
Newer model ICD’s not only have pacing functionality, but they are also able to deliver a high voltage shock to the heart. The ICD most commonly detects an arrhythmia known as ventricular fibrillation (VF), which is a condition that causes irregular contractions of the cardiac muscle. VF is the most common arrhythmia associated with sudden cardiac death. When an ICD detects VF, it will deliver a shock to the heart in an attempt to reverse the condition.
Back to Homeland, let’s see how close Hollywood was to getting it right. Although they mention a pacemaker in the episode, the actual implantable device is an ICD.
HOMELAND: The congressman is told to retrieve the serial number from a plastic box in the Vice President’s office. The plastic box he retrieves the serial number from has a circular wand and telephone inputs on the side.

Fact! The plastic box on the episode is a commonly used remote monitor/bedside transmitter. The primary use of the bedside transmitter is to read patient data from the pacemaker or ICD and send the data to a physician over the telephone line or network connection. The benefit to this technology is reduced in-person visits to the physician’s clinic. The data can be analyzed remotely, and the physician can determine whether an in-person visit is required.

Before 2006, all pacemaker programming and interrogation was performed using inductive telemetry. Programming using inductive telemetry requires very close skin contact. The programming wand is held up to the chest, a magnetic reed switch is opened on the implant, and the device is then open for programming and/or interrogation. Communication is near field (sub 1MHZ), and data rates are less than 50KHZ.
The obvious drawback to inductive telemetry is the extremely close range required. To remedy this, manufacturers began implementing radiofrequency (RF) communication on their devices and utilized the MICS (Medical Implant Communication Service) frequency band. MICS operates in the 402-405MHZ band and offers interrogation and programming from greater distances, with faster transfer speeds. In 2006, the FDA began approving fully wireless-5based pacemakers and ICDs.
Recent remote monitors/bedside transmitters and pacemaker/ICD programmers support both inductive telemetry as well as RF communication. When communicating with RF implantable devices, the devices typically pair with the programmer or transmitter by using the serial number, or the serial number and model number. It’s important to note that currently the bedside transmitters do not allow a physician to dial into the devices and reprogram the devices. The transmitter can only dial out.
So far, so good.
HOMELAND: The hacker receives the serial number on his cell phone and uses his laptop to remotely connect to the ICD. The laptop screen displays real-time electrocardiogram (ECG) readouts, heart beats-per-minute, and waveforms generated by the ICD. He then instructs his software to deliver defibrillation. Then it’s game over for the victim at the other end.
If you look past the usual bells and whistles that are standard issue with exploit software on TV, the scrolling hex dumps, the c code in the background—the waveform and beats per minute (BPM) diagnostic data from the implant that is shown in real-time is legitimate and can be retrieved over the implant’s wireless interface. The official pacemaker/ICD programmers used by the physicians have a similar interface. In the case of ICDs, the pacing and high voltage leads are all monitored, and the waveforms can be displayed in real time.
The attacker types in a command to remotely induce defibrillation on the victim’s ICD.It is possible to remotely deliver shocks to ICDs. The functionality exists for testing purposes. Depending on the device model and manufacturer, it is possible to deliver a jolt in excess of 800 volts.
Moving on to the remote attack itself, the TV episode never mentioned where the attacker was located, and even if it was possible to dial into the remote monitor, it was disconnected.
Some manufacturers have tweaked the MICS standard to allow communication from greater distances and to allow communication over different frequencies. Let’s talk a little about how these devices communicate, using a fairly new model ICD as an example.
The Wake-up Scheme:
Before an implantable device can be reprogrammed, it must be “woken up”. Battery conservation is extremely important. When the battery has been depleted, surgery is required to replace the device. To conserve power, the implants continually run in a low power mode, until they receive an encoded wake-up message. The transceiver in this ICD supports wake-up over the 400MHZ MICS band, as well as 2.45GHZ.
To wake-up and pair with an individual device, you must transmit the serial and model number in the request. Once a device has paired with the correct model and serial number and you understand the communications protocol, you essentially have full control over the device. You can read and write to memory, rewrite firmware, modify pacemaker/ICD parameters, deliver shocks, and so on.
When using a development board that uses the same transceiver, with no modifications to the stock antenna, reliable communication will max out at about 50 feet. With a high gain antenna, you could probably increase this range.
Going back to Homeland, the only implausible aspect of the hack was the range in which the attack was carried out. The attacker would have had to be in the same building or have a transmitter set up closer to the target. With that said, the scenario was not too far-fetched. The technology as it stands could very easily be adapted for physicians to remotely adjust parameters and settings on these devices via the bedside transmitters. In the future, a scenario like this could certainly become a reality.
––

As there are only a handful of people publicizing security research on medical devices, I was curious to know where the inspiration for this episode came from. I found an interview with the creators of the show where the interviewer asked where the idea for the plot twist came from [3]. The creators said the inspiration for the episode was from an article in the New York Times, where a group of researchers had been able to cause an ICD to deliver jolts of electricity [4].

This work was performed by Kevin Fu and researchers at the University Of Massachusetts in 2008. Kevin is considered a pioneer in the field of medical device security. The paper he and the other researchers released (“Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses”) [5] is a good read and was my initial inspiration for moving into this field.
I recommend reading the paper, but I will briefly summarize their ICD attack. Their paper dates back to 2008. At the time, the long range RF-based implantable devices were not as common as they are today. The device they used for testing has a magnetic reed switch, which needs to be opened to allow reprogramming. They initiated a wakeup by placing a magnet in close proximity to the device, which activated the reed switch. Then they captured an ICD shock sequence from an official ICD/pacemaker programmer and replayed that data using a software radio.
The obvious drawback was the close proximity required to carry out a successful attack. In this case, they were restricted by the technology available at the time.
At IOActive, I’ve been spending the majority of my time researching RF-based implants. We have created software for research purposes that will wirelessly scan for new model ICDs and pacemakers without the need for a serial or model number. The software then allows one to rewrite the firmware on the devices, modify settings and parameters, and in the case of ICDs, deliver high-voltage shocks remotely.
At IOActive, this research has a personal attachment. Our CEO Jennifer Steffens’ father has a pacemaker. He has had to undergo multiple surgeries due to complications with his implantable device.
Our goal with this research is not for people to lose faith in these life-saving devices. These devices DO save lives. We are also extremely careful when demonstrating these threats to not release details that could allow an attack to be easily reproduced in the wild.
Although the threat of a malicious attack to anyone with an implantable device is slim, we want to mitigate these risks no matter how minor. We are actively engaging medical device manufacturers and sharing our knowledge with them.