 I'm Tim Alrod. This is Stefan Morris. We're going to talk to you today about health care, health care protocols, health care systems. I've been a penetration tester for Fishnet Security. I've been doing health care systems and assessing those for about seven years now. Same here. I also work at Fishnet. Only four years though, so health care noob by comparison. Okay, so why would an attacker care about health care systems? Well, you know, obviously they're full of personal identifiable information, so identity theft, medical identity theft, protected health information. So that's going to be any diagnosis, any medical records, food allergies, drug allergies, things like that. Obviously, normal identity theft is always a concern, but medical identity theft, especially with legislation recently, that says you have to have health care. Medical identity theft is becoming bigger and bigger. Also, there are some political and social ramifications of disclosure of PHI. For example, from a political standpoint, McCain in O8, if you recall, there were questions about would he be healthy enough, would he be fit to serve in the presidency? Not all those records were disclosed publicly. Some were, but if they all were, maybe that would have been worse. Also, just embarrassing or compromising conditions for normal people or people of fame, whether that be something unfortunate like STDs or a mental health condition, these things still have real social ramifications in our society. Also, you see, for real, loss of life and limb. Some of these systems out there are exceedingly important that they just remain active, that they do not break, go down or are otherwise interrupted at all during treatment or during monitoring of a patient. And you will also see, you know, blame PCI for any number of things and its ineffectiveness in any number of areas, but it is prescriptive. It is prescriptive from a technology standpoint and we do not have that in healthcare. HIPAA does not have any sort of prescriptive guidance when it comes to implementing controls. So there's a lot of failure from any kind of legislation there. So some of the technologies we're going to talk about today, we're going to start with two healthcare protocols, HL7 and DICOM. We're going to talk kind of basically, these protocols are based on a history of non-standard standards, meaning that every doctor kind of insists on documenting and doing things their own way. So these standards are formed by committees and as we all know, standard by committee is kind of a bad thing. So these standards aren't very standardized, they're very open, a lot of unstructured data and a lot of room to make mistakes for programmers that program these systems. Also you'll see that a lot of the protocols and standards were initially dreamt up during the 70s and 80s. People didn't have as many off-the-shelf components for which to make pretty robust systems and so they were inventing wheels or reinventing wheels they did not know about. So dreamt up in committees and also engineered in garages, that's something we like to say. Because you'll see even big players today came from a not so distant past, maybe five, ten years ago when this was a garage project and now they are central to IT healthcare. So let's talk about HL7 a little bit. HL7 or Health Level 7 protocols and standards are basically the glue that holds a hospital healthcare system together. So in a hospital you're going to have a lot of different systems that are disparate and normally wouldn't talk to each other. These may be admitting systems or billing systems or radiology systems. HL7 is the glue that holds all those together. It's a clear text protocol. There is no security behind it. When you look at the standard, when it comes down to security, they recommend implementing IPsec because they just don't want to write it. HL7 segments are delimited by just a carriage return, they're clear text. Segments, like we said, we'll go ahead and show this. Always start with a three-letter identifier. So this MSH record is basically a record of a start of an HL7 message. It tells it that in the ninth, normally the ninth character field, you'll see it says ADT carat A04. So this is an ADT message, which is an admittance message. It just shows basically the information of a patient. Each one of these fields are pipe delimited, and then the subfields are carat delimited, which makes it very, very easy to fuzz. Very easy to write fuzzers for these. If you have the time to put into all the different fields. And while we're not showing it, V3 is just XML, so that's really easy. Right, so this is a V2 example. V3 is just an XML output. They've changed a lot, but it hasn't been implemented hardly anywhere yet. So at the core of these HL7 systems sit HL7 routers. These are very critical middleware to the hospitals in that they pass everything through them. So if I get admitted to a hospital, when I come in, they're going to take all my information. They're going to send it through the HL7 router to maybe a radiology machine if I have to have an X-ray over to the pharmacy machine, if I have to have some medications to the billing department to bill me. All of that goes through the central HL7 router. So the HL7 router will take in HL7 messages and parse them based on their content, and then send them off based on the rules to where it thinks they need to go. These HL7 messages normally come from EMRs and medical systems, but as we'll look at later, they can also come from malicious attackers from the Internet. All right, another key system that you'll see in any healthcare network is a PAC system or picture archiving and communication. So these are for centralized archiving retrieval of medical images. They will have various components. You'll have servers for centralizing archiving and routing PACs images, much like HL7. Sometimes they don't end up at that server. They end up passed along somewhere else. You'll have modalities, which are just medical systems, X-ray, CTs, MRIs. They'll also all fall into that category, and they'll communicate directly with your PAC system and dump information in there and can retrieve information and so forth. While retrieval viewing is usually left up to workstations, for viewing these things, it can also be done over the Internet with any number of portals. So they've really liked to have gone web portal capable recently. That's very new for healthcare though, so often it's very messed up, also mobile. So take a look at those components of these systems because they are very new. Let's see, and it is the standard format for medical image storage and transfer. So a DICOM is, excuse me, and that's what's used by these PAC systems. That means it is a network protocol as well as a file format. So as far as the network protocol goes, it's really easy to find. It can run over TCP, UDP, ports 104 and 111, 112. There's also an authenticated encrypted version that you can find on 2761, which does a maximum of DCBC and 2762, which will actually do TLS. Chances of finding these in the wild though is pretty low. This is almost always clear text. In DICOM parlance, a client is just a SCU or a service class user, and a server is a service class provider or an SCP. So when you see those, that's all they're talking about. To make a connection successfully to DICOM server, you're going to just need the IP port and the AE or application entity title, which is just a unique string, often the host name of the system. Now the server usually requires that you know it's AE title in order to connect. That's an almost always thing. And sometimes it will verify the client's AE title and make sure it's on a list. Also, this is sometimes restricted by IP address. But those are your only protections here. So no real authentication. DICOM as a network protocol has any number of commands. It's not like FTP, unlike FTP in many ways. You can store things, get them, move things around on the server, find them, check to see if the system's up with an echo command and so on and so forth. It's actually pretty easy to understand. And just if you're wondering if these things are all over the internet, I realized that I had forgotten to take a picture of this slide. So for this slide yesterday, so I ended up just running another in-map for 24 hours all over the internet, and I found 875 open ports that are likely to be DICOM. So brute force opportunities are available. So when you get into the file format, the file format's pretty typical of any number of other file formats. And this is for medical images, so think JPEG. There's a lot of metadata that can be stuffed beforehand, except the amount and the sensitivity is much, much higher. Basically, you can stuff an entire medical record in the metadata that is available for any of these DICOM images. So you'll have a header, which is pretty standard, and then you'll have data elements, and they're broken down and not like a TLV, but more like a type with your tag, a VR, which is another type, your length, and then the actual value. So just a little bit of complexity and this normal looking message, which would be just a data element with an explicit VR. However, the thing about this file format is that it gets really, really crazy and complex and how it likes to nest things and how many options it gives you to represent metadata. So you'll see here, this is simply an example of a data element with implicit VR defines the sequence of items of undefined length containing two items where one item is of explicit length and the other item is of undefined length. And this one's not that bad. So when people implement this stuff, you'll find that it's almost never implemented correctly. And so any DICOM parsing software I have seen so far just crashes constantly and there are definitely exploitable bugs. So yeah, pretty terrible, take a look at that. And just a couple more points on it. The pixel data, the actual images, you can have one or more frames, almost like one or more images within it and they'll be encoded in RLE, JPEG, JPEG lossless or the much forgotten about JPEG 2000. So there are opportunities to fuzz those things too that would parse those image formats. It doesn't have the full metadata that any of those would have because it usually just strips out the encoding and uses that portion. Also, just so you know about a little bit more of the complexity, some of those elements can be required, conditional, optional, fixed length, undefined length, nested, which I particularly like, big Indian and little Indian which can be negotiated before, yeah, okay, so no problems there. Actually it's a huge problem. Retired, private and a myriad of other options. And so as far as some of those options go, you do have like 100 or 1,000 registered VRs for that which are just part of the data elements and there are many, many more than are private and unregistered. So do take a look at this. It will fall over. So we decided when we were going to do this talk we wanted to release some sort of tools to try to help people look at healthcare systems. The fact of the matter is healthcare vendors in general are fairly bad about how it's kind of like hacking 10 years ago. It's pretty bad. There's no protections or anything like that and they really hate to patch things and they won't. We've tried to disclose bugs and had bugs sit for over a year trying to just get the vendor to acknowledge us that there's a bug there. So we figured the more people looking at this maybe the better it'll be. So we were going to release some fuzzers. We figured we could write them or we could just do it in Peach because Michael wrote it better than us. So we decided to release some Peach Pits. You'll be able to pick those up at metafuzz.com. The initial release will be two protocols, the HL7 and the DICOM, both the network and the file fuzzer. We're going to have more coming. If anybody's interested in this and wants to get in touch with us and maybe give us some ideas or volunteer to code some up, you're more than welcome. So we'll talk a little bit about EMRs and EHRs. So the EMR or the EHR you hear it kind of both ways depending on the vendor are basically just a central repository for what used to be your paper medical record. So back in the day you would go to the doctor you'd have a big thick file that had all your medical records in it, all that is now electronic and centrally located in an EMR or an EHR system. These systems are required by recent legislation that we'll talk about here in a minute. So they will be at every hospital. If they're not now they will be soon because they have a financial interest in making that happen. These basically take all the data in from different systems through an HL7 interface and into this one central location. It'll be either be at the hospital, a lot of them are remotely hosted as well. Things like billing systems, PAC systems, practice management systems, scheduling systems, things like that. Prescription drug systems we'll talk about later. Vital monitoring systems which we'll also talk about. And then business partner systems. So this is kind of something new that's come about and that data is now starting to be shared between hospitals more regularly due to legislation as well. So not only does your data get to say this EMR but it'll also get to all the other hospitals around this hospital's EMR for instance. So obviously this is a fairly juicy target for an attacker because all the data is in one location. So health information exchanges. This is what I was talking about. Due to the high tech act that was just recently passed as part of the stimulus package, all hospitals are required to prove what's called meaningful use by 2015. What meaningful use basically states is that you're going to use an EMR, you're going to use an EHR and you're going to contribute and participate in what's called a regional health information exchange. So these are systems that are set up by these companies to share data between hospitals. So I can't go to hospital A and maybe get a script for morphine and then go to hospital B and say hey, my back hurts too and get another script for morphine. Things like that, that's what they're trying to accomplish there and reduce fraud and waste. What they inadvertently do is they make data travel between all of these hospitals. So if I were to get an HL7 message perhaps into an EMR, that HL7 message that maybe malicious could propagate not only to this hospital but to hospitals around the country. So yeah, these can be local, state, regional or even national and like I said, data entered into one will propagate to the others indiscriminately. And that brings us to personal health records. This is an interesting idea that a lot of people jumped on board with not too long ago. Microsoft Health Vault is the big player in the PHR space. Google Health, you may have heard recently that it's going to be discontinued at the start of next year. So good move, Google. If there are any Google people in the audience, thank you. We're not big fans of these. Yeah, it's not Google, it's the idea. There are various others, usually created by an EMR or EHR vendor and sometimes by CMS vendors that build particular CMSs for the medical industry. And so you'll see that there too. There are patient facing web portals essentially that allow access to records for patients. Now, typically when you log into one, like you can set up a free account with Microsoft Health Vault, you will be blank and you can input your own information manually, you can import it from a file or you can create a trust between you and someone else. So other entities such as hospitals, doctor offices, pharmacy, et cetera, and so forth. And these trusts can go both ways. They can pull data from your PHR and they can push it. This can be a one-time operation. This can be an any-time operation. It just kind of depends on the level of control and granularity that you specify and agree to. It tends to be, however, more open than not, just to let you know. So one thing about health care in general is that doctors have very special ways of just kind of writing things down and documenting everything and they don't like to standardize. Only recently are they starting to be forced to get on board with standardizing just how they document stuff. And I think that PHRs and EHRs and EMRs reflect this a lot. And so you'll see the text inputs are both structured to some degree but highly unstructured in many, many areas where you can input data into these systems. Also, they'll accept nearly arbitrary file uploads, not just of images that might be useful but also stuff like PDFs and other formats that we now have all kinds of security problems and would be kind of bad if a doctor inside of a network just opened up. Also, real quick, they do allow for automated data upload from medical and fitness devices. So that's another way of communicating with them, which is kind of interesting. So to talk about Microsoft Health Vault a little bit, first off, great documentation, SDK, development sandbox. I love it. It's really easy to work with and learn a lot about, so props to Microsoft. Third parties can create all kinds of web and rich applications that interface with the Health Vault API, and it's not very hard at all. Data storage for Health Vault can follow any number of different modes. So you can basically have a web portal that you created that stores all of the information in Health Vault, right? And it's just sort of branded with your hospital, your institution's name, and that's a very common way of doing it. Or you can have some of that data reside in your local database as well as Health Vault, and you see that a lot when they're creating functionality that doesn't yet exist in Health Vault. So scheduling often with the internal systems at the hospital is a pretty common reason for doing that. And a lot of devices too, and it's a software that you might actually install on your computer, will have a local database local to your system. So that's a good thing to look for if you're trying to pillage data. One thing that's been hanging up there since I put this slide on there is that Health Vault doesn't seem to do much in the way of input validation at all. They won't reflect bad things back to you. They seem to be very good about that, but they do end up being a great way to store all kinds of good vectors, XSS being the really obvious one, for whoever might consume that PHR at a later date. Which brings us to the obvious, most just health records, MHRs because we thought there needed to be another acronym in this space. So XSS is obvious, and CSERF from that is another great result. SQL injection, I've seen that be passed on. Databases being messed with, although it's pretty hard because you're a couple layers deep. And then of course the file uploads. So if you found some bugs with DICOM images, which they're expecting to see, or some viewers for DICOM images, that'd be a great way, PDFs, etc., and so forth. And this affects many a system. So practice management systems, EMRs, EHRs, PAC systems, HL7 routers, modalities that eventually view those things or interact with them in another way. PHR and other web users. So some of the PHRs often have doctor portals too. So that's a really easy way to take advantage of that XSS for instance because I'm sure that doctor has access to more patient records than you do through the PHR. And also business partners and HIE connected systems are a possibility. We really haven't seen much of that yet, but it's just a matter of getting people to let us look a little bit more. So I got mad alert boxes, yo. Yeah, I said that. So once again, like I said, it's a great place for stored XSS, Microsoft Health Vault is. And the underachievers are particularly bad. So you can just do a script alert, right? Or your beef hook. And this will show up in all kinds of PHRs everywhere. If you get a little bit more creative and you actually try to bypass the minimal amount of filtering that some of them do, you will get a lot more. And there's just a tiny bit of proof health vault with a beef hook in it and some random PHRs that are health vault enabled that popped alert boxes for me. But sometimes they're even worse and more obvious issues. So last week I was just gathering some screenshots for this presentation and I was visiting some of these PHRs because the bugs come and go, frankly. And Injector here, Team Injector, they found this one called SpinPHR and it looked like it was probably vulnerable to a Drupal bug. So I'm glad they just decided to deface the page and tell everyone that, hey, we have your PHR. Because there are real consequences to that. Compromise of at least every account that was accessed after the attack is trivial. Basically all you typically need to access a record with health vault through the API is a person ID, a record ID, and the part of the record that you want to see. And these are just quits. So if you post to the right part of the page with the right format of things which it's no problem to figure out, you will be able to pull back information pretty simply. So they would have had access to those and the sessions going on, no problem. And that would have carried on. And depending on the design of the application by the attacker, they may have had access to every health vault account that was still linked and trusted with that particular PHR. So what they'll typically do is, sometimes you'll see those person IDs and record IDs are used directly and they'll be leaked all over the page and this can be really easy to grab those. But other times they'll actually, a PHR that uses health vault will have its own session management and they'll typically hire the person IDs and record IDs somewhere in a database and then use those later to access your account. But the thing is they're static. They don't change. That person ID and record ID will always give that PHR access to your account as long as it remains linked. That is per PHR and per application, but it's bad enough. So those guys, Injector, they had access to some stuff whether they knew it or not. But this does bring up a good question, though. You know, health care has significant breach disclosure laws, but when it comes to PHRs, especially things that are, used by other people, who exactly is responsible for that and who's disclosing breaches? I don't know. I'm not guessing that this is going to be disclosed at all, even though it's pretty public. So we did a bit of a medical hardware review on just some of the different medical devices that we'd seen. We took a look at a couple of vital monitoring systems. These are things that monitor your blood pressure, your heart rate, things like that. Infusion pumps, things that sit on IV poles that control the dosage of medication to you that are connected to a wireless network that can let anybody talk to them. Someone thought that was a good idea. We also looked at prescription drug cabinets. We figured since we were coming to Vegas what better stuff to do than to see how to get free oxy-gotten. So we took a look at those. Basically there are two vendors in that space, one called Omnicell, the other one called Pixis. Every hospital will have one of these vendors in their hospital. They'll have drawers on every floor. This is what the nurses go up to when you need a certain prescription for something. They'll get it out and bring it to you. We found some vulnerabilities in that that we'll talk about here in a second. We also looked at some radiology modalities, file format, bugs on those are pretty rampant. These things are obviously controlling not only patient care but lives in a lot of cases. They do have a lot of problems. We thought we'd take a look at them and it is kind of as scary as you would think. We kind of wrestled with putting stuff out there that wasn't particularly bad when it came to some of these medical devices. As he said, we have things like infusion pumps that are controlling the rate of drugs being put into an IV. That's something you don't just want to go talking to everyone about. This one seemed relatively harmless and it was actually, as we found, reported not terribly long ago in a roundabout way, not necessarily for this product but the underlying product they use. Omnicell, one of the drug cabinets, uses an application called OmniExplore. It's for reporting and various other things and it'll just run on the drug cabinets proper. It's a web application and it uses a funny piece of software called Westwind Web Connect. I don't know if anyone's run into it on a pin test or anywhere else but it has some problems and it's really easy to misconfigure. This here is editing a configuration file on Westwind Web Connect and it's truly easy enough. From here you just modify a couple values, namely those, and it becomes a pretty simple thing to do, to own it. So HackerCenter alluded to this issue with Web Connect in general but didn't say, hey, you'll find this on drug cabinets but basically you just need to go to the hostname wc.dll. Sometimes that's off a directory called wconnect and just wwwmate tilde edit config that will pull up the previous slide more or less and you can just add an I&I file for the application on the box, change a line that says exe file to whatever your executable is, update file, the location of the new file and then whack that other URL at the bottom on number four and it will actually update that for you and start a new server with that executable. So yeah, there you go. It's also running a system but afterwards I suggest that you get access to the desktop of whatever's on there because you'll probably see an application running that will allow you to do some more things with the drug cabinet. And like I said, we have no problem throwing this one out there since it's already reported. So inevitably when we're at a bar around here this week we get asked about death packets. Can you kill somebody with a packet? Unfortunately the answer is yes. Death packets do exist and you probably already know about them. They're not anything special. So these systems are required to stay up for patient care. Things that do, for instance, systems that do things like dose high intensity radiation at cancer patients that if they go down could potentially nuke a person. These things are sitting on these networks and they're running systems like Windows XP Service Pack 1 and they're not patched because the vendor claims that the Food and Drug Administration Certification for that device requires it to never be patched. Which is not true but that's what they let these hospitals know. These systems that sit out there for years and years and years and never get patched and if they ever go down could potentially kill somebody. And we thought this was pretty bad. So these systems are very fragile. If you're testing a hospital network please be careful because I may be there and I don't want to get nuked or something. So lack of operation of these systems can be bad. There are targeted attacks on things that could cause physical harm to a person that we've discovered. Again, HVACs are very important too. The HVAC systems in most hospitals will sit directly on the network. Heat in a hospital is bad. Again, everybody probably has loved ones in hospitals so be reasonable about this. Please don't disclose crazy stuff that will kill people. Disclose extremely responsibly. And that brings us to various miscellaneous healthcare notes if you're doing a PIN test. Once again, medical devices are exceedingly fragile. Directly affect patient care and can be downed with simple resource exhaustion. So even just scans can be vulnerability scans can be pretty bad on these devices and can cause something just to go unreported, unmonitored or worse. Also, you'll see one particular funny thing about hospitals and other places is that time to log in for doctors and nurses is of utmost importance. This really drives a lot of policy when it comes to security in a lot of different facilities. So you'll often find that authentication schemes are exceedingly lax and this also creates big problems where they think the solution is going to be a single sign-on solution or vendor that's going to come in and fix all their problems. But often these systems don't work terribly well either if you've tried to wrangle one of them before. You probably have a good idea. Also, you'll see massive amounts of remote access technology used for legacy applications and this is all going to be industry standard common stuff. Mixed with, of course, lax authentication policies, often you have the recipe for a remote access nightmare from a security standpoint. These systems are typically used both internally and externally to give access to that. We had mentioned before the FDA approval process and the misunderstanding of it and the miscommunicating of it by various vendors creates a lot of unpatched boxes. So, you know, forget MSO 8067. You're looking at MSO 4011. They're going to be out there. I can like it's 2004. Yeah, yeah, definitely. It is 10 years ago. So, wireless is also going to be an issue in these locations. Handheld medical devices that will roam the networks are usually stripped down Linux drivers that will only support things like web. So, you'll see web networks on these networks that are going to be directly connected to the hospital network because they have to talk and they have to have those to support those older handheld machines. Again, at best, maybe you'll see a leap. Maybe there's going to be no cert validation or anything like that on these networks. So, wireless networks are always going to be bad. Also, I mean, these are public places. You know, everybody's usually pretty busy. So, walking around with antennas on your backpack seems to not get you noticed apparently. So, you know, you can just kind of walk around and look around at those things. Again, these are public places. They have to let the public into them. So, you being there isn't going to go noticed necessarily. So, social engineering in general is a huge, huge problem for healthcare. It's a really big issue in that they have to have the public come in. They have to interact with you because it's their job. But then, you know, bad things can happen from that. Also, due to the lack of standardization of a lot of these protocols that we've been talking about, especially DICOM, it is not uncommon for patients to be given a CD with their medical images on it as part of their own personal health record. Those medical images will not view in every DICOM viewer because everybody's is a slight bit different. So, you'll also have like an EXE on there that's a special DICOM viewer for those images. And doctors regularly will get these CDs from patients and put them into computers and run those EXEs and bring it up and look at those images. So, you can literally just take the EXE and backdoor it and walk into a doctor's office and say, hey, my leg kind of hurts. Here's a picture of my broken leg and you get shells everywhere. Great, that's it. You can go find our pits, which will be up very soon at MediFuzz. We thought we were being clever and would make it something like MetaFuzz, but it's only led to confusion. So, medifuzz.com Send us an email if you want to get a hold of us and talk more about this or talk to us in QA. Yeah, we'll be in the QA or you can buy us a beer. I'm all up for beer, so. Absolutely, especially after this. Thanks guys. Thank you very much.