80 to 0 in Under 5 Seconds: Falsifying a Mediacal Patient's Vitals

Video thumbnail (Frame 0) Video thumbnail (Frame 2577) Video thumbnail (Frame 4107) Video thumbnail (Frame 5495) Video thumbnail (Frame 7451) Video thumbnail (Frame 10540) Video thumbnail (Frame 13156) Video thumbnail (Frame 14339) Video thumbnail (Frame 15652) Video thumbnail (Frame 16782) Video thumbnail (Frame 18727) Video thumbnail (Frame 20446) Video thumbnail (Frame 21392) Video thumbnail (Frame 22652) Video thumbnail (Frame 25197) Video thumbnail (Frame 26134) Video thumbnail (Frame 27601) Video thumbnail (Frame 28762) Video thumbnail (Frame 29686) Video thumbnail (Frame 31152) Video thumbnail (Frame 32274) Video thumbnail (Frame 33353) Video thumbnail (Frame 35167) Video thumbnail (Frame 36650) Video thumbnail (Frame 37722) Video thumbnail (Frame 44981) Video thumbnail (Frame 47623) Video thumbnail (Frame 49046)
Video in TIB AV-Portal: 80 to 0 in Under 5 Seconds: Falsifying a Mediacal Patient's Vitals

Formal Metadata

Title
80 to 0 in Under 5 Seconds: Falsifying a Mediacal Patient's Vitals
Title of Series
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2018
Language
English

Content Metadata

Subject Area
Abstract
It seems each day that passes brings new technology and an increasing dependence upon it. The medical field is no exception; medical professionals rely upon technology to provide them with accurate information and base life-changing decisions on this data. In recent years there has been more attention paid to the security of medical devices; however, there has been little research done on the unique protocols used by these devices. In large, health care systems medical personnel take advantage of to make decisions on patient treatment and other critical care, use central monitoring stations. This information is gathered from many devices on the network using uncommon networking protocols. What if this information wasn't accurate when a doctor prescribed medication? What if a patient was thought to be peacefully resting, when in fact they are under cardiac arrest? McAfee's Advanced Threat Research team has discovered a weakness in the RWHAT protocol, one of the networking protocols used by medical devices to monitor a patient's condition. This protocol is utilized in some of the most critical systems used in hospitals. This weakness allows the data to be modified by an attacker in real-time to provide false information to medical personnel. Lack of authentication also allows rogue devices to be placed onto the network and mimic patient monitors. This presentation will include a technical dissection of the security issues inherent in this relatively unknown protocol. It will describe real-world attack scenarios and demonstrate the ability to modify the communications in-transit to directly influence the receiving devices. We will also explore the general lack of security mitigations in the medical devices field, the risks they pose, and techniques to address them. The talk will conclude with a demonstration using actual medical device hardware and a live modification of a patient's critical data.
Presentation of a group Multiplication sign Projective plane Set (mathematics) Bit Field (computer science) Information technology consulting Type theory Personal digital assistant Energy level Freeware Communications protocol Information security
Mobile Web Pulse (signal processing) Touchscreen Information Decision theory Workstation <Musikinstrument> Execution unit Basis <Mathematik> Wave packet Revision control Sign (mathematics) Centralizer and normalizer Internetworking Bit rate Different (Kate Ryan album) Cuboid Metric system Pressure Backup
Point (geometry) Presentation of a group Observational study Multiplication sign Decision theory Execution unit Workstation <Musikinstrument> 1 (number) Real-time operating system Vector potential Perspective (visual) Hypothesis Centralizer and normalizer Mathematics Internetworking Different (Kate Ryan album) Vector graphics Computer hardware Endliche Modelltheorie Firmware Vulnerability (computing) User interface Information management Multiplication Magneto-optical drive Data storage device Cartesian coordinate system Vector space Software Statement (computer science) output Website Communications protocol Window Resultant Operating system
Point (geometry) Multiplication sign Workstation <Musikinstrument> Database Neuroinformatik Centralizer and normalizer Component-based software engineering Hooking Internetworking Cuboid Software testing Information Message passing Metropolitan area network Physical system Service (economics) Touchscreen Information Computer simulation Computer network ACID Broadcasting (networking) Software output Software testing Communications protocol Physical system Address space
Presentation of a group Content management system Open source Multiplication sign Workstation <Musikinstrument> Electronic program guide Online help Inclined plane Function (mathematics) 2 (number) IP Centralizer and normalizer Energy level Software testing Precedence diagram method Open source Computer simulation Bit Mereology Process (computing) Broadcasting (networking) Software Pressure Communications protocol Window
State observer Functional (mathematics) Greatest element Content management system Computer file Open source Multiplication sign Workstation <Musikinstrument> Online help 2 (number) Power (physics) Number Frequency Broadcasting (networking) Centralizer and normalizer Integer Software testing Communications protocol Binary multiplier Firmware Compilation album Physical system Binary code Open source Planning Bit Symbol table Loop (music) Broadcasting (networking) Internetworking Software Configuration space Hill differential equation Communications protocol Window
Functional (mathematics) Parsing Content management system Information Multiplication sign Binary code Workstation <Musikinstrument> Computer simulation Bit Parameter (computer programming) Limit (category theory) Symbol table Field (computer science) Category of being Centralizer and normalizer Hexagon Broadcasting (networking) Software Personal digital assistant Logic Military operation Normal (geometry) Simulation Computer worm
Frame problem Noise (electronics) Information Workstation <Musikinstrument> 2 (number) IP Centralizer and normalizer Software Revision control Communications protocol UDP <Protokoll> Communications protocol Physical system
Scripting language Metropolitan area network Email Computer font Hoax Open source Multiplication sign Workstation <Musikinstrument> Length Bit 2 (number) Hand fan Broadcasting (networking) Centralizer and normalizer Software Escape character Communications protocol Information security Address space
Point (geometry) Dependent and independent variables Content management system Open source Decimal Workstation <Musikinstrument> Bit Hypothesis Centralizer and normalizer Software Telecommunication Analogy UDP <Protokoll> Communications protocol
Scripting language Content management system Length Computer-generated imagery Right angle Bit ACID UDP <Protokoll> Number
Centralizer and normalizer Email Presentation of a group Uniform resource locator Software Multiplication sign Workstation <Musikinstrument> Moment (mathematics) Touch typing UDP <Protokoll> IP address Computer worm
Emulator Centralizer and normalizer Touchscreen Emulator Software Workstation <Musikinstrument> Statement (computer science) Videoconferencing Hypothesis Shareware Number
Point (geometry) Workstation <Musikinstrument> 1 (number) Bit CAN bus Broadcasting (networking) Emulator Type theory Centralizer and normalizer Goodness of fit Process (computing) Emulator Software Right angle Booting Communications protocol Physical system Condition number
Area Scripting language Ewe language Implementation Code Neuroinformatik Software Vector space Causality Internetworking Game theory Remote procedure call Conditional-access module Physical system
Point (geometry) Frame problem Trail Workstation <Musikinstrument> Real-time operating system IP address Number Emulator IP Centralizer and normalizer Cuboid Communications protocol UDP <Protokoll> Address space Email Arm Information Image resolution Length Computer simulation Proof theory Hexagon Software Personal digital assistant Sheaf (mathematics) Revision control Computer worm Address space
Point (geometry) Scripting language Beat (acoustics) Presentation of a group Touchscreen Information management Information Multiplication sign Workstation <Musikinstrument> Moment (mathematics) Motion capture Sound effect Bit 2 (number) Centralizer and normalizer Videoconferencing Escape character
Web page Beat (acoustics) Presentation of a group State of matter Multiplication sign Workstation <Musikinstrument> Real-time operating system Mereology Field (computer science) Sound effect Data management Mathematics Centralizer and normalizer Component-based software engineering Bit rate Different (Kate Ryan album) Touch typing Boiling point Normal (geometry) Local ring Pressure Scripting language Dependent and independent variables Touchscreen Arm Information Expert system Sound effect Bit Database Determinism Line (geometry) Instance (computer science) Flow separation Connected space Type theory Wave Data management Software Order (biology) Interrupt <Informatik> Video game Normal (geometry) Waveform Pressure Bounded variation Very long instruction word Row (database)
Presentation of a group Multiplication sign Workstation <Musikinstrument> 1 (number) Mereology Perspective (visual) IP address Likelihood function Data management Emulator Mathematics Bit rate Different (Kate Ryan album) Semiconductor memory Single-precision floating-point format Encryption Cuboid Position operator Physical system Vulnerability (computing) Touchscreen Mapping Stress (mechanics) Computer simulation Sound effect Determinism Staff (military) Bit Instance (computer science) Price index Flow separation Social engineering (security) Degree (graph theory) Data management Message passing Process (computing) Telecommunication Order (biology) output Bounded variation Pole (complex analysis) Point (geometry) Game controller Open source Observational study Field (computer science) Wave packet Number Product (business) Revision control Broadcasting (networking) Frequency Centralizer and normalizer Programmschleife Causality Internetworking Representation (politics) Energy level Software testing Normal (geometry) Address space Addition Multiplication Information System call Vector potential Shareware Hypermedia Software Personal digital assistant Waveform Game theory Pressure Communications protocol Local ring
and with that I'm gonna hand it over to Douglas McKee that was thank you she's gonna thank you for coming and welcome to our talk today we're really excited to be here and hopefully you won't find this too boring either so first of all who's the crazy guy standing in front of you my name is Douglas McKee I'm a security researcher on McAfee the advanced threat research team and I think more importantly for this talk is not who I am but who I'm not and in this case I'm not a medical doctor and don't claim to be in fact I have you'll notice throughout the presentation I have very little knowledge in the medical field but we are working with medical devices so with that I brought with me a medical doctor today I'd like to introduce to you dr. Sean Nordic he will be interjecting throughout the presentation to provide real-world scenarios for the research in which we've done and for now I'm gonna hand it over to dr. doc well thank you as Doug said I am a medical doctor specifically I'm a surgical resident at a level one trauma center I got involved with this project on my own free time I'm not a paid consultant I have no financial disclosures so with that out of the way kind of give you overview what we're gonna do I'm gonna provide you a little bit of background of the device on why we chose it as well as how it's used in actual medical setting then I'm gonna turn the talk over to Doug who's gonna then cover the protocol reversing the protocol how the attacks were carried out and we'll give you some demonstrations of that and then I'm gonna give you a little bit of insight into what that type of impact of these potential attacks will have in the medical setting and then we're gonna wrap it up with covering mitigation on how the different vendors as well as the facilities themselves can mitigate potential attacks so we're considering
what to investigate when we're doing our research we wanted to make sure that it was gonna be impactful and we already knew that insulin pumps as well as pacemakers have already been hacked but what else could we hack that would have a lot of impact and so came back to the fundamental and that is vital signs and vital signs form the foundation of every medical decision in clinical decision that we make as physicians and we rely on devices heavily for these vital signs rarely will you ever see a physician taking your blood manually or checking your pulse manually generally these are done by a device so we wanted to go and investigate patient monitors and those are the devices that you'll see at the bedside which will obtain your heart rate and vital signs now I agree with another speaker here dr. Jeff Thule when he states that we trust these devices implicitly to Broadus accurate information furthermore we don't receive any training in medical school or in our literature explaining the potential threats that exists with these devices so you might be wondering
what a patient monitor is a patient monitor is a device that you'll find in the emergency room as well as intensive care unit and those are these big boxes that you see at the top of the screen here they're gonna obtain the heart rate the heart rhythm as well as your blood pressure oxygen saturation and many other different metrics that we use as physicians to make decisions on whether a patient is sick not sick whether they need to go to the ER immediately or not basically how well is this patient doing and they form the basis here now they can be wireless or wired and they even come in a scaled-down version called a telemetry box which you see on the bottom those provide increased mobility for patients to be able to kind of move around while we still provide continuous monitoring of their heart rate their heart rhythm as well as things like oxygen saturation these contain patient identifiable information as well because obviously these have to be linked back to who the patient is that they're monitoring and all of these communicate to a central monitoring station a
central monitoring station is basically a PC that sits in an off site in the ER and the intensive care unit usually sits at a nursing station and what it does is receives all this input on for four patients it usually sits in a specific room called telemetry room and receives all the input from multiple different patient devices at one time these central monitoring stations have a built-in user interface that's kind of scaled down they typically run X P or some of the newer devices run Windows seven and they are monitored either by a nurse for like the ER or the intensive care unit or they're monitored by a telemetry technician someone who's trained to monitor these devices these devices also have audible and visual alarms they have the capability to store 24 hours or more of a heart rhythm on a patient and they have the ability to print off rhythms to for for later review and storing inside of a patient's medical chart we were able to secure both of these devices to investigate rather cheaply off of the Internet and I'm gonna turn the talk over now to Doug who's able to kind of carry forth what we did to investigate these thanks Sean for that great overview so as Sean said once we obtain these devices and was time to start
looking at what do we want to do to attack them and as John said in the beginning it's really important for us to make sure we did a meaningful attack so we take a moment and look at the different possible attack vectors that we have if we look at the central monitoring station it's very quick easy to see that there's the OS and the application well as Sean enumerated a lot of these OS is that on the central monitoring stations are running Windows XP and Windows 7 and let's face it we all know that Windows XP is a vulnerability within itself and Windows 7 is really not that far behind so and that's also not you know specific to the medical community so it really wasn't a good target to look at at least not for what we were trying to accomplish and next you have the application that's running on there and although that would be more specific to the medical community it really only attacks one of the two devices in which we're looking at and being at it's running on an older operating system vulnerabilities that we found could more be linked to the operating system than the application itself so this left the patient monitor itself and you've got the firmware and the hardware and these are great targets to look at we could take device apart pull off the former look for vulnerabilities but again two things that we didn't like from that in the beginning was one it's only looking at one of the two devices the results may be very specific to the model that we look at it wouldn't be very widespread and then also there's always the chance when used to get to that level on a device that you're going to destroy the device we wanted to be able to do more research at least and initially so the easiest thing to look at that was between both devices was the networking and so I started talking to Sean about what the possibilities were from a network perspective and we kind of came to a conclusion that if we were able to modify patient data as it went across the network in real time that this would be an impactful change and would effect dr. Nordic sees on a regular basis because as these studies making decisions in real time on this data so that really became the thesis statement for this the rest of this presentation which goes to can we modify patient data in real time over the network so if that was going to be our initial attack point then as a responsible researcher I scoured the internet looking for different networking protocols that were used by medical devices and obviously more specifically with the ones that we were able to purchase and I came across
something called the our what protocol and believe it or not what you see in front of you on the screen is the entirety of the information I was able to find on the internet for the R what protocol my point being is I wasn't able to find any RFC's there wasn't a whole lot of documentation out there and I always find this amusing that in the
documentation it says there's a lot of things in the packets so I was very interested to see what are the things so
now it was time to have a testing set up and it's pretty simple to network to devices so we took the patient monitor and the central monitor station we plugged them into a switch and then I put a computer on there as well in a monitoring port so I could see what the network traffic looked across the across the network but there was one main component in which we were missing and that is user input so how do you get user input for most devices well a lot of research you know you to build a fuzzer or you know whatever the normal input is well for us that's a patient so I did what any responsible researcher would do and I find myself a patient and so I had a co-worker and I said come here for a second I wanted to test something on you and so we hooked well hook my buddy up here to the patient monitor I was like okay great now I'm gonna have user input to see how this system works but I'm sitting there and I'm not getting any heartbeat or anything to go across the network and I'm like what am I doing wrong with this thing so I called dr. Nordic and Doc do you want to help me out here and what was I doing wrong so first off you get the leads almost right but not quite and then second you don't have to have a half-naked man all the time just the testers with it you can you can use a device they made which is called an ECG simulator it's a little box that you hook your plugs up to and you don't have to you don't have to have this so did I mention I'm not a doctor so we decided to improve our testing setups or
some more reliable testing and we bought this ECG simulator which was less than a hundred dollars on eBay and we hooked it up and this became our very simplistic test network and I want to point out here that the rest of the presentation we will focus on a patient's heartbeat but that is not limited to what this research goes to anything the patient monitor can output whether it's blood pressure o two levels etc can also be affected by with the rest of research but we will be focusing on the heartbeat because it was the cheapest thing to emulate for for this research so now as I go about the process of doing my setup I wanted to make it as simple as possible again so I wanted to look at one device at a time so the first thing I did like powered down the patient monitor powered down the ECG simulator and I only looked at the central monitoring station and I I powered it up and to a little bit to my surprise I
actually already saw packets going across the network and so looking at Wireshark this is what we see and the first thing that jumps out at me anyway was that the source and destination port for the packets going across the network was the same it was port 7000 and this will be a theme throughout the presentation as well the next thing as you can notice is it's very easy to see that every approximately every 10 seconds these packets are transmitted across the network and then also I have redacted some of this but the name of the central monitoring station in which we were testing is in clear text in these packets which doesn't confirm completely but gives us the inclination that maybe we're dealing with an unencrypted protocol now because as Sean and I enumerated that the central monitoring station runs Windows XP and Windows 7 it was very simple to pull the binaries off of that and take a look at them to kind of get a deeper understanding of what these packets are and to confirm what we see simply by looking at Wireshark so the help of Ida
Pro and the D compilers and the vendor for Ethan wanted thank you for leaving all the debugging symbols in the names in the binaries that was extremely helpful so with a little help of all that is the wild that handles the packets in which you see on the network and first you'll see at the top of the loop there's a function called broadcast or what that's the protocol being broadcast out and then towards the bottom here you see something called to get our what period function if we take a look at that function what we end up seeing is that it reads in a value from a config file which is an integer returns out integer and depending on what the answer is it multiplies it by a thousand in the windows sleep function and that's how long the function sleeps for and so all this does is confirm what we saw over Wireshark that we weren't making up these you know this wasn't a one-time thing this is actually how it functions
so now the next thing was to do was the power off the central monitoring system and to power on the patient monitor so that we all again only had the patient monitor on the network and once again we saw these broadcast packets going across the network and again we can make some very similar observations every 10 seconds approximately a packet is sent we noticed that the destination port is the same however the source port increments by one every single time that if one of these packets is broadcast across the network also if you stare at hex long enough for these packets you'll notice that I'd offset it approximately 34 there is a counter that's being incremented by 10 each time and not coincidentally the same as the number of seconds that is that each packet is sent and then of course you can see clearly here in plane tax that there is patient data going across the network and again these are broadcast packets these are not going directly to a single device and my understanding is from dr. Nordic that when you combine a patient's name their room number and your their bed number which is what this is you're now talking about HIPAA data so again I didn't want to completely disassemble the patient monitor because I want to continue testing so I didn't want to pull off the firmware to look at the binary for this however this data had to be received by something and so it's not far-fetched to believe that it had to receive by the central monitoring station so a little bit of digging once again in Ida and the
binaries that we have it's very you can determine the function that receives these packets off the wire and again kind of confirm and learn a little bit more about these packets the first thing you'll notice up at the top is that there's a function that takes the payload plus 12 and I'm not going to go back but if you add 12 to the beginning of the payload you'll land exactly where the patient name and the patient information starts and you can also see that that's passed to a function that again I didn't name this function this was because the debugging symbols called parse logical name you'll see the second parameter is xx in hex there's 32 bytes this tells us that there is a limit to how much data fits in there and we can start diagramming out the packet to know that okay this field is this large yada yada yada and then on top of that we see that there's property some decent handling being done in case that the field is left empty they handle the fact that looking for a null and then we can see that this value is parsed out and then stored later for use again all this does is confirm what we saw off the network traffic but it's kind of good to go back and have a little bit of a foundation so now that we've looked at both the central monitoring station and the patient monitor independently it's time to plug them in so we plug them both into the network we turn on the ECG simulator and lo and behold hey look we
have a heartbeat going across the network it works as intended and we now
have a fully functioning a live system that by the way makes a whole lot of noise and your co-workers do not appreciate but now what does this look like in Wireshark so in Wireshark now that we have two devices that can communicate you can see here that we have the patient monitor at 126 4 153 150 and we have the central monitoring station at 126 1.1.1 and without going into any real deep dive just at a first glance you can see that we have a bunch of packets being sent of approximately the same size and these to signify the data packets or the heartbeat going across the network you
know I threw a lot of information at you so let me take it's just about two and a half seconds to repeat everything and see if you come to the same conclusions that I did we have a UDP protocol going
across the network that's being sent to the broadcast address there's a couple
counters that we handle that are about 10 seconds apart
we've got source ports that are incrementing and we have a bunch of unencrypted data with like size data packets now I don't know about you but
as a security researcher so that immediately said to me that's a simple replay attack so that's exactly what I started to do and I'm personally a big fan of pythons KP module so I do a lot of my networking research in escapee and so I took so just a little bit of time and coded up a simple scape ii script that would read in the packets from a larger cashier replay them back on the network and with the patient monitor disconnected to see if this would allow for the central monitoring station to pick up my fake patient monitor well that did not work
exactly as planned and I also did try a little bit with UDP replay and a couple of those programs so that what told me was that I really needed to take an extra minute and really understand was going across I wasn't getting it the easy way out on this plus it wasn't doing what I wanted to do anyway so we took a deeper dive
into these packets now I'm about to explain to you I understand we're working with the UDP protocol I'm not telling anybody that this is doing a TCP handshake what I am saying is that there is a handshake going across the network that's very similar to TCP so I'm using that as an analogy so what we've got here is we can first notice that there is a packet that goes across the wire from the central monitoring station to the patient monitor and we see that that packet is on port 2000 as a destination I'm gonna call that the syn packet so that's the first packet that goes across the next we see the patient longer respond and I'm going to refer that as a syn ACK packet the most important thing to notice with this packet here is that it responds to the same port that was initially sent as the source port from the syn packet and if we continue to follow this communication we now have the central monitor station that responds with what I'm gonna refer to as the act packet to the to the central monitoring station excuse me on port 2000 falling at this point our hypothetical TCP handshake is complete and of course you'd start to see data well the first thing that we see from the patient monitor from the patient monitor is a packet that essentially is asking what port do we want to use to suspend our data packets for and what we do we see is a response from the central monitoring station say hey use this packet 36:27 because that's the source packet of the packet of the previous packet so and then we follow then we
followed up and say that we see this 639 length packets that are the data packets or the heart so with this understanding it's really
easy to update our scabies script from before because it's very obvious that it wasn't working because we didn't know the port numbers are changing and we need to account for that right we have to ask for the port number and then once we get it use the right port number to send the data and that didn't work
either so now I'm throwing things in my lab because I don't understand why this isn't working and I decide to look at the packets a little bit more intently and so I'm gonna go back for just a
moment and take a look at what I refer to as the syn ACK packet so this is this
packet here that goes across the network from the patient monitor to the central monitoring station and if we take a look at the payload of that packet and you
take a look at enough of these you will notice that there is a counter in this offset over here that's being incremented by one each time and more so that this packet isn't just the syn ACK packet but it's actually sent every 10 data packets that go across the wire and this counter has to be correct otherwise you get reset packets and basically with what was going on and the reason it didn't work for me the first time was I wasn't accounting for this I wasn't resetting this packet every 10 data packets I was getting a reset back because I wasn't doing that and I wasn't incrementing this counter and it's one more thing that I'd like to point out in this which isn't really relevant at the moment but you'll understand why it's relevant later in the presentation I don't know if you noticed or not but there's something that's especially looks like an IP address embedded in the payload this is not the TCP header this is the payload and there's an IP address in two locations here now that I said I'll touch on that again here in a moment so now that I found this counter that I
was missing before I update my Skippy strips and so what do we know what do we have so what we have is we have broadcast packets that we can easily emulate sending across the network that allows this the central monitoring station to detect a device on the network and then we know that we have to perform this handshake with the correct port numbers in the correct counters and then we should be able to send captured heartbeat packets on the wire and this should emulate a patient heartbeat and even though this really wasn't be as I said the thesis statement of our research it was a important stepping stone because this is what allowed us to have the understanding of how the packets work and lo and behold this works so the first demo I'd like to show you assuming the videos work is a demo of this emulation so what we have here on screen this is the central monitoring
station you notice there's no patient monitors on the network and what I've
done is I've loaded my emulation strips onto a Raspberry Pi and they're set to load on boot so now I'm going to plug in the Raspberry Pi and as soon as the Raspberry Pi boots up it starts sending those broadcast packets and Hey look there's a patient monitor on the network and then the handshake is completed and this central monitoring station says ok great thanks for the data here's a here's a live patient so at this point what we've effectively done is we've completely removed a patient monitor from the system and we can use any device we want as something as simple as as small as a Raspberry Pi to become a patient monitor so why does this matter
well as I said it wasn't we haven't modified any patient data we have learned a whole lot about that about the protocol in the process but there also are a few attack snares here that it's just the least worth mentioning if I was to walk into a hospital of this Raspberry Pi that I have loaded up and I put the correct vitals for a patient that was sitting in a patient room and I unplugged the patient monitor that was there and I plugged in my Raspberry Pi instead the central monitoring station would receive the same data over and over and over again and let's say that the patients peacefully resting that's good and it's not going to cause any alarms but now if the patient does go into some type of critical condition no one's going to be notified there's not any alarms they're gonna go off the data's not gonna make it there or if we want to get a little bit more Hollywood on it you know what if you wanted to kidnap patient or kill the patient right these are a little far-fetched but they're definitely plausible given given what we have found here and if you don't really like the Raspberry Pi ID there
well I had a co-worker that was recently in the hospital who noticed that the gaming system in the in the kids area was dual networked on the Internet and the medical network so now this gives me in a remote tack vector that I can load my scripts on to and but now the gaming system can become a patient monitor and it can transpire down from there and if you don't like that scenario well I don't know if
you've ever been in the hospital before but there's computers all over the place and they're not exactly monitored so once again it there's lots of ways to get this code and to be able to potentially cause havoc in hospital so I've showed this to dr. Nordic and quite frankly he was unimpressed and said that this really wasn't what we were looking to do and there's not a whole lot of medical implementation here so he really
tried to get me back on track and said I wanted you to modify data in real time on the network so how can we take what we learned and actually do that it's actually simpler than emulating emulation emulation we had to account for all this crazy stuff in the handshake well the handshakes already completed at this point so we don't have to do that what we do have to do is figure out those port numbers that were utilized in that handshake and the simplest the simplest way to do that I think most people can agree would be an arm spoof attack I'm sure there's other ways we can accomplish the goal but this was the easiest one for a proof of concept so what would happen if we are proof the patient monitor grabbed the information that we need and then send what we want to send to the central monitoring station well let me show you first we would have the patient monitor
once again at 126 4 153 150 sending packets across the wire and again since this is unencrypted we can find that the heartbeat value is stored at offset 71 and that heartbeat value is 50 in hex or 80 in base 10 and by the way we use 80 it's just a it's just a starting point so the doctor said that's a normal heartbeat and my simulator used that there's no significance to 80 then anyway so we have this going across the network and then we start to do our ARP spoof and Wireshark is kind enough to tell us that hey there's a duplicate MAC address on the network thank you and well that's our Cali box and then we send packets now from 150 3.1 53 not 150 however let's go back and think about what I said about the IP address being embedded in the payload it turns out that the central monitoring station isn't looking at the TCP IP header it's looking at the IP address that's stored in the payload so that means that I don't have to actually spoof much of anything because I could just leave the IP address of what it thought it was in the first place and all I have to do now is change the heartbeat value and it says in this case that I've now modified it to hex 78 or base 10 120 so why not we give this a whirl so for the first I have to demo
videos I'm going to show and for the first demonstration this is a little less practical but it gets the point across so here we have the patient monitor beating at 80 beats per minute and this central monitor sitting on Turing station I'm sorry sitting right next to it so we go ahead on a central monitoring station and we load up the patient monitor and as we would expect to see it's reporting the exact same data that is seen on the patient the patient longer 80 beats per second I'll also take a brief moment to point out you may have noticed there was the delay and loading information on the screen and you also notice that delay in the Raspberry Pi in the nation so that delay is normal it was not an effect of my Raspberry Pi being too slow or something but now I'm going to run my escapee scripts and do some ARB spoofing capture supports I need and send the packets I want to send to the central monitoring station well and my co-workers like to share that I've now killed a patient and you can see i zoom out here so you can see that it's still the same thank you
and I want to point out you see the red rim going around that's the alarms and you see it says saving document will speak on that in a few moments why that's important and then you can also see that all within a few moments of each other I can turn the heartbeat back to what it was and again dr. Nora will speak on why that's important so that was a fun scenario and I people joked with me all the time with how many people I killed doing this research but I promise nobody was harmed in the making of this presentation but now I consulted again with with the doc and he was giving a little to be a little bit more of a realistic scenario and so here we go again and we have the patient monitor beating peacefully at 80 beats per minute and we open up the central monitoring station to pull that information in and
once again we see 80 beats per minute going across the screen when it decides to do it there we go so now we have the heartbeat going across the network and what you're about to see is I'm going to once again run my python scripts but I'm gonna run them not the flat line the page but just to change their their heartbeat I'm gonna change it twice in a very short amount of time notice the title time it takes me to do this so now I'm changing it to 30 beats per minute you'll notice that the beat changes the alarms go off it's saving again the patient monitor says what it's supposed to say 80 beats per minute now what I'm gonna do is I'm gonna let that patient recover a little bit I'm gonna let it go back to 80 beats per minute and now it's back at 80 beats per minute and now I'm gonna start sending it a heartbeat that's too fast that's all so alarming I'm now going to send in 180 beats per minute and again you see the alarms go off and you see that it's saving it to the database these are important things for later and then all said and done I'm gonna make sure the patient goes back to their original state because we don't like the leave things messed up and now the patient is now beating once again at 80 beats per minute so this is a more realistic scenario and I'm gonna turn the presentation over to dr. Nordic and he can explain how this impacts him and his everyday life doctor thank you so as you were able to just see we're able to kind of inject any type of rhythm we want and while the asystole or the flatline rhythm is quite dramatic and is great for Hollywood to have a patient become a systolic doesn't really do a lot because I can easily go to their room and check and the nurse can check on them as well and clearly see that there's a patient who's white quite frankly quite alive so the concern becomes is with those intermittent cardiac rhythms though when the heart rate drops to slow or becomes too fast or if we start giving abnormal variations in that heart wave the wave the little squiggly line you saw has important components to a physician because if we change different parts of that waveform that means different things and it can mean that the heart is very sick and so when I start getting abnormal rhythms the first thing that's gonna happen is the tech or the nurse who's monitoring that is going to page me and let me know hey dr. Nordic this patient's heart rates 180 what can we do and so the thing I'm gonna do is obviously say alright go check on the patient what's our blood pressure I'm gonna order an EKG and I'm on my way to go see them clearly when I get in the patient's room if they have a bedside monitor it's gonna be discont so I'm gonna go back and I'm gonna ask for the tele tech to print me off that strip so I can look at it more closely because I'm not able to see what was going on real time in the room because they're no longer in that rhythm so when I review that rhythm and I see that it's abnormal now I need to do something about it and that's where it becomes concerning having these fictitious rhythms that are that are of a legitimate quality when I'm printing them out I need to do something about that because otherwise this patient could potentially go home and they could have a fatal arrhythmia now here's the other thing - you saw some pauses right so when the when you're astute and you catch these little gaps that happen what do we do about that well those little gaps don't mean very much because as you saw on the monitor the monitor doesn't even pick up and does an alarm on it because if it's a brief interruption in the connection that happens all the time and patients will disconnect their their monitors when they're getting dressed or when they're rolling over in bed so that doesn't really have much of an impact because it happens and as long as they get reconnected that's not going to cause any concern so the first scenario where we emulate data and we can abscond a patient or in the second scenario where we were modifying the heart rate those two scenarios if there's a pause even when I'm reviewing it I'm not gonna be too concerned I may catch on to it especially when I'm reviewing several instances of this over and over again that there might be something faulty with the equipment but still I have to trust what the equipment is telling me is factual so the other concern is what if my patients unconscious what if I can't go touch them and wake them up and ask them hey are you having trouble breathing does your heart feel funny are you having chest pain if that patient is unconscious or if they're intubated or worse if they're demented patient who has a known arrhythmia and they can't respond to me I have to trust again what this this equipment is telling me is true and we rely on this technology quite heavily and so what I want to suggest to you is that these small changes actually have Singh it can impact on patient care and to be able to interject these different rhythms and we only showed you two different rhythms but to be able to interject different rhythms could potentially alter the care for this patient and that could lead to not only just resource consumption at a minimum but could potentially lead to harm but you don't have to trust me there's
guidelines that actually tell us as physicians how we should treat abnormal heart rhythms so this is the American Heart Association in American College of Cardiology guideline of the management of arrhythmias and so whiling have one shown here this is management of atrial tachycardia is basically that 180 beat per minute rhythm that you saw this is only one of several dozen different management guidelines that we have we like evidence-based medicine and this is based on experts in the field who say this is the best way to treat somebody when you find an abnormal heart rhythm so the first thing that we have is we have that fictitious rhythm that's being sent intermittently and now what do I do well the next thing I do is are they hemodynamically stable that just simply means do they have a normal blood pressure if their blood pressure is low and we had affected that on the patient monitor then we go down a different arm but since we didn't touch that we're gonna stick over on the right side of the arm here so their heart rate their blood pressure is normal but they're having these abnormal rhythms so what do we do as you can see here either intervention yes or no we're gonna treat now we have documentation because as I said that central monitoring station records this information and prints it off and we can store it in the medical record so we have documentation so yes this patient has an intermittent rhythm yes we've diagnosed this abnormal rhythm now we need to treat it and so we're gonna put them on a medication to potentially fix that rhythm well I'll just want to let you know all medications have side effects especially if you're a healthy patient that don't does not need this medication and so now we have to deal with the potential adverse effects that these medications are being given to a patient that doesn't really need them and I don't want to say it's all doom and gloom
because there's actually a lot of different things that go into this but several other rhythm that we have have more serious implications and would potentially mean we need to do a intervention like send them to cardiac cath or do an electric mapping of their heart and these are invasive tests which have more potential for harm to a patient or start them on blood thinners which could potentially cause bleeding inside the brain or bleeding internally in their GI tract so there's lots of different scenarios and different interventions I'm only proposing one here which is the least harm to a patient but the good news is is this is not all doom and gloom and there's ways to mitigate this so I'm gonna turn this back over to Doug and he's gonna explain some of the ways that the industry as well as the facilities themselves can protect themselves thanks doc so as the doctor said let's talk
about some things that would make this pretty it would help mitigate this problem so we all can sleep a little bit better at night I'm going to approach this from from two perspectives and what can the vendor do of these patient monitor devices and what kind of facilities do so let's start with a vendor because that's a simple place to start and as you noticed you know it wasn't like we found some crazy zero-day or went through a whole bunch of memory corruption loops we simply looked at an unencrypted protocol that was authenticated and unauthorized and we manipulated it so I would consider that a design flaw and what we can do here is simply encourage the vendors to utilize encryption in the medical field for their communications you know we were using the broadcast address in order to find these devices on the network so there was really no validity and whether I am a patient monitor or not that's the whole point of the emulation with the Raspberry Pi so if we could get the medical vendors to implement some of this this would drastically reduce if not in some cases make it impossible for these attacks to be viable from a facilities perspective I looked at several different vendors patient monitors that are guidelines and every single vendor agrees that there are certain best practices at the hospitals and the clinical facilities should be taking to mitigate against problems one of them is isolation you know like I used the gaming system example earlier in the presentation you should never have your medical devices on the same network as the Internet because all of a sudden this simple physical potential attack is now a remote attack and I think we can all agree that that's even even larger impact so I really want to encourage you know management of hospital facilities to follow these guidelines make sure that your network is isolated make sure that you have nack controls on your access porch or you're locking the ports not making them easily accessible and and that really definitely does not make the takun possible but it definitely helps provide a lower risk let's face it to some degree hospitals are almost public places these days you don't have to do a whole lot to social engineer your way into a hospital room if you wanted to mess with this or mess with one of those workstations that are on wheels so I think if we could get the facilities to follow the guidelines and then even better couple that with the vendors adding a little bit of extra let's just call it 2018 protections I think that would really help reduce this risk a few other things to consider with our research when applying it to the real world is one we never actually modified the bedside monitor we've only modified the data on a central monitoring station also in order for this to actually have any real effect and the doc not just slap the monitor a few times you know the the information needs to be believable and the attacker has to have an understanding of how this protocol works so this isn't something that you know you're just gonna fire off and Metasploit tomorrow there is a little bit more to it than that and with that I'd like to wrap up and obviously give special thanks to dr. Sean Nordic who was willing to come up here and and present with me today I'd like to thank my coworker Charles for allowing us to make a little bit of fun with him on screen and those earlier pictures the mattress production team does a wonderful job of helping with my demos otherwise I would have been with myself own version of how to record this thing and obviously the support of the rest of my HDR team while doing this research assuming we have a few more minutes which i think we do we're willing to open the floor up to any questions anything medically related pass on to dr. Nordic and I'll be happy to answer anything as far as the protocol is concerned so the question was is can we send different variations of heart rates in the packets that were sending and so the information we captured was off of an ECG simulator so from the 30 to the 180 to even asystole with no heart rate that's all being generated by the simulator so that data was captured and easily able to be sent in in that packet the packets what's actually transmitting everything not just the heart rhythm but also will transmit the blood pressure everything that that monitor is is oxygen saturation the poles all of that information is packaged in that packet and sent across so using an advanced simulator such as the ones that we use for our medical training or advanced cardiovascular life support training where all of those variations are built in low heart rate low blood pressure fast heart rate abnormal waveforms you can send that in a packet and you could easily capture that from a simulator and have believable data sent in that packet does that answer the short version yes yeah I got two questions in the back there I was just asked trying to figure out if there was any surefire way to say if you do have a proprietary Linux box on a hot a single hospital network but the hospital has been affected by situations like this in the past if there is any advice you could give to us on how reassure hospital staff on getting us back on networks is there any medical devices that would reassure a hospital that they are preventing an attack or like visit you to be a bit more specific in our situation we have a Linux box on that was on hospital networks they were compromised and they dealt with internally part of them doing cleanup was kicking us off the network and now our system is not working at full capacity and if there is nothing you can get for this I understand it's kind of an oddball question I'm not sure I understand the question from from what I understand it sounds like you had a Linux box if it got compromised and trying to find out with with the way these monitors are set up they broadcast on a general system unfortunately that's the the vulnerability itself I don't think there's a way without assigning individual port numbers and and IP locations to prevent this and I'm not the technical guy so I'm gonna have to defer but I would presume that the reason why they at least in some hospitals that I've worked in the past these monitors get changed out sometimes they take one monitor from the ER and they leave it up in the ICU and take that monitor back downstairs of the ER so they don't ever assign them a fixed IP address that they're on this general broadcast and therefore that is a vulnerability in itself that would have to be mitigated through the network setup I mean does that answer your question okay sorry I thought he was asking what next research excellent presentation so thank you guys both thank you the one question that I had I noticed that you mentioned that you got the devices that you tested off and my immediate thought when you say that is that these are likely legacy or decomp devices so the question that I had is are these representative of the latest versions that are running in the hospitals and if so or if they're not then where are you able to do any research to identify whether these clear-text protocols are used in the latest versions first I want to thank you for asking that because I meant to mention that and totally forgot so we can answer that in two and two parts I'll let you focus I say these monitors the one that we tested is a monitor that is in play in multiple hospitals and to answer your question is the technology outdated or not no this these technology these monitors they undergo very minor changes with the new versions that get released it's unlikely that the protocol has changed I can defer that to Doug but the monitor that we tested as well as a central monitoring station both of those are actively used in multiple hospitals currently yeah when we when we purchased the devices we verified with what we didn't do like a national study to figure out how many are in use but we did take the time to verify for a couple local hospitals that these were devices that they are using on their network and doctrine or to confirm that he has seen these devices in several hospitals and as far as it being a an issue with the current devices I can't speak for sure because we didn't test any current devices but is my understanding based on a literature released online that even though the medical devices themselves have been updated the networking protocol has not changed and so if the networking protocol has not changed that would lead me to believe that you know there's no encryption nothing nothing else has been modified so thank you good question do we still have time for a couple more excellent question so the question was would based off of quality care would a position actually implementing a treatment based off of one time period basically you know one one little abnormal variation just one one blip and change one source of data so so that's an excellent question the question is would we do it on one source so just what we're getting off the central monitoring station the the answer is not likely no and the reason is is because again I can go and see the patient I can verify and I'm gonna do an EKG and this isn't going to happen however I can't say 100% no and the reason is is intermittent cardiac arrhythmias are gonna do that they're gonna be intermittent so I'm never gonna see I may never see that rhythm occur on a 12-lead EKG that I order so unfortunately if this occurs with enough variation and enough times throughout the course of that hospital stay for that patient I'm I'm gonna be more inclined to act now granted I'm a surgical resident so I'm likely to call cardiology and ask for additional inputs we may do some additional testing like stress testing to see if we can evoke these arrhythmias but there's the the likelihood is I guess the answer your question is maybe I mean there's a high potential that somebody could treat because there are guidelines that indicate that you should treat them I think it's important to mention that you know administering treatment change to a patient is the worst case scenario you know I very minimum which you're going to do is cause resection or resources right because is the doctor he's gonna order some other tests well that's gonna cost insurance more money right that's gonna cost time at the very minimum you're gonna have extra resource consumption yeah yeah the resource consumption is separate but but we have in my experience there have been instances where we see heart rhythms that are occurring intermittently enough that do warrant treatment and they would be coming from one source unfortunately in this case where the the central monitoring station on that telly box because we put the patient on telemetry anytime they have an abnormal heart rate or we put them on an anti rhythm ache medication or at all mental status that's an indication to put them on telemetry and if that telemetry is being sent back to the central monitoring station and being recorded at intervals or they're having it depends on how long those intervals are whether they're a minute two minutes and they're occurring every once a day three times a day it's going to kind of vary so there's gonna be some clinical intuition that's gonna have to be applied to this in judgment before treatments gonna be enacted last question we've time for one more sir so his question is on those training boxes can you adjust the QTc interval which is basically the part the big middle stroke and so the simulator that we bought is very basic but on advanced simulators there are ways that you can it depends on what level of money you're willing to spend but I believe urge a more advanced okay our budget was constrained we had a very small budget but there are simulators that you can adjust different aspects the PR interval the QT see you can the QT the ST changes you can you can adjust different things on different simulators okay thank you I think that's all we have time for [Applause]
Feedback