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.  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?  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.  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.  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.  Not all of them were still good but one of them was a DA account.  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


Hello everyone. I once again welcome you all to the MSP lecture series on Transmittal Chemistry. Now, since couple of last lectures we have been discussing about the oxidative addition and reductive elimination reactions. Let me continue from where I had stopped in my previous lecture. So I showed you how CH bond can be activated and how CC bond can be activated and what are the difficulties we come across. Now let us look into another important method of addition of substrate molecules. That means here we are considering polar molecules. When we consider polar molecules having an electronegative atom, how it follows a pathway that is different from the neutral molecules we considered. So neutral molecules I showed you CH I showed you H2 and even SIH bond addition and similarly one can also think of BH and all those things. Now let us look into the second mechanism that is followed by polar molecules that is called nucleophilic oxidative addition. So at the end of this one you will be knowing why we call this one as nucleophilic oxidative addition. So here if you see I have considering a square planar complex and now Rx is brought, Rx bond is polarised. When it is polarised what we have is R plus and X minus and addition of Rx to the square planar complex is a slow step and also this is a rate determining step here. So in this what would happen is now once bond is polarised, so the electron it moves and it becomes X minus, X minus it becomes and then it becomes X plus. When it is X plus it attacks here we have this dz square with two electrons. Now this attacks this one and then this generates a five coordinated species and now you can see here we have positive charge. We have a orbital with MT because the electrons are already given from metal to these two. To generate now you can see this is an anionic ligand, this is also an anionic ligand. So oxidation is halfway through. So now basically what happens this one attacks this position here and then the reaction is completed in the next step. This is fast. So that means this nucleophile is attacking here because of this one it is called nucleophilic oxidative addition reaction. So this is the path followed by most of the polar substrate molecules. So how to assess this reaction? For example, what are the factors that contribute to the rate of this reaction? So electron releasing ligands that means electron rich metals which are in a position to readily lose a couple of electrons that means metal should be more nucleophilic in order to make it more nucleophilic. So polar solvents if you use that increases the rate because polarizer transition state is there and inversion is observed carbon. These three things are important. So electron rich metal that is to in case of previous concerted addition also and then polar solvents should be used and then if you take a chiral molecule inversion is observed carbon. You can see from this one we are taking chiral compound here and you should focus here and now since it is added in a trans one so this is how the addition takes place here. So as a result what happens the configuration is changed. So that means inversion happens if any substrate molecule is added which is chiral in nature what happens in the oxidatively added product inversion can be observed. So now the third one radical pathways. Radical pathways is always followed by metals where we have odd electron systems such as cobalt 2 D7 system or manganese 0 D7 system exclusively follow radical pathway mechanism. It does not mean that other electronic configurations having even number of electrons do not follow it is not like that even a D8 system can also follow sometime radical pathways. So that means only thing is we should assess to know whether a radical pathway is followed or a concerted method is followed or nuclear philic oxidative addition method is followed. Of course distinguishing between concerted addition and nuclear philic addition would be very easy because the moment we look into substrate molecule we can tell whether it is a polar molecule or non-polar molecule if it is polar yes it is it follows nucleophilic oxidative addition if it is non-polar it follows concerted method. So that means between radical and nucleophilic addition we have to follow certain tests that means if the reaction shows ambiguity about the pathway that is followed we have to do this following experiments what we have to see is we have to see whether the rate increases with initiators such as peroxides oxygen or light and in case if we add radical scavengers then the rate should decrease and of course if the reaction follows radical pathway we can exclusively see resimization of stereochemistry at chiral carbon center if we consider any chiral carbon substrate then there will be resimization. So these three would tell us about the path followed by a particular polar molecule. So then what are the steps that are involved in a typical radical process let us look into it initially we have to use an initiator I write INIT and then this interacts with of course if I consider iridium D8 system to begin with we have a plus 1 species in the next step it interacts with substrate molecule Rx and generates a radical and this radical reacts with iridium 2 2 species 3 species and now it is still it is radical is coming 2 species and now iridium 2 species further reacts with another molecule to have plus so it continues. So these are the few steps that are followed and they are very similar to a typical radical reaction we come across in stereochemistry when R is tertiary or secondary but not for primary so you should remember this radical pathway is favored for R a tertiary carbon R secondary carbon but not for a primary carbon that means if we have CH3CH2PH. Now let us look into the reductive elimination so far we discussed about oxidative addition and two type of oxidative addition we saw now let us look into the reductive elimination so this is a typical reductive elimination process to begin with we have n plus 2 state is there and 6 coordination is there and it may be 18 electron species now after reductive elimination what happens so slowly there will be bond will be established these two entities are brought close to each other they start interacting and a bond is established and then eventually this will be eliminated and then now it gains 2 electrons and also it loses 2 ligands so coordination number decreases oxidative state decreases and we get back the starting compound prior to the oxidative addition what we had was this one and if the rate at which oxidative addition happens and reductive elimination also happens then we can say this called microscopic reversibility for example if a XY is added and if the XY is eliminated and the rate in both the cases are very similar then it is called microscopic reversibility because this is exactly opposite of oxidative addition reaction important this reductive elimination is very very important in organic synthesis especially when we are doing cross coupling reactions cis orientation is required for concerted elimination cis orientation the two leaving group should be cis to each other on a metal center and this because whether it follows initially concerted addition or nucleophilic addition reductive elimination is always a concerted three bond concerted process as a result cis orientation is very important in case due to some reason if we get trans position two moieties that are supposed to be get eliminated and we should find a way to perform isomerization so that trans to cis isomerization happens prior to reductive elimination and always proceeds with retention of stereochemistry at carbon the only in case of nucleophilic oxidative addition inversion takes place and then whatever the configuration we have and at the end of reductive elimination configuration is retained. Let us look into the stereochemistry of reductive elimination here so a chiral compound is chosen along with a metal having two methyl groups and two tertiary phosphines so here paradigm is in place to state so here nucleophilic oxidative addition has taken place so inversion has happened already okay so now you should remember this is a polar so nucleophilic oxidative addition means they will be added to the trans positions what we have here is bromide so now oxidative addition is completed now we are talking about concerted reductive elimination so now it should not change already you can see the configuration has changed now configuration has changed inversion has already happened now this inversion is retained in the next step that is during concerted reductive elimination what we get is so methyl group is coming here H will be here and D will be here and of course plus what we get is so you can see here so that means during reductive elimination retention one can see if you are using chiral molecules under what circumstances one can perform reductive elimination very easily can be seen here if you have bulky ligands if you have bulky ligands are there due to the steric crowding what happens reductive elimination will be very facile and of course if the metal is in higher access state it will try to get reduced okay as a result again reductive elimination will be very facile and besides these things what is important is what kind of ancillary ligands we are using on the metal the so called silent spectator ligands or ancillary ligands they have a role very important role so that means ancillary ligands capable of stabilizing lower access states is what important that means we should have ligands which are non classical in nature that means we should have ligands which are capable of functioning as sigma donors as well as pi acceptors you should remember when the reductive elimination happens metal will be coordinatively unsaturated and then more electrons will be there in that case what happens they can be inter electron repulsion that that will try to destabilize the metal in that case what happens we should have sufficient ligands having back bonding capacity so that they can release some of the repulsion by taking electrons to their appropriate back bonding orbitals in that context carbon monoxide allkeins and a variety of phosphines play an important role so this is about reductive elimination and then the nature of reductive elimination can be again assessed whether it is intra reductive elimination or inter molecular reductive elimination through some crossover experiments what happens for example if cc bond formation is there not necessarily both the carbon atoms should come from the same metal in cis or they can come from two adjacent metal atoms also that means although we know we have to confirm from further experiments for that one what we call it as crossover experiments are ideal then how to perform this crossover experiment let me show you that one let us consider two species again I am considering this tertiary phosphine having two methyl groups in one case it is deuterated and another case it is simple methyl groups so what we will do is we will take a one is to one mixture one is to one mixture of these two complexes and heat it okay when we heat it let us not worry about what happens to the metal center let us look into what kind of organic products we can get from this reaction three possibilities are there one is cd3 coupling to give deuterated ethane another one is simple ethane and third possibility is ch3 cd3 so when we analyze the product obtained in this reaction we can account for this one we can account for this one but this would be missing so that indicates if this is missing means the process the reductive elimination has proceeded via intramolecular process not intermolecular so that information comes if it is in inter then they would have very nicely combined so that product is not obtained so this is called crossover experiment in many other reactions also one can think of this kind of experiment to consolidate our climb about the type of product formed in a particular reaction so now let us look into bimolecular reactions and of course already I discussed in the beginning a few bimolecular reactions a typical bimolecular reaction I have shown here so metals which do not have two accessible access states with a difference of two electrons possibly on the other hand if they have two accessible oxidation states with a difference of one electron for example copper one copper two cobalt two cobalt three iron two iron in such cases one can anticipate bimolecular reductive elimination how that happens for example you take a molecule like this where we have a substrate x is there and another one we have a substrate y is there and what we are doing is reductive elimination so in this process through the establishment of a metal metal bond they will come close to each other and x y is eliminated this is a typical bimolecular reductive elimination and of course if we take this molecule and add this one we can get these two species that is bimolecular oxidative addition that I already showed you in my previous lecture one of the previous lectures so this is how one can imagine a bimolecular reductive elimination that is happening with species where we have metals which have a difference of one electron having two accessible oxidation states so results in mm bond formation and this is one electron reduction per metal and of course this kind of binuclear species unless these substrate molecules are capable of leaving this mm bond to add oxidatively you cannot use it in catalysis and if the as I mentioned if the species is capable of splitting this one reversibly okay then only we can use a binuclear process of course there are quite a bit of metal complexes are used in catalysis which follow binuclear reductive mechanism so this results in a new mm bond formation and this is one electron reduction per metal many examples go by radical process in these things where as I mentioned one electron process is there most of them follow radical mechanism can also occur in cases where intramolecular reductive elimination is expected so that means in some cases where intramolecular reductive elimination is expected also can follow this one binuclear method so for example if you consider this one here let us take two such species having H and CH3 here like this and as I mentioned they can come something like this and methane can be eliminated and of course here it does not follow this mechanism to give this con okay so that means basically here what you can see is if this is formed one can think that yes it is following a binuclear radical mechanism otherwise what happens you would have ended up with asmium tetracharbonyl complex so that means this shows that it follows binuclear method and what are the types of reductive elimination we come across you can see here RH so CH coupling can be seen and CC coupling can be seen and again here CH coupling can be seen and here CC coupling can be seen and here you can see carbon to silicon bond formation can be seen and binuclear reductive elimination for example you take this molecule here yeah so take this molecule on heating it can generate a species something like this or if you take a manganese compound like this with benzoil group or air CO and with combining with another metal hydride you can see this is a typical binuclear reductive process in this one you can see this species coming out through the formation of MN2CO10. Let me show you couple of more reactions here to make you familiar with this oxidative additional reductive elimination process. Let us consider this Na2 FeCO4 on several locations when question is asked whether this molecule can undergo oxidative addition or not many say no yes this can undergo oxidative addition despite it is an 18 electron species but I also showed you enough examples where an 18 electron species undergoes oxidative addition reaction so for example you take this one and treat with halide alkyl halide or aryl halide it forms yes in this fashion this can undergo oxidative addition and of course here Fe was in minus 2 state and here if you see Fe is in zero state so one electron is given one electron is taken here so it is zero state and here it was 18 electron here also it is 18 electron species. Let us try to see catalytically important reactions of course catalyst is needed here of course the moment I write these two substrate molecules and reagent you know that what kind of reaction this is so this gives if I just this one this is called Suzuki mirror Suzuki coupling reaction and if you take again air X and plus add 18 species again of course in all these reactions without saying without saying it goes that we are using a typical palladium complex or something this is still a reaction this is called Kosugi Megita still a reaction this is called Negasi reaction and of course you are familiar with this reaction as well I would say reaction of an alkali halide within alkyne catalyst is there even if I do not write you understand that you assume that there is a catalyst this is called Kumuda Kumuda and Koryu Tamil it is always good to write all the names of discoverers involved in this one it is not right to say simply Suzuki reaction we should tell always mirror Suzuki reaction and also a HEC reaction Mizaraki HEC reaction I do couple of other reactions I would write quickly so reaction of reaction of an alkyne halide with Grignard reagent is called Kumuda okay this this this is called sorry this is this reaction Kumuda this one is Sonogashira Sonogashira reaction this is addition of an alkyne halide to acetylene and in the last one in the series I am going to write Hiyama reaction we are using a silyl reagent called Hiyama so I think whatever I have discussed so far under these two topics oxidative addition reductive elimination would be enough to get some clear idea and understanding of these two reactions of course one can always go to textbooks to see similar reactions to understand in a better way at some point of time if you want to do some catalysis okay this is an ideal beginning to learn these things with this okay let me stop the discussion in my next lecture I should start discussion on another important topic in our ionic reaction mechanism so until then have an excellent time reading chemistry thank you for your kind attention