RIS-ky Business: Exploiting Medical Information Systems

okay hello thank you for coming I'd like to introduce Shaco Brackett from one medical please give me your attention and respect as you go through his slides and please refrain from questions until the end okay thanks cool yeah my name is Jacob Brackett I'm an application security engineer at one medical I'm here to talk to you today about some research we did as part of our vendor security program which is attacking radiology information systems so you may have seen in the news that there's medical devices are kind of a hot topic in the security world right now you may have seen other talks or read about some high profile attacks that have been really announced and

talked about recently medical devices are definitely becoming a real attack vector for ransomware for criminals to gain a foothold into hospital networks or other medical device works the FDA has actually stepped in to issue some guidance and regulation in the space it's definitely a hot topic in the security world for sure but this talk is not about medical devices what this talk is about is the medical device information systems that power these devices that they send their data to so you know it's where all the data lives the patient data is sent to a centralized location it's kind of the golden egg the treasure trove for attackers if they're able to gain access to this system they don't just get

access to the information stored on a single medical device they're able to get access to all of the patient data great so what are we going to talk about today at a high level we're gonna we're gonna look at an example hospital setup we're gonna talk about the DICOM protocol and we'll get into what that is a bit later and then we're gonna talk about how attackers can leverage that protocol in order to attack these information systems and gain access to them great so let's say you are a hospital and you purchase one of these for the first time this is an x-ray it's meant to do chest x-rays the patient lays down and they make an image of the patient's

chest you've set up your room you've got lead-lined walls you may notice something might be missing from this picture there's no place for for a doctor to actually go in and take a look at the image that came out all there is is kind of the camera if you will the x-ray device itself so what you may have to do is figure out a way for that device that device to send its data outward in order for doctors to look at that so first step may be you route it to a local computer but maybe you want something that scales so if you have a hospital network across the country so you maybe you set up

something like this so here is kind of an example we've got your x-ray machine there on the Left you've got now you've got that laptop that if writer is viewing images on it's serving as kind of a gateway or a router that you'll send your image to that initial on-site place because the x-ray itself is in a lead-lined room it can't send it directly to the Internet you probably don't want your medical devices connected directly to the internet anyway so you've set up some sort of intermediary you maybe you've locked that down and then that gets sent to your shared imaging cloud if that's maybe that's owned by you if you're a huge Hospital Network maybe that's owned

by a third party if you're that you've hired out four doctors to go in in teleradiology is what that's referred to when you have other doctors going in and doing if you're smaller company that's probably what your setup looks like you've hired contractors that actually go in and do your imaging cool so before we talk about that let's get into some definitions I mentioned DICOM earlier where that stands for is digital imaging and communications it is the protocol it's a standard for medical imaging transfers no matter what type of image whether it's an x-ray CT ultrasound if you if you've gone to Urgent Care and got some sort of medical image taken likely that image was translated into

DICOM and sent over the Internet it's both a file format and a network protocol and we'll talk about both of those elements later the next topic we're going to talk about is a packs or a pack system that stands for picture archiving and communication system it's basically the web UI where the it provides diagnostic quality images allows the doc to go in and actually make their diagnosis all their annotations happen in that application its where actually the actual Diagnostics happen and that may be on a web server somewhere that you can browse the internet it might be internal on an actual laptop but there is a PAC system that your doctor will be logging in to perform their work and

then finally we're going to talk about radiology Information Systems which is kind of the related to a pax in that it's it is a pax as a part of it kind of it's it's where it's the higher level the business logic side of the pack so where the pack whereas the pax is where you go in and view images the risk is where you go in manage provider schedules it allows you to click at a certain appointment time and then view the images that were associated to that appointment cool so now your radiology expert you know all the terms let's look at our diagram from before and take a look at what that actually looks like so

we've got our introduced one quick term here the modality is your actual device it's your x-ray or CT etc or whatever that device might be that's referred to as a modality in DICOM that would be talking DICOM so either DICOM rod DICOM which is unencrypted or DICOM over TLS for some more modern devices although it's usually a very modern device if it's speaking to I come over TLS locally over your network to a DICOM gateway in this case it's a it's a Raspberry Pi we've seen that set up or it's may be a Windows computer something a little more sophisticated but at the end of the day that has to get into your centralized risks or PAC system so that is done over

the Internet either over VPN which is the the common more traditional way to do it but more and more as does more systems or going into teleradiology that doesn't necessarily work if you have to set up a VPN to each of your hundred clients and some of these clients are very small and TLS is kind of sufficient so a lot of them will just setup DICOM over TLS or maybe they forget to set up TLS but they shove DICOM over TLS set over the internet to connect to the risk system so the images are sent encrypted hopefully over the wire over the Internet great first let's talk about the the DICOM Network so first of all what are some things you

can do with the DICOM network protocol the they're kind of broken down is different composite operations the main two we're going to talk about today and there's more are see find which is kind of your generic query retrieval service it's kind of how you do execute search operations if you if you want to pull out patient data you can use see fine to do that and then the next operation we're going to talk about is C store which is your ability to upload a DICOM study so that's take a DICOM file take an image that your x-ray is doing a c-store to that system eventually there's a few other like C print is one C move a few operations that would be

kind of database operations so let's dive into what that actual protocol looks like it's a classic kind of client-server model there's two components the the client is referred to as a service class user in DICOM or the SCU and then we have the service class provider which is the server in DICOM so it's kind of the initial handshake period happens where the to serve the client asks for an association we'll dive into that a little bit later that the service class provider either accepts or rejects that association based on what was provided and then once that association is established you've got that channel of communication in this case we're doing at C fine so that

client makes the C find request for the data that it wants and then the server is that the SCP is responding with all of the C fine records that match whatever the client had requested it sends that final one with special flag to indicate that it's done and then that association it can be closed and so there's kind of a session that happens as part of that referred to as an association cool and so let's dive into that association process your security minded so you're probably thinking what's going on here so there's three items that a service class user is sending with that Association process so the first is the called application any title basically it's a 16 character host

name that's configured when the SCP is set up the service class provider the server is set up and so that is has to match the client sends it and that that has to match with what the client had said so you're talking to the right person and then the calling application any title is also specified you have to identify yourself with your own host name your application and adhi title or AE title and then finally the presentation context is it's basically the data format it's what operation you're going to do on the server to make sure that the server can support it and then based on those three fields the service class provider responds with and

accept or reject those are the three things that are said you may be thinking where's the authentication we're talking about host names well that's not built into DICOM so this is that basically the only authentication that happens for a DICOM association is a check to make sure that the called application any title so that the client knows who it's talking to the host name it matches the application ID title that was configured when the service class provider was set up you know the host name of the server you're talking to in some ways and then sometimes that calling application any title how this how the client is identifying itself is checked against a list of recognized devices so below

here's the class from an open source now-defunct pack server called a clear canvas here's the class association verifier and you can see that what's doing at the comment there is mentioning that it's checking against a list of configured calling application and any tiles to make sure that it's a device that it knows it's talking to so we now know everything we we now know everything to set up an association and start querying a server so what does that look like this is using a Python library a an API for DICOM called pine net DICOM for the the network protocol we're gonna query a patient name of star so matching any patient record that the server has we're gonna initialize our a

title with with a a e title of hacker obviously the server isn't checking that calling a title in this case and we're gonna call that Association or the server with an AE title of gateway and so let's say that Gateway matches the configured SCP what it was set up with that application any title is valid so the server will respond and then if printing the records as we receive them here's what that might look like so there's three different patient records since those all match star that the server will respond with every record that it has for patients so AE titles are the main portion of authentication on for DICOM so kind of how realistic is

it to guess in AE title well it turns out that these aren't really passwords sixteen characters for a password alphanumeric doesn't sound too bad but consider that these are often made to be readable and recognizable by someone that's looking at it so human readable so they're configured with names like one medical if that's who your client is or one medical - four six seven eight nine if that's if you want to add some random values at the end to make it a little bit harder to guess or they're configured with default values so Gateway could be the AE title for your DICOM gateway the router that we talked about or you have something like find

seu for the service class user that's doing a CE fine so some kind of default values also it's you may want to find a way for on the web portion of your pack server in order to easily disambiguate between different clients let's say you set up a DICOM server and you have a hundred clients that you want to send records to that server has some route images to the correct place so what you can do is configure a hundred different application any titles that are all valid for your DICOM server but route to different clients so it's it's slower lowers the attack service for what you can actually pull from records if you're able to guess one of those but now

you're you're the ability to brute force now you have basically a hundred valid passwords almost in your system and then let's say you have the web UI portion where doctors actually have to go in and select different information in order to let's say they're logging in they have to figure out which client they're authenticating to so what what I've actually seen what we've actually seen during some testing is that some PAC servers will actually expose the application any titles to that web UI sometimes before authentication so you just have to select the application any title that you want to log into before you authenticate and so the attacker right away could get a list just by browsing to

your packs web server of every valid application any title for your system so that can be that can cause definitely problems for associating or of course you just forget to check them at all so there's this research done at in September of last year of some Australian researchers that were able to pull out a DICOM Records with that we're not checking applications any titles at all and we're left exposed completely on the internet so they were just able to download some DICOM viewing software download all the images look at all the patient information and look at all those images in daikon so let's say you've come across the daikon server you're either able to guess the

application any title or it's just sitting on the Internet exposed and you kind of want to see what it can do well it turns out DICOM doesn't have a nice little help function so there's no when you're talking to a daikon server there's no way to just get it to spit out what operations it supports so you end up having to make requests to - with all the things that you want to do and the and what see whether or not your association was accepted or rejected and that happens that negotiation happens during that that third field in the association that presentation context hopefully pie net DICOM has a dictionary it has a built some built-in

presentation context which are basically lists of actual operations so they're more human readable it's things like move presentation context or store presentation context where they correspond to the actual composite operation that you're trying to do so you can actually use those and in a simple Python loop just request six or seven I think there's 16 in total actually if you want to enumerate everything send though that many Association requests see if you can see which ones are either accepted or rejected by the server and that's how you know what operations you can actually perform on that server so see find is obviously dangerous that's the way you can query patient records if you are configuring a DICOM server o or a

PAC server setup on the internet you do not want to find so let's restrict that DICOM allows you to restrict certain operations look only allow c-store what could go wrong let's talk about DICOM files that's the second half of the daikon protocol and it's both a network and a file protocol this is the header of a daikon file basically all a daikon file is is a JPEG image with kind of a fancy hat a nice header there that's got some metadata information about what the image was actually taken so this is generated by your modality so let's say we're taking an x-ray image the the the provider that would take that image beforehand would enter in the patient ID from their

electronic medical record system their name their own the physicians name that's doing the the study they would enter the series number some IDs that can tie multiple images taking a single session together so that the PAC system can take ten different images asynchronously and then tie that into one single DICOM study so you can kind of see a time lapse of different images or different angles across the body so that's kind of how the DICOM file protocol works if you put on your offensive security hat for a second you you can see that these are generated by a machine usually but they are user generated value so potentially ripe for injection attacks especially for web

frameworks that may not expect DICOM information to actually be user controllable if you're developing a PAC system you may not realize that you have to actually sanitize user input that was pulled from a daikon study because you implicitly trust the devices that you connect your medical devices that connect to the system the only thing that can route to it so let's dig into cross-site scripting as an example we're gonna use pine net DICOM which is a sister library of we're gonna use pi daikon which is the sister library phenom pine net daikon to work on files this is how you can use it we're gonna open we're gonna download a file a test file from daikon library we're gonna

read that file in we're gonna set that modality which is the the identification this would say like x-ray or CT for the different device that's our identification we're gonna set that to our cross-site scripting payload next we're gonna save that file make sure that actually gets written to disk before we send it off to the server so with just a few different method calls we've got our malicious daikon file next we're gonna use an open source tool called DCM TK we're use the store as the use of a c-store a service class user we're gonna call the server AE because we've guessed the AE title or it's not checking in this case just local oats

but we're gonna upload that file that tests d kea DCM file that daikon malicious daikon file the association is valid and so the c-store request completes successfully now we're gonna look at it on the provider side so let's say this is our open source defunct PAC system called clear canvas we're gonna login with our super secure credentials admin admin we're in we're gonna ignore that last class we can remember that one we're gonna search for for new studies that came in maybe this is our queue we double click on it and then that that payload file fires so cross-site scripting we've bypassed all that authentication we haven't had the brute force any any providers if there was to

if a configured which this server allows you to do we bypassed that great so let's talk about some kind of lessons learned and next steps let's say you you've set up an x-ray device on your network and you protect that you you can make sure that it can only send to valid so no one can send can create a reverse shell on that and send back to their own systems the only thing you can talk to you is your PAC system well clearly you're not entirely safe because you can upload malicious daikon files to that with injection payloads that get routed make you have to make sure that your your PAC server is actually following

following OS 10 best practices and make sure you do your due diligence when choosing a PAC system in order for your providers to log in and do their in their data we talked a lot about DICOM and authentication it's worth noting that in the new versions of the DICOM standard that there's this new concept called a user identity negotiation where it's they've kind of realized that a titles don't aren't really authentication and they don't want to instead of building something on top of it here's something that the protocol actually supports you can actually use a Kerberos server stick or sam'l assertion if you have SSO configured in order to log in and send images to your to your DICOM server so

you can have your you can have your x-ray authenticate to single sign-on as a machine account and then before it uploads the server remember though if you're using a username or just use name and passcode I'm not sure how much I would trust my medical devices that I've set up to actually store user name and password securely or in a way that those devices don't get compromised so as much as you can abstract and remove that authentication piece so that no actual pass codes or hard-coded data is stored on your actual medical devices the better and then finally a note for all you blue teamers out there understand what protocols are on your network dicot

if you're configuring a hospital network.com may be missed or not monitored by your tools so make sure that you're you're actually your tools can interpret DICOM and look for malicious activity if your server suddenly starts sending see fine responds with every single record potentially you have problems so make sure that you're actually monitoring those networks just make sure you're not logging patient data in your logs and storing those unencrypted just make sure Hiep you all your best practices are followed with those logs because again this is a pH I that you're dealing with here protected health information so there's higher standards long around those great thank you [Applause]