 All right. Welcome to our next talk. We've actually got a presentation here on attacking medical devices by a presenter that's so Leet he actually has it in his name. Please welcome Rob Pruve-Leet to the Turcon stage. So, yeah, talk is on attacking medical devices. My name is Rob Portfleet. I'm the director of Red Team Services at Silence. Prior to that I was in that second lead at Foundstone, Yadda Yadda. Favorite things include breaking embedded systems, I did some wireless research, and of course red teaming. So we do a fair amount of medical device assessments for both providers, that being, you know, hospitals, etc., and for medical device vendors. So I figured this would be a good topic for a talk as you know, we've done some interesting testing and we've found, you know, a number of interesting vulnerabilities over time. A lot of stuff, I guess, is what you could consider systemic, right? And we'll talk about those later in the talk, but I figured it would be good to do a talk on this to kind of, you know, get it out there that, you know, there's a lot of issues with medical devices as there are with all embedded systems, right? or most embedded systems, and you know, kind of get some of the techniques out there that we've been using to assess these, so that other folks, you know, either if you work for a provider or a vendor, or you're just doing this on your own time, that can kind of, you know, move the ball forward. Can everybody hear me? All right? Cool. All right. I've never been accused of being too quiet. So anyway, we're gonna do a quick intro to medical devices, talk a little about some of the tools that you can use for assessing them. And then we'll talk about some of the attack techniques that we use, how we, you know, basically conduct an assessment. Some of the vulnerabilities that we've found and, you know, some recommendations for, you know, for fixing that. Right. All right. So, you know, one of the interesting things about medical devices is that they take so many different forms. You know, what you consider as a medical device, most people might just think of an embedded system, but it is those and it could be everything up to, everything from, you know, what we have there, like a an implanted cardioverter, right? Small embedded device, probably uses an RTOS or similar, you know, or a medical telemetry device that's a wearable, it transmits wirelessly, right? Also, generally like an RTOS, a small embedded device. But then you have, you know, large devices like mobile x-ray systems that would use a full-featured Linux OS. Sometimes a custom Linux OS developed by the, by the vendor. All the way up to basically what you'd consider just a Windows PC or some sort of Windows PC on a cart that you'd generally see with like exercise or stress testing systems, right? Also considered, medical devices are things like web applications. Those as well as developed by, by vendors, right? So it means many different things and they take many different forms and also communicate in many different ways. So we have a lot of different interfaces, right? And this is, you know, just a change from a number of years ago where, you know, most like, for instance, infusion pumps would just have like RS-232 serial, right? And I just looked at a bunch recently that were devices, you know, in existence already that had been out for a while. And, you know, that's primarily what you saw was, you know, RS-232 serial interfaces, if anything, right? So there's not a ton of external attack service there. But over the last number of years, that's branched out significantly. And this is mostly due to a demand for functionality, right? And as, as functionality increases, so does attack service, right? So you have, you know, Ethernet, Wi-Fi, Bluetooth and Bluetooth LE, different kinds of cellular, RFID, in terms of magnetic induction, and of course, you know, ZigBee, USB, obviously, and also wireless USB we've seen. And then, of course, there is all the proprietary stuff. Proprietary wireless protocols and implementations are very common in various medical devices such as implantables, wearables, or body-worn devices, and also patient telemetry devices. We'll talk a little bit about that. So kind of the challenge there, one of the fun parts about it, though, is that there's so many different types of interfaces and protocols, technologies in use that the, you know, the attack techniques are so varied, right? You get to do a lot of different stuff on one engagement. But it also makes it challenging. So medical device connectivity, real quick. These are two of the more common protocols that you run into. HL7 is very common. It's a standard for communicating between disparate and varied medical systems. The most common versions of that you'll probably encounter are V2 and V3. V2 is very, very recognizable when you see it. All the fields are limited with different, like, pipes or carrots and various symbols. When you see it, it's very recognizable. V3 is more XML-based. Both do not have built-in encryption, where it's, I guess you could say incumbent around you to secure it in some other fashion as a vendor, right? Like wrapping it in TLS or some other protective tunnel. DICOM is a standard for storing, transmitting and storing medical images. Generally between, like, some kind of imaging device and a PAK server or PAK's database. It does have built-in encryption and other security measures. However, you don't see them implemented as much as you would hope. And we'll talk a little bit about that later as well. Okay, so medical bands as defined by the FCC. The two main ones here, we have WMTS, so Wireless Medical Telemetry Service, right? That is for devices, telemetry devices worn on the body by a patient that would transmit vitals data wirelessly. And that is in two main bands there. The second of the, VC3, the second of the two are considered what you'd consider the 1.4 gigahertz band. The other is MedRadio, and the first there, MedRadio is for body worn devices, but also implantables. The two below that are what you'd call purpose-specific bands. The medical body area networks is for implantable devices only, and the MMMs or Medical Micropower Networks are actually for wireless devices used for bringing mobility or helping to bring mobility to paralyzed limbs, and that's its specific purpose, those specific bands. These are defined by the FCC as carved out airwavespace, but the protocols, there are no standard for protocols to be used in them. That is vendor-specific, and you see all kinds of different proprietary implementations in terms of protocols. All right, so a little bit about tool sets. So, on the network side, I recommend a good portable switch with a span port, that dual-com switch, about $170. It's a little pricey for a portable switch, but I've had really good luck with it. I'd never give me any problems. This is really useful for when you want to monitor Ethernet communication between two systems, a patient monitor or an infusion pump, and the system that is sending and receiving data from, so very useful there. Software-defined radio, so as I just mentioned, you have these defined WMTS and MED radio bands, but your protocol communications in there could be anything the vendor defines, and you see all kinds of interesting stuff in there. So, in that case, your best bet is to use SDR. I use a USRP B200, and that is very effective for that. Also, if you have to deal with, for instance, GSM, that's useful as well. If you're going to use it with GSM, you also need a GPS Do clock tamer chip, which is about an additional $600 or so, because of GSM's clock sensitivity, but I digress. A good wireless card, I use the AWS 51NH, you know, whatever you like, as long as it can do monitor, mode, and injection, golden. The AVR Ravens, that's for ZigBee, so if you would counter or assessing a device that utilizes ZigBee, I recommend these devices, they work best with the Killer V framework. I would recommend two, one for doing injection, and then the other for monitoring while you're doing injection, and those sort of attacks, they're cheap. The only bummer about them is that you're going to have to flash the firmware on them. There's a couple different techniques for doing that. The cheapest one is to use an Atmel AVR Dragon, which is like $40, and a few different adapters, step up and step down adapters to make it work, but that's like the cheapest route to go, so you don't have to buy like a $170 programmer. Ubertooth 1 for Bluetooth, Bluetooth LA, awesome passive monitoring. Best tool for that, and definitely essential for doing any kind of Bluetooth work. And then I recommend a good Class 1 Bluetooth adapter. Class 1 is the strongest Bluetooth adapter class, it's usually on paper, good for 100, I believe 100 yards. In practice, maybe not quite that, but you know, you want a powerful adapter. I recommend the Sina Perani, I've been using that for years. The latest revision of it supports both Bluetooth and Bluetooth LE, so that would be what I would go with. Again, your mileage may vary. Hardware, so on the hardware side of assessment is obviously where you're going to end up spending the most money or having the most devices. Hardware tends to multiply devices like rabbits. Some sort of all-purpose bus and debug interface device. I like the Chikra, the bus pirate is also good, but I found the Chikra to be a bit better. Just as long as you can do JTAG, SPI, UR, I2C. A universal IC programmer is great, only because the number of chips that they support, if you're trying to dump the firmware or contents of a flash chip, you don't have to mess around with different tooling. The Super Pro 610 does like 30,000 different kinds of chips. It's like 600 bucks, so it's expensive, relatively speaking, but it gets the job done. A logic analyzer, the Salleye stuff is great. The Logic 16 I recommend, because it's very fast and has a big buffer space for doing captures off of, you know, like SPI and etc. You could probably get away with the Logic 4 or the Logic 8, which are cheaper. Not quite as fast, the powerful is full-featured, but all their stuff is actually really good. I also recommend some kind of dedicated or professional JTAG and serial wire debug probe like SEGAR. Only because, again, when you're doing hardware stuff and things are not working, you would like to have something that is rock-solid. So you're not doing so much guesswork. You can get the student version of this for about 60 bucks, and it's definitely good to have on hand. JTAG, you're good for one purpose only, and it's awesome at that, and that is pinning out JTAG and UART at a high rate of speed. It does an awesome job for that, so if you're trying to pin out your JTAG or UART ports when you're doing hardware assessment, awesome for that. Particularly good when, for instance, you can't do it with a multimeter because the chips in question are a ball grid array or what have you, or the real steep pitch pins, you can't reach it. A good multimeter, invaluable for pinning stuff out. If you're like me and your eyes are crap, a good bench magnifier or USB microscope, at least a bench magnifier so that you can see the hardware that you're working on. You can read chip markings, you can look at pins and hook stuff up without guessing at it or messing things up, particularly also really invaluable if you're like me and you have fat fingers. A good soldering station is awesome for attaching headers and other stuff. In the medical device space if you're assessing for providers, they may not want you soldering stuff onto it. Making hardware modifications is somewhat frowned upon for vendors less because they have stuff in the lab so they don't really care so much. But the hack out stuff is always awesome and that one I believe is like under $100. And then various jumper wires, resistor, step ups, step down, resistor kits, headers, test clips and this stuff will multiply on you really quickly. Okay, so assessing and attacking. I was looking at the time a little bit. Alright, so some testing considerations real quick. If you're assessing for a provider, that being a hospital, the device should be a test device in a lab, a dedicated test device. It should never test number one in production. Number two, it should never go back into production after it's been tested on because you've done all kinds of horrible stuff to it. It's a safety critical system. It should not be relied upon for patient safety after what horrible things you've done to it. The device when you're testing it should be configured for normal operation. That being that it has all its supporting systems. You're using a patient vitals generator or some other demo to basically generate normal traffic and operation between the device and its supporting systems. If you're assessing for a provider, they have SMEs that can help you with this stuff. Make sure everything's set up and working as it should be. Because assessing a device in a vacuum won't get you interesting things. Assessing a device communicating as normal with the rest of its ecosystem and its supporting systems will. And that's where you're going to affect value. You're going to get cool stuff. Of course all the supporting systems should be in scope. We'll talk about that in a minute. And the main focus of your testing should really be two things. Number one, anything that impacts patient safety. Anything that will affect the safety of the patient or the integrity of the data being transferred as it relates to the patient's safety. Or the availability of the device as it applies to the patient's safety. And then of course anything that exposes PHI or PII because it's going to be a big concern for any providers under HIPAA. So the confidentiality of the patient data as it's stored or transferred by the device is of course going to be a big concern. And those would be in that order. Patient safety first, PHI, PII second and then anything else would be tertiary. So kind of a really bad tree here because I'm no good at creating these things of like the attack surface how we look at it. Look at the device attack surface. I will look at the hardware attacks as part of that. So that would be the internal device surface. So external device surface, all interfaces, all ports, protocols, services or any other way that you're going to be able to get data into the device in some fashion, data that you control. Hardware attacks, that being internal stuff, debug interfaces, the ability to dump chip sets through like SPI or I2C or anything like that. Protocol reverse engineering, split into two parts, wireless stuff and wired. So wireless protocols and wired protocols. All supporting systems, this could be vendor supplied servers, workstations, monitoring systems, vendor supplied applications, both thick apps, binaries, etc. And web applications or APIs or web services, any of that stuff. So those would come off as part of supporting systems. So basically any supporting systems or applications supplied by the vendor as well. Again, this is one big ecosystem and generally when vendors provide devices, often in the case of let's just say patient monitoring, they provide almost the whole ecosystem. They'll be the patient monitors, a central monitoring workstation, a backend database and some kind of gateway there. There actually may be actually a firewall included in that to segment it from the provider network. And there's a reason for that because anything that hits these devices knocks them over. And then probably also like some sort of WMTS or wireless medical telemetry system with its wireless APs and everything feeding back into that. So the whole thing is like one ecosystem and it, you know, it helps you to really test the whole thing as such because that's what the attacker will do. So, I'm getting my time again. Okay, device discovery, right? First thing you want to do is take a look at the model number of the device, look up everything you can on it, pull down all the service documentation. There's a couple of different sites like MedWrench and Frank's Hospital Workshop that are centered around medical device repair. And they store all kinds of data sheets and info. Good place to go for that stuff. All right, so you want to find everything you can there. Every device that is sold in the U.S. that has any kind of wireless communication will have an FCC ID on it. It will be a sticker on the device. Take that number, go to FCCID.io, I believe it is, just Google FCCID, look up. And what you can do is you can look that up there. It's a, the first three to five characters will be the grantee code and the rest will be the product code. So the grantee code is actually the vendor. Every device, if you just search that, every device they've ever made will come up. If you put in the grantee code as well, or the product code, it will show that device only. What you're looking for there is, when you have a device tested by the FCC, which you must, right? They have a bunch of documentation that they will keep. It will tell you the frequencies the device transmits on, the nature of the transmissions. You get stuff like internal photos of the device, external photos, which are useful if you want to learn more about the device, but you're not allowed to take it apart. Manuals, other kind of mundane stuff, but if you're fortunate and they didn't make a request for confidentiality, the FCC, you'll get stuff like block diagrams of the circuitry, schematics, and then really good stuff like operating descriptions, which is basically their engineering docs. So you'll get really good stuff there if they were not careful. If you don't see it for the most current device, go back a little ways and see if they dropped it for something previously before they got smart and then never had it removed, because you've seen that before, too. Determine any proprietary protocols that it's utilizing and search for that stuff. Look, the vendor probably won't have a lot of doc on it, but if you go to Google Patents, there may be a fair bit of info about it there if they filed a patent on it, and you may be able to find info elsewhere. The other thing you can do is go out and look for parsing tools that have already been written that are out on GitHub or elsewhere that the medical device community has already created. So don't reinvent the wheel. So let's see what else. Obviously look for any prior volums, any prior security work that's been done around the device. Enumerate all the device interfaces, and then look for external debug functionality on the device. All devices generally have a service mode, and you can find those hard-coded credentials in those service manuals. But some will also have actual debug functionality. I've saw a patient monitor once that would actually not only give you debug output on the monitor, but it would also give you stack dumps, stack traces, memory dumps. All kinds of really cool stuff. So get an idea of what you have to work with there. And again, by the way, hard-coded credentials everywhere, everywhere, everywhere in medical devices, and you can find them exceptionally easy. One time it was kind of funny. We went and reversed the binary to get some hard-coded creds, and then we realized it was in the manual on Frank's hospital workshop. Oopsie! Yeah, that was kind of dumb. I couldn't even write that up, and the report is like us being cool because it was like the client. It's in the manual, you know? Dummy. Okay, so supporting systems. I just kind of gave you guys the spiel on this, right? They'll often come with vendor-supplied servers, and if not, they'll be vendor-supplied applications, both thick and thin, right? Look through first, go in the directory, look through the config files. It'll be a wealth of all kinds of interesting stuff in there. Sometimes just plain-text creds or encrypted creds, where the key is stored in the binary. The binaries, more often than not, are .NET. You find a lot of .NET stuff, so if you just use something like dnspy, which is my favorite, you can decompile them real quick, and it's real easy to look through. Done. Other stuff like database connection strings, all kinds of interesting stuff. And once you go through the config files, any INI files, CFG text, anything text, go through it. Then look at the binaries. If they're .NET, take them apart immediately, search for the same thing. Look for anything that says, you know, key, cert, password, username. You look, you will find. You will find lots of. You will find more than you could imagine. The other thing that's useful about reversing the server-side binaries is it's generally less resource-intensive than pulling apart firmware, especially if it's .NET stuff, so if you're going to be doing any proprietary protocol reversing, right, much easier to pull it apart on that side and way faster, right. You know, generally we only have like a week or two to do one of these devices, like a couple weeks if it's hardware. So, you know, time is important in the scope of the engagement, right. So you want to take the path that, you know, that yields the most in the least amount of time. Yeah. All right. So protocol reversing, I guess, there's every vendor in medical device world seems to have their own proprietary protocol that they like to use. There are, as I said, parsers for a number of them, up on GitHub or elsewhere, so you will find a fair bit of parsers or partial parsers that you might have to add. So you'll have some stuff you might have to add to it as you go. It may, you know, decode certain kinds of packets but not others, right. But anyway, it's a starting point, right. They're often UDP based. You see this a lot in patient monitors, right. So they're going to be unencrypted. They're UDP based on streaming protocols. It's really easy to pull apart, right. And it makes for a lot of, like, man in the middle attacks, replay attacks, things of that nature. It also makes it pretty easy to identify any PHI or PII being sent across them. So the other thing that we'll talk about in a minute is really crappy, a roll your own encryption being used in that as well. And devices identifying each other through, like, UDP broadcasts. With no, you don't see anything in the way of, like, mutual authentication between devices. So anyway, as I was saying, right, okay, so wireless protocols, right. Wireless is a bit more difficult. The first thing to do is go through the FCCID lookup process that I was talking about, right. Find out what frequency it's utilizing. You can get an idea of what it is more or less there. And then another helpful thing to do if you can take the device apart, take a look at the wireless chipset, figure out what that, look at the markings, download the data sheets, look through that. If you can pull the firmware, pull that, that'll be helpful as well in ascertaining exactly what it is that they're doing. If it's easier to pull the firmware from what it's communicating with, like, if it's a telemetry device, it's going to communicate with a wireless telemetry AP. It might be easier or like, well the device might not have a JTAG interface, the AP might, right. So check out both, which one of them is easier to pull apart because they're both going to use the same thing to communicate. Pull that one apart, save yourself time. In terms of the actual capture, identify the frequency. Use a USRP with like GQRX to ascertain where it is transmitting. If you control the input on the device, which you should, generate some transmission input so that you can identify, you can take a look at how it is transmitting. You can use a tool like Osmocom FFT to take a capture of it. Once you've captured it, you can use this tool called Spectrum. That's really awesome for this. That allows you to do a graphical analysis of the captured signal and by doing so you can identify like, what kind of keying is it using? What kind of modulation rather? Frequency shift keying, frequency shift keying, on off keying, right. That should be pretty visually obvious due to their distinctions. And then the hard part is using something like GNU Radio Companion which has a fairly steep learning curve to demodulate, decode and bring it back to binary that we can work with, right. There's a new tool out there, relatively new tool that I haven't had a chance to use yet but actually looks really cool for this. It's called Universal Radio Hacker which seems to make, it looks like its aim is to make a lot of this affair a bit easier so I'm actually looking forward to trying that on an engagement. But this is a very fun but time consuming process. Unless you're like Michael Osman then it probably takes two seconds. So hardware discovery. Carefully open the device, look for any kind of tamper prevention stuff or tamper detection. I don't really run into anything very exotic. Largely just springs, different kinds of shields that are attached to the case that if the connection is broken the device won't function. Those are really easy to bypass. You can just short between the two or you can suppress the spring or in one case we found that it wasn't a medical device, it was a cheaper device because I don't think our medical device clients would have been happy about this one but the shield didn't cover all of the case. In fact right over the flash chip I was trying to dump was no shield so I took a dremel and just cut a hole in it. But again, medical device is a little more expensive if they don't like when you do that kind of thing. Use a bench magnifier or your phone camera works good for this stuff too. Figure out, look at the chip markings, write them down. Write down the markings and look up all the data sheets for each chip particularly like the microcontroller, the wireless sock or chipset, any flash chips, SPI, flash, nor NAND flash, whatever, any kind of memory chip you want that as well, those are the most important areas of it. Look at those data sheets and then see what they support. What kind of bus protocols they support, SPI, I2C, does the microcontroller support different kind of debug interfaces, JTAG, UR, background debug mode, serial wire debug, right? And then look at the board and look for debug interfaces, right? So look for any kind of again JTAG, UR, etc., any test points, any pins, headers that are already in place, pads, etc., right? So that's what we want to look for. This is just some of the stuff that you get out of data sheets, right? The one on the left, I think, is a free scale. The one in the middle there is ATML, MCU, and you can just see there the different JTAG pins, TMS, TDI, TDO, and that the free scale is where you will usually see background debug mode is in free scale processors. But anyway, this is the stuff that you'll get out of the data sheets. Different debug interfaces, right? JTAG has five pins, sometimes six, test data in, test data out, test mode select, test clock and ground, sometimes test reset. Serial wire debug actually will generally ride on top of that interface. So on your 20-pin standard ARM JTAG here, you can see that the three serial wire debug pins actually dual purpose with some of the JTAG pins. And then UR, it's just three pins, transmit, receive and ground. Connecting the UR, you can do this with a Shikra, a bus pirate, any FTDI friend or any kind of FTDI adapter. Three pins, any serial terminal will do. So mini-com, screen, what have you. All you have to do is specify the device and the speed. So things you'll get out of UR, right? Depending on how the vendor is done, their implementation or what they're sending out of it rather, it can give you a full root shell. It can give you like a less privileged shell, like some kind of manufactured menu type shell or an escape or like the boot loader to get yourself more privileged access. Or just shooting debug output, which is very common. It'll send debug output, which is actually really useful because on startup, when the device starts up, it'll give you the full hardware list of everything, where everything's mounted and everything else, all the addresses. So that's actually really valuable. It's also really good, like when you're working with JTAG and you have like, you're using open OCD and you're trying to set a reset or whatever, you can watch the output to make sure the device is actually bouncing when you expect it to, or freezing when you reset. Sorry, I want to get to the, while I'm watching my time here. I tend to be a little overly verbose. All right, so some of the ways that you can dump firmware, right? Dumping flash over SPI. This is a SPI flash, a wind bond chip. It's what you'd call an 8-pin SOIC. Here, this we can use as a chicro or a bus pirate, right? We hook up the Masi MISO S-Clock slave selecting ground pins, and then we can use a tool called FlashROM. FlashROM is a great open source tool for dumping or programming flash chips. As long as the chip in question is supported by FlashROM, you can dump it out to a file and then use a tool like BinWalk to pull it apart. And that'll pull out all the different sections of the file, hopefully, and then you'll have a little additional reversing that you can do from there. Another way to do this is dumping flash via JTAG. This is kind of a weird way we did it here, but it was cool. We used the JLink probe. We found that it had a JTAG interface. And what we used was Seger provides a free toolkit. You can download from their site. Part of that is the JFlash tool. And the JFlash tool will let you write or read to any internal or externally supported flash that it supports. And that's what we did here, was we used that to dump out the contents of this SD micro flash. If you see here, this is actually a, at least it's a NOR flash. It's not an SPI-enabled flash. It doesn't just use one pin for transmitting and receiving data over the bus. It uses multiple and they're quite fast. So the technique we used previously in this case, using JTAG here, we were able to dump the contents of that flash chip. All right, cool. We've got about 16 minutes. All right, cool. So, Volens, yeah. All right. So some of the, this is some of the stuff that we found on engagements, not naming any vendors or any particular devices. The purpose here is not to name and shame. These were all found on, engagements for providers, not for vendors themselves. And at any rate, so a lot of unauthenticated interfaces, okay. Lack of mutual authentication, no message integrity protection, lack of replay protection. So this is all protocol related stuff as well as remote denial of service. We found that you can knock devices over with a stiff breeze. Either unencrypted protocols or really weak encryption schemes and a lot of hard-coded credentials and keys. And what I'm going to do here is give you an example of quite a few of these, not just read this slide. So, I talked earlier about DICOM. All right. So DICOM is used for transferring images between an imaging device and a backend database server like a PAC server, right, which is a picture archiving and communications server, I believe. Medical World loves their long, really long acronyms. So anyway, part of what DICOM has is a DICOM service. Consider this kind of like a SCP or an FTP, if you will, right? It's an interface that allows you to, that's actually probably a bad analogy, but it's an interface that allows you to query the database and it is not necessarily authenticated. Generally, all you require is an AET, an application entity title. So this is a specific, think of it like an SNMP community name. If you know this word or this string, you can connect up and access and make queries against the database and all you need to know is what you're querying for. Again, as I said, DICOM does have security profiles. They are not often implemented and vendors will publish what they call a DICOM conformance statement. Basically, what it shows is it's devices, what DICOM features, it's their device supports and it's published and there's no probability between that device and other devices that speak DICOM, right? But it will tell you the list of their default AET titles, all right? It'll have a big list of those. It'll tell what classes are supported, if it supports any security profiles and in the case of one vendor, it's specifically that we do not support any, I'm paraphrasing, we don't support any DICOM security profiles. It is up to the provider to place the device and basically, it's not our problem. So, what we're able to do there was we found the open DICOM QRSCP port. We used PyNet DICOM to connect to it, which is a Python library for communicating over DICOM over the network and then there's also PyDICOM for viewing what you've gotten, what you've retrieved. We went and downloaded one of the top 1,000 most common surnames or last names, right? Then we basically ran those through a for loop and dumped thousands and thousands of records out of the database by doing that. Because as long as you know what you're querying for, you can pull it out, right? So, we just queried for all common last names and pulled out thousands and thousands of records, of patient records out of the database. Proprietary protocol manipulation. So, as I said, it was a simple UDP-based protocol. What we did was we generated known values on the patient monitor and watched it communicate with the central monitoring system. We modified those values and observed it again, identified how it was encoding them and where they were in the data packets. And then we just wrote a simple Ettercap filter to modify those. So, for instance, you know, you'd change 80 to 31337 to have them. And we were able to reliably change every value that was displayed on the central monitoring work station from these patient monitors. The result of it, of course, being that we could, you know, make the nurse who is watching the central monitoring station think whatever we thought about, you know, show regular normal values while we're, you know, killing the patient or the patient at that point. The other thing we found in that same protocol and in others, other vendors was that device impersonation was possible. And what we found was that in the one case, the devices would use, the patient monitors would, or they would, and the central monitoring station would send out a UDP broadcast saying, here I am, you know, as anybody out there. Response, the device will talk to you and it will actually respond to you with a, if you spoof the central monitoring system, it will respond to you with the patient data packet containing all the patient's information before it will start sending you the vitals data, right? This is encrypted very poorly and we'll talk about this in a second, but basically it's a very simple key where we were able to do is decrypt it by just reverse engineering. We reverse engineered the binaries on the central monitoring workstation to identify how the protocol worked and those actually shipped with debugging symbols, so that was really much easier and then to get the key, because we were lazy, there was a HL7 gateway system that had .NET binaries on it that had the key for this as well that array that we'll talk about in a minute. So we were able to pull that out of there. So both ways worked, but the end result was we were able to become a device, a trusted device and have the patient data sent to us. So remote dial-up service. This is like kind of goes without saying. A lot of the devices that we've assessed will fall over from a stiff breeze. You don't have to do any kind of elaborate fuzzing. They will end map them. They will fall over, which is, by the way, in terms of port or vulnerability scanning medical devices in a live clinical environment, I strongly advise against it. When we do pen tests for providers, network pen tests, I always ask them, what segments are your medical devices on? Because we don't want to do any scanning on there because they don't like it. They don't handle it well. They would fall over immediately and reboot constantly. That was actually the one that had the debug functionality on the monitor that I was talking about. And I thought that it would be so awesome to debug this thing out and find out if we get remote code execution, but we couldn't get it to not reboot as soon as we sent the thing to it. So another WMT-MTS system, you could just hold it offline by catting DevView random into Netcat and sending it to an open UDP port. I could hold it offline indefinitely. And then we found a null-poner dereference in a stress testing system. It was actually in a another QRSCP DICOM port. It was a third-party DICOM library and we found that if we sent it to the patient monitor, it would fall offline for a certain amount of time. And then we found a null-poner dereference in a stress testing system. It was actually in another QRSCP DICOM port. It was a third-party DICOM library and we sent this particular string here. I think it's actually the first couple of bytes of that that really do it. I think it opens some logic tree in there and it wants to accept data and then falls. It was a third-party DICOM library. We downloaded the trial, the SDK version of the DICOM library and, you know, reed it and debug this because this was actually in like a Windows-based system. And we found it to be a null-poner dereference. We didn't, in the time, allotted to us. We got a RCA or, you know, actually be able to control or structure, move the input where we want it to be. But we were able to reliably kill the device. All right. So crypto. Weak crypto, weird crypto or home-rolled crypto schemes are really common. What we find is that instead of using standard crypto implementations, multiple vendors are just doing all kinds of weird stuff. One I just talked about with the patient info packet when we were doing device impersonation, right? Basically, there's a 256-byte array on the sending and receiving system, right? I can't do that. Okay. On the sending and receiving system and then the decimal value of each byte in the packet. So that decimal value is the offset and the array to look for the unencrypted value and that's really all it is. So it's just a simple key key look at this point in this number and retrieve. And then there was a bit of byte reordering that you can see there as well. But that was the sum total of the encryption being used. This one's even better. So this one was being used to encrypt credentials stored in a config file. Those credentials actually granted admin access to a database server with all kinds of PHI and PII on it. So for each ASCII character that made up the encrypted value, picture an ASCII table. So you have the ASCII value and you have its corresponding decimal value. So ASCII value, decimal value. If the decimal value is less than 31, add 224 to it. If it's greater than 251, subtract 224 from it. So you're moving through the array. And then if the decimal value of the ASCII value is, trying to remember, if it was even decrement it by four, if it's odd add four and then you have the value. So that's it. And that is a hard coded system if you will on all of those devices. So basically once you know it you can do it with a pencil and paper. Which would then allow you to walk into, you know, any hospital in the world that has that particular device and know and be able to decrypt those stored credentials that will then grant you access not to the system that they're on but to the back end database system that has that and way other interesting stuff on it. Much more interesting stuff. I can talk. Plaintext protocols, this kind of goes without saying you got stuff all over the place XML based HTTP or plaintext HTTP also slip, which is the first time I'd seen slip in many, many years. If you guys remember slip the predecessor to PPP you were going back a ways. Also, I guess it should be mentioned that the, what you find quite often with the vendor supplied service is that they're also vulnerable like LLM and RMB TNS poisoning. So you can pull crads off the network by using those techniques. So another interesting thing here was we had a thick client from a vendor that communicated with a pack server, back end pack servers. This was like a thick client. It would switch to, when you put in your credentials to authenticate, it would switch to HTTPS. That's great, right? Unfortunately, immediately afterwards it would switch to HTTP. Back and forth, back and forth. It's going out each time in plaintext, right? So what's the freaking point? The other interesting thing about that session cookie is we couldn't kill that thing. We logged out properly. We stole it, we'll log in, yay. We logged out properly, still worked. We tried it a month later at the end of the engagement just for giggles, because the client's like, they still think it still works? Yep, still worked. After the server bounce. That would have been something. So anyway, the case of the cookie it wouldn't die. All right, so these last two are not medical devices. It's a full disclosure. I just want to throw these in because they're kind of cool examples of what hard coding stuff will get you. This was on a network pen test like two years ago. I was doing a pen test. It was an open network share. I found a bunch of these XML files and it was clearly encrypted credentials. You had the username and then you had encrypted password value and you had the domain name. And there was like 30 of these. And I'm like, man, that is interesting. So based on the name of the file I Googled it and I found what software it was. Pulled down the trial version of the software, reversed the software, lightly obfuscated hard coded key and we found it was using triple DES to do the encryption. Extracted the key, wrote some code to decrypt them and actually giving credit where credit is due, my colleague Brian Wallace worked with this on me. Anyway, decrypted the credentials. We got a bunch of sets of credentials. Not all of them were still good but one of them was a DA account. Not only was it a DA account, it was a DA account that never expired. There are other DA accounts required you to log in from specific systems, although you could just move the host name and get around that. This one didn't require that. They were surprised about that one. That's hard coding your crypto key, not a good idea. Another example of what hard coded creds will get you. This was a telematics device I assessed about a year ago and it communicated over 3G over GSM. It used a bus pirate and flash ROM to dump the wind bond SPI flash. It was a SOIC flash 8 pin. Dump that out. Used bin walk to extract it and there's an XML file in it again. XML files for the wind. So I noticed that in there there was a set of credentials, there was an FTP server IP address and then there was an APN name. Now an APN name, an access point name I was unfamiliar up to that point of what that was exactly but it is a gateway between a cellular network and an other computer network. Commonly the internet in this case it was the gateway we found basically what we did was we used WV dial in a wireless card we hooked up we put in the APN name and we found that this was a gateway between the cell providers network and the vendors privately addressed RFC 1918 private network. So now we're in there on their private network and there's a whole mess of systems in there and we have credentials for the FTP server. Go to the FTP server. Log in in it is all the versions of software for that particular, for that device and there was config files in there with a whole mess of creds for other servers, other databases, everything else. Now we were assessing this for third party so we didn't go any further from there because I didn't want to get in trouble but that server was the server that the device is and this is a live device in the field so this wasn't the only one it was the server that it used for it's over the year update so and the firmware wasn't signed either so we could have replaced any of the firmware on that server every one of those devices would have now pulled our firmware installed it and we would have backdoor on every one of these devices so that's what hard coding stuff in your flash chips gets you. Alright I'm almost on time here's some quick recommendations some recommendations for providers so for hospitals, right? Firstly, inventory your medical devices and assess their attack surface know what you have and know what they're speaking over what their interfaces are I found that a lot of providers they ask just to come in to help them identify what the inventory of their devices are they don't even know what they have let alone what their exposure is disable any unaided functionality if you're not using the wireless or anything with any other interfaces segregate medical devices from the general clinical network or the general hospital network as much as possible disable any unused ports that would allow physical ports ethernet ports that will allow access to those networks a hospital is pretty much a public area you can't really it's pretty difficult to keep people from being in a patient room and connecting into something unless the ports disabled you're finding from your assessments either internally or from third party to the device vendors and if you are a larger organization or even not put pressure on those vendors politely to remediate this stuff because enough of that will make a difference recommendations for vendors assume that attackers will buy your device off eBay or wherever and reverse engineer it a lot of them I think take the tact that oh well these are attacks in a hospital they'd have to be on the network how long would it take them to attack the hardware of that in a room in a hospital they're going to do like that they're going to take it home they're going to buy it they're going to take their time learn the vulnerabilities devise their attacks and create something that can be done in short order like plugging in a USB or an SD card that your device uses for its firmware update and then backdoor the firmware and use a TPM a trusted platform module to do key storage store your keys securely and use standard crypto algorithms do not roll your own cryptography is not easy don't run your applications on the service side under admin or root privileges run them on the obviously this is best security practice stuff mutual authentication between devices have devices I'd ascertain that each other are who they think they are mutual auth is critical in that sort of ecosystem and finally as we've seen don't encrypt credentials hash them or use the built in auth mechanisms and that's all I got so questions questions yeah go ahead honestly no so most of the stuff that we've done we either do it for vendors or we do it for providers in the case of providers it is the providers is basically up to their prerogative as to if they want to report it what they want to do we can't circumvent that process but the short answer really is no I have not yes neither built in diecom actually does have built in I think diecom has the built in ability to use TLS and it does not but can be in the implementation can be wrapped in like a TLS tunnel or use ipsec to wrap it or some other tunnel to carry it through in the case the difference there is that diecom it's actually built into the standard itself and I believe it specifies the ability it has the ability to use TLS so it's built in as a security profile but I don't often see that implemented sadly generally it seems like the vendors leave it up to the provider that the hospital to actually install all components so you're thinking about not just the back end server doing the communications but the device itself that's the imaging device sending images over diecom to it would both need to be in a secure network and etc so HIPAA I'm not an expert on HIPAA I'm more of yeah thank you sir yeah I'm more of a hands on guy than a policy guy as anybody I work with will tell you but yeah it wasn't to my knowledge either yeah so I have things medical devices coming out got an iPad doctors want to use it ER security related to those devices and the medical use of those in the clinical environment yeah I'm thinking on that one then you know I mean you have to look at the device itself and then the rest of the ecosystem right I think that you need to limit you know the what those devices are able to do just off the top of my head right you know try to lock them down as much as possible so that you don't have you know the same problem that you have with ICS systems like HVAC right where you know the maintenance guys are surfing bad places on the machine that the HMI machine for the HVAC system right and then you wonder why they're full of all kinds of interesting stuff so the same thing right you don't want them if it's an iPad for instance use to interface with one of these systems on the internet on it do other functions right you want to lock that down as much as possible right you know yeah I would you know honestly if you think about it probably the security model of the iPad is probably a fair bit ahead of that of most medical devices right or other yeah so yeah it's a strange world we live in back there oh time oh so in terms of the actual actually vendors that have their own Linux OS I could say one like GE has Helio OS which is a I guess you could say a fork of scientific Linux that would be one example you see a lot of like Windows XP embedded Windows CA you know other Linux variants it's basically all over the place because like such a wide disparate ecosystem of devices right and then you have like the RTOS but yeah it varies quite a bit yeah you see U-Boot a lot yeah I mean so you see stuff like U-Boot and Busy Box and you know everything that you know a lot of the stuff that you'd see you know just in I mean there's not a huge leap between that and the rest of the you know IoT embedded device world right it's really just more the purpose that it's put to and some other considerations all right guys I think I have to get out of here before I get booted off the stage so thank you