 Thank you very much. I appreciate this is the last talk of the day, so thank you very much for coming. Can you hear me okay? I feel like this isn't close enough. There we go. Okay, so today I'm going to be talking about the ways in which we can make hacking of medical protocols a lot simpler. If we can make the identification of the weaknesses in this protocol a lot easier, we can ensure that the devices using this protocol are a lot more secure in the long run. In an ideal world, the only hacking that should be going on in hospitals is the one that comes with a cough, right? But unfortunately that is not the case. There are still so many attacks going on in healthcare. In particular, Checkpoint recently released a blog post that stated a total of 1,684 attacks were observed on healthcare systems in just the first three months of this year. Therefore, it's still really important to make sure that we continue to test these devices and medical systems to make sure they're as secure as they possibly can be. Okay, just to quickly introduce myself. My name is Katie Ynnes. I'm from the UK and I'm a security consultant at Weave Secure. I actually specialise in attack surface management, so this topic and this research project is definitely a step outside of my comfort zone, but it is something that I've been working on for the past year or so. So, let's talk about tech in healthcare. So technology has actually been used in the healthcare industry for quite a long time now. And in particular, if we look at x-rays, they were first used all the way back in 1985. So a long, long time ago. But what we really care about here is protecting individuals and their data. So if we look at the systems and mechanisms to communicate that data, in fact, the first medical record systems were deployed all the way back in the 60s. So again, a long time ago. And let's take a look at some of those systems. So this is just an example of the types of device that you might find in a hospital environment. And each one of these is considered a potential access vector for an attacker. If we think about the data flow here just as an example, we might have a patient that's been admitted to a hospital. They might be hooked up to a number of medical systems. And for example, their heart rate might be getting recorded and stored within the data centre. That particular patient might have had a number of tests. So for example, they might have had some blood tests. That might have been recorded within the lab. And again, those records are then stored within the data centre. The pharmacist might also need to query these records. So they might need to access the data centre as well. And they might need these records to be able to prescribe the correct drugs. So how exactly is this data communicated? So these are just a few of the protocols that are commonly used in healthcare to communicate different types of data. The most commonly used protocol is called Health Level 7 or HL7. And this is actually the focus for my research today and this talk. The reason why I decided to focus on this protocol is in fact that a lot of healthcare systems and medical devices are still using this protocol today, even though it's quite old. There is another key protocol to mention here called FIRE, or Fast Healthcare Interoperability Resources. And this was kind of designed to be a replacement for HL7 in the long run. It was designed to be a little bit more secure, but in fact, Alyssa Knight published some research a couple of years ago and they were able to access around 4 million records through the exploitation of this particular protocol. Okay, so HL7 is a mechanism to communicate patient data in clear text. It was designed all the way back in 1979. And if you look across different types of medical devices, the most common version you'll see is in fact version 2. That is the version that I'm going to be talking about today. And in fact, if you did want to look into version 3, there are some complications here. In fact, it's not backwards compatible. So that's partly why I'm focusing on version 2 as well. The most common way to transport HL7 messages is through the minimal lower layer protocol. But it's not uncommon to see other types of protocol used to communicate HL7 messages, such as FTP, SMTP. And of course, you've got all of the weaknesses associated with those protocols to consider here as well. But the main thing to mention is that HL7 messages are communicated in clear text. So what do HL7 messages look like? So each message is made up of different segments. And you can see these by the first three letters on each new line. And each segment contains a number of fields which are separated with a pipe character. Most commonly, you'll see the first segment which is the message header. And this contains all the different fields that are associated with that particular message. For example, you've got the message type, which in this case is admissions, discharges, and transfers. And in particular, this particular message is a standard ambition. So maybe Mickey Mouse has found himself in hospital for whatever reason. And he's admitted as a patient. Other types of messages that you might see are things like observation results. So that might be if you are hooked up to a patient monitor and your heart rate is getting recorded. Each message associated would be an observation result. You might also see things like events, pharmacy dispenses. Okay, next you might find the event segment. So this is really important. And it actually states when and where the message was sent from. You might also find the patient identifier. So some key information about the patient. You might also have the next of kin. And also potentially some allergen information. So what the allergy is and the potential reaction. Not all segments are required. But if a segment is present, then there are specific fields within that segment that are required. Okay, so the most common way to transfer HL7 messages is through the minimal lower layer protocol, or MLLP by TCP IP. Where messages are sent by MLLP, they'll be wrapped in a start block. They'll also be, you'll see at the end an end block and also a carriage return. So then this particular example, you can see I've highlighted the start block in red. And then at the end you've got the end block which is one byte, and then a carriage return tacked on to the end as well. And this is basically so that the server knows where the message starts and where the message ends. Okay, so we're going to talk about some common vulnerabilities in HL7. So there's been some really great research into vulnerabilities affecting HL7 in the past. So if you did want to delve into these in a little bit more detail, I've included a couple of links at the bottom, but I have got some links in my resources slide as well. So typically HL7 doesn't require any kind of authentication to be able to send messages. So in theory John Doe could send any message he likes to any device, given he's on the same network and given the formats correct as well. There is in fact a user authentication credential segment that will allow you to configure authentication mechanisms such as Kerberos and SAML authentication as well. But it's really important to mention here that that segment is in fact optional. So in most cases it's not implemented. John Doe can also amend messages given he's on the same network. And if he did amend the message, the server would have just accepted it as if nothing's happened. It's also possible to cause denial of service as well. So quite often on servers or mid-aware applications, you will see a maximum number of connections I set. And that maximum number of connection is usually quite low, so it's usually around something like 10. And therefore if we can exceed that number of connections, we can cause a denial of service attack. Then lastly of course I've mentioned it already, but HL7 messages are communicated in clear text. This is obviously a massive problem as it allows us to be able to perform person in the middle attacks or ARPs within to gain access to patient data. Okay, so I've been talking about this quite light heartedly up to this point. Yeah, but I feel like it's really important to think about the impact here for just a second. These are just some of the examples of different impacts that you might see. But in a worst case scenario, we can cause severe impact to individuals here. If we're able to position ourselves on the network and potentially intercept traffic, which in theory is not unachievable, given a lot of hospital networks are quite flat, we can potentially change the records and messages that are being sent. That might look something like changing allergen information which then could cause prescription of incorrect drugs and then cause an allergic reaction. And then of course far, far worse as I'm sure you can imagine. This is obviously possible given the right conditions. Now you can see just how important it is to make sure that we are testing these devices, to make sure that we find the weaknesses and make sure that these devices are hardened. But of course this comes with its own challenges. It's not easy to fingerprint the use of HL7. So by default HL7 doesn't run on any specific port and therefore it's hard to identify when it's in use. There's also no real fingerprinting mechanisms in tools like NMAP to be able to identify when a port is actually using HL7. We could however look at the default ports set by a device. However, I would not recommend ports scanning a medical device. Quite a lot of them are quite legacy and they just cannot handle it. And therefore you're likely to cause denial of service in this case as well. It's worth me mentioning here that in fact I would not recommend testing production devices in this case either for obvious reasons. Okay, so I've mentioned a few times but HL7 messages are typically communicated in clear text. You will see however in some cases the device will allow you to configure SSL in the settings. So the device that I was using was a small patient monitor that you'll see very shortly and it did allow you to tick a checkbox in the settings to configure encryption. But of course this is not enabled by default so in most cases messages will be sent in clear text. If we can find a way to amend the messages or access this data we can potentially cause some sort of impact here. Unfortunately it's not easy to be able to intercept the data obviously HL7 is quite non-standard and also MLP is quite a non-standard protocol that we can't intercept with things like BIRP. We could however sit on the network and intercept communications via something like Wireshark which might look something like this. But in fact let's see this in action. So I mentioned that I was using a small patient monitor to do my testing and this is the Philips Sure Signs patient monitor. Philips actually provide a lot of health care equipment to the NHS in the UK so that's partly why I decided to choose this particular device. So we need to obviously get some readings so I decided to hook myself up to the patient monitor and after a while you should start seeing some heart rate readings and some blood oxygen readings as well. After a while we'll start seeing the packets come in and as you can see we've got some HL7 communication data here. Within that packet we've got each of the different segments and within the segments we've also got each of the different fields as well. Okay another challenge that comes with testing HL7 is its readability. As you can see HL7 messages are really easy to read. They're not easy to read at all. And can you imagine if you were testing a device that was spitting out messages just like this every minute it's just not going to be easy for you. Okay so how can we overcome these challenges? There are a few tools that have been released in the previous years that were designed to test medical protocols such as HL7. There has been a tool named Pestilence that was actually created by Christian Demef and a few other guys but they didn't actually release it. Another tool was created by anirudagal called MedAudit and this provided a nice graphical user interface and allowed you to do things like intercept messages and fuzz different fields as well which was quite useful. But there is still a number of items missing on my checklist of tooling requirements. So what do we need? This is all personal preference obviously but the TLDR here is that I just wanted a tool to be able to work with existing tools like BurpSuite. I wanted to be able to test HL7 just like you test HTTP or web applications. And so I decided to create HL7 magic. HL7 magic was designed as a BurpSuite plugin and this was basically to make use of the existing functionality that Burp has to offer. It was designed also using the HL7 API Python library which allows you to pass messages and the original objectives for creating this tool was basically to make testing of HL7 a lot easier. So how does it work? So we've got the original communication here at the bottom. So a HL7 message is sent from a medical device and is accepted by the server. And where the magic comes in is this communication in between. So I decided to use man in the middle relay to be able to proxy the traffic through from the client to Burp. So that's that between the client and the server and then it allowed us to be able to pass that traffic through man in the middle relay and allowed us to intercept through Burp. Once it hit Burp, the HL7 message is then passed and the contents of that message are dynamically stored. So that allows us to be able to intercept and send on any particular HL7 message with any contents. At this point here as well, it allows us to be able to do all the cases where we've got that MRRP wrapper and from that point onwards, the HL7 message is then converted into a nice JSON format. This allows testers or attackers to be able to easily read the message contents and also change the contents as well. Once testing is complete, the message is then converted back into HL7 format and sent on to the server. Okay, so time for the demos. Another quick disclaimer here. I am going to be open sourcing this tool after the conference. So please do not use this tool against any production systems, just as a warning. Okay, so I'm going to go through two types of demonstration here. So the first is going to be using an example message which will be sent from a client and this is basically using an emulator to act as a medical device. The second demo will be using an actual medical device and so the message you will see will be coming straight from the patient monitor that I featured earlier. Okay. So, the first demo, we've got the test message. So we're actually using the same message that was on the previous slide that you saw before. We have our man in the middle relay command set out so it's listening on any IP address locally. We've got our client sending data on port 8880 and the server is configured to listen on localhost on port 8888. We've also got Bert listening on localhost on port 8081 just to confuse you with all the eights as you can see and so if we go ahead and intercept we set our server listening on port 8888 and then we've got our man in the middle relay command so that's going to be sending the traffic through to Bert and then if we send our message from our client. As you can see this has now been intercepted in Bert. Standard HL7 message format but if we go into HL7 magic you can see it is converted into a nice JSON format. We've also got all of the segments and all of the fields within that segment as well plus some additional information that is gathered through the passing of these messages. If we wanted to prove the impact here we might decide to change some of the contents so we might change the patient name potentially from Mickey Mouse to Bob Mouse and if we go back that is now converted back into HL7 format. If we go to our server forward the message on and as you can see the server has now received our new message with Bob Mouse instead of Mickey Mouse. Okay so second demo here we are now using our patient monitor and so the message being received will be from the patient monitor. So the IP address here is slightly different so we are now using 192.168.0.10 IP and therefore our man in the middle relay command is going to be slightly different here as well. We are still listening on any IP locally but now our client is sending data on port 4000. We are listening on the 192.168 IP on port 8888 Bert is also listening on the same IP but on the same port as before so 8081. As you can see if we go ahead and intercept we set our server listening as same as before we've got our man in the middle relay command going and now we are waiting for the message to be sent from our medical device and there you go we're intercepted. Same again HL7 magic and you can see the contents of the message is now in a nice JSON readable format. Again if we wanted to prove the impact here we might decide to change the contents. So same as before we might decide to change the patient name quite a benign example but we might change this from Donald Trump to Donald Duck. But if we wanted to really prove the impact here we could change some of the readings like the blood oxygen reading and potentially the heart rate reading if we wanted to as well. Again we've now converted this back into normal HL7 format go to our server and the server has now received our new message. Okay so what can we take away from this? HL7 is still the most commonly used protocol in the industry and as we've seen it's vulnerable to a number of issues if not securely configured. HL7 is difficult to test from a security perspective it's difficult to read difficult to fingerprint and as we've seen it's difficult to be able to proxy the traffic through existing security tools. HL7 magic can provide testers with an easy method of testing medical devices using this protocol. So in future testers will be able to proxy traffic through BERT they'll be able to easily read these messages and also amend messages on the fly as well. In terms of future plans I intend to continue researching medical protocols I'll also intend to add support to HL7 magic for protocols such as FIRE potentially some fuzzing integration as well and I'll also be open sourcing the tool after this conference so I'll welcome any collaborations and any potential feedback and improvements to the tool. I just want to say thank you to anyone that supported me on this journey and thank you very much for joining me here.