 and with that I'm going to hand it over to Douglas McKee. Douglas. Thank you. Just want to 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's Douglas McKee. I'm a security researcher on McAfee's 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 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 going to hand it over to Dr. Doug. 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 and I have no financial disclosures. So with that out of the way kind of give you over what we're going to do. I'm going to provide you a little bit of background of the device on why we chose it as well as how it's used in the actual medical setting. Then I'm going to turn the talk over to Doug who's going to 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 going to 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 going to wrap it up with Doug covering mitigation on how the different vendors as well as the facilities themselves can mitigate potential attacks. So when we're considering what to investigate when we're doing our research we wanted to make sure that it was going to 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 impacts? And so came back to the fundamental and that is vital signs. And vital signs form the foundation of every medical decision and 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 pressure 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 Tully when he states that we trust these devices implicitly to provide us accurate information. Furthermore we don't receive any training in medical school or in our literature explaining the potential threats that exist 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 that's of these big boxes that you see at the top of the screen here. They're going to 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 or they need to go to the OR 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 offsite in the ER and intensive care unit. It usually sits at a nursing station and what it does is receives all this input. For floor patients, it usually sits in a specific room called a 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 XP or some of the newer devices run Windows 7 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 too 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 going to 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, it was time to start looking at what do we want to do to attack them. And as Sean 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 factors that we have. If we look at the central monitoring station, it's very quick, easy to see that there's the OS in the application. Well as Sean enumerated, a lot of these OSes 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 from 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 that 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 the device apart, pull off the firmware, 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 you get to that level on a device that you're going to destroy the device and we wanted to be able to do more research, at least 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 are 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 affect what Dr. Nordic sees on a regular basis because as he said he's making decisions in real time on this data. So that really became the thesis statement for 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 R 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 RFCs, 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 two devices. So we took the patient monitor and the central monitoring station and 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 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 in a lot of research you know you build a fuzzer or whatever the normal input is well for us that's a patient. So I did what any responsible researcher would do and I found myself a patient. And so I had a coworker and I said come here for a second I wanted to test something on you. And so we hooked my buddy up here to the patient monitor. I was like okay great now I'm going to have user input to see how the 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 to test your equipment. You can use a device they make which is called an ECG simulator. It's a little box that you hook your plugs up to and you don't have to have this. So did I mention I'm not a doctor? So we decided to improve our testing set up for some more reliable testing and we bought this ECG simulator which was less than $100 on eBang. We hooked it up and this became our very simplistic test network. And I want to point out here that for 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, O2 levels, et cetera can also be affected by what the rest of the research but we will be focusing on the heartbeat because it was the cheapest thing to emulate 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 was I powered down the patient monitor, powered down the ECG simulator and I only looked at the central monitoring station. And I powered it up and 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 and 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 and I've 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 IDAPRO and the decompilers and the vendor we want to thank you for leaving all the debugging symbols and the names in the binaries that was extremely helpful. So with a little help of all that this is the wild loop 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 R what that's the protocol being broadcast out. And then towards the bottom here you see something called the get R what period function and 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 that returns that integer and depending on what the integer 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 with 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 to power off the central monitoring system and to power on the patient monitor so that we only 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 notice that the destination port is the same however the source port increments by one every single time that one of these packets is broadcast across the network. Also if you stare at Hex long enough for these packets you'll notice that at 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 each packet is sent. And then of course you can see clearly here in plain text 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 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 wanted 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 be received 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 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 symbol is called parse logical name. You'll see the second parameter is 20 and hex is 32 bytes. This tells us that there's 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 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 was 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 low and behold hey look we have a heartbeat going across the network. It works as intended we now have a fully functioning live system. That by the way makes a whole lot of noise and your coworkers 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 first glance you can see that we have a bunch of packets being sent of approximately the same size and these signify the data packets or the heartbeat going across the network. So now I threw a lot of information at you so let me take 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 have to 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 that's a simple replay attack. So that's exactly what I started to do and I'm personally a big fan of Python's escape module so I do a lot of my networking research in escape and so I took just a little bit of time and coded up a simple escape script that would read in the packets from a wire short caster, 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 other of those programs. So that what told me was that I really needed to take an extra minute and really understand what was going across. I wasn't going to get the easy way out on this plus it wasn't doing what I wanted it to do anyway. So we took a deeper dive into these packets. Now when I'm about to explain to you, I understand we're working with the UDP protocol and I'm not telling anybody that this is doing a CCP 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 going to call that the SIN packet so that's the first packet that goes across. The next we see the patient monitor respond and I'm going to refer to that as a SIN act packet. The most important thing to notice with this packet here is that it responds as the source port from the SIN packet. And if we continue to follow this communication, we now have the central monitoring station that responds with what I'm going to refer to as the act packet to the central monitoring station excuse me on port 2000. At this point our hypothetical TCP handshake is complete and where she'd start to see data. Well the first thing that we see from the patient monitor is a packet that essentially is asking what port do we want to use to spend our data packets through. And what we do, we see is a response from the central monitoring station say hey use this packet 3627 because that's the source packet of the previous packet. So and then we follow it up and say that we see the 639 length packets that are the data packets or the heartbeat. So with this understanding it's really easy to update our scabie script from before because it's very obvious that it wasn't working because 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 decided to look at the packets a little bit more intently. And so I'm going to go back for just a moment and take a look at what I referred to as the sin act packet. So this is this packet here that goes across the network from the main 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 sin act 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 what was going on and the reason it didn't work for me the first time was I wasn't resending 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 there'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 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. And as I said before, now that I found this counter that I was missing before, I update my escapee 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 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 and the correct counters and then we should be able to send captured heartbeat packets on the wire. And this should emulate that. As I said, the thesis statement of our research, it was an 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 video's work, is a demo of this emulation. So what we have here on screen, this is the central monitoring station and you notice there's no patient monitors on the network. And what I've done is I've loaded my emulation scripts onto a 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, okay great, thanks for the data. 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 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 the protocol in the process. But there are also a few attack scenarios here that are just the least worth mentioning. If I was to walk into a hospital with 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 and the patient would receive the same data over and over and over again and let's say that the patient is 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 is going to be notified. They're not going to go off, the data is not going to make it there. Or if we want to get a little bit more Hollywood on it, what if you wanted to kidnap a patient or kill a patient? These are a little far from the Raspberry Pi idea. Well I had a co-worker that was recently in the hospital who noticed that the gaming system in the kids area was dual networked on the internet and the medical network. So now this gives me a remote attack vector that I can load my scripts onto and now the gaming system can become a patient monitor and it can transpire down from there. And if you don't like that scenario, I don't know if you've ever been able to go all over the place and they're not exactly monitored. So once again, there's lots of ways to get this code and to be able to potentially cause havoc in a hospital. So I showed this to Dr. Norik 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 that's what we did. We had to do a lot more than emulating emulation. Emulation, we had to count for all this crazy stuff in the handshake. Well, the handshake's 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 way to do that, I think most people can agree, would be an ARPS booth attack. I'm sure there's other ways we can accomplish something 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 as just a starting point. The doctor said that's a normal heartbeat and my simulator used 80. But anyway, so we have this going across the network. And then we start to do our ARPS booth and wire sharks kind enough to tell us there's a duplicate MAC address on the network. Thank you. And that's our Cali box. And then we send packets now from 153.153. 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 in the payload. So that means that I don't have to actually spoof much of anything because I can 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 two 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 the central monitoring station, I'm sorry, is sitting right next to it. So we go ahead on the 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 monitor, 80 beats per second. I'll also take a brief moment to point out you may have noticed there was the delay in loading information on the screen. I also noticed that delay in the Raspberry Pi information. 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 ARPS boofing, capture the ports I need and send the packets I want to send to the central monitoring station. Well, and my coworkers like to show that I've now killed the patient. And you can see I zoom out here so you can see that it's still the same. Thank you. There's a red rim going around that's the alarms and you see it says saving. Dr. Norak 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. Norak will speak on why that's important. So that was a fun scenario and people joke 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 Dr. Norak and he was giving me 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 them not the flat line of the patient but just to change their heartbeat. I'm going to change it twice in a very short amount of time. Notice the time of 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 is supposed to say 80 beats per minute. Now what I'm going to do is I'm going to let that patient recover a little bit. I'm going to let it go back to 80 beats per minute. And now it's back at 80 beats per minute. And now I'm going to start sending it a heartbeat fast. That's also alarming. I'm now going to send it 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 sudden done I'm going to make sure the patient goes back to their original state because we don't like to 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 going to turn the presentation over to Dr. Norik and he can explain how this impacts him on his everyday life. Dr. Thank you. So as you were able to just see, we were able to kind of inject any type of rhythm we want. And while the acystole or the flat line rhythm is quite dramatic and is great for Hollywood, to have a patient become acystolic 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 quite frankly quite alive. So the concern becomes is with those intermittent cardiac rhythms though when the heart rate drops too 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 going to happen is that the patient is going to check or the nurse who's monitoring that is going to page me and let me know hey Dr. Nordic, this patient's heart rate is 180. What can we do? And so the thing I'm going to do is obviously say all right, go check on the patient, what's their blood pressure, I'm going to 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 going to be discongruent. So I'm going to go back and I'm going to ask for anything that's 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 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 too. You saw some pauses so when you're a student 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 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 dressed, it doesn't cause any concern so the first scenario where we emulate data and we can abscond a patient or in the second scenario where we're modifying the heart rate, those two scenarios if there's a pause even when I'm reviewing it, I'm not going to 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 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 significant impact on patient care. If that patient is unconscious or if they're intubated or worse, if they're demented patient who hasn't known arrhythmia and they can't respond to me, I have to trust again what 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 we have significant 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 rhythm as a cardiology's guideline of the management of arrhythmias and so while we have one shown here, this is management of atrial tachycardias 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 abnormal heart rhythm so the first thing that we have is an ambitious 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 hit effect on the patient monitor, then we go down a different arm but since we didn't touch that, we're going to stick over on the right side of the arm here so their blood pressure is normal but they're having these abnormal rhythms so what do we do? Before no, we're going to 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 going to put them on a medication to potentially fix that rhythm. Well, I'll just like I want to let you know all medications have these effects especially if you're a healthy patient that 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 rhythms that we have have more serious implications and would potentially mean we need to do a path 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 this is not all doom and gloom and there's ways to make this so I'm going to turn this back over to Doug and he's going to 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 help mitigate this problem so we all can sleep a little bit better at night. I'm going to approach this from two perspectives and what can the vendor do of these patient monitor devices and what can the facilities do? So let's start with the 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 unauthenticated 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 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, guidelines and every single vendor 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 management facilities to follow these guidelines make sure that your network is isolated make sure that you have NAC controls on your access ports or you're locking the ports not making them easily accessible and that really definitely does not make the attack impossible 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 work social engineer your way into a hospital room if you wanted to mess up your hospitals. 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 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 only modified the data on the central monitoring station. Also in order for this to actually have a lock not to just slap the monitor a few times you know 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 going to fire off a medicine 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 present with me today. I like to thank my coworker Charles for allowing us to make a little bit of fun about the McAfee production team did a wonderful job helping me with my demos otherwise I would have been with my cell phone version of how to record this thing and obviously the support of the rest of my ATR 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 we'll pass on to Dr. Nordic and I'll be happy to answer anything as far as the protocol is concerned. You can if you want to. So the question was what are the heart rates in the packets that we're sending and so the information that we captured was off of an ECG simulator so from the 30 to the 180 to even acistically 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 packet is what's actually transmitting everything not just the heart rhythm but also will transmit the blood pressure everything that that monitor pulse 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 question short version yes 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 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 the situation 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 clean up bullets kicking us off the network and now our system is not working at full capacity and if there is nothing you can give for this I understand it's kind of an odd ball question I'm not sure I understand the question from what I'm understanding it sounds like you had a Linux box that got compromised and trying to find out with the way these monitors are set up they broadcast on a general system unfortunately that's the vulnerability itself I don't think there is a way without assigning individual port numbers and ID locations to prevent this and I'm not a technical guy so I'm going to 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 to the ER so they don't ever assign them a fixed IP address they're on this general broadcast and therefore that is a vulnerability in itself that would have to be mitigated through the network setup does that answer your question? yes that answers it very good sorry I thought he was asking something else excellent presentation so thank you guys both the one question that I had I noticed that you mentioned that you got the devices from eBay and my immediate thought when you say that is that these are likely legacy or decom 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 were 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 we can answer that in two parts I'll let you follow up in a second honestly 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 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 verify we didn't do like a national study to figure out how many are in use but we did take the time to verify of a couple local hospitals that these were devices that they are using on their network and Dr. Norder confirmed that he has seen these devices in several hospitals and as far as it being 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 the 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 there's no encryption nothing nothing else has been modified so good question do we still have time for a couple more go ahead excellent question so the question was based off of quality care would a physician actually 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 answer is not likely no and the reason is because again I can go and see the patient I can verify and I'm going to 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 going to do that they're going to be intermittent so I'm never going to 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 going to 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 likelihood is I guess the answer to your question is maybe I mean there's the 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 you know at a very minimum what you're going to do is cause extra resources right because the doctor is going to order some other tests well that's going to cost insurance more money right that's going to cost time at the very minimum you're going to have extra resource consumption yeah the resource consumption is separate 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 central monitoring station on that telebox because we put the patient on telemetry anytime they have an abnormal heart rate or we put them on an antirhythmic medication or an altered medical 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 where 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 is going to kind of vary so there's going to be some clinical intuition that's going to have to be applied to this and judgment before a treatment is going to be enacted last question we have 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 we're more advanced our budget was constrained we had a very small budget but there are simulators that you can adjust different aspects the PR interval the QTC the QT the ST changes you can adjust different things on different simulators okay thank you I think that's all we have time for