Securing Connected Healthcare Devices: Risks and Real-World Attacks

good to go yeah all right cool so our next speaker here is to tell a tale of two connectedness medical devices please put your hands together for sourabh and he is off you go everyone thank you for showing up before I start I just want to give a quick shout out to be fetch Toronto for the opportunity to present today I'd also like to give a shout-out to one of my friend Technic Tulowitzki also contributed to the three search but it couldn't be here today all right P Nick I am sort of I work at many and and much like everyone else these days I'm also a rare Timur also a wannabe reverse engineer and for all the recruiters in

the house I'm also all those fancy things this is what the agenda for the talk looks like time filler time filler time filler history one case study two time filler it's a start off with a small introduction to connected medical devices I'll talk about the architecture and workflow some real world attacks of the medical devices followed by the case studies of two case studies where I'll talk about the well images be discovered and two different connected medical devices followed by the closing remarks I know I only got 25 minutes the presentation on my laptop was more updated because I removed a few slides so I'll just walk through them because I had to like pull it out from the USB

Drive which isn't updated before I start one who have the disclaimer up there this talk is not about bashing anyone so I won't be naming any vendors or devices during the talk and I apologize for heavily redacted screenshots that might put CIA to shame also these devices are widely deployed in a lot of financial institutions so there's another reason also I got contacted by FDA and FBI before my last talk at blackhat so that's another reason I've tried to classify medical devices here and in five different categories so the first category you'd be most familiar with it so your fitness activity trackers sleep pattern monitors would fall in the first category and certain their patient

monitoring devices like insulin pump BP monitors heart rate monitors ECG glucose monitors then there are an IV D or in vitro devices that comprises of HIV detection system blood analyzers and all the devices that I've talked about so far they are usually external to patient's body hopefully and then there are devices that are embedded in patient's body and the most common example would be a pacemaker and then there are these huge bulky stationary medical equipments that you see lying around at the hospital like medical dispensing system MRI x-ray machine CT scanners these devices are also referred to as legacy medical devices they were never meant to be connected to the network but people are thinking they're

connecting everything to the network might not use to my sister all right so I just talked about how some devices are never built to connect to be connected to the network or Internet and so and all these devices are being connected to the network using fetal to Ethernet converters and and that's a terrible terrible idea these devices they communicate over the fetal communication port which doesn't have any security built into them in fact Department of Homeland Security last year they shouldn't alert against one of the most commonly used field to Ethernet converters called end port they're developed by a company muktha and so they were like fewer limiters ever disclosed first one was that an attacker

could extract sensitive information from these devices i'm not indicated and of course remotely the other validity would allow an attacker to downgrade or operate the firmware also unauthenticated also remotely and as if that was not enough there's not the third buffer foal buffer or oval immunity which would allow an attacker to achieve remote code execution remotely as well so a terrible idea to use these devices and if you must use these devices then it's better to lock them down I'm not sure if you remember the unscheduled power outage that happen in Ukraine in 2015 that was also caused by some attackers corrupting the firmware on these devices remotely all right so jump on to case study one so

the first device that we looked at was an infusion pump an IV envisioned form is usually used to inject fluid medication nutrients into pastéis body in a controlled manner scottson safety features built into it so you can serve you can set soft and hard limits so for example your doctor could set a hard limit one morphine 400 milligrams and once that is that if a patient want to inject more morphine and they can't they used to be standalone devices but they're now connected to to the network all right so I've tried to lay out what a typical workflow of an insulin pump would look like so it's usually connected to the hospital's private network using Wi-Fi or Ethernet

it talks to different subsystems on the hospital network primarily to a pump there and the pump server is a server that stores stores different configuration information like patient name what what medication would apply to a particular patient in what proportion for an in support this is typical for medical devices that they are usually maintained by the manufacturers so the IT technicians at the hospital usually do not have a lot of access to the medical devices sort of like a black box to them because they're heavily maintained by the manufacturers themselves and to do that manufacturers may gain access to the device via VPN through the hospital's enterprise gateway so to start with in our lab

setup we only had the infusion from we didn't have a pump server it wasn't connected to a network it didn't have any real-world data so we make some initial observations so it had capability to connect or Ethernet or or Wireless had a USB port also an irda port it had a touchscreen display pad a keypad and there was also a maintenance mode don't we found out as soon as we found out about the maintenance hood I frantically started googling looking for any manufacturer's guide to see if there's a default password somewhere and surely there was and and because no one ever changes both paths but that's just too difficult to do that worked and so

we we gain access to the maintenance mode it was like it was a lot more restricted mode than I hoped for so we could access some configurations we could change a bit of configurations but not really a whole lot there was an option to upgrade or downgrade the firmware but I'm not that technical so I didn't go that route all right so one of the things we saw that because it was just a stand standalone device at the point of time the next step for us was to connected to our own wireless network in the lab so we spun up a wireless access point gave it the same ap name as configured in the infusion pump

configured it to the same security settings but obviously it didn't connect because the wireless settings on the infusion pump had a username and password configured which we didn't have and I surprisingly the maintenance mode also did not give me the option to change I change the username and password but we did see an option to export the network configurations on the medical device through IR diem so we went on eBay the gift that never stopped giving and bought a PDA I think we bought it for 15 bucks or something so the idea was to get the PDA to talk to the infusion pump over the IRDA and and see if we can exchange some data

so we bought the PDA we brought it back to the lab environment and we were able to connect to the infusion pump easily no authentication required there just a bro code and it worked and so and so what we did was after that we beamed the settings from the infusion pump to the PDA and we were like so excited at that point of time as soon as it was done I opened up the settings in the in the Notes app of the PDA and well it was blank so someone from the manufacturing side I guess figured that it's not a good idea to exploit sensitive data to a foreign device so that's good of them

but we hit a dead end at the point of time so at that point of time we were just sitting with this blank template but just didn't have any information and you know how the same and life gives you lemons make lemonade so we did what you usually do to a template we filled it we filled it with our favorite network setting wireless settings we gave an own ap name our own username and our own password security settings and all that and then we beamed it back to the infusion pump and we had no hope out of everything that had to work or that didn't work this worked so when we beep it back to

the infusion pump it overrode the settings of infusion pump from the setting of our template go figure so yeah so really happy that work did not expect it to work but now at this point of time we were happy because infusion pump was connected to our wireless network so we made some more observations at the point of time we noticed that it had telnet FTP and SSH enabled we tried to brute force login that didn't work I think we need a better word list we also noticed that as soon as it connected to the wireless network it started looking for a pump server and from previous passive research we knew that infusion pumps usually talk to a pump server so no

surprises there but the problem was that we did not have a pump server in the lab environment so we spin up a virtual machine gave it the same net bias name as describe was looking for and spun it up let it girl install Wireshark on it or also netcat so at that point of time we started getting some some traffic from from the infusion pump so we saw that the initial packet was had a propriety protocol but was loosely based on XML I'm livin easy to decipher we got information like pump leader number current time wireless access point data IP Mac information maintenance to you date at the end there was a checksum after awhile we figured

that it was just an exploding checksum so it was easy to spoof so we wanted to automate the process of fuzzing so we quickly wrote a Python script that would sit and act as like an application server or on pump server received messages from the infusion pump and so we could analyze the traffic and then send start sending different kind of responses back to the infusion time you see what happens she has many many many hours to go through this process many different iterations but we started figuring out that there was a pattern to it started deciphering the packet information from the packets that were coming from the infusion pump and what kind of response

would it be would it be expecting so we we figured a different different message type so there was message type 2 which basically confirmed to the pump that you are now connected to the pump server then there was mrs. type 7 and 31 we're not really sure what they are then there's message type 8 and when you send message type 8 after or followed by message type 2 it changes the status of the infusion pump from none to receiving so at this point of time you might modify an existing packet and send it back to the infusion pump and to override some settings on the infusion pump message type 20 with network commands we're still working on it I

think there's something interesting there but not really sure what it does and then there's methods type 2 0 8 and 2/3 it was not sure what they are so during this whole process we we found a winning package so essentially when we sent a message type 2 followed by method type 8 we got this packet from the infusion pump and a lot of data is redacted but if you can see I've highlighted there are several headers there so there's a drug named drug the dosage in there you can see the care area and the patient location route site caregiver information and all the information and some of the information is blank here because our infusion pump did not have

any data but in a real world scenario where this is deployed and as you use all that information will be in there and once you once we capture this packet you can also overwrite data on this packet and then push it back to the infusion permanent will overwrite settings so we thought that was kind of cool the other thing we were able to get was get access to master drug list and this is no joke because master drug list on an infusion pump has information like what patient will get what drug in waters edge what proportion you can also overwrite this often hard limits which basically defeats the whole purpose of safety measures on the infusion pump

which we thought was not cool so anyways these were some other empties that we discovered in the infusion pump I think we're still working on it on and off to update the presentation if something else comes up so just move on to the next case re alright so the next device we looked at was a digital pen the medical practitioners and doctors use it to write prescription so they would use uses pen to write prescription on a special paper which would then be transmitted to the pharmacy so you can think of it as just a glorified fax machine the benefits they say are that by the time you reach a pharmacy you're they would have already received your

medication and then would have gotten ready these kind of pens are manufactured by different manufacturers we only looked at one device from one manufacturer and this is not the right picture for anything the workflow wife is connected to us but it's private network either on through Ethernet or Wi-Fi and then it breaks out using the hospital's entrance gateway to the cloud on the cloud side there are three components that was a web portal where patients could log in manufacturers could log in doctors could log in there's an application server and a database server as well right so initial observation we found out that the pen itself was running Windows 10 operating system or at least it wasn't in the

seven it came pre-configured with two different accounts one was for nerds physician and this is the account what your medical practitioner would use when they use the pen and then there's an admin server account which the I suppose would be used by manufacturers to to update the device and make any changes to it and I'm the other person who used that account then it also had a USB port capability to connect over Ethernet and Wi-Fi hdmi vga digital display audio port it came with fully updated windows to Windows Defender there was also a docking station so you could dock the pen on it it'll charge and there's also a software layer which comprised of two

applications that came from the manufacturer Youth kissing Aereo I just talked about it it'll depend would typically be deployed at a nurse's station doctors can carry it around when they go see the patient they can write the prescription to the special paper at the time of writing if the pen is connected to the internet it will transmit the data to to to the portal in the real time and if it's not connected to the Internet it will save that prescription in an encrypted manner on the disk itself and then it will be transmitted to the portal when it connects back to the Internet the data was transmitted over the wire that was protected as a cell so there wasn't

much there there was also a remote access component to it so when you boot up the pen because it had HDMI and USB ports you can connect a monitor to it you can connect mouse and keyboard to it and it boots up automatic so you don't have to login it automatically boots up into into Windows 10 using the D nurse account which is a lot more account so thinking from a typical pentester perspective my first goal was to escalate privileges on it for that we get local administrator access so that we can do much more with it so we looked at different avenues looked at different exploit codes that are out there for Windows 10 none of

them really worked we didn't have privileges to start or stop any of the services that were deployed but then we found this burn service which is actually from the manufacturer from one of the two applications that a manufacturer has and so although we couldn't start a stop this particular service we were able to over write the binary service binary on the on the disk so we created a malicious binary which had a simple payload which would create a local administrator account replaced it with the binary and then just rebooted the pen because we couldn't restart the service which is people if the pen and so that that work at it got executed and it created a local admin

account and at this point of time we had admin access so we can we could do a lot of things we could install tools on it so we installed Wireshark initially to start looking to started to look at the network traffic but like I mentioned the traffic is encrypted there wasn't much in there the next thing we did was we installed Windows System internal utility so specifically proc Mon and so if you've worked with proc Mon you would notice that it generate tons of tons of queries it captures a lot of traffic and although you can create filters to just capture queries from one particular application it still you end up with a lot of data so went

through the different logs that came different the capture from proc Mon it took a lot of time but like one thing we noticed was that the application would query something called a dot E&C file and yeah query this files if we look at this file and we figured that it would be an interesting triplet file and we verified it because I opened it in notepad and it was garbage so so definitely an encrypted file so as I mentioned before I'm a wannabe reverse engineer so that was my chance to reverse engineer so I put ollie debugger on to the Windows 10 operating system the system level debugger doesn't read any installation so that worked well for

us so essentially what the application was doing was that it would open this start ENC file and read certain contents and then exit so after doing some dynamic and Static reverse engineering found out that the block on your left is it's the code basically that Sheik rips the file so start in reverse engineering this logic of decryption once I had that down created a simple Python script that will just simply dictate the file decrypt the file and then copy the contents to to a different file for the few it later again heavily redacted file so it had a bunch of data in there but most importantly there was a database string in there so there was a there was

host name for my sequel database username as you can see the username is root which is the highest privileged user password in there and so we thought okay like maybe this file is redundant that aren't really using it and then even if they are there's no way to expose that database to the internet but like I had to do an nmap run it so and indeed they were like exposing it to the Internet and even at this point of time I'm thinking this is feeling more like those osep CTF type things where like they want you to think that there's a validity but it's not really there try to connect to the database and a network

and so at this point of time we had the leg when I started looking at the pen without like okay this looks like this doesn't do much in the worst case scenario I'll probably just be able to grab one or two prescriptions off the hardest and that's the most I can do and then with access to the database server where you can basically gain access to the patient data from all the medical institutions where the Pens are deployed and not just where our test ban was so like all over so there was tons of data in there so again the data is redacted but if you look at the headers of the table there is patient code there's

there's patient first name patient last name date of birth gender of the patient we found another table that contained the username username email password in plain text for the portal cell and then there's something called the roll code which basically tells if the user is just a patient a doctor manufacturer administrator so we grabbed we grabbed one of the manufacturers and logged on to one of the facilities or one of the healthcare institutions as manufacturer and again we can pull out data like present name your unit that home address room number SCN is the health card number for that particular patient so like ending thousands of records in there and finally we were also able to

pull out all the prescriptions that were written by the doctors for for all the patients across all the medical institutions right so these are some of the findings we found in these two medical devices as a closing remark they're pretty generic I think there's a lot of rush in getting the medical devices or IOT or Internet connected devices out to the market and so like what happens happening is that they're just bolting security on to them and if they're not building into the security hospitals already have a lot of connected medical devices and that's only going to grow so as long as like if they continue to trust those medical device which are connected in the network it's

going to create more and more threat scenarios for the hospital networks FDA has started to do quite a lot in terms of regulations for medical devices but also we also need to go beyond regulations to really make sure that those devices are secured so like one of the things with medical devices s but FDA regulations once the device is approved by FDA and deployed in a hospital you can't modify that device so even if you know that there's a t fault password you can't really change that password because the device might behave in an unintended manner so whatever the reason might be behind that but that leaves IT technicians at the hospitals with kind of a black box black box and

they can't really do much about it and now the funny buddies that I really talked about today are really zero days they're all known molarity is like we've already gone through with all these issues with with verve applications are the hardware's and so on so I think it's just it'll be easier to just learn from past mistakes and then while building a new products and that's it for me thank you

any questions am I on time okay thanks everyone [Applause]